Andy Garcia · dev freelance
FRENES
Retour au blog
IA & Dev

Anthropic est passé de 2 500 à 30 000 merges par jour et a sorti son monorepo de git. Ses ingénieurs relisent l'intention, pas chaque ligne

19 octobre 2026 8 min de lecture

Le mardi 13 octobre 2026, Anthropic a publié un article d'ingénierie intitulé « Redesigning source control at Anthropic », mis à jour le 15 octobre. Ses premiers chiffres sont ceux que tout le monde a repris : en mai 2026, l'entreprise fusionnait en moyenne environ 2 500 changements de code par jour, et depuis septembre, plus de 30 000 par jour. Pour tenir, elle a construit Scion, un système de gestion de versions interne, et a migré entièrement son monorepo hors de git en cinq mois. Sur la même période, elle a livré un outil de revue de code appelé Antique, un outil de recherche dans le code et un système de contrôle d'accès aux sources. Selon l'article, une équipe de sept personnes a construit Scion et Antique.

La phrase qui cadre tout vient avant le moindre chiffre. Écrire du code, dit Anthropic, n'est plus le goulot d'étranglement : « Le goulot, désormais, c'est toute l'infrastructure de développement construite à l'échelle humaine : gestion des sources, builds et CI. »

Je suis CTO d'une LegalTech construite sur Claude, et j'orchestre mon propre travail avec Claude Code. Mes dépôts sont une erreur d'arrondi à côté de celui-ci. Le système de gestion de versions est la partie la moins transposable de l'article. Ce qui se transpose, c'est l'endroit où la pression est apparue et ce que les ingénieurs ont cessé de faire à la main.

Les chiffres, et ce qu'ils donnent ensemble

L'historique de la branche principale pèse presque 100 Go. Une copie de travail compressée dépasse 25 Go. Anthropic effectue de l'ordre de 25 millions de checkouts par jour pour la seule CI, « sans compter les environnements de développement, les bacs à sable d'agents et les jobs de recherche ». Récupérés naïvement, dit l'article, cela ferait plus de 600 Po de trafic git par jour. Le calcul tient : 25 millions fois une copie de travail d'environ 25 Go font environ 625 Po.

Quelques divisions rendent ça lisible. Passer de 2 500 à 30 000 merges par jour, c'est un facteur 12 en environ quatre mois. Répartis sur 24 heures, 30 000 merges font environ 21 par minute. 25 millions de checkouts par jour, c'est environ 290 par seconde. Et si les deux chiffres décrivent les mêmes semaines, cela fait plus de 800 checkouts de CI pour chaque changement qui atterrit.

Git a des outils pour ça : clones superficiels, checkouts partiels, miroirs internes, instantanés dans du stockage d'objets. Anthropic les a tous utilisés et, à son pic, a fait tourner plusieurs centaines de miroirs git internes. Ça a fait gagner du temps.

Après la migration, l'article rapporte une empreinte de Scion 200 fois plus petite que l'ancien dispositif de miroirs git en CPU et en mémoire, des checkouts pour la CI et les jobs de recherche qui prennent des secondes au lieu de minutes, un taux de succès du cache supérieur à 99 % à chaque niveau, et un gain de 25 % de capacité CPU pour la CI.

Pourquoi git ne convenait plus

Git est décentralisé : chaque clone est un dépôt complet qui fonctionne hors ligne. L'observation d'Anthropic, c'est que, comme la plupart des entreprises, elle utilisait git comme un système centralisé avec une seule copie de référence, alors que presque tous ses clients étaient des agents et des jobs, en ligne par définition.

Scion part donc du principe que le client est toujours en ligne. Le serveur répond aux requêtes d'historique et de blame et exécute les commits, les merges et les rebases. Le client garde un cache borné et ne récupère que ce dont il a besoin. Les mêmes requêtes sont exposées par une API, si bien que de nombreux jobs de CI n'ont besoin d'aucun dépôt local. Interrogé sur Hacker News à propos du mode hors ligne, Nick G., l'un des auteurs de l'article, a répondu, comme le relaie Simon Willison : « Comme Claude est de loin le plus gros utilisateur de Scion et qu'il est forcément en ligne, ce n'était tout simplement pas important à faire. »

