À l’échelle agentique, un système où chaque nœud héberge une copie complète et autonome de l’historique Git n’est plus viable.

Anthropic, Cursor, GitHub et OpenAI s’accordent sur ce point. Chacun a entrepris de faire évoluer son système de gestion de versions en abandonnant le modèle purement décentralisé.

Anthropic abandonne Git pour un système propriétaire

Sur son monorepo interne, Anthropic est passé d’environ 2500 merges par jour en mai 2026 à plus de 30 000 en septembre. Avec un historique principal avoisinant 100 Go et près de 25 millions d’extractions quotidiennes pour le CI, l’utilisation classique de Git aurait exigé de transférer plus de 600 Po de données par jour. Le palliatif consistant à exécuter des centaines de miroirs et de snapshots de dépôts sur stockage objet était devenu ingérable.

Anthropic a opté pour une rupture avec Git. Il l’a remplacé par un système maison baptisé Scion et développé en 5 mois.

Exit, donc, le modèle décentralisé. Le serveur gère les opérations lourdes (merges, rebases, création des commits…) tandis que le client local se résume à une couche légère gérant un cache borné et la matérialisation à la demande des fichiers sur le disque.

Contrairement à un commit Git pointant vers un arbre complet d’objets, le changeset de Scion ne stocke que la liste des fichiers modifiés par rapport au premier parent. Cette liste est associée à des pointeurs adressés par contenu vers des blobs compressés.

Une approche asymétrique par changesets et caches hiérarchiques

De Git, Scion supprime aussi les packfiles. Il n’utilise, en parallèle, aucune copie totalement matérialisée du dépôt. La création d’un changeset s’effectue en temps proportionnel à la taille de la modification – et non à la taille du dépôt. Les références globales (branches, tags) sont strictement découragées hors de la branche principale ou des versions. Leur mise à jour se fait par CAS (compare-and-swap) sur une ligne de base Spanner.

Pour calculer rapidement le blame ou les graphes de commits, Scion génère des « données dérivées » (skip lists, index de chemins) définies récursivement et calculables à la demande. Le système expose ces primitives par API. CI et outils internes peuvent ainsi effecteur des requêtes sans cloner en local.

Le client communique via un socket avec un démon de nœud qui interroge des caches mémoire régionaux. Ces derniers s’alimentent auprès de serveurs d’autorité adossés à Spanner et au stockage objet. Un hiérarchie qui isole les pannes et supprime les protocoles de négociation de Git.

Anthropic affirme que cette infra consomme 200 fois moins de ressources calcul et mémoire que son ancienne flotte Git. Il ajoute que la CI a gagné 25 % de capacité CPU, avec des checkouts qui s’effectuent désormais en quelques secondes.

Source de vérité	Spanner et GCS
Modèle de cohérence	Append-only (changesets) sur Spanner, données dérivées asynchrones
Écritures	Aucun push, commits créés côté serveur sans verrou
Format de transfert	Arbres et blobs individuels adressés par contenu
Compaction	Éliminée (aucun packfile, aucun repacking)

Cursor emploie un WAL S3 comme source de vérité unique

Cursor a conservé le format de stockage et les outils natifs de Git sur disques NVMe locaux. Pour surmonter les limites de Spokes (architecture historique de réplication de GitHub), il a conçu un moteur alternatif nommé Continuity. Il l’a appliqué à son monorepo et à une flotte de micro-dépôts.

Son architecture est centrée sur un concept propre à S3 : les journaux d’écriture anticipée (WAL, Write-Ahead Logs). Lesquels consistent, dans les grandes lignes, à stocker plusieurs objets dans un même fichier de manière séquentielle. Ici, chaque push prend la forme d’une entrée de WAL distincte. Aucun push n’est acquitté tant qu’il n’est pas persisté sur S3. Un fichier d’index de WAL mis à jour par CAS linéarise chaque transaction.

Les répliques sur disques NVMe locaux ne sont que des caches qu’on réhydrate depuis le WAL. La localisation des dépôts ne dépend pas d’une base relationnelle centrale. Si un nœud tombe ou qu’un dépôt n’est pas présent localement, il est matérialisé depuis le WAL.

N’importe quel nœud peut recevoir une écriture et agir comme primaire. L’atomicité du CAS sur S3 garantit l’intégrité. La propagation des lectures se fait via un commérage UDP, chaque réplique vérifiant son état contre la source de vérité.

