Il y a deux semaines, je vous parlais de ce que m'inspire la méthode de l'équipe Claude Code pour relire du code écrit par des agents. En préparant cet article, je suis retombé sur un texte plus ancien du même auteur, qui pose le décor : Agentic Code Review, publié par Addy Osmani le 15 juin 2026. Là où le premier article raconte une équipe, celui-ci prend du recul et pose une question plus large : à quoi sert la revue de code maintenant que l'écriture ne coûte presque plus rien ?

Sa thèse tient en une phrase, que je reprends telle quelle :

« the hard part of engineering moved from writing code to deciding whether to trust it »

La partie difficile du métier est passée de l'écriture du code à la décision de lui faire confiance. Je vous propose de parcourir l'argumentaire, de regarder de près les chiffres sur lesquels il s'appuie, puis de voir ce qu'une équipe web peut en faire concrètement. Précision utile : Addy Osmani travaille chez Anthropic, sur Claude Code. Sa biographie l'indique, et j'y reviendrai.

Ce que dit l'article : le goulot a changé de place

L'idée centrale est simple. Quand les agents rendent l'écriture bon marché, le travail ne disparaît pas, il se déplace : il faut désormais quelqu'un pour être sûr qu'un changement est correct. La revue devient donc la compétence la plus rentable d'une équipe. L'auteur insiste sur un point pertinent : la bonne profondeur de revue n'est pas la même pour tout le monde, elle dépend de qui vous êtes et de ce que vous construisez.

Le texte s'articule en huit parties : les données de 2026, les problèmes différents que chacun cherche à résoudre, à quoi sert la revue, les outils, la question de laisser l'IA relire davantage, une liste d'actions, les conséquences pour un responsable d'équipe, et une conclusion sur un constat que je trouve très parlant : écrire est devenu bon marché, comprendre ne l'est pas.

Des chiffres à manier avec précaution

L'article commence avec des données qui dressent un rapport inquiétant. Voici les principales, telles que l'article les rapporte :

  • Faros AI (22 000 développeurs, 4 000 équipes, données de mars 2026) : renouvellement du code en hausse de 861 %, rapport incidents/PR en hausse de 242,7 %, durée médiane de revue en hausse de 441,5 %, PR fusionnées sans aucune revue en hausse de 31,3 %, et PR d'agents en moyenne 51 % plus volumineuses.
  • CodeRabbit (470 PR open source, dont 320 coécrites avec une IA) : environ 1,7 fois plus de problèmes dans les changements assistés, avec environ 75 % de problèmes de logique en plus.
  • GitClear : les utilisateurs quotidiens d'IA produisent environ quatre fois plus de code brut, mais le gain réel par rapport à leur propre production antérieure serait d'environ 12 %.
  • Anthropic Code Review : moins de 1 % des remarques jugées incorrectes par les ingénieurs d'Anthropic, et une part de PR recevant une revue de fond passée de 16 % à 54 %.

Le résumé que l'auteur en tire est frappant : environ quatre fois plus de code pour à peu près un dixième de valeur livrée en plus, et la revue serait l'écart entre les deux. C'est une formule efficace. Soyons pourtant francs : beaucoup de ces chiffres sont de seconde main, issus de blogs d'éditeurs, de benchmarks ou d'expériences menées par un seul ingénieur. L'article lui-même note que CodeRabbit et Faros vendent sur ce marché et qu'il faut lire leurs études avec prudence, et il reconnaît qu'une partie de l'écart de GitClear pourrait venir d'un biais de sélection.

Je retiens donc la tendance plutôt que les pourcentages. Un code plus volumineux, relu moins sérieusement, avec davantage de défauts : c'est cohérent avec ce que beaucoup d'équipes observent. Mais citer « +861 % » dans une présentation interne sans préciser d'où vient le chiffre serait une erreur.

Trois variables pour savoir quelle revue vous convient

