Pourquoi Anthropic a remplacé git par Scion (et ce qu'il faut en retenir)

Le 13 octobre 2026, Anthropic a expliqué pourquoi il avait abandonné git, l'outil qu'utilisent presque tous les développeurs du monde pour gérer les versions de leur code. Son dépôt principal recevait environ 2 500 merge requests par jour en mai. En septembre, il en recevait plus de 30 000. Git ne suivait plus, et l'entreprise l'a remplacé par Scion, un système maison construit par sept personnes en cinq mois (Anthropic).

Git fonctionne très bien. Son utilisateur, lui, a changé. Chez Anthropic, « nearly all of our clients were agents and jobs that are online by definition » : presque tous les utilisateurs du dépôt sont des agents d'IA et des tâches automatiques, connectés en permanence. Git a été conçu en 2005 pour des développeurs humains, qui travaillent chacun sur leur machine, parfois hors ligne. Scion est conçu pour des agents.

Faut-il quitter git pour autant ? Non, et Anthropic est le premier à le dire. Mais pour les très gros logiciels sur lesquels travaillent des milliers d'agents, le modèle de git atteint ses limites. Ce qui lui succédera se prépare déjà chez GitHub, chez GitLab et dans quelques start-up.

Git, un gestionnaire de versions pensé pour des humains

Un gestionnaire de versions enregistre chaque modification du code : qui l'a faite, quand et pourquoi. Il permet de revenir en arrière, de travailler à plusieurs sur le même projet et de réunir le travail de chacun. Git, écrit par Linus Torvalds en 2005 pour le noyau Linux, est devenu le standard.

Sa particularité est d'être distribué. Chaque développeur possède une copie complète du projet et de son historique. Il peut travailler hors ligne, créer une branche pour essayer une idée, puis la fusionner avec le travail des autres. Toutes les opérations (comparer deux versions, retrouver l'auteur d'une ligne, fusionner) se calculent sur son poste.

Git n'est pas GitHub. Git est un logiciel libre. GitHub, qui appartient à Microsoft, est une forge : un service qui héberge des dépôts git et y ajoute la revue de code, les tickets et l'intégration continue (CI), c'est-à-dire les tests lancés automatiquement à chaque modification. Il existe d'autres forges, dont plusieurs sont libres et peuvent être hébergées en Europe. Nous y revenons plus bas.

Pourquoi git ne suffisait plus chez Anthropic

Anthropic travaille dans un monorepo : un seul dépôt contient tout le code de l'entreprise, comme chez Google ou Meta. Ce dépôt est énorme. Son historique pèse près de 100 Go, une simple copie de travail compressée dépasse 25 Go, et la CI en extrait environ 25 millions de copies par jour.

Le volume a explosé avec l'IA. En juillet 2026, Claude écrivait déjà environ 80 % du code fusionné chez Anthropic, et les ingénieurs livraient en moyenne huit fois plus de code par trimestre qu'entre 2021 et 2025 (Anthropic). Résultat : 2 500 merge requests par jour en mai, plus de 30 000 en septembre, et Anthropic n'attend pas de ralentissement.

Pour tenir, l'entreprise avait multiplié les rustines : plusieurs centaines de miroirs git internes, des copies partielles de l'historique, des extractions limitées à certains dossiers. Selon ses calculs, un usage naïf de git à cette échelle générerait plus de 600 pétaoctets de trafic par jour (AIM). Le contrôle de source était devenu le premier goulot d'étranglement du développement.

Le décalage tient en quelques hypothèses :

Anthropic utilisait donc git comme un système centralisé, alors que git est conçu pour ne pas l'être.

Comment fonctionne Scion

Scion part de l'hypothèse inverse : les clients sont toujours en ligne. Cela change cinq choses.

Le serveur fait le travail. Les commits, les fusions, les rebases et les requêtes d'historique sont exécutés côté serveur. Le poste ou la machine de CI ne garde qu'un petit cache et sa copie de travail, et ne récupère que les fichiers dont il a besoin.

Tout passe par une API. Beaucoup de tâches n'ont même plus besoin d'une copie du code. Un robot qui cherche quel changement a cassé un test, ou qui annule un changement fautif, interroge directement le serveur.

Aucune copie complète n'existe. Les données sont réparties sur plusieurs machines et stockées dans Spanner, la base de données distribuée de Google Cloud. Trois niveaux de cache (sur chaque machine, par région, puis le serveur de référence) répondent à plus de 99 % des demandes. L'unité de travail, le « changeset », est une entrée dans un journal, comme dans une base de données, et non un nœud dans un graphe de commits comme dans git.

On teste après la fusion. Une file de fusion classique verrouille la branche principale le temps de tester chaque changement. À l'échelle des agents, ce verrou devient intenable. Anthropic fusionne d'abord et teste ensuite, avant le déploiement. Des changements simultanés peuvent entrer en conflit, mais selon l'équipe, « Claude can typically fix these conflicts faster than humans can even identify them » : Claude les corrige plus vite que des humains ne les repèrent.

La revue change de nature. Les relecteurs vérifient l'intention de chaque changement plutôt que chaque ligne. L'outil de revue, Antique, applique des règles selon le type de changement : modifier un commentaire demande moins de vérifications que modifier du code. Les permissions sont définies dossier par dossier. Et des instances de Claude, surnommées « superfans », surveillent chacune un composant à partir de ses journaux pour repérer ce que les alertes classiques ratent.

Claude a aussi participé à la construction. Une version préliminaire de Claude Mythos a réécrit le programme qui importe l'historique git dans Scion : il consomme 20 fois moins de mémoire et tourne 4 fois plus vite. L'équipe en tire une leçon plus terre à terre : « Very often, we found that the role of the engineers was to tell Claude "no." » Les agents violaient parfois des contraintes du système, et le travail des ingénieurs consistait souvent à dire non à Claude.

Ce que vaut Scion dans l'absolu

Des gains importants, mesurés par Anthropic seul

Anthropic annonce une infrastructure 200 fois plus économe en processeur et en mémoire que ses anciens miroirs git, des copies de code obtenues en quelques secondes au lieu de plusieurs minutes, et 25 % de capacité de calcul libérée sur la CI. Ce sont des chiffres de l'entreprise. Personne ne les a mesurés de façon indépendante.

Peu d'idées vraiment nouvelles

Anthropic cite lui-même ses modèles : Piper chez Google et Sapling chez Meta. Google a quitté les outils standards il y a plus de dix ans. En 2016, son dépôt unique comptait 86 To, environ 25 000 développeurs, et recevait chaque jour 16 000 changements faits par des humains et 24 000 faits par des systèmes automatisés. Piper tournait déjà sur Spanner (Communications of the ACM). Google lance aussi la plupart de ses tests après la soumission du code, avec annulation automatique des changements fautifs, une pratique décrite dès 2020 (Software Engineering at Google). Microsoft, de son côté, a gardé git pour Windows en ajoutant une couche de virtualisation.

Les critiques sont arrivées dans la journée. Simon Willison y voit « a reinvention of centralized source control along the lines of Subversion », c'est-à-dire le retour à un serveur central comme avant git (simonwillison.net). Sur Hacker News, où l'annonce a dépassé 840 points et 900 commentaires, d'anciens de Google rappellent que Perforce faisait déjà tout cela. D'autres jugent un historique de 100 Go absurde, notent que la centralisation crée un point de défaillance unique, ou se demandent qui relit vraiment 30 000 merge requests par jour (Hacker News).

Ce qui est nouveau : qui a atteint cette échelle, et en combien de temps

C'est le rythme qui nous a le plus frappés. Google et Meta ont construit leurs systèmes pour des dizaines de milliers d'ingénieurs, en une décennie. Anthropic a atteint une échelle comparable avec des agents, et a construit Scion, son outil de revue, sa recherche de code et ses droits d'accès à sept personnes en cinq mois, pendant que le volume de merge requests était multiplié par plus de dix. Et là où Google, Meta et Microsoft ont gardé une forme de compatibilité avec les outils existants, Anthropic a fait une migration complète.

Ce que Scion n'est pas

Scion n'est pas une alternative à git que l'on peut installer. Anthropic écrit que Scion « is by no means a suitable replacement for git for general use », et qu'il est « difficult to offer Scion in a form that would be broadly useful to other organizations ». L'adopter obligerait à remplacer tout le cycle de développement : revue, recherche, CI. L'entreprise dit vouloir partager ses idées avec GitHub, GitLab et les mainteneurs de git.

Plusieurs articles affirment qu'Anthropic a « confirmé » que Scion ne serait pas open source. Nous n'avons trouvé aucune déclaration en ce sens : la formule vient d'une phrase de The Register que le journaliste n'attribue pas à Anthropic.

Le problème dépasse Anthropic

GitHub vit la même chose à l'échelle du monde. En septembre 2026, développeurs et agents y ont fait 7,38 milliards de commits, plus de cinq fois le volume de septembre 2025. Les fusions de pull requests ont presque quadruplé, et GitHub Actions a tourné 3,26 milliards de fois en un mois. GitHub l'écrit sans détour : « Agentic software development is driving the next architectural shift » (GitHub). En avril, son directeur technique annonçait qu'il fallait concevoir la plateforme pour 30 fois son échelle d'alors (GitHub). En août, une panne de près de huit heures était due à un manque de capacité. Selon Satya Nadella, une pull request sur trois sur GitHub implique désormais un agent.

GitLab fait le même constat dans un document d'architecture de juin 2026 : « we see a significant rise in RPC calls that are caused by agentic workloads, and we expect this to accelerate » (GitLab). Un seul clone de son propre dépôt mobilise 4 à 6 Go de mémoire sur le serveur.

Mitchell Hashimoto, fondateur de HashiCorp, qui a retiré son projet Ghostty de GitHub en avril, le dit à sa façon : « The issue isn't Git, it's the infrastructure we rely on around it: issues, PRs, Actions » (The Register). Ce qui cède en premier, ce sont les tickets, les pull requests et la CI qu'on a construits autour de git.

Git n'est pas GitHub : les forges libres hébergées en Europe

Quand on parle de « git saturé », on parle surtout des serveurs de GitHub. Une entreprise peut faire tourner git ailleurs, avec des logiciels libres, chez elle ou chez un hébergeur européen.

Forgejo est la forge libre qui monte. C'est une branche de Gitea, sous licence GPL depuis 2024, dont la marque est détenue par Codeberg, une association berlinoise. En avril 2026, le gouvernement néerlandais a lancé code.overheid.nl, une instance Forgejo qu'il héberge lui-même, ouverte aux ministères des Finances, des Affaires étrangères, de l'Agriculture et de l'Intérieur, ainsi qu'aux villes de La Haye, Utrecht, Leyde et Arnhem. GitHub a été écarté parce que propriétaire, GitLab à cause de son modèle « open core », où une partie des fonctions est réservée à la version payante (It's FOSS). Fedora migre aussi vers Forgejo, et les projets Zig et Gentoo ont quitté GitHub pour Codeberg, en reprochant notamment à GitHub de pousser Copilot.

