Repenser le contrôle de code source chez Anthropic : Claude a dépassé Git

Anthropic a remplacé Git après que Claude a contribué à faire passer son monorepo d’environ 2 500 fusions quotidiennes en mai 2026 à plus de 30 000 en septembre. Cette hausse fait de la refonte du contrôle de code source chez Anthropic bien plus qu’une histoire de migration d’infrastructure. Elle montre ce qui se produit lorsque l’IA génère du code plus vite que les systèmes de développement ne peuvent l’absorber en toute sécurité.

L’entreprise a conçu Scion, un système interne de contrôle de code source pensé autour d’agents en ligne, d’opérations côté serveur et d’un accès limité à un immense dépôt. Sept ingénieurs ont également créé Antique, un nouveau système de revue de code, ainsi que plusieurs services connexes. Anthropic affirme que l’équipe a achevé la migration en cinq mois.

Le conflit important n’oppose pas simplement Scion à Git. Il oppose la production de code à l’échelle des agents à des pratiques de développement conçues autour de l’attention humaine. Google et Meta ont déjà créé des systèmes spécialisés pour d’immenses monorepos. Anthropic est arrivé à une destination similaire sous l’effet d’une pression différente : des essaims d’agents logiciels qui n’ont jamais besoin de travailler hors ligne.

La refonte du contrôle de code source chez Anthropic a commencé avec 30 000 fusions quotidiennes

Anthropic n’a pas abandonné Git parce que ses ingénieurs ne l’appréciaient pas. L’entreprise l’a abandonné parce que Claude a changé la nature et le volume du trafic dans le dépôt.

Selon le récit technique d’Anthropic, les fusions quotidiennes ont été multipliées par plus de dix entre mai et septembre 2026. L’entreprise présente cette croissance comme une demande durable plutôt que comme un pic de migration de courte durée.

La charge de travail qui en a résulté allait bien au-delà de la création de commits. L’historique de la branche principale d’Anthropic approchait les 100 Go, tandis qu’une copie de travail compressée dépassait les 25 Go. L’intégration continue, ou CI, réalisait environ 25 millions de checkouts de code chaque jour, avant même de compter les environnements de développement, les sandboxes d’agents et les tâches de recherche.

Récupérer ces checkouts naïvement aurait généré plus de 600 pétaoctets de trafic Git quotidien, a calculé Anthropic. L’entreprise a utilisé des clones superficiels, des checkouts partiels, des instantanés de dépôt et plusieurs centaines de miroirs Git internes pour maîtriser ce coût.

Ces mesures ont offert un répit, mais le dépôt continuait d’évoluer plus vite. Les instantanés devenaient obsolètes entre deux actualisations. Les clones partiels compliquaient aussi des opérations telles que les recherches dans l’historique, les diffs et le blame, qui identifie la dernière personne ayant modifié une ligne.

Le problème de l’entreprise venait d’un décalage entre les points forts de Git et les clients dominants d’Anthropic. Git donne à chaque clone suffisamment d’informations pour fonctionner comme un dépôt autonome. Cette conception prend en charge le développement hors ligne, l’historique local et la collaboration décentralisée.

Les agents et tâches automatisées d’Anthropic étaient déjà en ligne. Ils n’avaient pas besoin d’un historique local complet ni de la capacité d’agir comme des serveurs indépendants. Pourtant, l’infrastructure distribuait et maintenait sans cesse des données de dépôt comme si chaque client était un développeur humain utilisant un ordinateur portable.

Scion inverse cette hypothèse. Son serveur effectue les requêtes d’historique, crée les commits, calcule les diffs et gère les fusions ou les rebases. Un client léger conserve un cache borné et ne matérialise que les fichiers requis par la tâche en cours.

Cette différence compte lorsqu’une tâche de recherche a besoin d’un seul répertoire plutôt que de l’ensemble du monorepo. Elle compte aussi lorsqu’un service de CI n’a besoin que d’un diff ou d’un calcul de merge-base. Scion peut répondre à ces demandes via une API sans créer de copie de travail traditionnelle.