Continuity monte à 120 pushs par seconde sur S3 Standard ; à plus de 300 avec S3 Express One Zone. On atteint ensuite la limite intrinsèque de vitesse de compaction Git sur disque. En lecture, le système a démontré une montée en charge linéaire jusqu’à 100 répliques sans impacter les écritures.

Source de vérité	WAL S3
Modèle de cohérence	Stricte et linéarisable via index S3
Écritures	Locale + S3 en parallèle, linéarisée par CAS sur l’index S3
Format de transfert	Packfiles classiques
Compaction	Repackaging asynchrone sur répliques découplées

OpenAI opte pour la cohérence causale…

En deux ans, le volume de commits atterrissant sur la branche master du monorepo d’OpenAI a été multipliée par 25 environ. La fiabilité du contrôle de version était passée sous les 90 %. En 10 semaines, l’entreprise a développé Pando.

Ce back-end rejette l’idée qu’un serveur doit fournir un état cohérent de l’ensemble des branches à un instant T lors d’un clone ou d’un fetch. Les mises à jour de chaque branche sont indépendantes et sérialisables individuellement, mais Pando remplace le snapshot global par un modèle de cohérence causale. Un client qui récupère une branche respecte l’historique de l’auteur qui l’a créée, sans que le système impose d’ordre d’interclassement global avec les branches non liées. Deux clients qui lisent différentes branches au même moment peuvent donc voir des versions décalées dans le temps.

Traditionnellement, chaque fetch oblige le serveur à calculer dynamiquement la différence entre les objets que détient le client et ceux demandés. Puis à compresser un packfile sur mesure. Pando réutilise des packfiles immuables préexistants. Les serveurs n’ont par conséquent plus à recalculer de deltas à la volée.

Lors d’un push, le packfile qu’envoie le client est validé en une seule passe et streamé directement vers le stockage objet, sans déballage local. Une transaction enregistre une « version de référence » dans le magasin de métadonnées et bascule le pointeur de la branche de façon atomique. Lors de la phase de négociation du push, Pando n’annonce pas l’intégralité de ses branches. Cela évite de créer des packs trop interdépendants ou trop fragmentés.

… et pour des packfiles réutilisables

Pour transférer les données, Pando utilise packfile-url, directive Git qu’OpenAI a perfectionnée en amont dans le projet open source. Lors d’un fetch, la réponse HTTP principale renvoie un packfile vide accompagné d’une liste d’URI pointant vers les packfiles requis. Les clients téléchargent ces packs depuis Express, un service de cache régional distribué. Cela permet de maximiser l’usage de la bande passante réseau sans solliciter le CPU sur le serveur.

Chaque push génère un pack de niveau L0. Des processus en tâche de fond regroupent géométriquement l’ensemble des packs en couches supérieures (L1 à L4) pour améliorer la compression et accélérer les extractions.

OpenAI explique que Pando a réduit la latence médiane des pushs de près de 80 %. Et qu’il permet de délivrer près de 1 Po de données Git par jour avec « une poignée » de cœurs CPU.

Source de vérité	Stockage objet immuable + magasin de métadonnées
Modèle de cohérence	Cohérence causale
Écritures	Streaming direct vers le magasin d’objets sans décompression locale
Format de transfert	Packfile vide inline + URI de packfiles précompressés réutilisables
Compaction	Hiérarchique multiniveaux façon LSM-Tree (L0 à L4)

GitHub modernise Spokes grâce aux quorums par référence

En un an, le volume de commits qu’a enregistrés GitHub a plus que quintuplé : 7,38 milliards en septembre 2026, pour 3,35 milliards de pushs.

L’architecture qu’il a commencé à déployer en production minimise la coordination. Le quorum et le protocole 3PC (verrouillage des commits en 3 étapes) ne portent plus sur l’ensemble du dépôt. Ils sont isolés au niveau de chaque référence (branche) individuelle. Les agents qui travaillent en parallèle sur des branches distinctes ne subissent plus de contention mutuelle. Les étapes lourdes (écriture des objets, validation de connectivité, analyse des secrets) se déroulent hors du chemin critique. L’étape de coordination se réduit donc au déplacement du pointeur de référence. Les tests internes ont démontré un débit d’écriture 3 à 4 fois plus élevé sur les dépôts concurrents.

