Anthropic a migré son dépôt de code principal de Git vers un système de contrôle de version développé en interne, après que Claude a contribué à faire passer le nombre de fusions de code quotidiennes d'environ 2 500 en mai à plus de 30 000 en septembre. L'entreprise a indiqué qu'une équipe de sept personnes avait développé le nouveau système, baptisé Scion, ainsi qu'un outil de révision de code et d'autres infrastructures destinées aux développeurs. Ce projet reflète une évolution des limites rencontrées par Anthropic à mesure que ses agents d'IA produisent davantage de logiciels. Le codage n'est plus son principal goulot d'étranglement, a déclaré l'entreprise. Anthropic précise que Scion est adapté aux dépôts de code gigantesques et à un grand nombre d'agents de codage.Anthropic, PBC (stylisée ANTHROP\C ou A\) est une société d'intérêt public américaine spécialisée dans l'intelligence artificielle (IA), dont le siège social est situé à San Francisco, en Californie. Son produit phare est Claude, une série de grands modèles de langage (LLM) propriétaires. En janvier 2021, dans le but de promouvoir la sécurité de l'IA, Anthropic a été fondée par d'anciens membres d'OpenAI, notamment les frère et sœur Daniela Amodei et Dario Amodei, qui en sont respectivement la présidente et le PDG. La société est privée, mais envisagerait une introduction en bourse en 2026.
Récemment, Anthropic a migré son dépôt de code principal de Git vers un système de contrôle de version développé en interne, après que Claude a contribué à faire passer le nombre de fusions de code quotidiennes d’environ 2 500 en mai à plus de 30 000 en septembre. L’entreprise a indiqué qu’une équipe de sept personnes avait développé le nouveau système, baptisé Scion, ainsi qu’un outil de révision de code et d’autres infrastructures destinées aux développeurs, et avait mené à bien la migration en cinq mois.
Ce projet reflète une évolution des limites rencontrées par Anthropic à mesure que ses agents d’IA produisent davantage de logiciels. Le codage n’est plus son principal goulot d’étranglement, a déclaré l’entreprise. En revanche, le contrôle des sources, les compilations et l’infrastructure de tests automatisés, conçues pour s’adapter au rythme de développement humain, peinent à suivre le rythme. Anthropic a qualifié sa charge de travail d’exceptionnellement importante. L’historique de sa branche principale avoisine à lui seul les 100 Go, tandis qu’une copie de travail compressée dépasse les 25 Go. Les tâches de tests automatisés effectuent environ 25 millions d’extractions de code par jour, sans compter les environnements de développement, les sandbox des agents et les charges de travail liées à la recherche.
L'entreprise avait recours à des copies partielles, à des instantanés du dépôt et à plusieurs centaines de miroirs Git internes pour répondre à cette demande. Ces solutions de contournement sont devenues de plus en plus difficiles à gérer à mesure que le dépôt et le rythme des fusions prenaient de l'ampleur. Scion adopte une approche différente en partant du principe que ses utilisateurs, principalement des agents et des tâches automatisées, restent connectés. Les serveurs gèrent les opérations telles que la création de commits, la fusion des modifications et la récupération de l'historique des fichiers, tandis que les clients ne récupèrent que les données dont ils ont besoin.
Cela réduit la nécessité de conserver de volumineuses copies locales du référentiel. Certains outils peuvent interroger ou modifier le code entièrement via une API, tandis que les tâches nécessitant des fichiers peuvent récupérer des répertoires sélectionnés ou charger des fichiers à la demande.
L'IA, la technologie et les marchés qu'elles influencent : le tout dans un seul briefing quotidien.
Anthropic a indiqué que les besoins en CPU et en mémoire de Scion sont 200 fois inférieurs à ceux de son ancienne infrastructure de mise en miroir Git. Les extractions de code pour les tâches de test et de recherche sont environ 100 fois plus rapides, ne prenant que quelques secondes au lieu de plusieurs minutes. Selon l’entreprise, cette migration a également permis de libérer 25 % de la capacité CPU utilisée par ses charges de travail d’intégration continue.
Claude a joué un rôle central dans la mise en place de l’infrastructure nécessaire pour prendre en charge sa propre production. Anthropic a indiqué qu’une première version interne de Claude Mythos Preview avait réécrit un prototype de pipeline d’ingestion afin qu’il utilise 20 fois moins de mémoire et s’exécute quatre fois plus vite. Les ingénieurs sont restés responsables de l’architecture, des compromis de conception et du respect des contraintes du système. L’entreprise a précisé que les agents introduisaient parfois des raccourcis ou une complexité inutile, nécessitant une intervention humaine.
Les membres de l’équipe continuent d’examiner chaque demande de modification pour Scion, même si Anthropic a indiqué que son attention s’était désormais portée sur l’intention derrière ces modifications plutôt que sur la lecture de chaque ligne de code. L’entreprise utilise également des agents Claude pour surveiller les différents composants de l’infrastructure. Ces agents analysent les données télémétriques et les journaux à la recherche de comportements inhabituels, en complément des alertes classiques.
Le volume croissant de modifications a poussé Anthropic à repenser certaines de ses pratiques de développement. L’entreprise a expliqué que des centaines, voire des milliers de modifications pouvaient être fusionnées pendant l’exécution des tests, ce qui compliquait la gestion des files d’attente de fusion traditionnelles. L’entreprise a donc préféré investir dans des tests effectués après la fusion des modifications et avant le déploiement.
Anthropic précise que Scion est adapté aux dépôts de code gigantesques et à un grand nombre d’agents de codage. Son adoption nécessiterait des changements importants au niveau des outils de développement de l’organisation, et l’entreprise ne le présente pas comme un remplacement général de Git. L'entreprise s'attend à ce que ce type de contraintes liées à l'infrastructure se généralise au cours des six à douze prochains mois. Plutôt que de proposer une version grand public de Scion, Anthropic a indiqué vouloir partager son approche avec GitHub, GitLab et la communauté open source.
Il y a peu, un ingénieur logiciel a affirmé avoir perdu son poste au profit de Claude Fable. Il a soutenu qu'il n'avait pas été remplacé par une « intelligence supérieure », mais par la perception marketing et sa rentabilité financière. Bien que les modèles d'IA de l'époque aient encore manqué de discernement stratégique et de vision à long terme pour remplacer les experts, les dirigeants ont choisi de miser sur ces outils jugés économiques. Cette tendance a conduit à des licenciements massifs, provoquant un stress intense et une profonde incertitude chez les développeurs. L'auteur a reconnu tout de même que ces systèmes sont parvenus à exécuter des tâches techniques répétitives.
Voici la publication d'Anthropic sur la refonte de son système de contrôle de code source :
Refonte du système de gestion des versions chez Anthropic
Chez Anthropic, le codage n’est plus le goulot d’étranglement qui freine la création de systèmes ou la recherche. Claude est capable d’itérer de manière autonome sur des boucles de recherche, de micro-optimiser des programmes complexes et de créer de nouveaux services à partir de zéro, à une vitesse et à une échelle sans précédent. Le goulot d’étranglement réside désormais dans l’ensemble de l’infrastructure de développement conçue pour une échelle humaine : contrôle de version, builds et intégration continue (CI).
En mai 2026, Anthropic enregistrait en moyenne environ 2 500 modifications de code fusionnées par jour ; en septembre, ce chiffre dépassait les 30 000 par jour. Nous ne prévoyons pas de ralentissement de ce rythme de croissance dans un avenir proche ; la demande latente de fusion de code est pratiquement infinie, et chaque goulot d’étranglement que nous supprimons entraîne immédiatement une nouvelle augmentation de la quantité de code que nous produisons.
Afin d’accompagner cette croissance, nous avons développé Scion, un système de contrôle de version interne, et avons entièrement migré notre monorepo depuis Git en cinq mois. Nous avons également développé et déployé une interface de révision de code (baptisée Antique), un moteur de recherche de code, un système IAM avancé pour le contrôle de source, des méthodes innovantes pour gérer et intégrer de grandes quantités de code révisé, et bien plus encore, le tout au cours de cette même période.
Dans cet article, nous allons nous concentrer plus particulièrement sur la manière dont nous avons développé Scion. Cela constitue une étude de cas intéressante : c’est à la fois la capacité de Claude à écrire du code qui nous a placés dans cette situation au départ, et ce qui nous a permis de développer rapidement un système évolutif et de haute qualité pour y faire face.
Développer notre monorepo
Avant d’explorer ce que nous avons construit, il convient de souligner à quel point notre charge de travail est atypique. Sans surprise, Anthropic utilise Claude pour écrire des logiciels bien plus que la quasi-totalité des autres entreprises ; nous sommes donc souvent les premiers à constater où les outils conçus pour une échelle humaine commencent à montrer leurs limites. Le contrôle de version n’en est qu’un exemple parmi d’autres. Même si nous ne pensons pas que de nombreuses organisations soient confrontées à ces problèmes dans un avenir très proche, nous pensons qu’il ne faudra pas longtemps avant que d’autres utilisateurs d’outils de codage basés sur l’IA ne rencontrent ces mêmes difficultés. C’est pourquoi nous avons souhaité partager ce que nous avons développé et les enseignements que nous en avons tirés.
Git est un système décentralisé : chaque clone est un dépôt complet et autonome, capable de calculer des différences, de lire l’historique et les informations de responsabilité, et d’extraire n’importe quelle révision en mode entièrement hors ligne. Pour la grande majorité des dépôts, cette conception est la plus adaptée, et c’est en grande partie pour cette raison que Git est devenu la norme.
À mesure que notre monorépositoire s'agrandit, il ne correspond de moins en moins à ce modèle. L'historique de notre branche principale à lui seul pèse près de 100 Go, et une copie de travail compressée dépasse les 25 Go. Nous effectuons environ 25 millions de récupérations de code par jour pour l'intégration continue (CI), sans compter les environnements des développeurs, les sandbox des agents et les tâches de recherche. Si l'on considère ces chiffres de manière naïve, cela représenterait plus de 600 PB de trafic Git par jour.
Git propose des outils permettant de travailler avec une partie d’un dépôt, tels que les clones superficiels, les extractions allégées et les dépôts distants « promisor ». Au-delà de cela, il existe des solutions de contournement standard pour les monodépôts volumineux, comme les miroirs Git internes et les instantanés de dépôt (seeds) conservés dans un stockage de blobs. Nous les avons toutes utilisées : à notre pic d’activité, nous exploitions plusieurs centaines de miroirs Git internes pour faire face à la charge.
Cela nous a fait gagner du temps, mais leur gestion est devenue plus complexe à mesure que notre cadence de fusion augmentait. Les « seeds » prenaient de plus en plus de retard par rapport à la pointe de la branche « main » entre deux actualisations, et il fallait redoubler de vigilance pour que les opérations dépendant de l’historique, comme « diff » et « blame », continuent de fonctionner sur des clones partiels.
En prenant un peu de recul, nous avons remarqué que, comme la plupart des entreprises, nous utilisions Git comme un système centralisé avec une seule copie de référence, alors que la quasi-totalité de nos clients étaient des agents et des tâches qui, par définition, fonctionnent en ligne. Les caractéristiques qui font de Git un excellent outil pour le travail distribué et hors ligne nuisaient activement à notre capacité à évoluer à mesure que le dépôt grandissait. Nous nous sommes donc posé la question suivante : si nous concevions dès le départ un système de contrôle de version en tenant compte du fait que les agents sont toujours en ligne, à quoi ressemblerait-il ?
Principes d’un contrôle de version à l’échelle des agents
Avec le codage agentique, de nombreuses hypothèses courantes sur la manière dont les logiciels sont développés sont en train d’évoluer. Nous avons intégré ces changements lors de la conception de Scion, ce qui nous a permis d’adopter une approche fondamentalement différente de celle de Git sur plusieurs principes clés. Le contrôle de version pour les monorépos de grande envergure s’appuie sur des antécédents techniques, notamment Piper de Google et Sapling de Meta ; nous avons donc pu développer Scion en tenant compte des leçons qu’ils ont tirées à la sueur de leur front. Nos principes sont les suivants :
Les clients sont toujours en ligne. Git part du principe que les clients fonctionnent hors ligne et ont besoin d’une copie complète du dépôt. Comme la quasi-totalité de nos clients sont des agents et des tâches, nous avons conçu le client et les protocoles de Scion autour d’un serveur toujours accessible, et nous faisons en sorte que les clients récupèrent les données lorsqu’ils en ont besoin.
Asymétrie client-serveur. Dans Git, chaque client est capable de faire office de serveur à part entière. Dans Scion, le serveur répond aux requêtes concernant l’historique des fichiers et l’attribution de la responsabilité, crée des commits, effectue des fusions et des rebasages, etc. Le client gère un cache d’objets local limité, organise les fichiers de la copie de travail sur le disque, surveille les modifications du système de fichiers et offre aux utilisateurs un moyen ergonomique de travailler avec le serveur. Il ne peut effectuer que très peu de calculs de lui-même, mais en contrepartie, il nécessite beaucoup moins de données en local.
Un service complet de gestion du code source peut alimenter de nombreuses applications innovantes. Avec Git, un job ou un outil d’intégration continue (CI) qui doit interroger le dépôt — par exemple pour savoir qui a modifié une ligne en dernier ou quel est le lien entre deux commits — doit soit conserver une copie locale du dépôt, soit espérer que les API spécifiques au fournisseur fournissent la réponse. Avec Scion, toutes les requêtes de gestion du code source utilisées par le client sont également exposées via une API ; ainsi, dans de nombreux cas, les jobs n’ont absolument pas besoin d’un dépôt local. De nombreux outils internes, tels que nos pipelines automatisés de bisection et de restauration, ne seraient pas viables à grande échelle sans cet accès programmatique et peu coûteux au contrôle de version.
Tout doit être évolutif horizontalement. À notre pic d’activité, nous exploitions plusieurs centaines de miroirs Git, ce qui sollicitait considérablement la capacité et ne permettait plus d’évoluer dès lors que le dépôt dépassait les limites de disque ou de mémoire des miroirs. Dans Scion, les données du dépôt sont distribuées et chaque composant est évolutif de manière indépendante ; il n’existe nulle part de copie entièrement matérialisée du dépôt, pas même sur le serveur. Il n’y a pas d’équivalent des fichiers pack (les paquets d’objets compressés de Git), ce qui rend toute maintenance du dépôt superflue.
Les commits doivent être peu coûteux, incrémentiels et sans verrouillage. Dans Git, on effectue un commit localement, puis on effectue un push pour partager son travail. Dans Scion, chaque commit, rebase ou fusion s'effectue sur le serveur ; il n'y a donc rien à pousser, mais chacune de ces opérations doit être rapide. Le coût de la création d’un commit et de la mise à jour de ses structures de données en aval doit évoluer proportionnellement à la taille de la modification, et non à la taille globale du dépôt, sinon le serveur ne peut pas suivre. Le cycle de vie du développement dans Scion décourage l’utilisation des références (pointeurs vers des commits, tels que les branches et les balises), à l’exception de la référence principale ou des branches de version, car l’état global sur lequel chaque serveur doit s’accorder constitue un problème d’évolutivité imminent.
La copie de travail est facultative et clairsemée par conception. Notre monorépositoire étant très volumineux et nous effectuant des extractions de code des dizaines de millions de fois par jour pour l’intégration continue (CI), nous souhaitions éviter les extractions autant que possible. Avec Scion, une tâche d’intégration continue (CI) qui a besoin, par exemple, de la différence entre un commit et sa base de fusion, peut la demander au serveur. Il en va de même pour les écritures : de nombreuses tâches d’écriture peuvent également contourner la récupération et fonctionner entièrement via l’API. Le protocole de Scion s’articule autour de récupérations « clairsemées », qui ne contiennent que les répertoires demandés par le client, et de récupérations « virtualisées », qui matérialisent les fichiers à la demande ; ainsi, lorsqu’une tâche a besoin de fichiers sur le disque, le client ne paie que pour ce qu’il lit réellement.
Fonctionnement de Scion
Il est utile de comprendre comment ces principes ont été mis en œuvre concrètement lors du développement de Scion. Ces enseignements peuvent s’appliquer à d’autres systèmes de contrôle de version ou, plus largement, à d’autres étapes du cycle de vie du développement logiciel.
Structures de données
Dans Scion, l’unité de travail est un « changeset », c’est-à-dire une entrée dans un journal d’écriture anticipée (write-ahead log). Un changeset stocke la plupart des éléments que l’on attend d’un commit dans Git. Mais alors qu’un commit Git stocke un pointeur vers l’arborescence, un changeset stocke une liste des fichiers qui ont été modifiés par rapport à son premier parent, ainsi que des pointeurs adressés par contenu vers le contenu compressé des fichiers stockés dans le blob storage. Les changesets sont créés côté serveur et sont disponibles partout, instantanément.
Cette structure nous permet d’accepter des ensembles de modifications avec un débit très élevé, car il n’y a pas de fichiers de compression à accepter, pas de verrouillage ni de coordination entre serveurs, et pas de références à déplacer. Techniquement, Scion prend en charge les références, mais comme ni la création ni la récupération des commits n’impliquent ces dernières, le déplacement d’une référence se résume à une opération « compare-and-swap » sur une seule ligne de Spanner, qui s’effectue indépendamment de la création des ensembles de modifications.
Un ensemble de modifications n’enregistre que ce qui a changé ; à lui seul, il ne peut donc pas répondre rapidement à des questions telles que « qui a modifié une ligne en dernier » ou « quels commits ont affecté un fichier ». Pour y répondre, Scion construit des structures de données supplémentaires à partir des ensembles de modifications, notamment des structures dédiées à l’attribution des modifications (file blame) et à l’historique des chemins d’accès, ainsi que des listes de saut (skip lists) pour le graphe des commits. Nous appelons « données dérivées » tout ce qui ne fait pas directement partie du changeset, et nous les calculons toutes via un mécanisme générique unique. Chaque type de données dérivées est défini de manière récursive ; ainsi, sa valeur pour un changeset est calculée à partir des valeurs de ses parents.
Ce mécanisme présente trois avantages. Premièrement, nous pouvons facilement ajouter un nouveau type de données dérivées lorsqu’une nouvelle structure de données permet d’accélérer une opération. Deuxièmement, pour chaque type, nous pouvons choisir de le calculer immédiatement ou de différer le calcul, ce qui nous évite de matérialiser des données dont nous n’avons pas besoin. Et troisièmement, comme le client n’a jamais accès aux détails internes de ces structures de données, nous pouvons les optimiser sans modifier le client. Nous avons ajouté de nombreux nouveaux types de données dérivées au fur et à mesure que le système s’est développé, tels que de nouveaux index permettant la détection des copies ou la recherche de fichiers par chemin d’accès.
Évolutivité de Scion
Un petit parc de serveurs Scion fournit des API de contrôle de source pour toutes les opérations dont un client a besoin, telles que la récupération de jeux de modifications, le calcul de différences, la recherche de bases de fusion et la récupération de blobs. Toutes les données de contrôle de version sont adressées par contenu ; ainsi, une donnée ne change jamais une fois stockée, et n’importe quel serveur peut la mettre en cache sans avoir à consulter les autres. De ce fait, les serveurs sont évolutifs horizontalement et ne nécessitent que peu de coordination. Il s’agit essentiellement de vastes caches capables de calculer des données dérivées à la volée et de réécrire les résultats dans Spanner.
Les nombreux utilisateurs de Scion n’ont plus besoin de gérer leurs propres référentiels locaux. La récupération et la gestion du référentiel représentaient auparavant une charge de maintenance importante pour les tâches d’intégration continue (CI) ou les outils qui devaient interroger le système de contrôle de version, notamment concernant l’historique des commits et l’attribution des modifications. Au début de la migration, avant que nous ne disposions de notre propre client, format de dépôt ou protocoles, Scion ne répondait qu’à ces requêtes de « métadonnées ». La récupération du contenu des fichiers et la matérialisation des copies de travail sont des opérations bien plus gourmandes en données, qui nécessitaient une conception spécifique.
Le client scn de Scion s’écarte des protocoles de récupération de git sur plusieurs points importants et, de ce fait, se prête à une architecture hautement évolutive qui nécessite nettement moins de ressources CPU que les serveurs git. La négociation de Scion n’indique pas au serveur ce dont le client dispose déjà ; elle porte exclusivement sur les arborescences et les blobs que le client souhaite obtenir. À partir d’une arborescence racine, le client vérifie dans son stockage local les arborescences manquantes et les demande de manière récursive, puis répète le processus pour les blobs.
Chaque requête porte sur un objet spécifique qui ne change jamais ; n’importe quel cache peut donc y répondre, et l’architecture s’apparente étroitement aux caches à plusieurs niveaux traditionnels. Le processus est également efficace et reprenable, car il n’y a pas de réponse unique sous forme de fichier compressé de plusieurs gigaoctets. Les checkouts clairsemés, voire virtualisés, ne nécessitent pas de prise en charge particulière, car le client ne demande tout simplement pas les arborescences dont il ne veut pas.
Au sein de la flotte, le client communique via un socket avec un démon, « scion-daemon », qui stocke les objets pour l’ensemble du nœud. La plupart de nos nœuds ont besoin d’accéder au monorepo, et les tâches exécutées sur un même nœud réutilisent en grande partie les mêmes objets. Chaque démon démarre à partir d’un instantané actualisé périodiquement, puis communique uniquement avec les serveurs de cache d’arborescences et de blobs de sa région, appelés « scion-cache ».
Ces serveurs de cache transmettent les objets directement depuis la mémoire, dans le format disque que le démon va utiliser, ce qui leur évite de perdre du temps à calculer les objets manquants du client ou à effectuer une compression delta. Lorsqu’un cache ne dispose pas d’un objet, il interroge les serveurs scion de référence, qui lisent les données depuis Spanner ou un stockage cloud selon les besoins.
Le démon scion, le scion-cache et le scion-server répondent tous à des appels RPC identiques pour ce protocole ; le client n’a donc pas besoin de connaître la topologie du cache. N’importe quel niveau pourrait théoriquement communiquer avec n’importe quel autre, mais nous appliquons strictement la hiérarchisation des niveaux afin d’isoler les domaines de défaillance. Nous voulons éviter une situation où une défaillance dans un scion-cache régional submergerait les scion-servers en amont et provoquerait la panne de l’ensemble du système.
Chaque niveau de ce système maintient un taux de réussite de mise en cache supérieur à 99 % et ne nécessite pas d’état persistant, ce qui facilite sa mise à l’échelle si nécessaire. L’empreinte de notre infrastructure Scion est désormais 200 fois plus petite que celle de notre ancienne infrastructure de mise en miroir Git en termes de besoins en CPU et en mémoire. Les tâches d’intégration continue (CI) et de recherche extraient le code deux ordres de...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.