C'est la partie que je trouve la plus utile du texte. Plutôt que de prescrire une méthode unique, l'auteur observe que chacun résout un problème différent, et propose trois variables pour se situer :

  • Le rayon d'impact : que se passe-t-il si le changement est mauvais, et pour combien de personnes ?
  • La durée de vie du code : un prototype jeté dans trois semaines ne se relit pas comme un module de paiement.
  • Le nombre de personnes qui doivent le comprendre, aujourd'hui et plus tard.

Un projet personnel sans utilisateur peut différer la revue, mais pas la vérification. Le piège se situe au milieu : le projet gagne des utilisateurs, et les habitudes de l'époque solo, comme fusionner sans relire parce que « ça marche chez moi », restent en place. À l'autre bout, les gros systèmes historiques ressentent chaque statistique alarmante à pleine puissance. J'aime cette grille parce qu'elle évite le faux débat « faut-il relire ou non ». La vraie question est « combien, et quoi ».

À quoi sert la revue : retrouver l'intention

L'argument qui m'a le plus marqué concerne l'intention. Quand un humain écrit du code, son intention voyage avec : on la devine dans les noms, dans la structure, dans la description de la PR, et on peut lui poser la question. Avec un agent, le raisonnement est généralement jeté une fois la tâche terminée. Le relecteur doit alors reconstituer l'intention à partir du seul résultat.

La réponse proposée est un outillage : demander à l'agent d'énoncer son objectif et les options qu'il a écartées, puis de consigner tout cela comme un journal de décisions dans la PR. L'article cite à ce propos un développeur qui se décrit comme « the first human being to ever lay eyes on this code », le premier humain à poser les yeux sur ce code. La formule fait sourire, mais elle décrit bien la situation de nombreux relecteurs aujourd'hui.

L'auteur ajoute une limite honnête : une IA qui relit le travail d'une autre IA attrape de vrais bugs, mais elle ne peut pas dire si le changement devait être construit. Ce jugement-là reste humain.

Deux relecteurs IA valent-ils mieux qu'un ?

La recommandation est claire : faire tourner au moins un relecteur IA sur tout. Mais l'article va plus loin et affirme que deux outils d'architectures différentes valent mieux que la quête du meilleur outil unique. La preuve avancée est une expérience menée par un auteur de dev.to sur 146 PR et 679 remarques, pendant trois semaines et demie : sur 617 emplacements distincts signalés, 93,4 % l'avaient été par un seul des quatre outils, 6 % par deux, et aucun par les quatre.

La conséquence est que les outils se complètent plus qu'ils ne se recoupent. Les benchmarks cités montrent d'ailleurs des classements contradictoires : un outil domine sur le score F1 (compromis entre précision et rappel), un autre trouve davantage de bugs mais avec plus de fausses alertes. D'où la consigne de mesurer les outils sur votre propre code, pas sur celui d'un benchmark.

Il y a un revers, que l'article formule avec une formule joliment trouvée :

« Four copies of one model is a single reviewer with a larger invoice »

Quatre copies d'un même modèle, c'est un seul relecteur avec une facture plus grosse. Pour que la diversité serve à quelque chose, il faut des angles morts différents. Sinon vous obtenez ce que l'auteur appelle la borrowed confidence, la confiance empruntée : des modèles aux défauts corrélés qui se valident mutuellement, et une équipe qui se sent rassurée sans raison.

De « human in the loop » à « human on the loop »

Faut-il alors laisser l'IA relire davantage ? L'article remarque que la machine relit déjà plus de code que les humains : GitHub indique plus de 60 millions de revues Copilot, soit dix fois plus en moins d'un an, avec plus d'une revue sur cinq impliquant un agent. La question n'est donc plus « si », mais « avec quelles garanties ».

La réponse tient dans une formule :

« Human in the loop becomes human on the loop »

L'humain ne lit plus chaque changement : il supervise le système. Il échantillonne, audite, assume la responsabilité et décide de ce qui mérite d'être construit. Je trouve ce déplacement convaincant, à une condition : que quelqu'un exerce réellement cette supervision. Une revue « sur la boucle » que personne ne regarde n'est qu'une revue absente avec un meilleur vocabulaire.

