La revue de code au rythme de l'IA : proportionner l'examen au risque

Quand écrire du code a cessé d’être la partie difficile

L’IA a rendu le code bon marché à écrire, donc c’est désormais à la revue que la vitesse se gagne ou se perd. La réponse n’est pas de relire moins, mais de relire avec discernement : proportionner l’examen au risque, et demander à chaque modification de faire ses preuves.

Un ingénieur accompagné d’un agent de code peut ouvrir cinq pull requests avant le déjeuner. Les recherches de DORA nomment bien la tension : une adoption plus forte de l’IA apporte à la fois plus de débit et plus d’instabilité, et les heures gagnées à écrire du code sont souvent réinvesties à le vérifier.

Valider les yeux fermés érode discrètement la confiance. Tout relire à l’ancienne transforme la revue en salle d’attente. Il existe un meilleur chemin pour toutes les personnes impliquées, fondé sur trois idées : un examen proportionné au risque, des preuves plutôt que des affirmations, et des déploiements qui rendent un bug manqué peu coûteux.

Cette première partie traite de la première idée : qui relit quoi, et avec quelle profondeur. Les deux autres, ainsi que les arguments pour ne pas lire le code du tout et ce qu’exigent les régulateurs, suivent dans la partie 2, Mériter le droit de lire moins.

Trois niveaux de sensibilité

Chaque modification reçoit un niveau avant que quiconque ne la lise : les machines relisent le risque faible, une personne relit le risque moyen en quelques minutes, deux personnes relisent le risque élevé en profondeur.

	Niveau 1, risque faible	Niveau 2, risque moyen	Niveau 3, risque élevé
Mode de revue	Entièrement automatisé	Revue humaine rapide	Revue humaine approfondie
Modifications typiques	Textes et traductions, documentation, mises à jour de patch de dépendances, configuration derrière un flag désactivé, modifications de tests uniquement, outillage interne	Nouveaux écrans d’interface, endpoints d’API non critiques, refactorings au sein d’un seul bounded context, nouvelle fonctionnalité derrière un flag	Paiements, authentification et autorisation, données personnelles ou financières, prix et frais, migrations de schéma sur des données partagées, cryptographie, reporting réglementaire
Rayon d’impact	Cosmétique ou nul, réversible instantanément	Une fonctionnalité ou une équipe, réversible avec un flag ou un rollback	Argent, données clients, conformité ou plusieurs équipes ; difficile voire impossible à annuler
Qui approuve	Les barrières de CI et un relecteur IA, puis auto-merge	Un relecteur humain de l’équipe propriétaire	Deux humains : un responsable du domaine et un ingénieur senior ou principal
Preuves obligatoires	Pipeline au vert, revue IA sans constat bloquant	Preuves du niveau 1 plus preuve visuelle pour les modifications d’interface et un bref résumé des tests	Preuves du niveau 2 plus note de conception, modèle de menaces, plan de déploiement et de rollback, preuve d’observabilité
Délai cible	Quelques minutes	Dans la demi-journée	Planifié, généralement 1 à 2 jours

Ces preuves voyagent sous forme de proof pack : les captures d’écran, traces et rapports de tests que le pipeline joint à chaque pull request. La partie 2 montre comment en construire un.

Break-glass : une quatrième voie, réservée aux incidents. Quand la production est en feu, le chemin normal est trop lent, et une équipe sans raccourci autorisé en inventera un non autorisé. Le break-glass rend le raccourci explicite, étroit et visible :

Lié à un incident déclaré. La voie ne s’ouvre qu’avec une référence d’incident, jamais pour une fonctionnalité urgente ou une échéance.
On saute la file, pas le pipeline. Le build, les tests critiques et les scans de sécurité s’exécutent toujours. Ce qui change, c’est l’approbation : un approbateur qualifié de la rotation d’astreinte, ou deux personnes en binôme en direct pour un domaine de niveau 3.
La plus petite correction d’abord. Basculez le flag ou faites un rollback avant d’écrire du nouveau code ; une correction en avant sous pression, c’est là que naît le prochain incident.
Des droits qui expirent. Les permissions de break-glass sont accordées pour l’incident et révoquées à sa clôture, et chaque usage est journalisé avec qui, pourquoi et quel incident.
La revue a quand même lieu. Dans un délai d’un jour ouvré, la modification passe par son niveau complet, preuves comprises, et toute suite est traitée comme une modification normale.

Comptez les usages du break-glass chaque mois. Un nombre en hausse est un signal, soit de problèmes de qualité en amont, soit d’un chemin normal devenu trop lent pour qu’on lui fasse confiance.

Laisser le pipeline décider du niveau

Le niveau est calculé à partir du diff ; les personnes peuvent le relever, jamais l’abaisser discrètement.

Tenez une cartographie des risques sous forme de code à côté de vos règles de propriété : des motifs de chemins pour payments/, auth/, ledger/, les migrations, et tout ce qui touche aux données personnelles ou de carte. Une vérification de CI applique la cartographie à chaque pull request et publie le niveau comme statut requis, de sorte que la protection de branche impose d’elle-même le bon nombre d’approbations.

[contenu intégré : routage par niveau · 2 décisions, 3 niveaux, escalade uniquement vers le haut]

Un chemin critique signifie niveau 3 ; toute autre modification du comportement à l’exécution signifie niveau 2 ; le reste est niveau 1. Une taille importante, de nouvelles dépendances, des modifications de schéma et des migrations de données irréversibles font monter une modification d’un niveau.

Deux règles maintiennent l’honnêteté du dispositif. N’importe qui, relecteur humain ou IA, peut escalader, tandis qu’un abaissement nécessite une décision journalisée du responsable du domaine. Et la cartographie des risques est elle-même un fichier de niveau 3, parce que celui qui la modifie décide de ce que tous les autres peuvent sauter.