Comme ses pairs, GitHub a découplé le stockage du calcul. Il a confié les données d’autorité au stockage objet Azure. Un nœud de calcul éphémère intègre le quorum de vote comme passerelle. Il streame les écritures, agrège les transactions de branches disjointes en un nombre réduit d’E/S, puis s’occupe de la compaction. D’autres nœuds temporaires sont instanciés à la demande pour absorber les pics de lecture. Ils réconcilient leur cache en arrière-plan avec Azure Blob Storage. Des workers indépendants gèrent le décompactage, le repacking et le nettoyage des objets orphelins.

Dans son architecture cible, GitHub annonce un gain potentiel de débit d’écriture allant jusqu’à un facteur 35. Tout en assurant une montée en charge autonome de la couche de lecture.

Source de vérité	Azure Blob Storage
Modèle de cohérence	Forte via quorum délimité par référence
Écritures	Concurrentes sur branches disjointes via quorum par référence
Format de transfert	Packfiles classiques
Compaction	Workers d’arrière-plan isolés du chemin critique

Illustration générée par IA

The post Anthropic, Cursor, GitHub, OpenAI : 4 approches pour passer Git à l’échelle agentique appeared first on Silicon.fr.

Je ne sais pas si vous êtes déjà tombé dessus, mais le ministère de l'Éducation nationale fait tourner son propre GitLab depuis un petit moment maintenant, il est public, et il s'appelle La Forge des communs numériques éducatifs . Au moment où j'écris ces lignes, il y a dessus 12 896 projets et 15 638 membres dans ce qu'ils appellent "l'atelier".

Alors c'est quoi cette dinguerie comme disent les anciens ? Hé bien derrière, c'est du GitLab CE, infogéré par le pôle de compétences Logiciels Libres (oui, ça existe, et c'est un vrai service de l'Éducation nationale), et classé dans les services partagés d' apps.education.fr .

Les 595 ressources de la ressourcerie, avec les étiquettes de niveau et de discipline sous chaque fiche

Et le plus beau c'est que pour aller fouiller dedans, vous n'avez besoin de rien du tout puisque les dépôts publics s'ouvrent via le navigateur, sans authentification.

Bien sûr, cette grosse dizaine de milliers de dépôts de code bruts, ça ne se visite pas comme ça. Il y a donc une vitrine, nommée la ressourcerie , qui en met en avant un peu moins de 600, triées par niveau, par discipline et par tag et pour la plupart, testables en ligne.

Par contre, pousser du code est un poil plus encadré. Pour cela, le personnel du ministère doivent avec leur compte Apps, et tous les autres, profs retraités, universitaires, Inria, boîtes de l'EdTech, associations, et j'en passe, passent par un second annuaire avec validation préalable.

Donc non, vous ne pourrez pas y déposer votre side-project éducatif du week-end, mais si votre truc sert vraiment à des profs, la porte n'est pas fermée...

Là-dessus l'Éducation nationale n'est pas toute seule, puisque les Pays-Bas ont également monté leur forge de code , où une cinquantaine d'administrations et de communes publient déjà.

Et l'IA là-dedans ?

Hé bien c'est complètement décomplexée et tant mieux ! Le catalogue a 7 tags officiels rien que pour ça, de "IA chatbot" à "IA prompt" en passant par "IA LLM souverain", et 48 fiches en font partie. Ce n'est donc pas la majorité du catalogue, mais il y a quand même un projet nommé EduVaibe dont le boulot est de "générer, étape par étape, un prompt complet à coller dans une IA pour créer des applications numériques éducatives".

Le truc le plus utile du lot, je trouve, même quand on n'a aucune classe à gérer, c'est ChatMD . Vous forkez le dépôt, vous remplacez le contenu d'index.md par vos propres réponses écrites en Markdown, et votre agent conversationnel bien à vous est ensuite accessible à partir d'une simple URL. Le tout est sous licence MIT bien sûr !

Maintenant derrière une bonne partie de ces dépôts, il y a un prof tout seul qui bricole sur son temps libre, et malheureusement, le jour où il abandonne, le projet s'arrête. Mais la bonne nouvelle c'est que la Forge rétribue chaque année quelques profs pour justement les soutenir dans leurs projet.

C'est maigre à l'échelle d'un ministère, je vous l'accorde, mais c'est quand même mieux que rien. Voilà, en attendant, je vous invite à y faire un tour ! Vous y trouverez peut-être des choses intéressantes.

Merci à Sylvain Bruyère pour le lien !

