Le code double, les annulations reculent : comment Anthropic a cessé de tout relire

Le 15 octobre 2026, l’équipe qui construit Claude Code, l’assistant de programmation d’Anthropic, a publié le récit de sa manière de relire son propre code. Le point de départ est inhabituel : Claude écrit environ 90 % du code de Claude Code. Entre juin et septembre, le nombre de modifications intégrées au logiciel a plus que doublé, et la part de celles qu’il a fallu annuler a reculé de plus de 40 %. La production a monté pendant que le taux d’erreurs descendait, parce que l’équipe a cessé de demander « un humain a-t-il tout lu ? » pour se demander quel contrôle, automatique ou humain, doit attraper quelle erreur.

Deux fois plus de modifications, une part d’annulations en recul de 40 %

Une équipe de développeurs ne modifie pas son logiciel directement. Chaque changement passe par une pull request, une proposition de modification qui attend d’être relue, puis intégrée au code principal. Quand une modification intégrée casse quelque chose et qu’on la retire, c’est un revert, une annulation. Ce sont les deux compteurs d’Anthropic.

La baisse porte sur la part de modifications annulées, pas sur leur nombre. Si l’on prend les seuils annoncés tels quels (volume multiplié par deux, part multipliée par 0.6), le nombre d’annulations aurait augmenté d’environ 20 % pour un volume doublé. Ce calcul est le nôtre ; Anthropic ne publie pas le chiffre. Le résultat tient donc à ceci : le volume a doublé sans que les annulations suivent au même rythme.

Personne ne peut plus tout lire : 30’000 modifications par jour

Anthropic range l’essentiel de son code dans un seul grand dépôt. En mai, environ 2’500 modifications y étaient intégrées chaque jour. En septembre, plus de 30’000.

À ce rythme, aucun humain ne lit chaque ligne. L’équipe en a tiré la conséquence : « un humain a-t-il lu le code ? » est, selon elle, un indicateur imprécis. La bonne question est de savoir ce qui peut mal tourner, et quel contrôle doit l’attraper. La ressource rare n’est plus le code, c’est l’attention humaine. L’objectif devient que la plupart des modifications passent avec au plus un humain dans la boucle, qui peut être l’auteur lui-même.

Le garde-fou tient en une phrase : si les annulations ou les incidents augmentent, le temps humain n’a pas été économisé, il a seulement été déplacé de la relecture vers le nettoyage. L’efficience se mesure donc à la sortie du processus. L’équipe suit le nombre d’approbations humaines par modification, le temps passé à attendre une personne, et, comme frein, les annulations et les incidents.

Sept couches de contrôle, chacune attrape ce que les autres laissent passer

1. Un travail vérifié avant d’être proposé. Claude reçoit de quoi exécuter ce qu’il écrit (tests, compilation, capture d’écran à comparer à la maquette) et doit montrer le résultat au lieu d’annoncer que c’est fini. Boris Cherny, créateur de Claude Code, estime que cela améliore le résultat final de deux à trois fois. Un second agent, qui repart d’une page blanche, relit la modification.
2. Une relecture par des agents sur chaque modification. Plusieurs agents cherchent des erreurs en parallèle, un autre groupe vote sur chaque trouvaille, et seules celles qui font consensus sont publiées. Chacune doit être corrigée ou refermée avec une raison.
3. Une revue de sécurité qui bloque. Tant qu’une trouvaille reste ouverte, la modification ne passe pas.
4. Des contrôles automatiques obligatoires. Style du code, types, tests sur toutes les plateformes, compilation. La fiche de chaque modification demande comment elle a été testée et comment l’annuler.
5. Une approbation humaine proportionnée au risque, détaillée ci-dessous.
6. Une file d’intégration, puis un déploiement progressif. La file rejoue tous les contrôles sur la dernière version du code. La nouveauté arrive d’abord chez les employés d’Anthropic, derrière un interrupteur qui l’active ou la coupe.
7. Une détection rapide et un retour arrière. L’interrupteur coupe une fonction sans nouveau déploiement. Chaque semaine, l’équipe d’astreinte se demande quelle couche aurait dû attraper chaque incident.

Risque	Exemples	Approbations humaines
Faible	Documentation, textes, fonctions internes, ajouts derrière un interrupteur	Aucune, une fois les contrôles automatiques et de sécurité au vert
Moyen	Changements de produit ordinaires, zones sensibles (cache, mise à jour automatique, instructions du modèle)	Une personne
Élevé	Le code le plus risqué	Deux personnes

Un classificateur fixe le niveau à partir de la modification elle-même, pas de son auteur. Certains fichiers, comme ceux qui pilotent les contrôles automatiques, exigent toujours une personne.

Deux règles à copier en premier

