Scion : pourquoi Anthropic a remplacé Git pour ses agents

Le test attend encore son code

Votre agent corrige une fonction. La modification est prête, mais le retour des tests tarde. Dans les journaux, le compilateur n’a même pas démarré : la machine prépare son environnement et récupère le dépôt. Accélérer la génération du code ne raccourcit pas cette partie du parcours.

Imaginons mille tâches indépendantes, chacune chargée de vérifier une petite partie du même projet. Elles consultent des versions très proches. Si elles reconstruisent toutes leur environnement depuis zéro, le réseau et les disques servent plusieurs fois les mêmes données. Cet exemple est pédagogique ; ce n’est pas une mesure du système d’Anthropic.

Le 13 octobre, Anthropic annonce avoir migré son monorepo vers Scion. L’entreprise rapporte environ 25 millions de checkouts quotidiens en CI. Sept personnes ont construit l’ensemble Scion, Antique et des services associés, puis migré en cinq mois. Scion crée les changements côté serveur, calcule des index dérivés et distribue des objets via des caches locaux et régionaux, avec Spanner et du stockage objet en amont. Retour d’ingénierie.

Pour comprendre ce choix, suivons notre tâche de test. Le dossier distingue les mécanismes documentés chez d’autres acteurs, nos exemples de calcul et les questions qui restent ouvertes. Aucun test de Scion n’a été exécuté par LeCompute.

Ce que Git sait déjà éviter

Trois volumes doivent être séparés : l’historique disponible, les contenus téléchargés et les fichiers présents sur disque. Git permet de limiter l’historique avec un clone superficiel et de différer des contenus avec un clone partiel. Le sparse checkout sélectionne les fichiers du répertoire de travail. Documentation de clone, sparse checkout.

Anthropic dit avoir déjà utilisé ces optimisations, des miroirs et des instantanés du dépôt. Ils ont retardé la migration sans suffire à sa charge. Solutions Git employées.

Dans notre exemple, le test d’un parseur peut n’avoir besoin que de son répertoire et de quelques dépendances. Limiter les fichiers visibles ne suffit cependant pas à prouver que le transfert initial était petit. Inversement, économiser le téléchargement d’un objet ne signifie pas que le test ne le demandera jamais : il peut le récupérer plus tard. Le chronomètre doit donc continuer jusqu’au moment où le travail utile commence.

Il faut aussi séparer la représentation logique du stockage physique. Un commit Git référence une arborescence ; les objets inchangés sont réutilisés. Cela ne signifie pas qu’une nouvelle copie physique de tous les fichiers est enregistrée à chaque commit. Objets Git.

Les packfiles regroupent les objets et peuvent représenter certains d’entre eux par des différences avec d’autres. Cette compression échange du calcul contre de l’espace et des transferts. Son intérêt dépend de la charge, et la réutilisation de packs ou de deltas compte aussi : chaque requête ne reconstruit pas nécessairement tout depuis zéro. Documentation de git-pack-objects.

Pour notre flotte, la question devient précise : quelle part du temps vient du transfert, quelle part vient de la décompression, et quelle part vient de l’écriture des fichiers ? Une seule durée intitulée « clone » masque ces différences.

Git peut aussi mutualiser les objets : plusieurs worktrees partagent un dépôt, et un clone peut utiliser un dépôt de référence. Ces mécanismes réduisent certaines copies ; ils ne constituent pas à eux seuls une isolation entre tâches non fiables. Worktrees, dépôt de référence.

Enregistrer un changement, préparer les réponses

Dans Scion, un changeset énumère les fichiers modifiés relativement au premier parent. Des API peuvent éviter un checkout aux tâches qui demandent seulement un diff. Structures et API décrites.

Le précédent technique de Meta est particulièrement instructif. Mononoke, le serveur de Sapling, conserve un modèle central nommé Bonsai, puis en dérive d’autres représentations. Son architecture sépare les chemins d’écriture et de lecture, avec des services dimensionnables indépendamment. Architecture de Mononoke.

