Anthropic abandonne git pour Scion en cinq mois : 30 000 merges par jour

En mai 2026, Anthropic mergeait environ 2 500 changements de code par jour dans son monorepo. En septembre, ce chiffre dépassait 30 000. Écrire du code n'est plus le problème : Claude itère sur des cycles de recherche, optimise des programmes complexes et met en place des services à partir de zéro.

Le goulot d'étranglement s'est déplacé vers une infrastructure conçue pour des humains : contrôle de version, builds et CI. Pour le desserrer, l'entreprise a migré en cinq mois la totalité de son monorepo de git vers Scion, son propre système. Elle a aussi développé en parallèle Antique, un outil de revue de code, un moteur de recherche dans le code et un système IAM pour le source control.

Où git ne suffisait plus

Git est décentralisé : chaque clone est un dépôt à part entière, capable de calculer des diffs, de lire l'historique et de fonctionner sans réseau. Pour la plupart des projets, c'est la bonne conception. Chez Anthropic, elle a fini par gêner. L'historique de la seule branche main pèse près de 100 Go, et la copie de travail compressée dépasse 25 Go. Le CI exécute environ 25 millions de checkouts par jour, sans compter l'environnement des développeurs, les sandbox des agents et les tâches de recherche. Avec un téléchargement naïf, cela représenterait plus de 600 Po de trafic git par jour.

L'équipe a tout essayé : shallow clone, sparse checkout, promisor remotes, miroirs internes et snapshots dans un stockage de blobs. Au plus fort, plusieurs centaines de miroirs git étaient en service. Ils faisaient gagner du temps, mais devenaient de plus en plus difficiles à maintenir à mesure que le merge rate augmentait. Les snapshots prenaient du retard sur la tête de main, et diff et blame sur des clones partiels exigeaient toujours plus d'entretien. La conclusion de l'équipe : git servait de système centralisé avec une seule copie de référence, et ses clients étaient des agents et des jobs, en ligne par définition. Les propriétés précieuses pour le travail hors ligne freinaient le passage à l'échelle.

Comment fonctionne Scion

Dans Scion, l'unité de travail est le changeset, une entrée dans un write-ahead log. Au lieu d'un pointeur vers un arbre, il stocke la liste des fichiers modifiés par rapport au premier parent, ainsi que des références adressables par contenu vers des données compressées dans le stockage de blobs. Le changeset est créé côté serveur et immédiatement disponible partout. Il n'y a ni packfile, ni verrou, ni coordination entre serveurs. Un ref, si nécessaire, se déplace par compare-and-swap sur une seule ligne dans Spanner, indépendamment de la création du changeset.

Les questions du type « qui a modifié cette ligne en dernier » sont traitées par des données dérivées : structures pour blame, historiques de chemins et skip-lists du graphe de commits. Chaque type est défini récursivement à partir des valeurs des parents. On peut le calculer immédiatement ou à la demande, et modifier son fonctionnement interne sans toucher au client.

Le client scn ne dit pas au serveur ce qu'il possède déjà. Il part de l'arbre racine, demande les arbres manquants, puis les blobs. Chaque requête porte sur un objet immuable, ce qui permet à n'importe quel cache d'y répondre. Le nœud dialogue avec un scion-daemon local, qui récupère les données auprès des scion-cache régionaux ; en cas de défaut de cache, ceux-ci interrogent les scion-server faisant autorité. Cette séparation stricte des niveaux isole les pannes : la défaillance d'un cache régional ne doit pas faire tomber le centre. Les checkouts sparse et virtualisés sont pris en charge sans logique particulière : le client se contente de ne pas demander les arbres superflus.

Ce que l'entreprise présente comme résultats :

• passage de 2 500 à 30 000+ merges par jour (mai — septembre 2026) ;
• migration du monorepo hors de git en cinq mois ;
• infrastructure Scion 200 fois plus petite que les miroirs git en CPU et en mémoire ;
• checkouts dans le CI et les tâches de recherche plus rapides de deux ordres de grandeur : des secondes au lieu de minutes ;
• cache hit rate supérieur à 99% à chaque niveau ;
• gain de 25% de puissance CPU pour le seul CI.

Ce qu'il faut en retenir

Les principes d'Anthropic s'appuient sur Google Piper et Meta Sapling : clients toujours en ligne, serveur chargé du gros du travail, commits peu coûteux et sans verrou, copie de travail facultative. Toutes les requêtes du client sont aussi exposées sous forme d'API, si bien que les tâches de CI n'ont souvent pas besoin de dépôt local. C'est sur cette base que reposent les pipelines internes de bisect et de revert automatiques, qui seraient autrement impraticables à grand volume.

Anthropic précise elle-même que sa charge est atypique et que beaucoup d'équipes ne risquent pas de rencontrer ces problèmes prochainement. Mais si une équipe fait déjà tourner des dizaines d'agents, elle gagnerait à mesurer combien de checkouts elle effectue par jour, ce que lui coûtent les miroirs et à quelle distance de la tête de main ses snapshots restent. On peut commencer par déporter dans un service des métadonnées comme diff, merge base et blame, comme Anthropic l'a fait dans Scion au début de la migration.

Anthropic note également que Claude Mythos Preview et Claude Tag, apparus en interne durant ces mêmes mois, ont renforcé le besoin de Scion et accéléré son développement.