Comment l’équipe Claude Code mène la revue de code : sept étapes et aucun disjoncteur

Le 15 octobre 2026, l’équipe de Claude Code a publié son propre récit de sa manière de relire le code, un article d’ingénierie de quatorze minutes signé Addy Osmani, Morgan Westlee Lunt et Qing Wang. La phrase qui explique pourquoi on cherche cela arrive tôt : Claude écrit environ 90 % du code de Claude Code lui-même. L’article n’est pas une défense de ce chiffre, mais la description de la mécanique qui devait exister en dessous avant que cela ne soit viable, et les parties qui méritent une lecture attentive sont celles qui manquent encore.

La plupart des résumés s’arrêtent aux deux chiffres phares : les pull requests fusionnées dans la base de code de Claude Code ont plus que doublé entre juin et septembre 2026, tandis que la part de celles qui ont dû être annulées a chuté de plus de 40 %. Les deux proviennent de l’équipe elle-même, et tous deux peuvent être obtenus par plusieurs dispositifs différents, y compris celui que l’on suppose, à savoir que la revue a été discrètement supprimée. Le billet affirme que ce n’est pas le cas. Ils ont transféré l’essentiel de la lecture aux machines, optimisé pour le temps et l’attention humains, et investi pour que les erreurs puissent être annulées vite et facilement. Tout le reste n’est que le détail de la mise en œuvre.

Pourquoi la revue est devenue le goulot d'étranglement en premier lieu

La pression ne venait pas d’une décision politique. Elle venait du volume. Dans le monorepo d’Anthropic, rapporte l’article, les changements intégrés chaque jour sont passés d’environ 2 500 en mai à plus de 30 000 en septembre 2026. Claude Code vit dans son propre dépôt, séparé de ce monorepo, mais il subit la même pression à une échelle moindre.

À ce rythme, le billet l’admet, une relecture manuelle ligne par ligne est incroyablement difficile, voire impossible. Personne là-bas ne prétend qu’une lecture humaine de chaque diff est inutile. Ils affirment que lire chaque diff ne passe plus à l’échelle, et que « un humain a-t-il lu le code » n’a toujours été qu’un indicateur imprécis pour la question qui compte : qu’est-ce qui pourrait mal tourner avec cette modification, et quel contrôle, automatisé ou humain, est le bon pour l’attraper.

Une fois formulé ainsi, le seuil se déplace. La revue cesse d’être une porte au bout du chemin pour devenir continue, plus proche du correcteur orthographique pendant que vous écrivez. La plupart des modifications ont été lues et corrigées par Claude avant qu’une personne ne les examine.

Ce qu’ils ont optimisé, et ce qui compte comme un échec

L’objectif annoncé est que la plupart des pull requests dans les dépôts Claude Code, que l’article décrit comme l’interface CLI, les applications de bureau et web et les applications mobiles, soient fusionnées avec au plus un humain dans la boucle, qui peut être l’auteur, sans augmentation des réversions ni des incidents. C’est la troisième clause qui en fait un véritable objectif plutôt qu’un exercice de réduction des coûts.

Ils mesurent le temps humain des deux côtés du bilan : le temps que les gens passent à relire, et celui qu’ils passent à réparer ce que du mauvais code casse. Réduire le premier ne sert à rien si le coût réapparaît sur le second, et l’équipe le dit clairement. Les chiffres suivis sont donc les approbations humaines par pull request, exprimées en médiane et au 95e percentile, les commentaires humains, et le temps qu’une pull request attend avant qu’une personne ne s’en occupe. Les taux de revert et d’incident se trouvent en dessous de tout cela comme garde-fou : s’ils augmentent, le temps humain n’a pas été gagné, seulement déplacé.

Les métriques de coût des revues sont faciles à manipuler isolément ; un relecteur qui approuve tout produit de superbes graphiques de délai d’approbation. C’est le garde-fou qui empêche le graphique de mentir.

Sept étapes, et non une seule porte

