Anthropic remplace git : 30 000 merges par jour, sept personnes, cinq mois

Anthropic a publié le 13 octobre un billet d'ingénierie qui détaille Scion, son système de contrôle de version maison, et Antique, son outil de revue de code. La raison du chantier tient en deux chiffres : environ 2 500 merges par jour en mai 2026, plus de 30 000 en septembre. Claude écrit une grande partie de ce code, et git ne suivait plus. Sept personnes ont construit et migré l'ensemble en cinq mois. Scion ne sera pas publié en open source.

TL;DRL'essentiel pour les pressés

Les merges quotidiens d'Anthropic sont passés de 2 500 en mai à plus de 30 000 en septembre 2026, portés par le code écrit par Claude. Git est devenu le goulot.
Scion centralise tout côté serveur : commits, merges, blame et historique passent par des API, et les clients ne gardent qu'un cache. Checkouts en secondes, empreinte machine divisée par 200.
Anthropic juge Scion inadapté à la plupart des équipes et dit vouloir travailler avec GitHub, GitLab et l'open source pour appliquer ces idées à git.

600 Pode trafic git par jour qu'auraient généré les 25 millions de checkouts CI quotidiens d'Anthropic sans Scion (estimation Anthropic, octobre 2026)

Git suppose des humains hors ligne, Anthropic n'a que des agents en ligne

Le point de départ est l'architecture de git : chaque client est supposé travailler hors ligne avec une copie complète du dépôt. Or l'historique du monorepo d'Anthropic pèse près de 100 Go, et une copie de travail compressée dépasse 25 Go. Les clients sont presque tous des agents et des jobs CI connectés en permanence. À 25 millions de checkouts par jour, Anthropic a d'abord empilé les contournements, jusqu'à plusieurs centaines de miroirs git internes. Scion inverse le modèle : le serveur fait les commits, les merges, le blame et l'historique, le client ne télécharge que ce qu'il lit. Résultats annoncés : des checkouts en secondes au lieu de minutes, un taux de cache au-dessus de 99 % et 25 % de capacité CPU récupérée sur la CI.

Le billet contient une décision plus parlante que la technique : pas de verrou global sur la file de merge. Des centaines de changements fusionnent pendant que les tests tournent, et les conflits sont assumés, car Claude les corrige plus vite que les humains ne les détectent. La revue de code suit la même logique. Antique distingue un changement cosmétique d'un changement logique sensible, pour concentrer les relecteurs humains sur ce qui compte. La revue adversariale entre modèles a montré sa limite : trop défensive, elle pousse Claude à empiler des validations inutiles. Les ingénieurs relisent désormais l'intention d'un changement, pas chaque ligne.

Très souvent, nous avons constaté que le rôle des ingénieurs consistait à dire non à Claude.

Équipe source control d'Anthropic, billet du 13 octobre

Simon Willison y voit une réinvention du contrôle de version centralisé, dans la lignée de Subversion. Il note aussi que la courbe des merges coïncide avec les sorties de modèles 2026, tout en précisant que ce lien reste une supposition de sa part. Mon avis : notable, pas pour l'outil, que personne n'aura, mais pour le signal. Quand les agents écrivent le code, le goulot se déplace du clavier vers la revue, la CI et le contrôle de version. Pour une équipe française, la partie réutilisable est là : la file de merge, les tests après merge et la revue par intention.

Ce que ça change pour vous

Pour la grande majorité des équipes, git reste le bon outil, et Anthropic le dit elle-même. Le billet se lit comme un aperçu de ce qui casse en premier quand la production de code est multipliée par dix. Si votre équipe fait déjà tourner Claude Code ou un équivalent sur un monorepo, la pression arrivera dans cet ordre. La revue humaine sature, puis la file de merge, puis la CI. Si vous facturez du conseil, retenez le chiffre de l'équipe : sept personnes en cinq mois pour remplacer git, la revue de code et une partie de la CI. Claude a écrit une grande partie du code. Le coût d'un outil interne vient de chuter, celui de la relecture humaine non.

Ce que vous devez faireConcrètement, pour votre visibilité

Mesure ta cadence réelle avec git log --since="1 month ago" --oneline | wc -l, avant et après l'adoption d'agents, pour voir si ta revue suit le rythme.
Active une merge queue (celle de GitHub suffit) plutôt qu'un verrou global si plusieurs agents poussent sur la même branche.
Borne tes agents relecteurs sur l'intention du changement, pas sur chaque ligne, pour éviter la sur-ingénierie défensive décrite dans le billet.