Pendant longtemps, le goulot d'étranglement d'une équipe de développement, c'était l'écriture du code. Ce n'est plus vrai partout. Quand un agent peut ouvrir une pull request en quelques minutes, la question n'est plus « qui va écrire ça ? » mais « qui va relire tout ça ? ». C'est exactement le sujet d'un article qui m'a beaucoup fait réfléchir ces dernières semaines.

Addy Osmani a publié sur X How the Claude Code team does code review, un article cosigné avec Morgan Westlee Lunt et Qing Wang et également disponible sur le blog claude.dev, où il est daté du 15 octobre 2026. Pour ceux qui ne le connaissent pas : Addy Osmani a longtemps été l'une des voix de Chrome et de la performance web chez Google, il est l'auteur de Learning JavaScript Design Patterns, et il fait aujourd'hui partie de l'équipe technique d'Anthropic. L'article décrit, de l'intérieur, comment l'équipe qui développe Claude Code a réorganisé sa revue de code.

Le contexte compte. Selon l'article, Claude écrit environ 90 % du code de Claude Code. À l'échelle du monorepo d'Anthropic, les auteurs indiquent, en s'appuyant sur une publication de l'équipe d'ingénierie, que le nombre de changements intégrés par jour est passé d'environ 2 500 en mai à plus de 30 000 en septembre 2026. Aucune équipe humaine ne relit 30 000 changements par jour. À ce volume, la revue de code n'est plus un rituel d'équipe : c'est un problème de capacité humaine.

Je vous propose de parcourir ce que décrit l'équipe, puis de confronter ses choix à d'autres travaux, y compris ceux d'Addy Osmani lui-même, et de voir ce qu'une équipe web aux moyens plus modestes peut en tirer.

Ce que l'équipe Claude Code a changé

La phrase qui résume le mieux la démarche est celle-ci :

« We didn't remove review. But we did move most of the reading to machines, optimized for human time and attention. »