L'article présente le parcours d'un changement typique en sept étapes numérotées. Chaque couche détecte certains problèmes et en laisse passer d'autres, et les contrôles les moins coûteux s'exécutent avant les plus coûteux.

• Vérification avant même que la pull request n'existe. Claude exécute les tests, la compilation et le linter, et un second agent examine le diff dans un contexte vierge. De nombreux ingénieurs mobilisent aussi des compétences internes : l'une recherche les bugs, une autre simplifie le diff, une troisième vérifie le comportement de bout en bout. Boris Cherny, créateur de Claude Code, a déclaré que donner à Claude un moyen de vérifier son propre travail était probablement la chose la plus importante pour obtenir de bons résultats, et estime que cela rend le résultat final deux à trois fois meilleur.

• Revue par IA sur chaque demande de tirage. Une revue Claude lit le diff par rapport à l’ensemble du dépôt et à l’intention déclarée de la demande de tirage. Plusieurs agents recherchent des bogues en parallèle, puis un groupe distinct vote sur chaque constatation, et celle-ci n’est publiée que si suffisamment de membres conviennent qu’elle est réelle. Les constatations concernant le style, les diagnostics ou le nettoyage sont écartées. Ce qui subsiste apparaît sous forme de commentaires en ligne étiquetés Important, Nit ou Préexistant. Au lancement de l’aperçu de recherche, la proportion de demandes de tirage internes recevant des commentaires de revue substantiels est passée de 16 pour cent à 54 pour cent. Les administrateurs définissent chaque dépôt sur Rapide, Standard ou Approfondi.

• Revue de sécurité. Une passe automatisée distincte. Une pull request ne peut pas être fusionnée tant qu'un constat de l'une ou l'autre revue reste ouvert ; vous le corrigez ou vous fermez le fil avec une brève justification. Le même contrôle est public sous la forme de la GitHub Action de revue de sécurité open source ou de la commande /security-review.

• Vérifications automatisées qui bloquent. Lint, vérifications de types, tests sur chaque plateforme et compilation.

• Approbation humaine, proportionnée au risque. Un classificateur lit le changement et définit le niveau plutôt que de laisser l'auteur le définir. Cette étape a sa propre section ci-dessous, car c'est là que réside l'essentiel de la conception intéressante.

• File d'attente de fusion, drapeaux de fonctionnalité et déploiement progressif. La file relance chaque vérification sur main avec la modification appliquée, de sorte que deux pull requests qui réussissent chacune ne peuvent pas se combiner en un main cassé. Le nouveau comportement est d'abord livré derrière un drapeau aux employés d'Anthropic, puis au canal le plus récent, avec le canal stable en dernier.

• Détection et retour arrière rapides.Les indicateurs de fonctionnalité se désactivent sans déploiement, une rotation d'astreinte hebdomadaire est en place, et les revues d'incident demandent quelle couche aurait dû détecter le problème. Certaines erreurs passeront malgré tout, c'est pourquoi la dernière couche consiste à les remarquer rapidement plutôt qu'à les prévenir.

Le changement définit le palier, pas l’auteur.

Une correction de documentation et une modification de l’auto-updater ne présentent pas le même risque, elles ne bénéficient donc pas de la même revue. Le tableau de l’article comporte trois niveaux, et chacun répond à une seule question : combien de personnes, le cas échéant, doivent approuver cette modification avant sa fusion.

Faible couvre la documentation, les contenus rédactionnels, les fonctionnalités réservées à l’interne et les changements additifs derrière un flag ; une fois la revue automatisée et les contrôles de sécurité au vert, aucune intervention humaine n’est nécessaire. Moyen couvre les changements produit ordinaires ainsi que les zones sensibles telles que la mise en cache, le mécanisme de mise à jour automatique et les prompts système, et nécessite une personne. Élevé couvre le code le plus risqué et un petit ensemble de chemins qui nécessitent toujours deux personnes.