L'article s'appuie aussi sur des travaux académiques à propos des PR d'agents : environ 28 % sont fusionnées presque instantanément, et l'abandon du relecteur expliquerait 38 % des rejets. Là encore, ce sont des ordres de grandeur à prendre comme tels. Mais le premier chiffre rappelle ce que « moins de revue » donne dans la pratique : un clic.

Ce que j'appliquerais dès maintenant

La partie « What to actually do » est la plus directement exploitable, et elle ne demande aucun budget particulier. Pour un développeur React freelance à Toulouse comme moi, qui intervient dans des équipes de tailles très variées, c'est précisément ce qui compte : des règles simples, applicables sans infrastructure lourde. Voici comment je la résumerais :

  • Proportionner la revue au risque, pas à l'auteur. Une page de documentation et un module de facturation ne méritent pas la même attention.
  • Faire échouer vite la queue coûteuse. Les contrôles automatiques bon marché passent en premier, pour ne mobiliser un humain que sur ce qui a déjà franchi ce filtre.
  • Refuser les PR sans preuve. Une déclaration d'intention, la sortie des tests et la preuve que le code a tourné.
  • Garder des PR petites, pour que la revue reste réellement possible.
  • Lire les changements de tests plus attentivement que le code. Un agent peut rendre un test vert en l'affaiblissant. L'article préfère d'ailleurs le test de mutation à la simple couverture.
  • Traiter la CI comme un mur fixe, que ni l'auteur ni l'agent ne peuvent contourner.
  • Un humain possède la fusion. Quelqu'un dont le nom est attaché à la décision.

Le dernier point rejoint ce que j'écrivais dans mon premier article : le développeur devient le garant du code plus que son auteur. Pour les responsables d'équipe, l'article ajoute un avertissement que j'apprécie : réduire les relecteurs parce que « l'IA nous a rendus plus rapides » transforme des économies apparentes en incidents. La capacité de revue doit être mesurée et protégée comme n'importe quelle ressource critique.

Les limites de l'article

Une lecture critique demande de regarder aussi d'où parle le texte. Trois points me paraissent mériter d'être signalés :

  • Un conflit d'intérêts discret. L'auteur travaille chez Anthropic, sur Claude Code, et recommande notamment Claude Code, Codex et le produit Code Review d'Anthropic. Sa biographie le précise, mais le corps du texte ne le rappelle pas au moment des recommandations.
  • Des chiffres de seconde main présentés comme mesurés à grande échelle, alors qu'ils proviennent en partie d'éditeurs, de benchmarks ou d'expériences individuelles. L'expérience des quatre outils, par exemple, est celle d'une seule personne sur 3,5 semaines.
  • Peu de chiffres sur le coût. Faire tourner deux relecteurs IA sur chaque PR a un prix, en jetons comme en temps de configuration, et l'article en dit peu.

Rien de tout cela n'invalide l'argument de fond, et l'auteur conclut d'ailleurs lui-même qu'il tient sa position avec souplesse (« I hold this loosely »). Mais cela invite à lire l'article comme un cadre de réflexion très solide plutôt que comme une démonstration chiffrée.

Ce que je retiens

Ce qui me paraît juste : le goulot s'est déplacé vers la confiance, la profondeur de revue doit suivre le rayon d'impact, et l'intention perdue par les agents doit être reconstituée par l'outillage plutôt que par le relecteur.

Ce qui mérite d'être nuancé : des statistiques en grande partie de seconde main, et un auteur qui évolue dans l'écosystème dont il recommande les outils.

Ce qui reste à démontrer : qu'une supervision « sur la boucle » soit réellement exercée dans les équipes qui manquent déjà de temps pour relire.

Si le sujet vous intéresse, lisez Agentic Code Review dans le texte, puis mon article sur la méthode de l'équipe Claude Code, qui en est le complément concret : l'un pose le cadre, l'autre montre ce qu'une équipe a vraiment mis en place, avec ses réussites et ses ratés.