Selon Anthropic, la nouvelle architecture a généré des gains internes substantiels. Chaque niveau de cache maintiendrait un taux de réussite supérieur à 99 %. L’infrastructure utilise 200 fois moins de CPU et de mémoire que l’ancienne flotte de miroirs Git.

Anthropic indique aussi que les checkouts de CI et de recherche sont passés de plusieurs minutes à quelques secondes. Ce changement a rendu 25 % de la capacité CPU de CI à l’ensemble de la flotte de calcul.

Il s’agit de mesures rapportées par l’entreprise à partir d’un système interne. Des chercheurs externes ne peuvent pas les reproduire sans accès aux charges de travail, aux dépôts et à l’infrastructure d’Anthropic. Néanmoins, ces chiffres expliquent pourquoi un nouveau cycle d’optimisation de Git ne semblait plus suffisant.

Le système devait prendre en charge bien plus qu’un grand dépôt. Il devait prendre en charge un dépôt dont les principaux auteurs, lecteurs et consommateurs automatisés opéraient à la vitesse des machines.

Claude a transformé l’infrastructure logicielle en goulot d’étranglement

La véritable importance de Scion est que la génération de code a cessé d’être la ressource rare d’Anthropic. La capacité de revue, l’infrastructure et le jugement sont devenus les contraintes.

Les assistants de codage IA s’intégraient initialement à un processus de développement familier. Une personne demandait une fonction, examinait le résultat, exécutait des tests et soumettait une pull request. L’assistant augmentait la vitesse de saisie d’un développeur individuel sans modifier le système environnant.

Anthropic décrit un modèle opérationnel plus avancé. Claude itérerait dans des boucles de recherche, optimiserait des programmes complexes, créerait des services, surveillerait des composants de production et aiderait lors de migrations de grande ampleur. Chacune de ces activités peut produire de nouveaux changements ou exiger un nouvel accès au dépôt.

Ce schéma crée une pression multiplicative. Un agent peut lancer une autre tâche pendant qu’un changement antérieur progresse dans les tests. Des réviseurs automatisés peuvent demander des corrections, qui produisent des changements supplémentaires. Les systèmes de CI créent alors des checkouts et lancent davantage de requêtes vers le dépôt pour chaque candidat.

Le graphique mis en avant par Simon Willison montre une nette accélération au cours de 2026. Willison a relié cette accélération aux générations plus récentes de modèles internes d’Anthropic, tout en distinguant soigneusement leur disponibilité interne de leurs dates de lancement public.

Anthropic établit un lien plus précis. L’entreprise affirme que le développement de Scion a débuté à peu près au moment où Claude Mythos Preview et Claude Tag sont devenus disponibles en interne. Ces modèles auraient accru le besoin de Scion tout en aidant l’équipe à le construire.

Un exemple concerne le pipeline qui transférait les données de Git vers Scion. Les ingénieurs d’Anthropic avaient écrit à la main un prototype initial. Une première version interne de Claude Mythos Preview a ensuite réécrit le pipeline avec peu d’instructions supplémentaires.

Le remplacement aurait utilisé 20 fois moins de mémoire et fonctionné quatre fois plus vite. Anthropic affirme qu’il a préservé des exigences implicites concernant l’ordre d’ingestion et les structures de données. Cette affirmation est frappante, mais elle reste un résultat décrit par l’entreprise plutôt qu’un benchmark indépendant.

La boucle de rétroaction plus large est plus facile à établir. Une génération de code plus rapide a accru l’activité du dépôt. Cette activité a justifié une nouvelle infrastructure. Claude a ensuite contribué à construire cette infrastructure, supprimant une autre limite à la génération de code.

