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

> Le développement piloté par l'IA a changé notre façon de livrer du code. Pour garder une revue rapide et une qualité élevée, proportionnez l'examen au risque, préférez les preuves aux affirmations, et concevez des déploiements qui rendent les erreurs peu coûteuses.

Source: https://www.bluewise.fr/fr/code-review-at-ai-pace-earning-the-right-to-read-less  
Author: Marc Morel  
Published: 2026-09-15  
Category: Engineering  
Series: Code review at AI pace, part 2

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 :

```ts
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](https://x.com/unclebobmartin/status/2080257779395154409) 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](https://startupfortune.com/uncle-bob-martin-says-he-no-longer-reads-ai-generated-code-and-the-developer-world-is-split/) 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](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-14) 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.