Le 13 octobre, Anthropic a publié un retour d'expérience technique révélant qu'elle a mis cinq mois à faire passer l'ensemble de son monorepo de git à Scion, un système de gestion de versions développé en interne. Dans le même temps, elle a aussi créé un outil de revue de code baptisé Antique. L'équipe centrale ne comptait que 7 personnes.
Le déclencheur est le volume de merges. En mai 2026, le monorepo d'Anthropic enregistrait environ 2 500 merges par jour ; en septembre, ce chiffre dépassait 30 000. Le document indique :
"As our merges per day grew more than tenfold, source control became our biggest development bottleneck."
Lorsque nos merges quotidiens ont plus que décuplé, la gestion du code source est devenue notre principal goulot d'étranglement en développement.
Écrire du code ne bloque plus rien. Ce qui coince, c'est la gestion du code source, le build et la CI.
Là où git ne suit plus
Anthropic avance plusieurs chiffres : l'historique de la branche principale approche 100 Go, la copie de travail compressée dépasse 25 Go, et la CI effectue chaque jour environ 25 millions de checkouts. Si chacun récupérait tout scrupuleusement, le trafic git quotidien dépasserait 600 Po. Aux heures de pointe, l'entreprise fait tourner plusieurs centaines de miroirs git internes ; plus les merges s'accélèrent, plus les miroirs et les instantanés préparés deviennent difficiles à maintenir.
La cause profonde avancée est un décalage entre les objectifs de conception. Git est né pour une collaboration humaine distribuée et hors ligne, où chacun détient un dépôt complet ; les principaux clients d'Anthropic sont aujourd'hui des agents et des tâches automatisées, toujours connectés.
Scion adopte donc la logique inverse : l'historique, le blame, les commits, les merges et les rebases résident tous côté serveur, le client ne conservant qu'un cache local et une copie de travail limités, avec des données récupérées à la demande. Le commit s'achève sur le serveur, et son coût dépend de la taille de la modification, pas de celle du dépôt entier. Seules la branche principale et les branches de release sont conservées ; déplacer un pointeur de branche revient à une opération de comparaison et échange (compare-and-swap) sur une ligne de la base de données. Le client passe par un démon local et des caches à plusieurs niveaux avant d'atteindre le serveur, et le taux de succès du cache dépasse 99 % à chaque niveau.
Un petit calcul
En prenant les chiffres du document pour un calcul approximatif : 600 Po divisés par 25 millions de checkouts font environ 24 Go par checkout, ce qui correspond à peu près à une copie de travail de plus de 25 Go. Les 600 Po sont donc un plafond estimé en supposant une récupération complète à chaque fois.
Répartis sur 24 heures, 30 000 merges représentent un peu plus de 20 par minute. Avec le modèle de push de git, chaque push exige d'abord une synchronisation avec le dépôt distant ; à cette fréquence, les nouvelles tentatives dues aux conflits engorgent la file. Scion déplace le merge côté serveur et supprime l'étape du push. Anthropic a par ailleurs abandonné le verrou de merge global pour s'appuyer sur des tests automatisés après le merge et avant le déploiement ; lorsque des modifications simultanées entrent en collision, elle confie la résolution à Claude.
Le résultat, selon les chiffres de l'entreprise : l'infrastructure Scion consomme environ 200 fois moins de CPU et de mémoire que l'ancien cluster de miroirs git ; les checkouts pour la CI et les tâches de recherche passent de plusieurs minutes à quelques secondes ; la CI à elle seule libère environ 25 % de la capacité CPU.
Ce que Claude a fait dans l'opération
La migration elle-même a aussi fait appel au modèle. Le pipeline d'import de git vers Scion, écrit à la main au départ, a été réécrit par Claude Mythos Preview : l'empreinte mémoire est tombée à 1/20 de l'original et la vitesse a été multipliée par environ 4. Selon le document, Claude a aussi trouvé des optimisations au niveau algorithmique et écrit de nombreux tests, simulations et tests de fuzzing ; le travail des ingénieurs a consisté à tenir l'intention de conception, à écarter les solutions peu raisonnables et à examiner l'intention des modifications plutôt que de lire le code ligne à ligne.
Le retour d'expérience ne détaille pas Antique ; il indique seulement que l'outil permet de définir des règles sémantiques pour les approbations, en séparant les commits qui ne touchent que des commentaires de ceux qui modifient une logique sensible, afin que la relecture humaine se concentre sur ces derniers.
Scion n'est pas open source. Anthropic est catégorique : "Scion is by no means a suitable replacement for git for general use." Les composants internes sont trop personnalisés pour être packagés pour d'autres. L'entreprise espère que GitHub, GitLab et la communauté open source s'inspireront d'idées comme le RPC côté serveur et le sparse checkout pour faire évoluer git. Piper de Google et Sapling, publié en open source par Meta, ont suivi des voies similaires ; la différence est que, cette fois, la pression à réécrire vient du volume de code produit par l'IA.
Sources : Anthropic Engineering Blog, CocoLoop ; les merges quotidiens, le nombre de checkouts et les facteurs de consommation de ressources sont des chiffres déclarés par Anthropic, et la taille d'un checkout est un calcul approximatif de la rédaction à partir de ces données.