Cette boucle met sous pression chaque partie du cycle de vie du développement. Un service de build qui gère des changements au rythme humain peut devenir coûteux lorsque des agents créent des milliers de tâches simultanées. Une file de revue devient moins utile si le dépôt avance de centaines de changements pendant l’exécution d’une suite de tests.

L’accès aux connaissances devient également une contrainte. Les agents ont besoin de spécifications, de décisions d’architecture, d’historiques d’incidents et de contexte de responsabilité, et pas seulement de fichiers source. Les équipes qui construisent des flux de travail similaires ont besoin d’une base de connaissances d’ingénierie consultable, en parallèle d’une infrastructure de code plus rapide.

Anthropic indique utiliser désormais des moniteurs Claude persistants appelés « superfans » pour des composants Scion individuels. Ces agents surveillent la télémétrie et les logs via des canaux Slack dédiés. Les alertes traditionnelles restent en place, tandis que les agents recherchent des schémas que des seuils fixes pourraient manquer.

Ce modèle opérationnel élève le travail d’ingénierie. Les personnes définissent les invariants, choisissent les frontières architecturales, interprètent les défaillances et décident de ce qui doit atteindre la production. Les agents génèrent des implémentations et analysent la télémétrie dans ces limites.

Ce changement n’élimine pas l’ingénieur. Il transforme la compétence rare : il ne s’agit plus de produire du code, mais de décider quel code mérite d’exister.

Scion remplace le modèle hors ligne de Git par un service à l’échelle des agents

Scion gagne en débit en abandonnant la symétrie déterminante de Git : un client ne porte plus toute l’intelligence du dépôt.

Les commits Git contiennent des pointeurs vers des arborescences complètes de répertoires. Les clients échangent des collections compressées d’objets appelées packfiles, ce qui permet aux dépôts locaux de conserver leur historique et de fonctionner indépendamment. Ce modèle reste adapté à la plupart des projets logiciels.

Scion utilise un changeset, une entrée dans un journal d’écriture anticipée qui enregistre les fichiers modifiés par rapport à un parent. Le contenu des fichiers est compressé, adressé par contenu et stocké séparément. L’adressage par contenu signifie que la clé de stockage dérive des données, de sorte que les objets immuables peuvent être mis en cache en toute sécurité.

Les changesets sont créés sur le serveur et deviennent disponibles dans l’ensemble du système. Ils ne nécessitent pas qu’un client construise et téléverse un grand packfile. Ils évitent également de déplacer un pointeur global de branche à chaque opération de commit.

Scion prend toujours en charge les références, c’est-à-dire des pointeurs tels que les branches et les tags. Cependant, Anthropic déconseille la plupart des références au-delà de la ligne principale et des branches de publication. L’état coordonné à l’échelle mondiale devient de plus en plus coûteux à mesure que le rythme des commits augmente.

Le système calcule séparément les informations d’historique sous forme de données dérivées. Il construit des index dédiés pour l’historique des fichiers, le blame, la copie et les relations au sein du graphe de commits. Ces index peuvent être générés immédiatement ou différés jusqu’à ce qu’un consommateur les demande.

Cette séparation permet à Anthropic de modifier un index sans modifier chaque client. Elle permet aussi au service d’éviter de calculer des données dont aucune tâche n’a besoin.

Le protocole de checkout de Scion suit le même principe. Les clients demandent des arborescences et objets de fichiers précis plutôt que de négocier une image complète de ce qu’ils possèdent déjà. Des serveurs de cache régionaux peuvent satisfaire la plupart des demandes, car les objets stockés ne changent jamais.

Un daemon sur chaque nœud de calcul partage les objets mis en cache entre les tâches locales. Des services de cache régionaux se placent ensuite entre ces daemons et les serveurs Scion faisant autorité. Anthropic impose cette hiérarchie afin d’empêcher une défaillance d’un cache régional de submerger le service central.