Déplacer la revue du côté de l’auteur

La revue la plus rapide a lieu avant l’ouverture de la pull request : l’auteur, aidé par des agents, remet une modification petite, pré-vérifiée et facile à lire.

C’est le plus grand changement de 2026. Au lieu de diriger l’IA vers la file du relecteur, dirigez-la vers la boucle de l’auteur, là où un constat coûte quelques secondes à corriger. DORA recommande exactement cela : fournir le retour de l’IA à l’auteur pendant l’écriture, pas au relecteur après coup.

Une auto-revue avec un agent d’abord. Lancez une revue IA locale avant de pousser, comme /code-review dans Claude Code ou Copilot dans l’IDE. La pull request arrive avec les constats évidents déjà traités.
Une intention par pull request. Quand un agent produit une modification tentaculaire, découpez-la en pile : le refactoring mécanique d’abord, qui tombe en niveau 1, puis la modification de comportement, désormais assez petite pour une vraie revue. Les stacked pull requests natives de GitHub, en preview publique depuis juillet 2026, rendent cela indolore, pour les personnes comme pour les agents.
Un guide du relecteur en deux lignes. Commencez par le service ledger ; les douze autres fichiers sont un renommage. Une phrase comme celle-là peut diviser le temps de revue par deux.
La question du risque, traitée d’emblée. Chaque description dit ce qui pourrait mal tourner, et comment nous le saurions.

Niveaux 1 et 2 : une touche légère, un vrai soin

Les modifications à faible risque sont fusionnées sur automatisation au vert ; les modifications à risque moyen ont un relecteur pendant une quinzaine de minutes, preuves d’abord.

Le niveau 1 empile les machines. Les barrières déterministes passent d’abord : build, tests, analyse statique, détection de secrets, politique de dépendances. Puis un relecteur IA lit le diff avec le contexte du dépôt. Les relecteurs multi-agents actuels, comme Claude Code Review, la revue de code de GitHub Copilot, CodeRabbit, Greptile ou Qodo, vérifient leurs propres constats avant de les publier, ce qui limite le bruit. Briefez le vôtre avec vos conventions écrites, et demandez-lui de contester le niveau autant que le code. Tout ce qui est fusionné automatiquement apparaît dans un digest quotidien, et une modification sur vingt est lue après coup : cet échantillon vous dit si vos frontières sont au bon endroit.

Le niveau 2 suit chaque fois le même chemin court :

L’intention. Est-ce la bonne modification pour le problème ? Un cache devant un endpoint lent peut cacher un endpoint qui exécute quarante requêtes par appel.
Les preuves. Les captures d’écran et la trace correspondent-elles à l’intention ? Les tests vérifient-ils un comportement qu’un utilisateur remarquerait, ou se contentent-ils de refléter le code ?
Les cas limites. États vides, chemins d’erreur, retries, un utilisateur qui double-clique. Le code écrit par l’IA est souvent excellent sur le chemin nominal et discrètement naïf partout ailleurs.
Décider. Approuver, demander des modifications ou escalader. Le silence n’est pas une option.

Les commentaires indiquent leur poids, bloquant, suggestion ou détail, et sont formulés sous forme de questions quand c’est possible : que se passe-t-il si ce webhook arrive deux fois ? enseigne davantage qu’un verdict. Un commentaire écrit deux fois devient une règle de lint ou une ligne dans les instructions du relecteur IA, jamais un troisième commentaire.

Niveau 3 : en profondeur là où cela compte

Les modifications critiques ont deux relecteurs préparés, une discussion de conception avant tout code, et un rollback répété.

C’est là que le temps gagné ailleurs est réinvesti. Dans les paiements, l’authentification, les données personnelles ou la tarification, un seul défaut coûte de l’argent, de la confiance ou l’attention d’un régulateur.

La conception avant le diff. Une note d’une page tranche le flux de données, l’idempotence et ce qu’il advient de l’argent en transit quand une dépendance dépasse son délai. Pour un agent, cette note sert aussi de spécification.
Deux regards. Le responsable du domaine vérifie les règles métier : arrondis, devises, états de remboursement et de rétrofacturation, piste d’audit. Un ingénieur senior ou principal vérifie le système : cohérence, retries, rayon d’impact, défaillance partielle.
De la patience pour les portes à sens unique. Un contrat public, un modèle de données ou une migration irréversible mérite le chemin lent ; une modification réversible derrière un flag, non.
Un petit modèle de menaces. Qui pourrait abuser de ce chemin, et quel contrôle l’en empêche ? Pour les modifications d’autorisation, le proof pack montre les requêtes interdites refusées.
Une preuve à la fidélité de la production. Logs, métriques et événements d’audit d’une exécution en staging sur des données réalistes. Dans les contextes régulés, signez le proof pack comme attestation de build, pour que la preuve elle-même rejoigne la piste d’audit.
Un déploiement validé par les relecteurs. Comptes internes d’abord, puis un pour cent du trafic, avec un arrêt automatique si les taux d’autorisation passent sous la référence.

Pour les plus grosses modifications, trente minutes de présentation en direct remplacent souvent trois jours de fils de commentaires.

La suite

La partie 2 de cette série, Mériter le droit de lire moins, explore comment rendre une revue plus légère sûre grâce à des proof packs fondés sur les preuves, des déploiements qui contiennent les erreurs, et un apprentissage continu par l’analyse des incidents. Nous verrons aussi ce qu’exigent DORA et PCI-DSS, comment s’aligner sur les standards existants, et comment construire un système qui suit le rythme du développement piloté par l’IA tout en maintenant sécurité et conformité.