GitLab Community Edition reste le choix le plus répandu en auto-hébergement, y compris dans le secteur public : forge de l'Adullact pour les collectivités françaises, forge des communs numériques de l'Éducation nationale, openCode en Allemagne, code.europa.eu pour les institutions européennes. GitLab est toutefois une entreprise américaine. Clever Cloud propose un GitLab managé hébergé en Europe.

Il existe d'autres options : Gitea, SourceHut (aux Pays-Bas) et Heptapod, une variante française de GitLab pour Mercurial maintenue par Octobus.

L'argument de souveraineté se renforce. Depuis le 24 avril 2026, GitHub entraîne Copilot sur les données d'interaction des comptes individuels, sauf refus explicite (les offres Business et Enterprise ne sont pas concernées) (heise). Nous détaillons cette question de dépendance dans notre article sur la souveraineté numérique face aux États-Unis.

Ces forges ne règlent pas le problème de débit. Codeberg tient sur trois serveurs et, en juillet 2026, ses membres ont voté l'interdiction des projets « vibe-codés », dont ceux « created by LLM "agents" in autonomous ways », notamment parce qu'un disque qui coûtait 700 € en coûte aujourd'hui 3 700 (Codeberg). SourceHut interdit depuis septembre le contenu écrit avec un LLM pour les nouveaux projets. Une forge européenne répond à la question de la souveraineté. Le débit des agents, c'est à l'entreprise de le dimensionner.