Prenons un fichier dont notre agent modifie une fonction. Accepter cette modification et répondre à « qui a écrit chaque ligne ? » ne demandent pas les mêmes opérations. Le premier besoin est de conserver un changement correctement relié à son histoire. Le second exige une manière efficace de parcourir ou d’indexer cette histoire. Les réunir dans une opération unique peut faire attendre l’écriture pour préparer une réponse que personne ne demandera.

Mononoke documente des données dérivées pour les arborescences, les historiques et l’attribution des lignes. Elles peuvent être calculées à la demande ou en arrière-plan, puis conservées pour les lectures suivantes. Mécanisme de dérivation.

La conséquence est facile à suivre : notre premier lecteur peut payer un calcul, tandis que les suivants réutilisent son résultat. Mais il faut mesurer ce premier accès. Déplacer du travail après l’écriture ne le rend pas gratuit ; cela change le moment où il est payé et les ressources qui l’exécutent.

Un dépôt central peut être servi par plusieurs machines

Dans Software Engineering at Google, publié en 2020, les auteurs distinguent l’autorité centrale d’un projet de la nature distribuée d’un outil. Une équipe peut utiliser Git tout en désignant un dépôt comme référence. Ils décrivent Piper, le système central spécialisé de Google. C’est un précédent historique, pas un relevé de son infrastructure en octobre 2026. Chapitre sur le contrôle de versions.

Pour notre exemple, une référence unique permet de dire quelle version est testée. Elle n’oblige pas à faire passer chaque lecture de fichier par une seule machine. Les contenus stables peuvent être copiés près de leurs lecteurs. En revanche, une information mutable comme « quelle version est désormais la référence ? » demande des règles de coordination.

Le choix d’un stockage transactionnel n’efface pas cette question. Spanner documente des transactions atomiques et des garanties de cohérence ; une application doit encore choisir quelles mises à jour placer dans une transaction. Il serait donc imprudent d’assimiler l’absence d’un verrou applicatif global à l’absence de toute coordination. Transactions Spanner.

Réutiliser les données sans promettre un miracle

Revenons aux mille tâches. Hypothèse de calcul : chacune a besoin de 200 Mo de données compressées identiques. Mille transferts indépendants représentent 200 Go, avec les unités décimales. Si les tâches sont regroupées sur dix machines et qu’un cache commun à chaque machine ne récupère ces données qu’une fois, le trafic provenant de l’amont descend à 2 Go.

Ce rapport de cent concerne uniquement ce trafic, dans cet exemple idéal. Il ne dit rien du temps CPU des tests. Les fichiers peuvent encore être écrits dans mille répertoires isolés ; les lectures locales, la décompression et les métadonnées du système de fichiers restent à payer. Les nouvelles versions et les évictions du cache réduiraient aussi le partage.

EdenFS, dans l’écosystème Sapling, rend les fichiers disponibles à la demande. Microsoft avait également développé GVFS pour son usage de Git avec Windows. Ces précédents montrent que le chargement différé se travaille aussi au niveau du système de fichiers. EdenFS, Git et Windows chez Microsoft.

Le bénéfice dépend alors du programme lancé. Un test ciblé peut ne lire qu’une petite partie du projet. Un outil qui parcourt chaque répertoire puis ouvre tous les fichiers finit par demander presque tout. Avant d’adopter un système paresseux, il faut observer ses consommateurs.

Le jour où le cache est vide

Anthropic décrit un cloisonnement strict des étages de caches pour protéger les serveurs en amont. Ce garde-fou est déclaré ; nous n’en avons pas mesuré l’efficacité. Hiérarchie des caches.

Un cache très efficace peut masquer le dimensionnement réel du stockage en amont. Supposons, pour un autre exemple, un taux de succès de 99 %. L’amont reçoit une requête sur cent. Si ce cache disparaît et que chaque lecture est immédiatement redirigée, la demande potentielle devient cent fois plus élevée, à débit client identique. Ce n’est pas une prévision d’incident Scion.

Les travaux SRE de Google décrivent comment les caches froids et les surcharges participent à des pannes en cascade. Ils recommandent de tester les limites de capacité et le comportement en surcharge. Les nouvelles tentatives doivent également être bornées pour ne pas amplifier la panne. Pannes en cascade, pratiques de service.