Autrement dit : la revue n'a pas disparu, mais la lecture ligne à ligne a été confiée aux machines, et le temps humain est traité comme la ressource rare. L'objectif affiché est que la plupart des PR soient fusionnées avec au plus un humain dans la boucle (qui peut être l'auteur lui-même), sans augmentation des reverts ni des incidents. Ce sont ces deux indicateurs qui servent de garde-fou.

Le résultat revendiqué par l'équipe : entre juin et septembre, le nombre de pull requests fusionnées sur Claude Code a plus que doublé, pendant que la part de PR qu'il a fallu annuler a baissé de plus de 40 %.

Une revue continue, organisée en couches

La revue n'est plus une porte à franchir à la fin du processus, mais une suite de contrôles qui commence avant même qu'un humain ouvre la PR. L'article décrit six couches, avec la possibilité de revenir en arrière en dessous de toutes :

  • Vérification par l'agent lui-même : Claude lance les tests, le build ou une comparaison de captures d'écran et montre le résultat, puis un sous-agent relit le diff avec un contexte neuf.
  • Revue IA sur chaque PR : plusieurs agents cherchent des bugs en parallèle, puis un groupe d'agents vérificateurs vote sur chaque remarque, qui n'est publiée que si assez d'entre eux sont d'accord. Les remarques de style ou de nettoyage sont écartées.
  • Revue de sécurité séparée, qui peut bloquer la fusion.
  • Contrôles automatiques bloquants : lint, types, tests sur toutes les plateformes, build. Le modèle de PR demande comment le changement a été testé et comment l'annuler.
  • Approbation humaine proportionnée au risque, sur laquelle je reviens plus bas.
  • File de fusion, feature flags et déploiement progressif : d'abord auprès des employés d'Anthropic, puis sur un canal latest avant le canal stable. Le tout adossé à une détection rapide, des flags désactivables sans déploiement et une astreinte hebdomadaire.

Un détail m'a marqué : quand le relecteur IA remonte souvent le même type de problème, l'équipe corrige à la source, dans une compétence de l'agent, une règle de lint, un CLAUDE.md ou un fichier REVIEW.md rédigé par les responsables du code. La revue ne sert plus seulement à corriger la PR du jour, elle améliore le système qui produit les suivantes.

Le changement fixe le niveau de revue, pas l'auteur

C'est pour moi l'idée la plus intéressante de l'article. Un classifieur attribue à chaque changement un niveau de risque, et un second se demande si une personne doit regarder malgré tout :

  • Faible : aucune approbation humaine une fois la revue automatique et la sécurité au vert (documentation, textes, fonctionnalités internes, ajouts derrière un flag).
  • Moyen : une personne (changements produit courants, mais aussi zones sensibles comme le cache, l'auto-updater ou les prompts système).
  • Élevé : deux personnes, pour le code le plus risqué et quelques chemins qui l'exigent toujours.

Plusieurs garde-fous complètent le dispositif : certains chemins exigent toujours un humain, dont tous les fichiers de workflow CI ; l'approbation d'un agent ne compte jamais comme celle d'une personne ; une approbation ne vaut que pour un commit précis ; et seuls les auteurs de confiance accèdent aux circuits allégés. La formule de l'article est limpide : « The change sets the tier, not the author ».

Ce qui me plaît ici, c'est l'honnêteté sur une fiction que beaucoup d'équipes entretiennent. L'article qualifie la question « un humain a-t-il lu le code ? » d'imprecise proxy, un indicateur imprécis. Soyons francs : un « LGTM » posé en trente secondes sur une PR de 800 lignes n'a jamais garanti grand-chose. Il rassurait le process, pas forcément la production. Concentrer l'attention humaine là où le risque est réel me paraît plus sain que de la diluer partout.

Quand deux IA se renvoient la balle

Le passage le plus instructif est aussi le moins flatteur. Une PR de la CLI a traversé plus de cinquante cycles de revue et de corrections en une nuit, jusqu'à ce que son auteur l'arrête. Une analyse git blame a montré qu'environ 59 % de ce que le relecteur continuait de signaler était du code présent depuis son premier passage.

« An agent author and an agent reviewer can keep each other busy indefinitely. »

Un agent auteur et un agent relecteur peuvent s'occuper mutuellement sans fin. L'équipe a donc ajouté des amortisseurs : après trois cycles, le relecteur demande à l'auteur de prendre du recul sur son approche ; après les premiers passages, il ne relit plus que le diff ; il signale une classe de bug plutôt que chaque occurrence ; et il ne répète jamais une remarque déjà publiée.

Les chiffres partagés par l'équipe sur ses PR internes, avant et après ces changements :

  • PR validées après un seul cycle de revue et de correction : de 65 % à 78 % ;
  • PR nécessitant cinq cycles ou plus : de 8,9 % à 1,5 % ;
  • nombre moyen de revues avant validation : de 2,08 à 1,32.

J'y vois une leçon qui dépasse l'IA : une boucle de contrôle sans amortissement oscille. Quiconque a vu deux relecteurs humains se renvoyer des nits pendant une semaine reconnaîtra le problème, ici simplement compressé en une nuit.

Multiplier les relecteurs IA rend-il le code meilleur ?

Sur le papier, mettre plusieurs agents en parallèle sur chaque PR semble une évidence. L'article ne dit pourtant pas « plus d'agents, plus de qualité ». Il désigne plutôt un autre ennemi : le bruit.

« Noise costs more when the author is an agent. »

Le bruit coûte plus cher quand l'auteur est un agent, parce qu'un agent tend à corriger tout ce qu'on lui signale, fausses alertes comprises, et relance la boucle. D'où le vote des vérificateurs, l'abandon des remarques de style et le classement par sévérité (Important, Nit, Pre-existing), des filtres que l'équipe dit avoir testés en A/B. Le bruit est mesuré à partir des réactions des auteurs (corrigé, faux, intentionnel, sans importance), et le relecteur tourne aussi sur des PR connues pour être saines. D'après l'article, au lancement de la préversion, la part de PR internes recevant des commentaires de fond est passée de 16 % à 54 %, et la plupart des PR de plus de 1 000 lignes reçoivent des remarques, quand la plupart des petites reviennent sans rien.

Une autre pratique m'a convaincu : les incidents passés deviennent une évaluation. Les PR à l'origine d'incidents, avec leurs reverts et leurs correctifs, sont vérifiées par des experts puis ajoutées à un jeu de cas sur lequel le relecteur tourne chaque jour. Toute modification de ses prompts, de ses outils ou du modèle est notée sur l'ensemble de ces cas. C'est du test de non-régression appliqué au relecteur lui-même.

Pour nuancer, il faut lire un autre texte d'Addy Osmani, Agentic Code Review, publié en juin 2026. Il y cite une comparaison de quatre outils de revue IA sur 146 PR : 93,4 % des problèmes relevés n'avaient été détectés que par un seul des quatre outils, et aucun ne l'avait été par les quatre. Il y met aussi en garde contre la borrowed confidence, cette confiance empruntée qui naît quand des modèles aux angles morts corrélés se valident entre eux. Sa recommandation : traiter chaque revue IA « as a sensor, not a verdict », comme un capteur et non comme un verdict.

J'en retiens que multiplier les relecteurs élargit la couverture, mais que la qualité vient du filtre et de la mesure, pas du nombre. Sans jeu d'évaluation construit sur ses propres incidents, empiler des agents revient surtout à empiler des commentaires.

Une IA peut-elle vérifier le code d'une autre IA ?

C'est la question qui me met le plus mal à l'aise, et l'article y répond avec prudence. Il ne prétend pas que l'IA se suffit à elle-même : les zones risquées (facturation, auto-updater, workflows CI) restent relues par des humains, et la vérification repose d'abord sur des preuves exécutables, tests, builds, captures, plutôt que sur l'avis d'un modèle. L'article cite au passage Boris Cherny, selon qui donner à Claude un moyen de vérifier son travail rend le résultat final deux à trois fois meilleur. Une estimation, précisons-le, pas une mesure.

Je note pourtant une tension. L'annonce du produit Code Review, citée dans l'article, rappelle que « approving a pull request is still a human call ». Dans le même temps, l'équipe explique que dans ses propres dépôts, les responsables du code décident quels changements à faible risque peuvent être fusionnés sur la seule base des contrôles automatiques. Les deux sont compatibles, mais la frontière se déplace, et c'est un classifieur qui décide de quel côté tombe chaque PR. La fiabilité de tout le dispositif repose donc sur un composant dont l'article dit assez peu de choses.

Il faut aussi rappeler d'où parle le texte. Ses auteurs travaillent chez Anthropic, qui commercialise justement un outil de revue de code. Les chiffres sont internes, non audités, et portent sur quelques mois. Dans Agentic Code Review, Addy Osmani signale lui-même que certains éditeurs dont il cite les données vendent sur ce marché et que leur cadrage n'est pas désintéressé ; la remarque vaut aussi, logiquement, pour son employeur. Cela n'invalide rien, mais invite à lire ces chiffres comme un retour d'expérience, pas comme une preuve.

Petit exercice de lecture, d'ailleurs : si le nombre de PR fusionnées a plus que doublé et que la part de reverts a baissé d'un peu plus de 40 %, le nombre absolu de reverts est resté, en ordre de grandeur, à peu près stable, voire en légère hausse (2 × 0,6 ≈ 1,2). C'est mon calcul, pas celui de l'article, et c'est un bon résultat vu le volume. Mais un revert ne mesure que ce qu'on a détecté. Une faille latente, une dérive d'architecture ou un module que plus personne ne comprend n'apparaissent pas dans ce compteur.

Ce que la revue de code faisait aussi : transmettre

L'article reconnaît que la revue de code a deux fonctions : trouver et corriger les problèmes, et construire un contexte partagé dans l'équipe. Il se concentre surtout sur la première. Pour la seconde, la réponse de l'équipe consiste à demander à Claude une explication d'une portion de code, plutôt que de lire des diffs triviaux.

C'est là que j'ai le plus de réserves. Addy Osmani a lui-même décrit ce risque en mars 2026 dans Comprehension Debt : « the growing gap between how much code exists in your system and how much of it any human being genuinely understands ». L'écart grandissant entre la quantité de code d'un système et la part qu'un humain comprend réellement. Il souligne que cette dette « breeds false confidence » : contrairement à la dette technique, qu'on sent passer, elle se cache derrière des tests verts et un code propre.

Une étude d'Anthropic publiée en janvier 2026 va dans le même sens. Sur 52 développeurs, majoritairement juniors, qui découvraient la bibliothèque Python Trio, le groupe assisté par IA a obtenu en moyenne 50 % au quiz de compréhension, contre 67 % pour le groupe qui codait à la main. L'écart le plus marqué portait sur les questions de débogage, et le gain de temps, environ deux minutes, n'était pas statistiquement significatif. Les auteurs soulignent eux-mêmes la petite taille de l'échantillon et le fait que le quiz mesurait la compréhension juste après la tâche. Ils observent aussi que les participants qui utilisaient l'IA pour poser des questions conceptuelles s'en sortaient bien mieux que ceux qui lui déléguaient tout, sans établir de lien de causalité.

Or le débogage, c'est précisément ce qu'on fait quand l'incident tombe. L'article pose un principe auquel j'adhère : « Whoever prompted the change is on the hook for it », celui qui a demandé le changement en est responsable. Mais peut-on vraiment répondre d'un code qu'on n'a pas lu ? Une explication générée à la demande aide à comprendre un morceau de code ; elle ne remplace pas la familiarité qu'on construit en lisant, en se trompant et en corrigeant. Quand j'ai enquêté sur la mémoire de pods Next.js qui ne redescendait jamais, la réponse n'était dans aucun diff : il a fallu lire le code de Next et comprendre le comportement de l'allocateur de la glibc. Ce genre de compréhension ne s'obtient pas avec un résumé.

Je ne dis pas que l'équipe Claude Code se trompe. Je dis que ce second volet mériterait ses propres indicateurs. Combien de personnes savent expliquer telle partie du système ? Combien de temps faut-il pour diagnostiquer un incident dans du code généré ? Les reverts ne répondent pas à ces questions.

Et dans une équipe web aux moyens plus modestes ?

Soyons réalistes : la plupart d'entre nous ne disposent ni de classifieurs de risque, ni d'un jeu d'évaluation construit sur des années d'incidents, ni de canaux de release multiples, ni d'une astreinte dédiée. L'article ne dit d'ailleurs rien du coût, en tokens comme en infrastructure, de plusieurs agents et vérificateurs lancés sur chaque PR. Fusionner sans humain les changements à faible risque n'a de sens que si l'on sait détecter et annuler vite. Sans flags ni rollback fiable, je ne m'y risquerais pas.

En revanche, une bonne partie de la démarche se transpose sans budget particulier, et l'article propose d'ailleurs sa propre liste pour l'adopter. Voici ce que je retiendrais pour une petite équipe :

  • Proportionner la revue au risque, par chemin de fichier. Un fichier CODEOWNERS et des règles de protection de branche suffisent pour exiger deux relecteurs sur la facturation ou les workflows CI, et une revue légère sur la documentation.
  • Écrire un REVIEW.md qui dit au relecteur IA ce qui compte vraiment dans le projet, et y reporter les remarques récurrentes plutôt que de les répéter PR après PR.
  • Demander dans le modèle de PR comment le changement a été testé et comment l'annuler. Cela pousse vers des changements atomiques et réversibles, dans l'esprit de ce que j'expliquais sur la façon de bien écrire ses commits avec Git.
  • Placer les contrôles bloquants côté CI, pas seulement en local. Un hook pre-commit se contourne d'un simple --no-verify, je l'ai même détaillé dans comment ignorer les hooks Git commit. Quand des agents committent à notre place, seuls les contrôles côté serveur sont de vrais garde-fous.
  • Plafonner les allers-retours entre agents, à la manière des trois cycles de l'équipe Claude Code, au-delà desquels on remet l'approche en question.
  • Mesurer le bruit en notant ce que deviennent les commentaires du relecteur IA, et garder sous la main quelques PR qui ont causé des incidents pour tester chaque changement de configuration.

Le développeur, de producteur à garant

L'article dresse la liste de ce qui reste aux humains : décider s'il faut construire la fonctionnalité, relire le code risqué, juger l'architecture, lire les preuves, et assumer le résultat. Rien de tout cela n'est de la production de code. Tout relève du jugement.

C'est, je crois, le vrai sujet pour notre métier. Le développeur devient progressivement le garant du code plus que son auteur. Ce n'est pas forcément moins exigeant : lire une preuve demande de savoir reconnaître une bonne preuve, un test qui teste vraiment quelque chose, une capture qui montre le bon état. Or ce jugement s'est toujours construit en écrivant du code soi-même. Si les juniors n'écrivent plus, comment deviendront-ils les seniors capables de relire les zones à haut risque ? L'étude d'Anthropic ne tranche pas, mais elle donne de bonnes raisons de se poser la question.

Une dernière mise en perspective. En juillet 2025, l'étude de METR sur des développeurs open source expérimentés avait mesuré qu'avec les outils d'IA de l'époque, ils mettaient 19 % de temps en plus à traiter leurs tickets, tout en estimant après coup avoir gagné 20 %. METR indique aujourd'hui que ces résultats sont dépassés, et les outils ont beaucoup changé depuis. Mais l'écart entre ressenti et mesure reste instructif. C'est peut-être la meilleure leçon de l'équipe Claude Code : elle ne juge pas son process à l'impression de productivité, mais à des indicateurs qui font mal quand ils bougent, les reverts et les incidents.

Ce que je retiens

Ce qui me paraît juste : traiter l'attention humaine comme la ressource rare, proportionner la revue au risque du changement plutôt qu'à l'identité de son auteur, ancrer la vérification dans des preuves exécutables, et évaluer le relecteur lui-même sur les incidents passés.

Ce qui mérite d'être nuancé : des chiffres internes, sur une période courte, publiés par une entreprise qui vend l'outil, et un indicateur de succès, les reverts, aveugle à la dette invisible.

Ce qui me pose question : la transmission du savoir dans l'équipe, la formation des futurs relecteurs, et la confiance accordée à un classifieur qui décide quand un humain doit regarder.

Je vous recommande vraiment de lire l'article original d'Addy Osmani, Morgan Westlee Lunt et Qing Wang, ainsi que Comprehension Debt et Agentic Code Review, qui en forment presque le contrepoint. Il est rare de voir une équipe documenter aussi précisément ses ratés, comme cette PR à cinquante cycles, à côté de ses réussites. Rien que pour ça, la lecture vaut le détour.