Ce qui va émerger pour les très gros logiciels

Pour la plupart des équipes, git n'a aucune raison de disparaître. Pour un très gros logiciel sur lequel travaillent des milliers d'agents, nous pensons en revanche que son modèle ne tient plus : un serveur qui doit servir des copies complètes, des calculs faits sur des postes qui n'existent que quelques minutes, une branche principale qu'on verrouille pour tester. Ce qui va le remplacer se lit déjà dans les choix de GitHub, de GitLab, de Google et de quelques start-up, qui convergent sur six points.

Git reste sur le poste, le serveur change complètement

GitHub sépare désormais le stockage du calcul, place les données de référence dans un stockage objet et ne coordonne plus que la mise à jour des branches, pour un débit en écriture jusqu'à 35 fois supérieur en interne. GitLab propose la même architecture. La start-up East River Source Control construit un serveur qui parle le protocole git sans stocker de dépôt git. Martin von Zweigbergk, créateur de l'outil Jujutsu, l'a rejointe comme directeur technique en septembre 2026, après quinze ans chez Google. Son diagnostic : « the remote server is still Git, which has a ceiling that comes fast for products at scale » (ERSC). Scion pousse cette logique jusqu'au bout, en abandonnant aussi git côté client.

Les dépôts deviennent des services qu'on interroge