Une bonne partie de tout cela a des précédents, et l'article citait dès le départ Piper de Google et Sapling de Meta comme art antérieur. Ce crédit a été contesté. Le 14 octobre, Rain, qui a aidé à construire Mononoke, le composant serveur de Sapling, dans l'équipe de gestion des sources de Meta, a écrit que ne citer Sapling que pour des « leçons durement acquises », sans nommer Mononoke, « frôle le plagiat », et a qualifié Scion de copie dans un second billet le 15 octobre. Ce jour-là, Nick G. a répondu sur Hacker News qu'Anthropic avait cité Sapling parce que c'est ainsi que Meta nomme lui-même l'ensemble du système, et l'article a gagné une note de bas de page disant que Mononoke « a été pionnier de nombreuses techniques que nous utilisons dans Scion », en particulier son modèle de données Bonsai. Rain a ensuite écrit qu'une attribution suffisante avait été ajoutée, tout en maintenant ses deux billets tels qu'ils étaient au moment où ils ont été écrits. Quiconque raconte l'histoire des « sept personnes, cinq mois » devrait ajouter que le modèle de données au cœur du système est un modèle qu'Anthropic attribue désormais à Meta.

La ligne que j'ai soulignée porte sur la revue

La voici : « Les membres de notre équipe relisent encore chaque demande de changement pour le système, mais ils examinent désormais l'intention du changement au lieu de lire chaque ligne de code. »

Note le périmètre. Cette phrase décrit la base de code de Scion et son équipe, pas une politique valable pour tout Anthropic. Mais l'arithmétique à l'échelle de l'entreprise montre pourquoi ça ne restera pas une habitude d'une seule équipe. À dix minutes de lecture attentive par changement, ce qui est généreux pour tout ce qui n'est pas trivial, 30 000 changements par jour représenteraient 5 000 heures de revue, soit 625 personnes qui lisent huit heures par jour sans rien faire d'autre. Au-delà d'un certain volume, la revue ligne par ligne cesse d'être un processus et devient une file d'attente.

Ce qui l'entoure est détaillé ailleurs dans l'article, et ce n'est pas « fais confiance au modèle ». Scion gère des permissions sur des répertoires individuels, pour protéger le code le plus sensible. L'outil de revue sait exprimer des contraintes sémantiques sur les approbations : un changement qui ne touche que des commentaires est traité autrement qu'un changement sensible de logique, et les humains se concentrent sur ceux qui comptent. L'équipe a construit des simulations hermétiques et du fuzzing. Elle utilise la revue adversariale, que l'article juge efficace mais « myope » : une revue était si méfiante envers un autre service interne que Claude a ajouté une validation excessive et de la complexité.

Puis ceci : « Très souvent, nous avons constaté que le rôle des ingénieurs était de dire "non" à Claude. » L'exemple est concret. Plusieurs systèmes essayaient de trouver quand un changement avait été fusionné dans main en lisant le journal des commits de façon linéaire, au lieu d'interroger l'outil de revue de code qui le savait déjà. Chaque ingénieur du projet, dit l'article, estimerait désormais que Claude écrit mieux du code qu'eux. Ce qu'ils apportaient encore, c'était la compréhension au niveau du système et les arbitrages de conception.

Le même article contient une anecdote de l'autre côté. Chargé de réécrire le pipeline d'ingestion de git vers Scion, un instantané interne précoce de Claude Mythos Preview a produit, sans autre consigne, une version qui utilisait 20 fois moins de mémoire et tournait 4 fois plus vite, tout en préservant les invariants sur l'ordre d'ingestion. Écrire le code n'était pas la partie difficile. Savoir ce qu'il ne doit jamais faire, si. Cette fois, le modèle a respecté les invariants ; dans le cas du journal des commits, les agents ne l'ont pas fait.

La file de merge abandonnée

