Anthropic remplace git par Scion alors que les fusions dépassent 30 000 par jour
Anthropic a migré son monorepo de git vers Scion, un système de gestion de versions maison, après que les fusions quotidiennes sont passées d'environ 2 500 en mai 2026 à plus de 30 000.
4 min de lecture

En chiffres
- code changes merged per day in September, up from about 2,500 in May
- 30,000+
- size of the main branch's history
- ~100 GB
- less CPU and memory than the old git mirrors, per Anthropic
- ~200x
- to migrate, with a team of seven
- 5 months
Anthropic a migré son principal dépôt de code de git vers Scion, un système de gestion de versions qu'elle a créé elle-même. L'entreprise indique avoir fusionné environ 2 500 modifications de code par jour en mai 2026, et plus de 30 000 par jour en septembre. The Register attribue ce bond au fait que Claude écrit une plus grande part du code de l'entreprise. Git repose sur l'idée que chaque copie contient l'historique complet. Ce principe a perdu son sens quand presque tous les utilisateurs sont devenus des agents d'IA toujours connectés. Anthropic a décrit le système le 13 octobre, mais ne le publiera pas.
Pourquoi git a cessé de fonctionner
« Le goulot d'étranglement, désormais, c'est toute l'infrastructure de développement conçue à l'échelle humaine », écrit Anthropic dans son billet d'ingénierie. Écrire du code n'est plus l'étape lente. Les étapes lentes sont la gestion de versions, les builds et l'intégration continue (CI), les tests automatisés qui s'exécutent à chaque modification.
Le dépôt est un monorepo, un dépôt unique qui contient la majeure partie du code de l'entreprise. Sa taille explique la pression :
| Mesure | Chiffre |
|---|---|
| Historique de la branche principale | Près de 100 Go |
| Copie de travail compressée | Plus de 25 Go |
| Checkouts par jour pour la seule CI | Environ 25 millions |
| Trafic git si chaque checkout était un simple clone | Plus de 600 Po par jour |
| Miroirs git internes au pic | Plusieurs centaines |
Anthropic a essayé les solutions habituelles. Elle a utilisé des clones superficiels et partiels (shallow et sparse), qui ne téléchargent qu'une partie d'un dépôt. Elle a aussi utilisé des miroirs internes et des copies préconstruites. Chacune de ces solutions est devenue plus difficile à gérer à mesure que les fusions augmentaient. Les copies préconstruites s'écartaient de la branche principale, et des outils comme diff et blame ne fonctionnaient plus sur les clones partiels.
Comment fonctionne Scion
Scion part du principe que ses clients sont toujours connectés. Le serveur gère l'historique, le blame, les commits, les fusions et les rebases. Chaque machine ne conserve qu'un cache local limité et sa copie de travail, c'est-à-dire les fichiers qu'elle modifie réellement.
Chaque modification est stockée sous forme de changeset dans un journal d'écriture anticipée (write-ahead log), un registre continu des modifications. Il liste les fichiers modifiés et pointe vers leur contenu dans un stockage de blobs. Les fichiers sont récupérés à la demande. Un checkout ne télécharge donc jamais d'abord un paquet de plusieurs gigaoctets.
Scion fonctionne sur trois niveaux : un daemon sur chaque machine, un cache dans chaque région et un serveur qui fait autorité. Anthropic indique que chaque niveau de cache répond à plus de 99 % des requêtes. Les branches autres que main et les branches de release sont déconseillées.
Scion ne remplace pas git à l'identique. Nick G., ingénieur sur Scion, a expliqué ce compromis sur Hacker News, cité par Simon Willison. « Comme Claude est de loin le plus gros utilisateur de Scion et qu'il est forcément connecté, ce n'était tout simplement pas important à faire », a-t-il écrit. Willison compare le résultat à d'anciens systèmes centralisés comme Subversion.
Ce qu'Anthropic dit avoir gagné
Anthropic rapporte ces résultats sur les dépôts qui fonctionnent nativement sur Scion :
- Environ 200 fois moins de CPU et de mémoire que ses anciens miroirs git.
- Des checkouts de CI et de recherche environ 100 fois plus rapides, en quelques secondes au lieu de plusieurs minutes.
- Une baisse de 25 % du CPU utilisé par son système de CI.
Sept personnes ont construit Scion, un outil de revue de code appelé Antique et environ une demi-douzaine de systèmes associés. La migration a pris cinq mois. The Register rapporte que le travail sur Scion a commencé en janvier 2026.
Les autres outils comprennent la recherche de code, des permissions d'accès par répertoire et un moyen d'intégrer des modifications sans file de fusion globale unique. L'équipe les a construits avec l'aide de Claude. Une réécriture par Claude du premier pipeline d'import de git vers Scion a utilisé 20 fois moins de mémoire et tourné quatre fois plus vite, selon Anthropic.
Des humains ont tout de même piloté le travail. « Très souvent, nous avons constaté que le rôle des ingénieurs était de dire “non” à Claude », a déclaré Anthropic, citée par The Register.
Quelqu'un d'autre aura-t-il accès à Scion ?
Non. Anthropic indique que Scion est difficile à proposer sous une forme utile au plus grand nombre et qu'il n'est pas adapté à un usage général. L'entreprise partage plutôt sa conception. Elle dit vouloir travailler avec GitHub, GitLab et la communauté open source.
Le billet suggère des idées que les hébergeurs git pourraient reprendre sans changer le fonctionnement de git. Il s'agit notamment de faire davantage de travail côté serveur et de rendre plus simple la combinaison des clones partiels et superficiels. Git lui-même évolue aussi : nous avons couvert le débat sur SHA-256 par défaut dans Git 3.0 plus tôt ce mois-ci.
Ce que cela signifie pour les développeurs
- Git reste adapté à la plupart des équipes. The Register note que git reste le bon choix pour la plupart des dépôts. Scion résout un problème qui apparaît à des dizaines de milliers de fusions par jour.
- Surveillez le coût des checkouts de CI à mesure que les agents se multiplient. Environ 25 millions de checkouts par jour, c'est ce qui a fait céder git ici. Si vos agents clonent le dépôt pour chaque tâche, mesurez ce trafic dès maintenant.
- Traitez les agents comme des clients toujours connectés. Les copies hors ligne comptent pour les humains, pas pour les agents qui tournent dans le cloud. Les outils qui récupèrent les fichiers à la demande peuvent réduire le coût de chaque exécution d'agent.
- Attendez-vous à ce que les hébergeurs git reprennent ces idées. Anthropic veut que GitHub et GitLab adoptent une partie de la conception. Les opérations côté serveur et de meilleurs clones partiels sont les premières étapes probables.
- Gardez des humains dans la revue. Les ingénieurs d'Anthropic ont passé une grande partie de leur temps à rejeter les suggestions de Claude. Prévoyez cette charge de revue quand les agents écrivent la majeure partie du code.
Sources
Articles liés

Les stacked pull requests de GitHub sont désormais disponibles pour tous
GitHub a rendu les stacked pull requests disponibles pour tous le 6 octobre 2026, sur toutes les offres github.com, avec des files de fusion adaptées aux piles et la CLI gh stack.

Claude Code 2.1.287 ajoute Claude Mods pour des plugins qui vont plus loin
Claude Code 2.1.287, sorti le 1er octobre, permet aux plugins de modifier le comportement profond de l'agent via Claude Mods et ajoute un agent annexe facultatif qui signale les erreurs.

Claude Code ne lit AGENTS.md que si la télémétrie est activée
La prise en charge d'AGENTS.md dans Claude Code 2.1.277 dépend d'un feature flag distant et cesse en silence sans télémétrie, montre une issue GitHub.