Anthropic a reconstruit le contrôle de version pour une charge de travail d’agents toujours connectés

Anthropic indique que son monorepo interne est passé d’environ 2 500 changements fusionnés par jour en mai à plus de 30 000 par jour en septembre 2026. Son récit d’ingénierie du 13 octobre décrit Scion, un système de contrôle de version conçu pour les agents et les tâches automatisées à l’origine d’une grande partie de cette croissance. La question d’ingénierie utile est de savoir quel travail un client doit encore effectuer lorsqu’il peut s’appuyer sur un service central pour l’historique, les commits et les fusions.

Le grand changement

• Ce qui a changé : Anthropic a transféré son monorepo de Git à Scion en cinq mois. Les clients Scion ne récupèrent que les objets nécessaires et confient commits, fusions, rebasages et requêtes d’historique à un serveur. Anthropic l’a conçu pour une charge dominée par des agents et des tâches en ligne.
• Pourquoi c’est important : Une tâche CI peut demander un diff ou une base de fusion via une API sans maintenir de dépôt local. Lorsqu’elle a besoin de fichiers, une extraction partielle ou virtualisée limite ce qui est écrit sur le disque. Les coûts et la responsabilité opérationnelle sont ainsi déplacés vers le service central.
• Points à suivre : Anthropic fait état d’extractions plus rapides et d’une utilisation moindre de l’infrastructure dans son propre parc, sans validation indépendante ici. L’entreprise précise que Scion est un système interne sur mesure et que la migration a également nécessité des changements pour la revue de code, la recherche et la CI.

Pourquoi Git est devenu coûteux dans ce monorepo

La conception distribuée de Git donne à chaque clone complet l’historique et les objets nécessaires au travail hors ligne. Anthropic indique que l’historique de la branche principale de son monorepo approche 100 Go, tandis qu’une copie de travail compressée dépasse 25 Go. Son parc CI effectue environ 25 millions d’extractions de code par jour, sans compter les environnements de développement, les bacs à sable des agents et les tâches de recherche. Ce sont les chiffres de charge de travail d’Anthropic, pas un seuil général au-delà duquel Git cesse de fonctionner.

L’entreprise utilisait déjà des clones superficiels, des extractions partielles, des miroirs internes et des instantanés du dépôt. Elle affirme que plusieurs centaines de miroirs sont devenus difficiles à exploiter avec la croissance du dépôt et du rythme des fusions. Le diagnostic d’Anthropic est spécifique : la plupart de ses clients étaient déjà des agents ou des tâches en ligne, mais les outils supportaient encore une grande partie du coût de conservation d’un dépôt local.

Scion prend cette connexion en ligne comme hypothèse de conception. Le récit d’ingénierie indique que le serveur répond aux requêtes d’historique et d’attribution, crée les commits et exécute les fusions et les rebasages. Le client conserve un cache d’objets de taille limitée, écrit les fichiers de travail demandés sur le disque et surveille les changements locaux. Renoncer à exécuter ces opérations de façon autonome est un compromis délibéré pour transférer moins de données à chaque client.

Une extraction peut être plus petite, voire inutile

Scion expose par API les requêtes de contrôle de version utilisées par ses clients. Anthropic indique qu’une tâche CI ayant besoin d’un diff depuis une base de fusion peut interroger directement le serveur. Ses pipelines automatisés de bissection et d’annulation utilisent la même voie programmatique. Pour ces tâches, il se peut que la tâche n’ait jamais besoin de matérialiser une copie de travail.

Lorsqu’une tâche a besoin de fichiers, Scion prend en charge les extractions partielles limitées aux répertoires demandés et les extractions virtualisées qui matérialisent les fichiers lors de leur lecture. Le client demande récursivement les arbres et blobs spécifiques qui lui manquent, plutôt que de négocier un grand packfile. Chaque objet demandé possède une identité immuable adressée par contenu ; les caches peuvent donc le renvoyer sans vérifier si son contenu a changé. Anthropic décrit un démon au niveau du nœud et des caches régionaux entre les clients et les serveurs faisant autorité ; tous les niveaux utilisent le même protocole de demande d’objets.

Cette conception place différemment les limites de panne et de maintenance par rapport à un clone local complet. Le client dépend du service pour des opérations que Git peut effectuer hors ligne, et le service doit fournir des requêtes d’objets et d’historique au rythme du parc. Anthropic indique qu’elle applique des niveaux de cache notamment pour éviter qu’une panne régionale ne submerge les serveurs en amont. L’article ne fournit pas de mesures de disponibilité de cette architecture.

Ce que le serveur stocke et calcule

L’unité de travail de Scion est un changeset dans un journal à écriture anticipée. Anthropic indique qu’il enregistre les fichiers modifiés par rapport à un premier parent, avec des pointeurs vers les contenus compressés dans le stockage blob. Le serveur crée des changesets sans déplacer un pointeur de branche partagé à chaque écriture. Des structures dérivées distinctes prennent en charge des requêtes telles que l’attribution d’un fichier, l’historique d’un chemin et l’ascendance d’un commit ; Anthropic peut en calculer certaines immédiatement et différer les autres.

Cette séparation compte dans la conception de l’API. Les tâches peuvent demander une base de fusion ou l’historique d’un fichier sans embarquer toutes les structures nécessaires à un calcul local. Le coût d’entretien de ces structures est lui aussi transféré au service d’Anthropic. L’entreprise indique qu’elle distribue les données du dépôt et dimensionne séparément ses composants, sans copie entièrement matérialisée du dépôt, même sur le serveur.

Anthropic affirme que l’infrastructure de Scion utilise 200 fois moins de CPU et de mémoire que son ancien système de miroirs Git, et que les extractions CI et recherche prennent désormais quelques secondes plutôt que quelques minutes. Elle attribue à ce changement un gain de 25 % de capacité CPU dans la CI. Ces comparaisons portent sur l’ancien système interne d’Anthropic et sa propre charge de travail ; BIG CHANGE n’a pas reproduit les mesures ni examiné la télémétrie sous-jacente.

Le coût de migration fait partie du résultat

Anthropic indique que sept ingénieurs ont construit Scion, un outil compagnon de revue de code appelé Antique et les systèmes associés, puis migré le monorepo en cinq mois. Ce récit décrit aussi une nouvelle recherche de code, le contrôle d’accès et des changements dans la revue et l’intégration du code. Une organisation qui évalue cette conception doit tenir compte de ces flux de travail connexes, ainsi que du service de contrôle de version lui-même.

Anthropic précise explicitement que Scion ne convient pas comme remplacement général de Git. Ses composants internes de revue, de recherche et de CI sont sur mesure, et abandonner Git nécessiterait des changements dans tout le cycle de développement. La leçon plus restreinte de son récit est architecturale : un service en ligne peut répondre à davantage de questions de contrôle de version pour des clients automatisés, tandis que ceux-ci ne conservent que les fichiers utilisés. Anthropic suggère que certaines idées — notamment des API serveur plus riches et une meilleure combinaison des fonctions sparse et shallow de Git — pourraient être appliquées sans adopter Scion.

Sources et lectures complémentaires

• Anthropic Engineering, « Redesigning source control at Anthropic » (13 octobre 2026). Le récit de première main d’Anthropic sur l’architecture Scion, la migration et les chiffres internes de charge de travail et de performance. BIG CHANGE n’a pas vérifié indépendamment les mesures et résultats opérationnels rapportés ; aucun système Scion n’a été testé pour cet article.