Les checkouts partiels ne demandent que des répertoires sélectionnés. Les checkouts virtualisés créent les fichiers lorsqu’un processus les lit. Certaines tâches ignorent entièrement le système de fichiers et demandent directement à l’API un diff, un résultat d’historique ou une merge base.

Cette conception rappelle des réponses antérieures à l’échelle des monorepos. Google a décrit Piper comme faisant partie de l’infrastructure prenant en charge une vaste base de code centralisée. Son analyse publiée sur les monorepos documente les avantages du code partagé, des dépendances unifiées et des changements à l’échelle de l’organisation.

Meta a adopté une autre voie avec Sapling, un système qui conserve des concepts familiers de contrôle de code source distribué tout en passant à l’échelle de son dépôt interne. Meta affirme que son serveur peut gérer des dizaines de millions de fichiers, de commits et de branches. La conception publique de Sapling prend également en charge les dépôts Git et les flux de travail locaux des développeurs.

Scion s’inspire de ces deux histoires, mais son hypothèse centrale est plus étroite. Le client dominant est toujours en ligne, souvent automatisé, et peu susceptible d’avoir besoin d’un dépôt entier. Le serveur devient donc une base de données de contrôle de version et un service de calcul plutôt qu’un partenaire de synchronisation.

Le compromis est la dépendance. Un client Scion ne peut pas reproduire l’ensemble du comportement hors ligne de Git, car il conserve délibérément moins de données et effectue moins d’opérations localement. Une panne de réseau ou du service central a donc des conséquences différentes.

Les coûts de migration dépassent également le client en ligne de commande. Anthropic a dû créer la recherche de code, les contrôles d’identité et d’accès, les intégrations CI et Antique. Une entreprise adoptant la même conception devrait remplacer une grande partie de sa plateforme de développement.

Cela explique pourquoi Scion n’est pas une alternative à Anthropic Git pour les équipes ordinaires. C’est un système verticalement intégré pour une charge de travail exceptionnelle.

Des fusions plus rapides font de la revue de code le problème le plus difficile

La question non résolue n’est pas de savoir si Scion peut accepter 30 000 changements. Elle est de savoir si Anthropic peut préserver la responsabilité à cette vitesse.

Anthropic affirme que chaque changement dans Scion fait toujours l’objet d’une revue humaine. Les relecteurs se concentrent désormais sur l’intention d’un changement plutôt que de lire chaque ligne. Ce choix découle du volume, mais il déplace aussi la confiance vers les tests, les explications des agents et l’analyse automatisée.

La revue de l’intention cherche à déterminer si un changement proposé correspond aux objectifs du système et aux règles architecturales. La revue ligne par ligne cherche à vérifier si son implémentation se comporte correctement. Des contrôles automatisés robustes peuvent relier ces deux niveaux, mais aucune suite de tests ne capture toutes les exigences cachées.

Anthropic reconnaît que les ingénieurs devaient souvent dire « non » à Claude. Les agents choisissaient parfois des modèles localement plausibles qui violaient des contraintes à l’échelle du système. Certains composants générés tentaient de parcourir linéairement le journal des commits au lieu d’interroger Antique pour obtenir une heure de fusion faisant autorité.

La revue contradictoire a créé un autre mode de défaillance. Claude pouvait répondre à des risques hypothétiques par une validation et une complexité excessives. Les ingénieurs humains devaient décider à quel moment la programmation défensive cessait d’améliorer le système.

Ces exemples compliquent l’affirmation simpliste selon laquelle de meilleurs modèles produisent directement de meilleurs logiciels. Les agents peuvent trouver des optimisations utiles tout en créant des mécanismes inutiles. Un volume de production élevé amplifie les deux comportements.

Anthropic indique que son équipe a mis en place des simulations, des tests fuzz et des limites de débit pour Scion. Le fuzzing fournit des entrées inattendues afin de révéler des défauts, tandis que des simulations hermétiques reproduisent le comportement de l’infrastructure dans des environnements isolés. Ces contrôles apportent des preuves plus solides que les seuls comptes de fusions.