Le classificateur ne représente que la moitié du dispositif. Un second classificateur demande si cette modification particulière nécessite une autre personne, même lorsque son niveau indique que non. Certains parcours nécessitent toujours une personne, quel que soit le niveau : tout ce que les propriétaires ont répertorié comme sensible, et tout fichier de workflow CI. Seuls les auteurs figurant sur la liste de confiance du dépôt, principalement l’équipe propriétaire, bénéficient des parcours allégés ; tous les autres ont besoin d’une seconde personne. L’approbation d’un agent ne compte jamais comme celle d’une personne, donc une revue automatisée peut valider une modification à faible risque mais ne peut pas occuper un créneau qui exige un humain. Celui qui est à l’origine de la modification en est responsable. Et une approbation couvre un commit précis, donc un nouveau commit, y compris un push d’agent ou une fusion résolue manuellement, nécessite à nouveau l’approbation.

Deux détails valent la peine d'être repris, même si vous ne construisez jamais de classifieur. Le niveau vient du changement, pas de l'auteur, et la confiance est une barrière distincte et plus étroite, par-dessus. Et une approbation est liée à un commit plutôt qu'à une pull request, ce qui bouche le trou le plus courant des systèmes de revue : une coche verte obtenue tôt dans une branche, dépensée sur du code que personne n'a regardé.

Le réviseur est formé sur ses propres incidents.

C’est la partie que la plupart des comptes rendus omettent, et elle explique pourquoi l’arrangement continue de fonctionner plutôt que de dériver.

L’équipe a rassemblé d’anciennes pull requests ayant provoqué des incidents, ainsi que leurs correctifs en avant (fix-forwards) et leurs annulations (reverts), et a demandé aux ingénieurs qui connaissent ce code de confirmer chaque bug et l’endroit où il se trouvait. Cette collection est désormais une évaluation. Le relecteur l’exécute chaque jour. Lorsque ses prompts, ses outils ou son modèle changent, la modification doit résister à l’ensemble : la garder si le score augmente, l’abandonner sinon. Leurs échecs sont devenus la suite de tests de ce qui est censé détecter leurs échecs.

C’est une posture différente de celle qui consiste à régler un linter, lequel est jugé par rapport à un ensemble de règles fixes. Ce réviseur est jugé par rapport aux manières précises dont cette base de code a déjà échoué, de sorte que l’évaluation s’étoffe chaque fois que quelque chose ne va pas. Aucun score le concernant n’apparaît dans ce qu’Anthropic a publié que nous avons lu, et l’article ne prétend pas que le réviseur est terminé.

La couche qui n'est pas encore construite

Voici l’aveu qui rend l’article crédible. Tout ce qui précède décrit un système qui détecte et annule les erreurs, pas un système qui remarque que son propre taux d’erreur change. L’équipe n’a pas encore de disjoncteurs qui resserrent automatiquement l’approbation lorsque les chiffres de revert ou d’incident évoluent, et ses ingénieurs les veulent avant que davantage de code ne passe à des fusions sans intervention humaine.

Ce qui existe à la place, c’est la vigilance humaine. Les flags sont désactivés sans déploiement, la rotation hebdomadaire d’astreinte assure une veille, et les revues d’incident demandent quelle couche aurait dû détecter le problème. La phrase d’un collègue est la plus utile pour quiconque planifie un déploiement similaire : ralentir fait bien baisser votre taux d’erreur, mais surtout parce que vous faites moins de tout. L’équipe préfère devenir plus rapide à repérer et corriger les problèmes plutôt que plus lente à en créer.

Relisez les sept étapes en gardant cela à l’esprit. Six déterminent si un changement peut avancer. La septième est un ensemble d’habitudes pour remarquer les choses après coup. Aucune boucle de rétroaction n’est câblée depuis le résultat vers la porte de décision, et les personnes qui ont conçu le système le disent.

La deuxième fonction de Review, que l’article laisse en grande partie de côté

Le billet affirme clairement que la revue de code remplit deux fonctions : détecter et corriger les problèmes avant leur mise en production, et construire un contexte partagé à l’échelle de l’équipe. Il se concentre sur la première, puis revient sur la seconde avec une réponse d’une honnêteté inhabituelle : il n’existe aucun processus formel pour cela, personne ne garde un modèle mental complet de Claude Code en tête, et ils estiment que personne n’en a besoin. Vous voulez comprendre une partie de la base de code ? Demandez à Claude une explication de précisément ce segment.

