Une branche principale dont l’historique pèse près de 100 Go, interrogée sans relâche par des agents qui écrivent plus vite que n’importe quelle équipe humaine : Git a cédé. Anthropic vient de le reconnaître en décrivant, dans un billet d’ingénierie, le système de contrôle de version qu’elle a construit en interne pour le remplacer.
Douze fois plus de changements en quatre mois
Deux chiffres publiés par l’entreprise donnent l’échelle. En mai 2026, Anthropic fusionnait en moyenne environ 2 500 changements de code par jour. En septembre, plus de 30 000. Le rythme a été multiplié par plus de douze en un peu plus de quatre mois, au moment où ses propres modèles écrivent une part croissante de son code.
Git n’a jamais été conçu pour absorber un tel flux. Il suppose des humains qui travaillent sur des copies locales, qui fusionnent de temps en temps et qui règlent leurs conflits à la main. Quand des centaines d’agents poussent en parallèle sur le même dépôt, chaque conflit de merge, chaque récupération complète d’historique devient une file d’attente.
Le billet cite aussi « Antique », un nouveau système de revue de code, bâti en parallèle. La revue est le second goulot : produire 30 000 changements par jour ne sert à rien si personne ne peut les relire.
Scion, ou le retour du contrôle centralisé
Le système s’appelle Scion. Ses contraintes, telles qu’Anthropic les expose, donnent la mesure du problème : l’historique de la seule branche principale approche les 100 Go, une copie de travail compressée dépasse 25 Go, et l’entreprise effectue de l’ordre de 25 millions de checkouts par jour pour ses tests automatiques (la CI, l’intégration continue), sans compter les environnements de développeurs, les bacs à sable d’agents et les jobs de recherche. Récupérés naïvement avec Git, ces checkouts représenteraient plus de 600 pétaoctets de trafic quotidien.
Face à cela, la réponse a tout d’un retour en arrière assumé : un système centralisé, dans la lignée de ce que Subversion proposait avant l’arrivée de Git. Le serveur détient la vérité, les clients ne clonent plus l’histoire entière. Une équipe de sept personnes l’a construit, et la migration depuis Git s’est terminée en cinq mois.
Un détail de conception éclaire cette logique. Interrogé sur l’absence de mode hors ligne, un ingénieur de Scion, Nick G, a répondu sur Hacker News que Claude est de loin le plus gros utilisateur du système et qu’il est nécessairement connecté : le hors ligne « n’était tout simplement pas important ». L’outil est donc dimensionné pour des machines, pas pour un développeur dans un train.
Reprendre la main sur un maillon de la chaîne
Anthropic ne cherche pas à détrôner Git sur le marché : personne ne le lui demande. Elle retire une pièce que d’autres contrôlent. Git appartient à tout le monde, évolue au rythme de sa communauté et ne tiendra jamais compte des besoins d’un seul gros utilisateur. En construisant Scion, l’entreprise reprend la main sur un maillon de sa chaîne que ses propres modèles venaient d’étouffer.
L’intérêt est double. Le premier est opérationnel : tant que le contrôle de version limite la cadence, la vitesse des agents ne se traduit pas en produit livré. Le second est stratégique : celui qui maîtrise l’outil où les agents écrivent, relisent et fusionnent sait mesurer ce que ces agents font vraiment, et peut l’optimiser pour eux. Les éléments publiés ne disent pas si Scion sera un jour proposé hors de l’entreprise ; pour l’instant, il reste un avantage d’infrastructure que les concurrents devront reproduire ou contourner.
L’entreprise reconnaît elle-même une limite. La revue contradictoire, où un modèle cherche les failles du travail d’un autre, est décrite comme très efficace, mais aussi myope : des ingénieurs expérimentés ont dû empêcher Claude de sur-concevoir certaines parties du système pour répondre à des risques hypothétiques. Même à 30 000 changements par jour, le jugement humain reste le dernier filtre.
Le hook plutôt que la consigne
Tout le monde ne construit pas son propre Scion, mais la leçon se transpose à l’échelle d’un projet. Geoffrey Huntley, développeur qui documente sa pratique des agents IA de programmation, en donne un exemple. Quand l’agent n’utilise pas sa bibliothèque de diagnostics, la tentation est de compléter le fichier AGENTS.md (les instructions que l’agent lit en début de session). Mais l’écart subsiste et finit par dériver. Huntley écrit plutôt un hook pre-commit, un script qui s’exécute avant chaque commit et inspecte le diff à la recherche d’appels directs aux modules d’observabilité qui contournent sa bibliothèque. Le commit échoue et un prompt est injecté pour rappeler à l’agent la bonne bibliothèque. « Tout à coup, c’est dix sur dix. »
Un fichier d’instructions est une demande, que l’agent lit, pondère et oublie parfois. Un hook est une contrainte, vérifiée mécaniquement à chaque commit. Quand le volume de changements est multiplié par douze, on ne relit plus chaque diff pour y chercher une règle bafouée : la règle doit se vérifier toute seule.
- Ce qui peut s’exprimer en test ou en vérification automatique (bibliothèque imposée, appel interdit, format de journal) va dans un hook ou dans la CI.
- Ce qui relève du goût ou de l’architecture reste dans les consignes, avec une revue humaine derrière.
- Chaque échec de hook devrait renvoyer à l’agent un message qui dit quoi faire, pas seulement ce qui est refusé.
Anthropic traite le goulot au niveau de l’infrastructure, Huntley au niveau du dépôt, et le diagnostic est le même : les agents produisent plus vite que les processus pensés pour des humains ne peuvent l’encaisser. Une fois le contrôle de version et la revue remis à niveau, le prochain point de rupture se trouve peut-être ailleurs : les tests, le déploiement, ou la capacité de chacun à comprendre ce qui entre en production.
Vous avez aimé celui-ci ?
La newsletter du vendredi réunit les articles de la semaine, avec leurs sources.
Offert à l'inscriptionMa configuration Claude Code, avec mes skills, mes sous-agents et mes hooks, prêts à copier.
Sources
Ils m’ont fait confiance
« Il ne se contente pas de corriger les symptômes, il cherche à comprendre l'origine des problèmes et à sécuriser les modifications effectuées. J'ai réellement le sentiment d'avoir trouvé un développeur qui comprend à la fois la technique et les enjeux globaux du projet. »
Évaluation client · projet WordPress · septembre 2026
5,0/5 sur 22 évaluations
Faire appel à mes services →