La première : l’approbation d’un agent ne compte jamais comme celle d’une personne. Une relecture automatique peut valider une modification à faible risque, elle ne remplit pas une case qui exige un humain. La seconde : celui qui a demandé la modification en répond, comme s’il avait tapé le code lui-même. Sur une modification écrite par un agent, la personne qui le dirige compte comme relectrice obligatoire. Une approbation ne vaut en outre que pour une version précise : un ajout qu’elle n’a pas vu en demande une nouvelle.

Le contrôleur aussi se contrôle

Le relecteur automatique s’améliore en boucle. Chaque incident passé devient un cas d’essai, confirmé par un expert, et le relecteur est évalué chaque jour sur l’ensemble de ces cas. Un problème inédit est apparu : un agent qui écrit et un agent qui relit peuvent s’occuper l’un l’autre sans fin. Le relecteur signale une erreur, l’agent la corrige, le relecteur en trouve une autre. Une modification a ainsi traversé plus de 50 tours en une nuit, avant qu’un humain l’arrête à la main. Désormais, après trois tours, le relecteur demande à l’auteur de reculer et de repenser son approche.

Mesure (Anthropic)	Avant	Après
Modifications qui reçoivent des commentaires de fond	16 %	54 %
Modifications validées en un seul tour de relecture	65 %	78 %
Modifications qui demandent cinq tours ou plus	8.9 %	1.5 %
Nombre moyen de relectures avant validation	2.08	1.32

Les humains n’ont pas disparu. Ils décident s’il faut construire une fonction, relisent le code à risque (facturation, mise à jour automatique, fichiers de contrôle), jugent les choix d’architecture que d’autres recopieront, lisent les preuves (résultats de tests, captures, trouvailles du relecteur) et répondent des résultats.

Ce n’est pas une idée neuve : les machines vérifient les machines depuis longtemps

Personne ne contrôle à la main chaque paquet qui traverse internet. Le protocole TCP ajoute une somme de contrôle à chaque paquet et redemande celui qui arrive abîmé ou n’arrive pas. La mémoire d’un serveur corrige seule un bit inversé grâce à des codes correcteurs d’erreurs. Une base de données écrit chaque changement dans un journal qu’un serveur de secours rejoue, pendant que d’autres processus le surveillent. La comptabilité en partie double, vieille de plus de cinq siècles, enregistre chaque opération deux fois, au débit et au crédit, pour que les comptes doivent s’équilibrer. En 1948, Claude Shannon a montré qu’on peut transmettre un message de façon fiable sur un canal bruité à condition d’y ajouter la bonne redondance.

On n’a jamais rendu ces systèmes fiables en faisant inspecter chaque étape par une personne. On les a rendus fiables en faisant vérifier les machines par des machines, selon des contrôles conçus par des personnes. Le code écrit par des agents rejoint cette tradition.

Le goulot a changé de place

Écrire plus vite déplace le goulot vers la lecture. En 2025, Faros AI a analysé les données de plus de 10’000 développeurs répartis dans 1’255 équipes. Celles qui utilisaient beaucoup l’IA intégraient 98 % de modifications de plus, mais le temps de relecture montait de 91 %, les erreurs par développeur de 9 % et la taille moyenne des modifications de 154 %. L’étude ne relève pas d’amélioration significative au niveau de l’entreprise, ni sur le débit de livraison ni sur la qualité. Faros vend des outils de mesure et mesure de l’activité, non de la valeur livrée : ce sont des corrélations. Elles décrivent pourtant le mur contre lequel butent les équipes qui accélèrent sans repenser la relecture.

La méthode d’Anthropic suppose un socle. L’équipe peut alléger la relecture humaine parce que presque tout y est réversible : tests qu’un agent peut lancer, interrupteurs, déploiement progressif, retour arrière en quelques minutes. Sans cela, relire moins n’est pas une option. Elle reconnaît d’ailleurs une lacune : elle n’a pas encore de disjoncteur qui resserre l’approbation quand les annulations ou les incidents montent, et ses ingénieurs en veulent un avant de confier davantage de code à des fusions sans relecteur humain.

Ce que nous en retenons pour une organisation

• Mesurer l’attente, pas les lignes. Le volume de code produit ne dit rien de l’efficience. Le temps qu’une modification attend une personne, le nombre d’approbations par modification et le taux d’annulations le disent.
• Construire le socle avant d’ouvrir le robinet. Tests qu’un agent peut exécuter, interrupteurs, déploiement progressif, retour arrière rapide. Commencer strict, relâcher quand les preuves le permettent.
• Transformer chaque relecture répétée en règle, en test ou en outil. Et faire passer chaque jour au relecteur automatique le pire incident que l’organisation ait connu : personne d’autre ne possède ce cas d’essai.
• Garder une personne responsable. Dans un établissement régulé, la question utile est de savoir qui approuve chaque changement et qui en répond. C’est le principe des quatre yeux, appliqué à un relecteur qui ne dort jamais.

Tout le monde peut acheter l’accès aux mêmes modèles. Ce qui distingue les organisations, c’est de reconstruire le processus autour d’eux, et de garder des personnes là où le jugement, la confiance et la responsabilité ne se délèguent pas.