Notre critère de décision devient plus exigeant : la flotte doit progresser quand les caches sont chauds, mais aussi récupérer proprement après un redémarrage. Refuser temporairement du travail peut être préférable à transmettre toutes les requêtes à un service déjà saturé.

Construire le remplaçant comprend aussi la migration

Pour évaluer un projet de ce type, nous demanderions comment l’équipe vérifie l’équivalence des anciennes et nouvelles représentations. Une migration de contrôle de versions doit permettre de retrouver le bon contenu, ses parents et les autorisations qui s’y appliquent. Tester seulement un téléchargement réussi laisserait de côté les renommages, les fusions et les reprises après interruption.

Anthropic déclare des simulations et du fuzzing. Aucune offre publique de Scion n’est annoncée dans ce billet. Tests et diffusion.

Un protocole d’évaluation pertinent comparerait des échantillons d’historiques, injecterait des pannes entre les étapes d’écriture et rejouerait les opérations interrompues. Ce sont nos critères d’audit, pas une description d’implémentations internes que nous aurions inspectées. De même, nous n’attribuons pas de langage de programmation à Scion sur la seule base du langage utilisé par un projet voisin.

La question économique comprend le maintien des intégrations : revue de code, construction, tests, recherche et outils des développeurs. Une amélioration du service de fichiers peut être réelle sans que l’investissement total soit rentable pour une autre organisation.

Mesurer avant de changer de système

Pour décider, instrumentez un parcours complet, de la demande du test à son résultat. Séparez l’attente d’une machine, la récupération du code, l’installation des dépendances, la construction et l’exécution. Comparez des tâches identiques avec cache chaud et cache froid. Regardez aussi les tâches les plus lentes : une médiane satisfaisante peut cacher les attentes qui bloquent une livraison.

Fixez la révision, les dépendances, les ressources et le nombre de tâches concurrentes. Précisez quel cache est vidé : le cache de fichiers du système, celui du nœud et celui du service distant ne couvrent pas le même périmètre.

Si la préparation domine, expérimentez un périmètre de checkout plus petit ou un partage de données adapté à l’isolation des tâches. Vérifiez que l’amélioration ne reporte pas l’attente au premier accès. Si les tests dominent déjà, une migration du contrôle de versions ne sera probablement pas le premier investissement à faire.

Cette démarche rejoint notre guide d’observation d’une pile IA : suivre le travail réel avant de choisir le composant à remplacer. Le résultat utile est une validation correcte obtenue plus vite, à coût maîtrisé. Le nombre de modifications intégrées ne mesure pas à lui seul cette réussite.

Sources et méthode

Périmètre. Recherche documentaire au 15 octobre 2026. Le billet d’Anthropic du 13 octobre est un retour de son équipe, pas une évaluation indépendante. Nous ne disposons ni d’un accès de test ni de traces brutes permettant de reproduire ses résultats. Les distributions de latence, le coût complet et les incidents de migration restent à documenter pour une comparaison reproductible.

Mécanismes documentés. Les manuels de clone, de sparse checkout, des objets et des packs servent à distinguer les fonctions de Git. Les documents de Meta sur Mononoke, ses données dérivées et EdenFS décrivent ces projets, pas le code de Scion. Un rapprochement de conception ne prouve pas une réutilisation de code.

Contexte et fiabilité. Google sur le contrôle de versions, Microsoft sur Git et Windows, transactions Spanner, pannes en cascade et pratiques SRE.

Calculs illustratifs. 1 000 × 200 Mo = 200 Go ; 10 × 200 Mo = 2 Go. Avec 99 % de succès en cache, 1 % des requêtes atteignent l’amont ; sans ce cache, 100 / 1 = 100 fois plus peuvent l’atteindre. Ces hypothèses isolent des mécanismes et ne constituent ni des mesures ni des estimations de performance de Scion. Aucun script de benchmark n’a été exécuté.

Traçabilité. Les sources Meta sont figées au commit 79071c2a3ea20c36ed71332608535e5801101bba, daté du 14 octobre 2026. Les documentations Git et cloud sont des pages évolutives consultées le 15 octobre 2026.