En résumé : Anthropic Scion est le système de gestion de versions interne développé par Anthropic après que ses agents de développement ont fait passer le nombre de fusions (merges) sur son monorepo d'environ 2 500 par jour en mai 2026 à plus de 30 000 par jour en septembre. Scion exécute les commits, merges et rebases directement sur le serveur. Il s'agit d'un outil interne, et Anthropic précise qu'il n'a pas vocation à remplacer Git pour un usage général.
Ce qu'Anthropic a accompli avec Scion, et pourquoi
Le 13 octobre 2026, l'équipe d'ingénierie d'Anthropic a publié Redesigning source control at Anthropic. Le constat initial est sans détour : « l'écriture du code n'est plus le goulet d'étranglement pour concevoir des systèmes ou mener des recherches. » Le véritable obstacle, écrivent-ils, réside dans « l'ensemble de l'infrastructure de développement conçue à l'échelle humaine : la gestion de versions, les builds et la CI. »
Les chiffres parlent d'eux-mêmes. En mai 2026, l'entreprise intégrait environ 2 500 modifications de code par jour. En septembre, ce chiffre dépassait les 30 000. Soit une multiplication par douze en seulement quatre mois, qu'Anthropic attribue directement aux agents qui écrivent désormais le code.
Git tenait bon à l'échelle humaine. À l'échelle des agents, il a cédé. Anthropic rapporte environ 25 millions de checkouts CI par jour, un historique de la branche principale avoisinant les 100 Go et plusieurs centaines de miroirs Git internes au plus fort de la charge. Une stratégie de fetch naïve aurait généré plus de 600 Po de trafic Git quotidien.
Une équipe de sept personnes a donc conçu Scion, un outil de revue de code nommé Antique, un moteur de recherche de code ainsi qu'un système de contrôle d'accès par répertoire. Ils ont migré le monorepo hors de Git en cinq mois. Anthropic a même confié à Claude Mythos Preview la réécriture du pipeline d'ingestion Git vers Scion, aboutissant à une version consommant 20 fois moins de mémoire tout en s'exécutant 4 fois plus vite.
Si vous déployez Claude Code, Codex ou un autre agent de développement au sein d'une équipe, cet article vous offre un aperçu de votre prochain goulet d'étranglement. Sharkly a été pensé précisément pour résoudre ce problème : il centralise le travail des agents, leurs résultats et leur revue au sein de tâches partagées plutôt que de les disperser dans des terminaux isolés.
En quoi Scion diffère de Git
Git part du principe que chaque clone constitue une copie complète et autonome de l'historique, capable de fonctionner hors ligne. Scion adopte la démarche inverse : les clients sont connectés en permanence et effectuent très peu de calculs par eux-mêmes.
| Git | Anthropic Scion | |
|---|---|---|
| Where commits, merges and rebases run | En local, sur votre machine | Sur le serveur |
| Local data | Historique complet | Un cache d'objets limité, checkout partiel (sparse) ou virtualisé |
| Unit of work | Commit pointant vers un arbre (tree) | Changeset dans un journal write-ahead, listant les fichiers modifiés |
| Branches and refs | Peu coûteuses et encouragées | Découragées, à l'exception de main et des branches de release |
| Fetch | Packfiles | Par objet (arbres, puis blobs), sans maintenance de dépôt |
| Offline work | Oui | Non |
| Main clients | Humains | Agents, CI et jobs de recherche |
L'architecture s'articule autour de trois niveaux : scion-daemon sur chaque nœud, scion-cache par région, et un serveur d'autorité scion-server. L'interface en ligne de commande cliente est scn. Le taux de succès du cache (hit rate) dépasse les 99 % à chaque niveau.
Le gain est considérable. L'empreinte CPU et mémoire est 200 fois inférieure à celle de l'ancienne infrastructure de miroirs Git. Les checkouts pour la CI et les tâches de recherche ne prennent plus que quelques secondes au lieu de plusieurs minutes, et la CI a récupéré 25 % de capacité CPU.
Ce que l'on sacrifie avec les commits côté serveur
Les commits côté serveur abandonnent l'atout qui a fait le triomphe de Git : un historique local complet permettant de travailler n'importe où, même dans un avion sans connexion. Anthropic l'assume d'ailleurs sans détour. Scion n'est « en aucun cas un remplaçant adapté à Git pour un usage général », et le proposer sous une forme exploitable par d'autres organisations s'avérerait complexe. L'outil n'est pas distribué, et l'article ne le décrit pas comme un projet open source.
La gestion de la concurrence déjoue elle aussi les attentes. Anthropic ne sérialise pas chaque merge derrière un verrou global. Des modifications concurrentes peuvent donc entrer en conflit, mais l'équipe les intercepte grâce à des tests automatisés exécutés après le merge et avant le déploiement.
Git à l'ère des agents IA : la leçon pour les équipes sans Scion
Vous n'aurez pas accès à Scion, et vous n'en avez pas besoin. Votre dépôt ne pèse pas 100 Go et vous n'exécutez pas 25 millions de checkouts par jour. Ce qui est véritablement instructif dans cet article, c'est la nature du problème décrit, car elle se manifeste à n'importe quelle échelle.
Lorsque ce sont des agents qui écrivent le code, le goulet d'étranglement se déplace en aval. Il touche d'abord les fusions, puis la revue. Les analyses de DevOps.com et de TechSpot décrivent toutes deux Scion comme une infrastructure forcée de rattraper le débit de production des agents. Une équipe de cinq personnes faisant tourner dix agents se heurte à une version miniature de ce même obstacle.
Vous en reconnaîtrez sans doute les symptômes :
- Deux agents modifient le même fichier au cours d'un même après-midi et vous devez résoudre le conflit manuellement.
- Les pull requests s'accumulent plus vite que personne ne peut les relire.
- Les files d'attente de la CI s'allongent de semaine en semaine pendant que les agents continuent de coder à toute vitesse.
- Personne ne sait quel agent a modifié quoi, ni pour quelle raison.
- Une branche créée le mardi devient un cauchemar à rebaser le vendredi.
Anthropic s'est attaqué aux points 1 et 3 en développant une nouvelle infrastructure. De votre côté, vous pouvez résoudre ces cinq problèmes grâce à des processus adaptés et aux outils Git dont vous disposez déjà.
Conflits de fusion et agents de code : pourquoi ils se multiplient
Les conflits de merge n'augmentent pas avec les effectifs, mais avec le chevauchement du code. Dix agents travaillant sur un même objectif global touchent constamment aux mêmes fichiers. Dix agents assignés à dix tâches bien ciblées entrent rarement en collision. La granularité de chaque tâche compte bien plus que le nombre d'agents.
Les branches à longue durée de vie aggravent encore la situation. Chaque heure passée avec une branche ouverte voit la branche principale continuer d'évoluer en parallèle. Les agents accentuent ce décalage parce qu'ils ouvrent des branches bien plus vite que des humains ne peuvent en fermer. Notre précédent article sur le nombre de journées de travail d'agents qu'une journée humaine peut réviser chiffre concrètement cet écart.
Ce que vous pouvez mettre en place dès aujourd'hui sans Scion
Ces cinq bonnes pratiques répondent à l'essentiel des besoins d'une équipe ordinaire. Aucune n'exige de changer de système de gestion de versions.
Attribuer un worktree dédié à chaque tâche
Un worktree Git est un répertoire de travail secondaire rattaché au même dépôt. Dédier un worktree à chaque tâche garantit que deux agents n'écriront jamais simultanément dans le même répertoire.
git worktree add ../tasks/COIN-212 -b agent/COIN-212 origin/main
cd ../tasks/COIN-212
# run the agent here, commit, push, open a PR
git worktree remove ../tasks/COIN-212
Nous détaillons cette configuration dans les worktrees Git pour les agents de développement IA ainsi que le volet nettoyage dans gérer les worktrees sans la corvée du nettoyage.
Définir des tâches courtes et bien ciblées
Rédigez chaque tâche en précisant les fichiers ou le module concernés ainsi que le test qui valide sa complétion. Une tâche qui tient en un diff facile à relire se fusionne sans encombre. Une consigne vague comme « refactoriser l'authentification » mènera droit au conflit.
Mettre en place une merge queue devant main
Une file de fusion (merge queue) teste chaque pull request par rapport à la dernière version de main enrichie de toutes les PR qui la précèdent dans la file, avant de fusionner dans l'ordre. La merge queue de GitHub propose cette fonctionnalité pour les branches protégées. C'est l'équivalent à l'échelle d'une petite équipe de ce qu'Anthropic gère par ses tests post-merge : cela évite de découvrir des incompatibilités de code une fois qu'elles ont déjà été intégrées.
Associer la revue à la tâche, preuves à l'appui
Un simple diff ne permet pas au relecteur de savoir ce qui a été demandé à l'agent ni ce que ce dernier a vérifié. La revue est bien plus rapide lorsque la consigne initiale, l'exécution, les résultats de tests et le diff sont réunis au même endroit. Consultez nos articles sur la revue de code généré par IA étayée par des preuves au niveau de la tâche et sur les raisons pour lesquelles la revue humaine devient le goulet d'étranglement.
Conditionner les agents à une approbation humaine
Laissez les agents explorer, coder, tester et rendre compte. Laissez les humains fixer le cap, valider les étapes délicates et approuver le résultat. Un agent qui s'interrompt pour attendre un feu vert humain avant de merger vous fait perdre quelques minutes. Un agent qui pousse du code non revu sur main vous fait perdre une journée. Notre guide sur les points de validation (approval gates) pour agents de développement vous indique où placer ces garde-fous.
Le rôle de Sharkly
Sharkly ne remplace pas Git et ne résout pas les conflits de fusion à votre place. Vos agents continuent de commiter sur votre dépôt via votre hébergeur Git habituel. En revanche, Sharkly orchestre tout le travail en amont et en aval de ces commits.
Chaque tâche confiée à un agent est une Task dotée d'un Assignee, d'un statut et d'un journal d'exécution. Les agents s'exécutent sur vos propres Computers, en s'appuyant sur l'environnement d'exécution que vous payez déjà (Claude Code, Codex ou autre). En mode Temporary, chaque Task bénéficie d'un répertoire isolé, et les exécutions adossées à un dépôt peuvent préparer un worktree distinct, évitant ainsi que des Tasks concurrentes n'écrivent dans un dossier partagé.
Lorsqu'un agent termine son travail, il peut laisser la Task en attente d'une revue humaine. Cette notification arrive dans Inbox, où le responsable ouvre la Task, examine le résultat en contexte et décide de valider, relancer ou réassigner. L'exécution de la Task et les échanges qui s'ensuivent sont consignés dans la chronologie de la Task, transformant ainsi votre tableau en une véritable file de revue.
Cette approche combine les bonnes pratiques Git mentionnées plus haut et un espace partagé unique pour la consigne, l'exécution, les preuves et la prise de décision. Si vous évaluez plusieurs solutions, notre comparatif d'outils pour gérer des agents de code en parallèle dresse un tour d'horizon complet.
Qui doit agir dès maintenant ?
Les équipes faisant tourner au moins trois agents au quotidien. Vous approchez du mur des fusions. Mettez en place des worktrees et une merge queue dès cette semaine.
Les développeurs solos exécutant des agents en parallèle. Votre goulet d'étranglement n'est pas le merge, mais la revue. Réduisez la portée de vos tâches jusqu'à ce que chaque diff prenne moins de dix minutes à relire.
Les responsables plateforme et infrastructure. Surveillez le temps d'attente de votre CI et l'ancienneté de vos PR. Le retour d'expérience d'Anthropic montre que la gestion de versions et la CI ont flanché avant tout le reste ; attendez-vous à ce qu'il en soit de même chez vous. La configuration d'agents en parallèle avec des worktrees isolés vous fera gagner un temps précieux.
Conclusion
Anthropic Scion est un indicateur de tendance, pas un produit que vous pouvez adopter. Le volume de fusions d'Anthropic a été multiplié par douze en quatre mois, la conception de Git orientée hors ligne n'était plus adaptée, et une équipe de sept personnes a repensé la gestion de versions pour des clients qui sont majoritairement des agents. La plupart des équipes n'auront jamais de tels besoins.
Toutefois, chaque équipe employant des agents de code connaîtra cette même transition : écrire du code devient peu coûteux, tandis que le fusionner et le relire devient très cher. Isolez chaque tâche, découpez-les en petites unités, mettez vos fusions en file d'attente et passez le code en revue preuves à l'appui.
Pour centraliser toute la phase de revue au même endroit, connectez un Computer à Sharkly, créez un Agent et confiez-lui une Task modeste et sans risque. Observez où arrive le résultat, puis jugez sur pièces.
FAQ
Qu'est-ce qu'Anthropic Scion ?
Scion est le système de gestion de versions interne d'Anthropic. Il a remplacé Git pour le monorepo de l'entreprise en 2026. Le serveur prend en charge les commits, les merges et les rebases, tandis que les clients ne conservent qu'un cache local limité.
Pourquoi Anthropic a-t-elle remplacé Git ?
Les agents de développement ont fait passer le nombre de merges quotidiens d'environ 2 500 en mai 2026 à plus de 30 000 en septembre. Les miroirs Git, les checkouts et la CI ne parvenaient plus à suivre un tel rythme, faisant de la gestion de versions le principal goulet d'étranglement.
Scion est-il open source ou disponible à l'utilisation ?
Aucune version publique n'est disponible. Anthropic précise que Scion n'est pas un remplaçant adapté à Git pour un usage général et qu'il serait difficile de le proposer à d'autres organisations. L'entreprise a partagé son architecture technique afin que d'autres puissent en transposer les principes dans Git.
Comment réduire les conflits de merge entre agents de code ?
Attribuez à chaque tâche son propre worktree, définissez des tâches suffisamment restreintes pour tenir en un diff facile à relire, effectuez des merges fréquents et installez une merge queue devant main. Les conflits découlent du chevauchement de fichiers ; le ciblage du périmètre importe donc bien plus que le nombre d'agents.
Les petites équipes ont-elles besoin d'un nouveau système de gestion de versions ?
Pratiquement jamais. Le problème d'Anthropic provenait d'un historique de 100 Go et de 25 millions de checkouts par jour. À une échelle normale, les worktrees, les merge queues et une revue organisée au niveau de la tâche suffisent amplement à absorber la charge.
