Refonte du contrôle de version chez Anthropic : Scion remplace git pour le monorepo

Anthropic a fait évoluer son infrastructure de développement pour répondre à une contrainte nouvelle : le goulot d'étranglement n'est plus l'écriture du code, mais les outils conçus pour une échelle humaine. Selon l'article, la production de code est devenue telle que le nombre de changements fusionnés par jour dans le monorepo de l'entreprise est passé d'environ 2 500 en mai 2026 à plus de 30 000 en septembre. L'entreprise attribue cette accélération à Claude, qui automatise une part croissante des boucles de recherche, des optimisations et de la construction de nouveaux services.

Pour absorber cette croissance, Anthropic a développé Scion, un système de contrôle de version interne, et a migré l'intégralité de son monorepo depuis git en cinq mois. Le même calendrier a vu naître une interface de revue de code appelée Antique, une recherche de code, un système de gestion des droits sur le contrôle de source et de nouvelles méthodes pour intégrer de grands volumes de code relu.

Le point de départ technique est un constat sur la nature même de git. Ce système est décentralisé : chaque clone est un dépôt complet capable de fonctionner hors ligne. Cette conception convient à la grande majorité des dépôts, mais pas au monorepo d'Anthropic, dont l'historique de la branche principale dépasse 100 Go et qui subit environ 25 millions de checkouts quotidiens pour la CI, sans compter les environnements de développement, les bacs à sable des agents et les tâches de recherche. Les contournements habituels (clones superficiels, checkouts partiels, miroirs internes git, snapshots stockés dans du blob storage) ont été employés, jusqu'à plusieurs centaines de miroirs à leur pic, mais leur exploitation est devenue de plus en plus difficile à mesure que le rythme de fusion augmentait.

Le raisonnement de l'équipe repose sur une observation : presque tous les clients de ce monorepo sont des agents et des tâches, c'est-à-dire des entités toujours connectées par définition. Les propriétés qui font la force de git pour le travail distribué et hors ligne deviennent alors un frein. Scion repose donc sur plusieurs principes différents : des clients toujours en ligne, une asymétrie client-serveur où le serveur assure l'essentiel des calculs (historique, blame, création de commits, fusions, rebases), une exposition de toutes les requêtes de contrôle de source via API, une scalabilité horizontale de chaque composant, des commits peu coûteux et sans verrou, et un working copy facultatif et sparse par conception. L'article cite explicitement Piper, de Google, et Sapling, de Meta, comme antériorités dont l'équipe a tiré des leçons.

Sur le plan architectural, l'unité de travail est un « changeset », une entrée dans un journal d'écriture anticipée qui ne stocke que les fichiers modifiés et leurs pointeurs vers un contenu adressé par hash. Les structures dérivées, comme l'index de blame, l'historique des chemins ou les skip lists du graphe de commits, sont calculées par un mécanisme générique et récursif, ce qui permet d'en ajouter sans modifier le client. Le protocole de récupération, lui, ne négocie pas ce que le client possède déjà : il demande les arbres et blobs manquants à partir d'une racine, ce qui rend chaque requête cacheable et reprenable. Une architecture à trois niveaux (scion-daemon, scion-cache régional, scion-server) isole les domaines de panne. Selon l'article, les caches atteignent plus de 99 % de taux de succès, l'empreinte d'infrastructure est 200 fois plus petite que l'ancienne infrastructure de miroirs git en CPU et mémoire, et les checkouts de CI sont passés de minutes à quelques secondes, avec un gain de 25 % de capacité CPU pour la seule CI.

L'article tire aussi des enseignements sur le rôle des ingénieurs. L'équipe de sept personnes a construit Scion et Antique en parallèle de plusieurs systèmes annexes. Selon l'article, le travail humain a consisté en grande partie à dire « non » aux agents, qui contournaient parfois des contraintes du système pour satisfaire un motif de code inapproprié. Les équipes relisent désormais l'intention des changements plutôt que chaque ligne. Anthropic décrit aussi l'usage de « superfans » — des instances de Claude dédiées à la surveillance d'un composant — et l'abandon de la file de fusion traditionnelle, remplacée par des tests post-fusion et pré-déploiement.

Plusieurs questions restent ouvertes. L'article précise que Scion n'est pas destiné à remplacer git pour un usage général et que ses composants internes sont trop spécifiques pour être publiés tels quels. Anthropic dit vouloir partager sa réflexion afin que d'autres puissent appliquer certains principes à git, sans que le calendrier, les gains annoncés ou la reproductibilité hors de son contexte puissent être évalués de manière indépendante à partir du texte seul.