Pourtant, le volume de fusions n’est pas une métrique de qualité. Un changement peut être minuscule, expérimental, généré, annulé ou sans rapport avec les progrès visibles pour les clients. Trente mille changements quotidiens révèlent une activité extraordinaire, mais ne démontrent pas indépendamment la fiabilité ou la valeur métier.

Les réactions publiques des développeurs se sont concentrées sur cette distinction. Dans la discussion Hacker News, certains lecteurs se sont demandé si Anthropic devrait reconsidérer son monorepo. D’autres ont soutenu que l’intention, la provenance et la vérification continue importent davantage que les mécanismes traditionnels de commit.

Un ingénieur d’Anthropic répondant dans ce fil a défendu les outils cohérents et les changements atomiques du monorepo. Le même ingénieur a précisé que Scion bloque les conflits textuels, mais ne peut pas éliminer les conflits sémantiques entre des changements simultanés.

Un conflit sémantique survient lorsque deux modifications individuellement valides produisent ensemble un comportement incorrect. Un changement peut modifier une fonction et mettre à jour ses appelants, tandis qu’un autre ajoute simultanément un nouvel appelant. Les fichiers peuvent fusionner proprement alors même que le programme combiné est incorrect.

Les files de fusion traditionnelles réduisent ce risque en testant un état de dépôt proposé avant d’accepter le lot suivant. Anthropic affirme qu’un verrou global sur le dépôt devient impraticable lorsque des centaines ou des milliers de changements arrivent pendant l’exécution d’un test.

L’entreprise a réorienté ses investissements vers les tests post-fusion et pré-déploiement. Cette approche permet au débit du dépôt de se poursuivre pendant que les contrôles déterminent ce qui peut atteindre la production en toute sécurité.

C’est le compromis central de la refonte du contrôle de version chez Anthropic. Scion supprime la sérialisation du contrôle de version, mais une certaine forme de sérialisation subsiste au déploiement, lors des migrations de données ou aux points de décision humaine. Le risque se déplace plutôt qu’il ne disparaît.

Anthropic affirme que Claude peut résoudre les conflits simultanés plus vite que les humains ne peuvent les identifier. Cette réponse concerne la vitesse de réparation, non le coût d’une interaction non détectée. La sécurité dépend de la rapidité avec laquelle la surveillance détecte un problème et de l’efficacité avec laquelle les systèmes l’isolent ou l’annulent.

Les contrôles d’accès au niveau des répertoires et les règles d’approbation sémantique sont utiles. Selon Anthropic, Antique peut distinguer un changement limité à des commentaires d’un changement affectant une logique sensible. L’attention humaine peut alors se concentrer sur les changements aux conséquences plus importantes.

L’écart de vérification restant est considérable. Anthropic n’a pas publié de taux de défauts indépendants, de fréquence des annulations, de tendances en matière d’incidents ni de proportion des changements écrits et revus par des agents. Sans ces mesures, les observateurs externes ne peuvent comparer les gains de débit aux risques en aval.

La leçon la plus utile pour les autres équipes n’est donc pas de poursuivre le nombre de fusions d’Anthropic. Elle consiste à mesurer l’ensemble du parcours, de la spécification au déploiement. Parmi les indicateurs utiles figurent les défauts échappés, la latence de revue, les changements en échec, les annulations, le travail dupliqué et le temps consacré à la restauration du contexte.

Un workflow d’IA personnel peut aider les ingénieurs à préserver les décisions et la provenance à mesure que les agents génèrent davantage de contenu. Toutefois, le contexte stocké n’aide que lorsque les équipes le relient à des tests applicables, à la propriété et à une politique de revue.

Ce que l’expérience d’Anthropic en matière de contrôle de version changera ensuite