Un agent n'a pas besoin de cloner 100 Go pour lire trois fichiers. GitLab étudie un « repositories as a service » avec une API par dépôt, dont il cite comme usage les espaces de travail d'agents. Anthropic appelle les forges à standardiser ces appels côté serveur. Personne ne l'a encore fait.

Les copies de travail deviennent virtuelles

Le développeur, humain ou agent, voit tout le dépôt, mais seuls les fichiers qu'il ouvre sont téléchargés. Google le fait depuis des années. Jujutsu, un client compatible git, est aujourd'hui généralisé en interne chez Google, avec un système de fichiers virtuel en préparation.

La fusion se fait après, et autrement

Tester après la fusion avec annulation automatique devient la norme à grande échelle. La fusion elle-même devient plus intelligente : Mergiraf, un outil libre hébergé sur Codeberg, fusionne en comprenant la structure du code. Sur 7 415 fusions conflictuelles du noyau Linux, il en résout entièrement 428 (LWN). Les LLM retrouvent la bonne résolution dans 55 à 62 % des cas selon une étude de Virginia Tech de juillet 2026 (arXiv). C'est mieux que les outils classiques, mais loin d'être fiable.

L'intention est conservée avec le code

Quand un agent écrit le code, savoir ce qui a changé ne suffit plus : il faut pouvoir retrouver la demande qui a produit le changement. Cursor propose un format ouvert, Agent Trace, qui relie chaque portion de code à la conversation qui l'a produite. Entire, la start-up de l'ancien PDG de GitHub Thomas Dohmke, a levé 60 millions de dollars pour stocker les prompts et les décisions avec chaque commit. Le noyau Linux impose déjà une mention Assisted-by: pour le code écrit avec une IA.

Chaque agent a une identité et des droits limités

Scion attribue des permissions dossier par dossier et des règles d'approbation selon le type de changement. Les fournisseurs d'identité suivent : Okta a rendu disponible en août 2026 une authentification unique dédiée aux agents.

Le modèle qui se dessine

Mitchell Hashimoto parle d'un « Gmail moment for version control » : ne plus rien supprimer, tout archiver (The Pragmatic Engineer). Pour un très gros logiciel, cela donne : git, ou un client compatible comme Jujutsu, sur le poste ; un service de dépôt distribué et interrogeable par API côté serveur ; des tests après fusion ; une trace de l'intention attachée à chaque changement.

Ce qu'une DSI peut en retenir dès maintenant

1. Garder git. Tous les outils le connaissent, les agents aussi, puisqu'ils ont appris à coder sur des dépôts git. Git continue d'évoluer : sa version 2.56, sortie en septembre, calcule certaines opérations sur un gros monorepo en 0,01 seconde au lieu de 0,68.
2. Mesurer la part des agents. Combien de pull requests ouvertes par des agents, combien de temps d'attente en revue et en CI ? C'est là que le goulot apparaîtra en premier, bien avant le gestionnaire de versions.
3. Choisir sa forge pour la souveraineté, puis la dimensionner pour les agents. Un Forgejo ou un GitLab Community Edition hébergé en Europe convient, à condition de prévoir la capacité de CI, des plafonds de pull requests par agent et des accès MCP maîtrisés. Nous expliquons ce que MCP change pour les agents dans cet article.
4. Relire selon le risque. Anthropic classe son code par niveau de risque et réserve la revue humaine au code critique, tout en faisant relire par des humains un échantillon du reste. Vercel fusionne 58 % des pull requests de son plus gros dépôt sans revue humaine, selon une grille de risque (Vercel). Relire l'intention plutôt que chaque ligne suppose d'avoir écrit, pour chaque type de changement, ce qu'on attend de lui.
5. Donner à chaque agent une identité et le minimum de droits. Un agent qui peut tout fusionner partout est un risque, comme un compte de service sans restriction. Nos principes pour les agents IA en entreprise s'appliquent ici.
6. Regarder au-delà du code. Chez l'hébergeur Neon, 80 % des bases de données étaient déjà créées par des agents en octobre 2025. Chez Vercel, plus de la moitié des déploiements sont lancés par des agents depuis juin 2026. Le ticketing, l'ERP, le CRM, la gestion des identités et les contrats de logiciels facturés par utilisateur ont été conçus pour des humains, eux aussi. Netlify a donné un nom à cette question : l'Agent Experience, ou expérience de l'agent quand il est l'utilisateur d'un produit. Les outils dont vos agents deviendront les principaux utilisateurs subiront la même pression que git chez Anthropic.

