La revue de code au rythme de l'IA : mériter le droit de lire moins

La partie 1 a classé chaque modification dans trois niveaux, pour que l’attention humaine aille là où est le risque. Cette partie répond à la question qui suit : qu’est-ce qui permet aux humains de lire moins en toute sécurité ? Deux choses : des preuves qu’une modification fonctionne, et des déploiements qui rendent un bug manqué peu coûteux. Viennent ensuite les limites : les arguments pour ne pas lire le code du tout, ce qu’exigent les régulateurs, et les signaux qui maintiennent l’honnêteté du système.

Des preuves, pas des affirmations

Chaque pull request porte un proof pack généré automatiquement, pour que le relecteur vérifie des résultats au lieu de reconstruire mentalement le travail de l’auteur.

Un relecteur qui doit récupérer une branche et cliquer à travers un parcours passe vingt minutes avant de se forger une opinion. Celui qui voit des captures d’écran avant/après, un rapport de tests au vert et une preview en direct en a besoin de deux. Pour du code écrit par un agent, le proof pack est la façon dont l’agent gagne la confiance au lieu de la demander.

Modification	Preuves que le pipeline joint
Visuelle ou design	Captures Playwright de chaque écran concerné, avant et après, desktop et mobile, clair et sombre, avec un diff au pixel
Parcours utilisateur	Trace ou vidéo Playwright du parcours, plus le scan d’accessibilité
Logique métier	Tests nouveaux et modifiés listés par nom, couverture des seules lignes modifiées
API ou schéma	Résultats des tests de contrat et diff du schéma, changements cassants signalés
Migration	Exécution à blanc sur un snapshot anonymisé de la taille de la production : durée, verrous, lignes touchées

Playwright est devenu l’ossature naturelle. Ses agents de test, un planner qui explore l’application, un generator qui écrit les tests et un healer qui répare ceux qui cassent, permettent à l’auteur de produire des preuves en même temps que la modification. Les snapshots ARIA vérifient la structure au regard de l’arbre d’accessibilité ; les captures d’écran attrapent ce que seuls les yeux remarquent :

test('checkout summary', async ({ page }) => {
  await page.goto('/checkout/summary?fixture=standard-basket');
  await expect(page.getByRole('main')).toMatchAriaSnapshot();
  await expect(page).toHaveScreenshot('checkout-summary.png', {
    mask: [page.getByTestId('timestamp')],
  });
});

La CI publie les images directement dans la pull request, et un environnement de preview par pull request permet au relecteur d’ouvrir la vraie application en un clic quand une image ne suffit pas.

La confiance dans le pack vient des détails : données à graine, horloges figées et horodatages masqués, pour qu’un diff ait toujours un sens ; des preuves limitées à ce que touche la modification ; des échecs affichés en haut, jamais repliés. Une mise en garde tirée de l’expérience : un test auto-réparateur qui réécrit une assertion peut cacher une vraie régression, donc les modifications du healer hors niveau 1 passent sous des yeux humains.

Rendre un bug manqué peu coûteux

Aucune revue n’attrape tout, donc chaque modification devrait être livrée de façon à limiter qui un défaut peut atteindre et combien de temps il vit.

Ce filet de sécurité est ce qui rend responsable une revue plus légère. Quand une modification peut être désactivée en quelques secondes et n’atteint d’abord qu’une petite partie du trafic, un bug manqué devient une note d’incident, pas une crise.

Pratique	Ce qu’elle vous apporte	Idéale pour
Feature flags	Le déploiement est séparé de la mise en service ; un kill switch désactive un comportement en quelques secondes, sans redéploiement	Toute modification visible par l’utilisateur ; les apps mobiles, où le rollback est impossible
Canary avec analyse automatisée	Une petite part du trafic atteint la nouvelle version ; erreurs et latence sont comparées à la version stable, et une dégradation déclenche un rollback automatique	Services et API des niveaux 2 et 3
Déploiement en anneaux	L’exposition s’élargit par étapes : personnel, clients partenaires, un pourcentage, tout le monde	Fonctionnalités à fort impact et modifications de niveau 3
Trafic miroir	Les vraies requêtes sont dupliquées vers la nouvelle version et les réponses comparées, sans impact client	Réécritures de moteurs critiques : tarification, grands livres, routage des paiements
Blue-green	Deux environnements de production, basculés d’un coup et rebasculés tout aussi vite	Mises à jour d’infrastructure et de runtime
Migrations expand and contract	Les modifications de schéma arrivent par étapes rétrocompatibles, pour que l’ancien code continue de fonctionner et que le rollback reste possible	Toute modification de données partagées

