Quand l'IA code trop vite pour Git : pourquoi Anthropic a dû réinventer le contrôle de version

Imaginez une équipe qui, en l'espace de quatre mois, passe de 2 500 à plus de 30 000 modifications de code fusionnées par jour. Pas parce qu'elle a embauché des milliers de développeurs, mais parce que ses agents d'IA codent sans relâche.

C'est exactement ce qui est arrivé chez Anthropic, l'entreprise derrière Claude. Et le résultat est surprenant : le problème n'était plus d'écrire du code, mais de le ranger. Git, l'outil que tous les développeurs du monde utilisent, a commencé à craquer.

Voici l'histoire, expliquée simplement.

🚀 Le vrai goulot d'étranglement a changé de place

Pendant des décennies, la ressource rare en informatique, c'était le temps des développeurs. Écrire du code prenait du temps, donc tous nos outils (versioning, intégration continue, revue de code) ont été conçus à l'échelle humaine.

Mais quand des agents d'IA peuvent écrire, tester et proposer du code en continu, la donne s'inverse. Anthropic le résume ainsi : chaque fois qu'un blocage est levé, la quantité de code produite augmente aussitôt. La demande est pratiquement infinie.

Le nouveau frein ? Toute l'infrastructure qui entoure le code.

🧱 Pourquoi Git a atteint ses limites

Git a été pensé pour un monde décentralisé : chaque développeur possède une copie complète du projet et peut travailler hors ligne. C'est génial pour la plupart des projets.

Mais le dépôt unique (le « monorepo ») d'Anthropic est devenu gigantesque :

• ≈ 100 Go d'historique sur la seule branche principale
• plus de 25 Go pour une simple copie de travail compressée
• environ 25 millions de récupérations du code par jour, rien que pour les tests automatiques
• soit plus de 600 pétaoctets de trafic quotidien si tout était cloné naïvement

L'équipe a tout essayé : clones partiels, miroirs internes (jusqu'à plusieurs centaines !), instantanés pré-chargés… Ça a fait gagner du temps, mais plus le rythme accélérait, plus ces rustines devenaient difficiles à maintenir.

💡 Le déclic : les « utilisateurs » de Git n'étaient presque plus des humains hors ligne, mais des agents et des jobs toujours connectés. Pourquoi alors leur donner une copie complète du projet ?

🔄 Scion : repenser le versioning pour les agents

La réponse s'appelle Scion, un système de contrôle de version maison, construit et déployé en cinq mois. Il s'inspire de systèmes déjà éprouvés à très grande échelle, comme Piper chez Google et Sapling chez Meta.

L'idée centrale tient en une image :

Avec Git, chaque poste est un mini-serveur qui sait tout faire. Avec Scion, c'est l'inverse :

• Le serveur fait le travail lourd : historique, « blame » (qui a modifié quoi), création des commits, merges, rebases.
• Le client reste léger : il garde un petit cache local et ne télécharge que ce dont il a besoin.
• Tout est accessible par API : un outil qui veut savoir qui a modifié une ligne n'a même plus besoin de cloner le dépôt.
• Les commits sont légers : leur coût dépend de la taille du changement, pas de la taille du projet entier.

⚡ Le secret de la vitesse : une cascade de caches

Pour servir des millions de demandes par jour, Scion empile plusieurs niveaux de cache, du plus proche de la machine jusqu'à la source de vérité :

L'astuce : chaque donnée est identifiée par son contenu et ne change jamais. N'importe quel cache peut donc y répondre sans consulter les autres. Résultat, chaque niveau répond seul à plus de 99 % des demandes.

Et au lieu d'envoyer un énorme « paquet » de plusieurs gigaoctets comme Git, le client demande les fichiers un par un, uniquement ceux qu'il va réellement lire.

📊 Les résultats parlent d'eux-mêmes

• Une infrastructure 200 fois plus légère en CPU et mémoire que l'ancien système de miroirs Git
• Des récupérations de code environ 100 fois plus rapides : quelques secondes au lieu de plusieurs minutes
• 25 % de capacité CPU libérée sur l'intégration continue
• Le tout construit par seulement 7 personnes, avec en bonus un outil de revue de code, de la recherche de code et un système de permissions… pendant que le volume de code décuplait

🤝 Et les développeurs dans tout ça ?

C'est peut-être la partie la plus intéressante. Tous les ingénieurs du projet reconnaissent que Claude écrit désormais du code mieux qu'eux. Un exemple frappant : une première version d'un module, écrite à la main, a été confiée à une version en avant-première de Claude. Sans autre consigne, il l'a réécrite pour consommer 20 fois moins de mémoire et tourner 4 fois plus vite.

Pour autant, les humains sont loin d'être inutiles :

• Ils gardent la vision d'ensemble : comment les systèmes s'emboîtent, quels compromis accepter.
• Ils savent dire « non » : un agent peut contourner une règle fondamentale du système pour faire passer une solution qui « marche ».
• Ils freinent la sur-ingénierie : face à des risques hypothétiques, l'IA a parfois tendance à ajouter trop de vérifications et de complexité.
• Ils relisent l'intention d'un changement plutôt que chaque ligne de code.

Côté exploitation, l'équipe a même créé des « superfans » : des instances de Claude dédiées chacune à un seul composant, qui scrutent en permanence les journaux et les métriques pour repérer la moindre anomalie.

🎯 Ce que ça change pour nous

Soyons clairs : Scion n'a pas vocation à remplacer Git pour tout le monde. Anthropic le dit elle-même, ce type de solution n'a de sens que pour des dépôts absolument énormes, alimentés par des dizaines de milliers d'ingénieurs ou des essaims d'agents.

Mais le message de fond nous concerne tous :

1. Nos outils ont été pensés pour des humains. Dès qu'on y branche des agents IA à plein régime, ils sont mis à rude épreuve.
2. Le goulot d'étranglement se déplace : du code vers les tests, la revue et le versioning.
3. Git peut évoluer : Anthropic invite GitHub, GitLab et la communauté open source à s'inspirer de ces idées (serveurs plus intelligents, API riches, récupération à la demande) sans abandonner Git.

Selon Anthropic, ce genre de problème devrait toucher beaucoup plus d'équipes dans les 6 à 12 prochains mois. Autant commencer à y réfléchir dès maintenant : et si votre prochain bouchon n'était pas votre code, mais tout ce qui l'entoure ?

---

Source : cet article est une adaptation vulgarisée en français de « Redesigning source control at Anthropic », publié par l'équipe Engineering d'Anthropic le 13 octobre 2026 : https://www.anthropic.com/research/redesigning-source-control

Illustrations réalisées pour cet article à partir des chiffres publiés dans l'article original.