Questions fréquentes sur Scion et git

Qu'est-ce que Scion d'Anthropic ?

Scion est le système de gestion de versions qu'Anthropic a construit pour remplacer git sur son dépôt principal, annoncé le 13 octobre 2026. Contrairement à git, il exécute les commits, les fusions et les requêtes d'historique sur le serveur, s'interroge par API et ne conserve jamais de copie complète du dépôt sur les postes. Sept ingénieurs l'ont construit en cinq mois, avec un outil de revue de code (Antique), une recherche de code et une gestion des droits d'accès.

Pourquoi Anthropic a-t-il abandonné git ?

Parce que son dépôt principal est passé d'environ 2 500 à plus de 30 000 merge requests par jour entre mai et septembre 2026, et que presque tous ses utilisateurs sont des agents d'IA et des tâches automatiques connectés en permanence. Git est conçu pour des développeurs humains qui ont chacun une copie complète du code et peuvent travailler hors ligne. À cette échelle, servir ces copies et faire tourner une file de fusion était devenu le principal goulot de développement d'Anthropic.

Scion est-il open source ?

Non, et il n'est pas proposé à l'extérieur. Anthropic juge difficile d'en faire un outil utile à d'autres organisations, puisque l'adopter imposerait de remplacer toute la chaîne de développement, et dit vouloir partager ses idées avec GitHub, GitLab et les mainteneurs de git. Anthropic n'a pas pour autant annoncé que Scion ne serait jamais ouvert : cette affirmation, reprise par plusieurs sites, vient d'une phrase de The Register qui ne cite pas l'entreprise.

Faut-il quitter git ?

Non, pour la quasi-totalité des entreprises. Anthropic écrit lui-même que Scion n'est pas un remplaçant de git pour un usage général. Le problème se pose pour des dépôts de dizaines de gigaoctets qui reçoivent des milliers de merge requests par jour. Les forges comme GitHub et GitLab refondent leurs serveurs pour absorber la charge des agents, tout en gardant git côté développeur.

Quelle différence entre Scion d'Anthropic et Scion de Google ?

Ce sont deux projets sans lien. Scion d'Anthropic est un système de gestion de versions interne, qui a remplacé git. Scion de Google, publié en open source sur GitHub en 2026, est un banc d'essai pour faire travailler plusieurs agents de code en parallèle, chacun dans son conteneur avec sa propre copie de travail git. Il existe aussi SCION, une architecture réseau développée à l'ETH Zurich, sans rapport avec les deux.

Quelles alternatives open source à GitHub peut-on héberger en Europe ?

Les deux principales sont Forgejo et GitLab Community Edition. Forgejo, sous licence GPL et gouverné par l'association berlinoise Codeberg, a été choisi en 2026 par le gouvernement néerlandais pour sa forge publique. GitLab Community Edition est très répandu dans les administrations européennes, mais son éditeur est américain. Gitea, SourceHut et Heptapod sont d'autres options. Toutes peuvent être auto-hébergées ou confiées à un hébergeur européen.

---

Git va très bien, et la plupart des entreprises le garderont longtemps. Scion montre autre chose : un outil conçu pour des humains finit par céder quand ses principaux utilisateurs deviennent des agents. Anthropic a eu les moyens de tout reconstruire en cinq mois. Les autres attendront que GitHub, GitLab ou une start-up comme ERSC le fassent pour eux.

Pour une DSI, l'exercice utile est de repérer dans son système d'information les outils qu'utiliseront bientôt surtout des agents, et de mesurer où ils coinceront. Le gestionnaire de versions sera rarement le premier.