La profondeur suit le niveau, exactement comme la revue. Le niveau 1 est livré en déploiement continu avec rollback automatique en cas d’échec des health checks. Le niveau 2 est livré derrière un flag, via un canary. Le niveau 3 combine flags et anneaux et, quand un composant critique est remplacé, une période de trafic miroir d’abord, avec le rollback répété avant la mise en production. Les standards ouverts rendent cela moins cher qu’avant : OpenFeature donne aux flags une API indépendante des éditeurs, et des outils comme Argo Rollouts ou Flagger automatisent l’analyse canary sur Kubernetes.

Trois mises en garde. Le trafic miroir ne doit jamais rejouer d’effets de bord : bouchonnez le prestataire de paiement, l’envoi d’e-mails et tout ce qui écrit en dehors du service. Les flags sont de la dette, donc chacun a un propriétaire et une date d’expiration et disparaît une fois le déploiement terminé. Et sur les chemins critiques, basculer un flag est une modification de production à part entière, auditée et portée par la personne d’astreinte.

Quelqu’un doit-il encore lire le code ?

Arrêtez de lire le code là où le harnais peut prouver ce qui compte, et continuez de le lire là où il ne le peut pas. Ne pas lire le code ne supprime pas le goulot d’étranglement ; cela le déplace.

En juillet 2026, Robert C. Martin, l’auteur de Clean Code, a déclaré qu’il ne lisait plus le code qu’écrivent ses agents : « C’est la seule façon pour moi de tirer parti de leur productivité. Ce que je fais à la place, c’est entourer les agents de contraintes extrêmes. » Son parcours d’obstacles : tests unitaires et d’acceptation, mutation testing, couverture, limites de complexité et de taille de module, analyse des dépendances. Grady Booch a répondu qu’il continuait de tout lire, parce que les métriques montrent si le code fonctionne, pas s’il a ouvert une vulnérabilité ou enfoui une mauvaise conception.

Les deux ont raison, à propos de codes différents. La position de Martin est celle à laquelle mènent le niveau 1 de la partie 1 et les proof packs ci-dessus : une fois les vérifications assez solides, lire chaque ligne apporte peu et constitue l’étape la plus lente de la boucle. Mais quelqu’un écrit toujours les critères d’acceptation, décide de ce que mesurent les evals et maintient l’honnêteté du harnais. C’est de la revue sous un autre nom, faite une fois pour de nombreuses modifications au lieu d’une fois par modification.

Trois limites empêchent de l’appliquer partout :

Un harnais ne trouve que ce qu’il a été construit pour chercher. Le mutation testing prouve que les tests attrapent les bugs que quelqu’un a imaginés. Un contrôle d’autorisation manquant, un chemin d’injection ou une règle d’arrondi que personne n’a spécifiée passent une suite au vert, et ce sont exactement les risques du niveau 3.
Le harnais devient le code le plus critique que vous possédez. Une assertion affaiblie, un test ignoré ou un seuil relâché élargit silencieusement ce qui est livré sans être lu. Les modifications des tests, des evals et des barrières méritent plus d’examen, pas moins, pour la même raison que la cartographie des risques est un fichier de niveau 3.
Une pratique personnelle n’est pas un contrôle. La règle de Martin fonctionne pour ses propres projets. Dans une entreprise régulée, quelqu’un d’indépendant de l’auteur approuve la modification, comme le montre la section suivante.

La réponse pratique est un gradient : lire les garde-fous avant le code.

Niveau	Ce qu’un humain lit
1	Aucune modification individuelle : le harnais, le digest quotidien et l’échantillon post-merge
2	Le proof pack et les tests d’abord ; le code seulement là où les preuves sont minces ou surprenantes
3	La note de conception, les tests et le code lui-même, ligne par ligne partout où circulent de l’argent, de l’identité ou des données personnelles

À mesure que le harnais mûrit, davantage de modifications peuvent remonter ce tableau, de lues à non lues. Chaque passage doit être mérité via l’échantillon post-merge et les revues d’incidents, jamais décrété.

Ce qu’exigent réellement les régulateurs