La prochaine phase déterminera si le développement à l’échelle des agents devient un modèle d’ingénierie transférable ou reste une exception Anthropic coûteuse.

Le premier signal à surveiller est la discussion promise par Anthropic sur Antique. Le contrôle de version explique comment les changements sont stockés et récupérés, mais la revue de code détermine comment l’intention, la propriété et l’approbation survivent à un volume extrême.

Les détails du modèle de revue d’Antique renforceraient l’argument d’Anthropic s’ils démontraient une provenance claire et une intervention humaine fondée sur le risque. L’argument s’affaiblirait si la revue dépendait principalement de résumés de modèles sans validation mesurable.

Le deuxième signal est la qualité logicielle au fil du temps. Les affirmations d’Anthropic sur l’infrastructure auront davantage de poids si l’entreprise publie les taux d’annulation, les défauts échappés, les incidents de service ou d’autres mesures de résultats parallèlement au débit de fusions.

Une fiabilité stable ou en amélioration soutiendrait l’idée que les agents peuvent augmenter le volume de changements sans accroître proportionnellement le risque. Une hausse des régressions ou des réparations d’urgence suggérerait que Scion a accéléré la production plus vite que la gouvernance.

Le troisième signal est la manière dont les plateformes Git et les grandes organisations d’ingénierie réagissent. La plupart des entreprises ne remplaceront pas Git, mais elles peuvent adopter des API de métadonnées côté serveur, des espaces de travail virtualisés, une revue tenant compte des risques et un meilleur soutien aux agents parallèles.

Sapling de Meta démontre déjà une voie qui maintient la compatibilité avec des workflows familiers. Scalar de Microsoft et les améliorations Git associées en démontrent une autre, en étendant Git pour les grands dépôts au lieu de remplacer son modèle de données.

Anthropic s’attend elle-même à ce que ces pressions se propagent dans les six à douze mois. Cette prévision relève du jugement de l’entreprise, non d’une tendance de marché mesurée. Sa pertinence dépend de la capacité d’autres organisations à atteindre des limites similaires sans l’accès interne aux tokens d’Anthropic et l’usage inhabituellement concentré de Claude.

Scion introduit également une dépendance stratégique que les concurrents pourraient éviter. Anthropic contrôle le modèle, le service de dépôt, l’interface de revue, les agents d’observabilité et le workflow de déploiement. Cette intégration accélère l’itération, mais rend l’environnement de développement plus difficile à reproduire ou à remplacer.

Pour la plupart des organisations, Git restera le choix par défaut raisonnable. Il offre une interopérabilité étendue, des outils matures, un historique portable et une résilience hors ligne. L’architecture de Scion ne devient attrayante que lorsque le trafic du dépôt a déjà submergé ces avantages.

Le changement le plus immédiat concerne la gestion. Les responsables de l’ingénierie doivent cesser de considérer le volume de code généré comme l’objectif. Une production accrue ne crée de valeur que lorsque les équipes peuvent la revoir, la tester, la déployer, l’observer et l’annuler en toute sécurité.

Les développeurs doivent également s’attendre à une évolution de leur travail. Le récit d’Anthropic accorde plus de poids à la conception de systèmes, aux contraintes architecturales, à l’évaluation et au refus. L’ingénieur définit de plus en plus les limites dans lesquelles un agent peut progresser rapidement.

La refonte du contrôle de version chez Anthropic offre donc un avertissement en parallèle de son récit de performance. Une fois le code devenu peu coûteux, chaque spécification faible, test manquant et limite de responsabilité floue peut être reproduit à la vitesse de la machine.

La question utile n’est pas de savoir si votre équipe a besoin de Scion. Elle est de savoir si vos systèmes actuels de revue, de CI et de connaissances resteraient fiables si les agents produisaient dix fois plus de changements le trimestre prochain. Mesurez cette capacité dès maintenant, identifiez le premier contrôle défaillant et renforcez-le avant que le volume de fusions n’augmente.