Deux fichiers d’instructions portent le contexte qui vivait autrefois dans la tête des relecteurs. CLAUDE.md indique à Claude ce qu’est le projet, la stack, les conventions, les objectifs et les non-objectifs, volontairement gardés courts. REVIEW.md est rédigé par les code owners et précise à quoi ressemble un échec dans leur partie du code, quels chemins ignorer, et demande un fichier et une ligne plutôt qu’une supposition.

La responsabilité a sa propre ligne : vous la mergez, vous l’assumez. Mergez une modification petite ou moyenne et quelque chose tourne mal : la norme veut que vous la corrigiez. Cela fonctionne parce que les modifications sont petites, parce que les flags et les reverts annulent la plupart des erreurs en quelques minutes, et parce que le rayon d’impact fixe le niveau d’exigence pour le nombre de vérifications qu’une modification doit subir. C’est une norme qui se superpose à la règle d’approbation, et non un substitut à celle-ci.

Là où un routeur a sa place, et où il ne l'a pas

Le pipeline ci-dessus est un pipeline d’appels de modèles : un agent de revue qui lit un diff par rapport à un dépôt entier, plusieurs agents de recherche de bugs en parallèle, un groupe qui vote sur chaque constat, une passe de sécurité, et le réviseur réexécuté quotidiennement sur une évaluation croissante. C’est un problème de routage avant d’être un problème de revue, car un fournisseur qui connaît un après-midi difficile ne devrait pas bloquer une file de fusion.

OrcaRouter est un point de terminaison compatible OpenAI donnant accès à plus de 200 modèles avec une seule clé, avec basculement automatique entre fournisseurs et zéro marge, c'est-à-dire le prix catalogue du fournisseur répercuté tel quel. Les équipes qui exploitent leur propre version de ce pipeline bénéficient d'une relation de facturation unique et d'un point unique pour changer de modèle lorsque la qualité d'un évaluateur évolue, ce que l'évaluation quotidienne est précisément conçue pour détecter.

La frontière est importante. Nous hébergeons des modèles. Nous n’hébergeons pas Claude Code, nous n’exécutons pas Code Review for Claude Code, et nous n’avons aucun accès au pipeline dont traite cet article. Code Review for Claude Code est un produit d’Anthropic, généralement disponible avec les plans Team et Enterprise, une version allégée étant disponible localement sous la forme de /code-review. Si c’est ce pipeline que vous voulez, c’est là qu’il se trouve ; dans la version qu’en a votre propre équipe, un routeur relève d’une décision d’infrastructure plutôt que d’une décision de revue.

Ce qu'une équipe plus petite peut réellement copier

Écrivez les règles de revue là où le relecteur peut les lire : un court CLAUDE.md pour le projet et un REVIEW.md par zone qui précise à quoi ressemble un échec et exige un fichier et une ligne plutôt qu’une supposition. Consignez les niveaux de risque par écrit, faites-en une propriété du changement plutôt que de l’auteur, commencez strict et assouplissez seulement avec des preuves. Plafonnez ce que la revue automatisée peut approuver et ne laissez jamais l’approbation d’un agent compter comme celle d’une personne. Liez les approbations aux commits. Faites tourner la file de fusion. Transformez les incidents et les annulations en cas de test et réévaluez le relecteur chaque fois que vous le modifiez, car un relecteur non mesuré est un linter avec un meilleur marketing.

Surveillez donc le garde-fou, pas le délai d’approbation. La formulation de l’équipe elle-même vous donne le critère pour tout changement de revue que vous envisagez : les taux de revert et d’incident sont-ils restés stables, ou le temps a-t-il simplement été déplacé du réviseur vers la personne qui nettoie ensuite ? Cette question peut être tranchée avec les données que la plupart des équipes possèdent déjà, et elle distingue un processus devenu plus rapide d’un processus qui ne fait que sembler plus rapide pendant un trimestre.