Les régulateurs demandent le principe des quatre yeux, un approbateur indépendant de l’auteur, pas un humain sur chaque pull request. Les niveaux satisfont cette exigence, à condition que le chemin d’approbation soit lui-même gouverné.

Pour les entités financières de l’UE, la norme de gestion du risque informatique de DORA, le règlement délégué (UE) 2024/1774, fixe deux règles pertinentes. L’article 16 exige des revues de code source couvrant les tests statiques et dynamiques, avec un suivi des constats via un plan d’action. L’article 17 exige des procédures de changement dotées de « mécanismes garantissant l’indépendance des fonctions qui approuvent les changements », des garde-fous pour les changements d’urgence et leur approbation a posteriori.

Les paiements par carte sont plus littéraux. Selon l’exigence 6.2.3.1 de PCI DSS v4.0.1, une revue manuelle du code est effectuée par une personne autre que l’auteur, et la direction approuve la modification avant sa mise en production.

Obligation	Où elle se trouve dans ce modèle
Approbation indépendante de l’auteur (DORA art. 17(1)(b), PCI DSS 4 - 6.2.3.1)	Niveaux 2 et 3 : un relecteur humain qui n’est pas l’auteur ; la protection de branche bloque l’auto-approbation
Revue du code source, statique et dynamique (DORA art. 16(3))	Barrières du niveau 1 et revue IA sur chaque modification, constats suivis comme toute autre vulnérabilité
Changements d’urgence avec garde-fous, approuvés a posteriori (DORA art. 17(1)(i) et (j))	La voie break-glass de la partie 1 et sa revue dans un délai d’un jour ouvré
Procédures de repli (DORA art. 17(1)(h))	Flags, canaries et rollbacks répétés
Une piste d’audit de qui a approuvé quoi	Proof packs signés et décisions de niveau journalisées

Deux points demandent de la vigilance :

D’abord, l’auto-merge du niveau 1 n’a aucun humain qui approuve la modification individuelle, donc l’indépendance remonte d’un niveau : la cartographie des risques, la configuration des barrières et les instructions du relecteur IA sont approuvées comme des modifications de niveau 3, selon la même logique qu’un « changement standard » pré-approuvé. Écrivez-le, et convenez-en avec votre fonction conformité et vos auditeurs avant de l’appliquer à des systèmes dans le périmètre, comme un environnement de données de titulaires de cartes.
Ensuite, quand un agent écrit le code, l’auteur est la personne qui a piloté l’agent. Elle ne peut pas être aussi le vérificateur, et un relecteur IA ne compte jamais comme l’approbateur indépendant aux niveaux 2 et 3 : sa production est une preuve, pas une signature.

La règle de contrôle humain de l’AI Act européen est souvent citée ici, mais elle régit les systèmes d’IA à haut risque en usage, comme la notation de crédit, pas les assistants qui écrivent votre code.

Maintenir l’honnêteté du système

Une poignée de signaux détectent tôt les modes de défaillance habituels.

Surveiller	Signal
La dérive des niveaux : modifications découpées ou réétiquetées pour esquiver la revue	Part des modifications par niveau ; constats dans l’échantillon post-merge
La validation les yeux fermés	Approbations de niveau 2 en moins de deux minutes sans commentaire
La lassitude face aux preuves	Tests visuels instables ; captures d’écran approuvées sans avoir été ouvertes
La congestion du niveau 3	Délai entre la note de conception et le merge ; charge par relecteur senior
Les angles morts de la cartographie des risques	Incidents rattachés à leur niveau d’origine

Le dernier signal est le plus instructif. Chaque revue d’incident pose une question supplémentaire : par quel niveau est passée la modification d’origine, et aurait-elle dû être plus haut ? La réponse met à jour la cartographie des risques, et c’est ainsi que le système apprend.

Ce qui change

La revue de code au rythme de l’IA ne consiste pas à relire moins ; elle consiste à dépenser le jugement humain là où il change l’issue.

Comment commencer lundi : commencez petit

Écrivez vos trois niveaux et les chemins qui rendent une modification critique. Ajoutez des captures Playwright au pipeline d’une équipe et publiez-les sur chaque pull request. Activez un relecteur IA pour le niveau 1 et lisez son digest pendant un mois.

Puis écoutez vos revues. Vous devriez entendre moins de questions sur le quoi, et de bien meilleures sur le pourquoi. C’est le son d’une équipe qui fait confiance à ses preuves, et qui a de nouveau du temps pour les conversations qui font progresser tout le monde.