Anthropic a publié le 13 octobre un billet détaillant le remplacement de Git par un système de
gestion de versions maison, baptisé Scion, pour l’ensemble de son monorepo interne. L’entreprise
explique que la croissance du volume de code généré par ses propres agents Claude a fini par
saturer l’infrastructure Git classique, pensée pour des développeurs humains et non pour des
milliers de clients automatisés toujours connectés.
Un volume de changements multiplié par douze en quatre mois
Le nombre de changements fusionnés chaque jour sur le monorepo est passé d’environ 2 500 en
mai 2026 à plus de 30 000 en septembre. L’historique de la branche principale pèse près de
100 Go, et une copie de travail compressée dépasse 25 Go. Les seules vérifications continues
représentaient environ 25 millions de clonages quotidiens, avant même de compter les
environnements de développement, les bacs à sable des agents et les tâches de recherche.
Pourquoi Git ne suivait plus
Le modèle de Git repose sur une copie complète de l’historique à chaque clonage, un choix
raisonnable quand les clients sont des postes de développeurs occasionnellement connectés. Chez
Anthropic, la quasi-totalité des clients sont des agents ou des tâches d’intégration continue
toujours en ligne : récupérer naïvement l’historique aurait représenté plus de 600 pétaoctets de
trafic Git par jour. Pour compenser, l’entreprise exploitait plusieurs centaines de miroirs Git
internes, une infrastructure devenue elle-même le principal poste de coût.
| Indicateur | Avant (miroirs Git) | Avec Scion |
|---|---|---|
| Changements fusionnés / jour | ~2 500 (mai 2026) | >30 000 (septembre 2026) |
| Empreinte CPU/mémoire de l’infrastructure | Référence | ~200 fois plus faible |
| Durée d’un clonage CI | Plusieurs minutes | Quelques secondes |
| Capacité CPU disponible pour la CI | Référence | +25 % |
| Taux de succès du cache (par étage) | Variable | >99 % |
Scion et Antique : l’architecture retenue
Scion remplace le modèle de Git par un journal d’écriture : chaque changeset décrit
les fichiers modifiés par rapport à son premier parent et pointe vers des blobs adressés par leur
contenu, sans fichiers pack ni verrouillage de référence. Les données dérivées
(blame, historique de chemin, graphe de commits) se calculent de manière récursive à partir des
changesets parents, et les clients ne récupèrent que les arbres et blobs dont ils ont réellement
besoin — ce qui rend les clonages partiels natifs, sans configuration particulière. Trois étages
de service (démon local, caches régionaux, serveurs faisant autorité sur Spanner) maintiennent
chacun un taux de succès de cache supérieur à 99 %. Antique, l’outil de revue de code associé,
complète l’ensemble avec la recherche de code et des permissions fines par source.
Historique Git classique :
clone complet -> ref locking -> packfiles -> fetch coûteux pour un agent
Modèle Scion :
changeset (write-ahead log) -> blobs adressés par contenu -> fetch partiel
par étages (démon local / cache régional / serveur Spanner), >99% hit rate
« Le goulot d’étranglement, désormais, c’est toute l’infrastructure de développement construite pour l’échelle humaine. »
Scion n’est pas un produit public ni un remplaçant généraliste de Git : Anthropic le précise
explicitement dans son billet. L’intérêt pour les équipes web ordinaires reste indirect, mais
illustre une tension qui touchera d’autres éditeurs d’outils à mesure que les
agents éditoriaux en production et les pipelines
pilotés par des agents de code génèrent un volume de changements que les files d’attente de
fusion classiques n’ont pas été conçues pour absorber.
Une équipe de sept personnes, cinq mois de migration
La construction de Scion, d’Antique et d’une demi-douzaine de systèmes annexes a mobilisé sept
personnes pendant cinq mois, Claude ayant lui-même écrit une grande partie du code de migration.
Les ingénieurs décrivent leur rôle comme consistant surtout à dire non à Claude lorsqu’il
cherchait à sur-ingénierer une solution, et à revoir l’intention des changements plutôt que
chaque ligne. Le billet va jusqu’à affirmer que l’ensemble des ingénieurs ayant travaillé sur ce
projet estime désormais Claude meilleur qu’eux pour écrire du code — une déclaration à prendre
avec la prudence habituelle sur les billets publiés par l’éditeur du modèle lui-même, mais qui
recoupe des retours similaires ailleurs dans l’écosystème, notamment autour du
protocole MCP et de son adoption rapide dans
les chaînes d’outillage agentique.
Ce qu’il faut retenir
Le cas Anthropic reste un cas extrême, propre à une entreprise qui fait tourner ses propres
agents à très grande échelle sur son propre code. Il offre néanmoins un signal utile : les
outils de gestion de versions et d’intégration continue pensés pour des humains occasionnellement
connectés commencent à montrer leurs limites face à des clients automatisés permanents, et des
alternatives à Git centrées sur le serveur gagneront probablement en visibilité dans les mois qui
viennent, sans pour autant remplacer Git pour l’immense majorité des équipes.
Je reste sceptique sur la portée pratique de ce genre d’annonce pour la plupart des équipes que
j’accompagne : aucune d’entre elles n’approche, et de très loin, les 30 000 changements
quotidiens qui ont motivé ce chantier. Ce qui me semble en revanche à surveiller, c’est la
pression croissante que les agents de code mettent sur les CI classiques, même à une échelle bien
plus modeste — un sujet qui, lui, concerne déjà les projets sur lesquels j’interviens. —
Simon Janvier
Pour aller plus loin : le billet complet est disponible sur
le blog d’ingénierie d’Anthropic.