Depuis ce printemps, sachez qu'un git clone ordinaire peut maintenant récupérer un dépôt qui n'existe sur aucun serveur spécifique. En fait, le code est stocké dans Freenet, le réseau pair-à-pair qu'Ian Clarke a relancé en mars. Et comme y'a plus d'hébergeur, bah y'a plus personne pour fermer un compte ou shooter le dépôt.

Car Git est décentralisé depuis toujours et fonctionne très bien comme ça, puisque chaque clone contient l'historique complet, ce qui permet à 2 clones de se synchroniser directement. Ce qui lui manquait par contre, c'était l'hébergement, et c'est là-dessus que les forges que nous connaissons, Github en tête, sont venues capitaliser. Y'a bien des initiatives comme Grasp qui essaie d'en sortir grâce au protocole Nostr mais freenet-git lui range carrément le dépôt dans un contrat que les nœuds recopient, et se publie lui-même à l'adresse freenet::99TmCayXn6Tm/freenet-git.

Cloner ou publier du code exige donc le paquet freenet-git et un nœud qui tourne sur votre machine, ce qui fait qu'on ne supprime pas vraiment le serveur, mais on le ramène juste chez soi.

perso, je n'ai jamais été très à l'aise avec Git. Je l'utilise tous les jours, mais c'est vraiment pas ma came. Dès que ça devient trop compliqué, genre conflit de merge qui repeint des dizaines de fichiers en rouge, je ne m'en sors plus ^^.

Heureusement qu'il y a l'IA pour m'aider dans des moments difficiles ! Mais si vous n'aimez pas confier la gestion de vos merges à un LLM en aveugle, je vous invite à découvrir GitWand, développé par Laurent Guitton, qui s'occupe uniquement de la gestion des conflits avec Git et vous laisse gérer le reste.

Gitwand, c'est donc un client Git open source, sous licence MIT, qui classe chaque bloc conflictuel selon des règles fixes et ne résout automatiquement que ceux dont le résultat ne fait aucun doute.

Pour cela, il dispose de plusieurs patterns déterministes :

• same_change, c'est quand les deux branches ont écrit exactement la même chose.
• whitespace_only ne voit qu'une indentation qui a bougé,
• reorder_only les mêmes lignes remises dans un autre ordre.
• Un numéro de version qui change, lui, tombe dans value_only_change.
• Et puis il y a complex, le fourre-tout des modifications qui se chevauchent pour de vrai. Celle-là n'est jamais tranchée toute seule.
• git rerere rejoue les résolutions que vous avez déjà tranchées à la main,
• et Mergiraf se branche directement dans git merge pour arbitrer en lisant l'arbre syntaxique de votre code.

Ce qui change ici, c'est que chaque décision est justifiée. En effet, chaque bloc reçoit un score de confiance ainsi qu'une trace qui nomme le motif retenu ligne par ligne.

Par exemple, si une branche écrit const theme = 'dark', et l'autre const theme = localStorage.getItem('theme') ?? 'dark', hé bien l'outil garde la seconde, étiquette sa décision prefer-theirs, et affiche 97 % de confiance à côté.

Sur la page d'accueil, l'outil annonce 95 % des conflits triviaux résolus automatiquement. Le moteur est aussi exposé aux agents IA via un serveur MCP, ce protocole qui branche des outils externes sur des assistants comme Claude Code ou Cursor. L'installation se fait comme ceci : claude mcp add gitwand -- npx -y @gitwand/mcp.

L'agent réclame un aperçu, récupère les blocs déjà réglés, et ne garde que les cas ambigus, avec les trois versions du code sous les yeux. Le modèle ne touche qu'à ce qu'aucune règle ne sait faire, soit l'inverse de ce qu'on voit d'habitude.

Le projet est jeune et ça se voit. Mais ça vaut le coup d'essayer parce que je pense que ça peut rendre de nombreux services. L'app existe pour macOS, Linux et Windows, l'interface est traduite en français, et elle se double d'une ligne de commande (npm i -g @gitwand/cli) et d'une extension VS Code.

Si l'interface graphique vous tente, je vous avais montré Gittyup dans le même registre, et pour les irréductibles du terminal j'avais présenté Lazygit .

À vous maintenant de commencer par gitwand resolve --dry-run --verbose pour voir "à blanc" ce qu'il trouve et comment il aurait tranché pour le merge.

Merci à Laurent pour le lien !

Source