Claude Code : sa revue de code, couche par couche

Ce qui se passe

Claude écrit environ 90 % du code de Claude Code. À ce volume, lire chaque ligne n'est plus tenable : dans le monorepo d'Anthropic, les changements fusionnés par jour sont passés d'environ 2 500 en mai à plus de 30 000 en septembre. L'équipe Claude Code décrit son dispositif. Résultat annoncé : de juin à septembre, les pull requests fusionnées ont plus que doublé, et la part annulée par un revert a baissé de plus de 40 %.

L'idée : « un humain a-t-il lu le code ? » est un mauvais indicateur. La question utile est « qu'est-ce qui peut mal tourner, et quel contrôle, automatique ou humain, l'attrape ? ». La revue n'est plus une barrière en fin de route mais un contrôle continu. Objectif : que la plupart des PR fusionnent avec au plus une personne dans la boucle (l'auteur peut l'être), sans hausse des reverts ni des incidents ; ces deux taux servent de garde-fou.

Les couches

Vérifier avant la PR. L'agent exécute tests, build ou comparaison de capture d'écran et montre le résultat ; un sous-agent relit le diff avec un contexte neuf. CLAUDE.md reste court ; REVIEW.md, écrit par les propriétaires du code, dit au relecteur ce qui compte (à quoi ressemble un échec ici, plafond de nits, chemins à ignorer, fichier et ligne exigés comme preuve, résumé qui commence par un décompte).
Revue IA sur chaque PR. Plusieurs agents cherchent des bugs en parallèle, puis un autre groupe vote sur chaque constat ; seuls ceux qui font consensus sont publiés. Les constats de pur style sont écartés. Étiquettes : Important, Nit, Pre-existing. Chaque constat doit recevoir une réponse. Au lancement de l'aperçu, la part des PR internes avec des commentaires de fond est passée de 16 % à 54 %.
Revue de sécurité bloquante. Aucune fusion tant qu'un constat reste ouvert.
Contrôles automatiques : 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 selon le risque.

Risque	Exemples	Approbations
Faible	documentation, textes, fonctions internes, ajouts derrière un drapeau	aucune une fois les contrôles verts
Moyen	changements ordinaires, cache, mise à jour automatique, invites système	une personne
Élevé	code le plus sensible	deux personnes

Le niveau dépend du changement, pas de l'auteur (un classifieur le décide) ; l'approbation d'un agent ne compte jamais comme celle d'un humain ; celui qui a demandé le changement à l'agent en est un relecteur ; une approbation vaut pour un commit.

File de fusion, drapeaux, déploiement progressif (canal latest avant stable).
Détection et retour arrière rapides : drapeaux désactivables sans déploiement, astreinte hebdomadaire.

Les limites, dites par l'équipe

Un agent auteur et un agent relecteur peuvent s'occuper indéfiniment : une PR a subi plus de cinquante tours en une nuit, et environ 59 % de ce que le relecteur signalait portait sur du code déjà présent à sa première passe. Réponse : plafond de trois tours, puis relecture du seul nouveau diff, signalement de la classe de bug plutôt que d'une ligne, aucun constat répété.
Il n'existe pas encore de coupe-circuit qui durcit l'approbation quand les reverts montent.
Chiffres auto-déclarés, sur le dépôt de l'équipe qui vend l'outil.

Que faire

Ce que l'équipe conseille d'adopter :

donner à l'agent des contrôles exécutables dans un CLAUDE.md court, avec des hooks de formatage et de lint ;
lancer /code-review et /security-review en local, ou une revue par sous-agent à contexte neuf ;
ajouter un REVIEW.md et y déplacer les remarques qui reviennent ;
ajouter « Testing », « Risk » et « How to revert » au modèle de PR ;
exiger que tous les fils de revue soient résolus avant fusion ;
noter les paliers de risque par écrit, en commençant strict.

Source : How the Claude Code team does code review, équipe Claude Code, 15 octobre 2026 (date de la page).