Deuxième surprise : « Une vraie file de merge, par exemple, n'a pas beaucoup de sens à l'échelle des agents. » Anthropic n'a pas pu reproduire le verrou global habituel du dépôt sur la file de merge, et a donc investi dans des tests automatisés après le merge et avant le déploiement. L'article en accepte la conséquence. Des changements concurrents peuvent entrer en conflit, et Claude peut généralement corriger ces conflits plus vite que des humains ne peuvent les repérer. Sur Hacker News, Nick G. a précisé que les conflits textuels ne sont jamais autorisés ; ceux qui passent sont sémantiques, par exemple un nouvel appel à une fonction qui atterrit pendant que quelqu'un d'autre change la logique de cette fonction et met à jour ses appelants existants.

Un changement peut maintenant atterrir avant que tous les tests qui le couvrent aient fini, et la barrière qui compte devient celle d'avant le déploiement. C'est un compromis raisonnable à 30 000 merges par jour. Dans un logiciel qui contient les dossiers juridiques de clients, je voudrais savoir exactement où se trouve cette dernière barrière avant d'emprunter l'idée.

Ce qu'Anthropic dit de ne pas copier

L'article est d'une franchise inhabituelle. « Scion n'est en aucun cas un remplacement adapté de git pour un usage général. » Les concepts n'ont de sens que pour des « monorepos vraiment énormes, avec soit des dizaines de milliers d'ingénieurs, soit des essaims d'agents qui écrivent du code de façon prolifique ». Et : « Anthropic est unique en ce que notre capacité à dépenser des tokens pour un usage interne dépasse de loin ce que n'importe quelle autre entreprise voudrait raisonnablement dépenser. »

Ce n'est pas un produit. Ce qu'Anthropic propose à la place, c'est une prévision et une liste de souhaits. Elle s'attend à ce que « cette classe de problèmes » devienne plus courante « dans les six à 12 prochains mois », et suggère que les plateformes git fournissent des API côté serveur comme celles de Scion, peut-être standardisées entre hébergeurs, et fassent en sorte que les fonctions partielles et superficielles de git se combinent bien. Elle nomme GitHub, GitLab et la communauté open source comme les partenaires qu'elle veut.

Ce que je vérifierais, à une échelle normale

Personne n'a besoin d'un nouveau système de gestion de versions. Ce qui est utile, c'est la liste de ce qui a cédé : les checkouts et la CI, la revue, la file de merge.

Suis les merges par jour et les minutes de CI par changement fusionné, mois par mois. Si les agents doublent le premier chiffre, le second décide de la facture.

Regarde ce que récupère chaque job de CI. S'il clone tout l'historique pour tester la pointe, les options superficielles et partielles qu'Anthropic a dépassées restent la bonne taille pour la plupart des équipes.

Écris quels chemins un humain lit ligne par ligne. Sur GitHub, un fichier CODEOWNERS plus l'option « Require review from Code Owners » dans la protection de branche rend l'approbation d'un propriétaire du code obligatoire avant qu'un changement sur ces chemins puisse être fusionné (pour les dépôts privés, sur un forfait payant). Tout le reste reçoit une revue d'intention : à quoi sert le changement, et quelle contrainte il pourrait casser.

Mets ton « non » par écrit pour l'agent. L'exemple du journal des commits d'Anthropic est le schéma : l'agent recalcule ce qu'un système de référence sait déjà. Une règle comme « demande, ne recalcule pas » a sa place dans les instructions que l'agent lit au début de chaque session, pas seulement dans la tête d'un relecteur.

Si tu achètes un logiciel à un éditeur dont les agents écrivent l'essentiel du code, pose deux questions : ce qu'un humain lit encore ligne par ligne, et où se trouve la dernière barrière de tests avant la production.

Anthropic n'a pas sorti son monorepo de git parce que les agents écrivent du mauvais code. Elle l'a fait parce qu'ils en écrivent beaucoup, et que tout ce qui est en aval était dimensionné pour des personnes. Dans une petite équipe, la première chose dimensionnée pour des personnes, c'est le relecteur.

Sources

Un projet du même genre ?

Je conçois et déploie des produits comme celui-ci. Parlons-en.

Discutons