Git n'a pas été conçu pour les agents : deux ex-GitHub, deux réponses

Il y a des coïncidences qui n'en sont pas. En l'espace de quatre mois, deux personnes qui ont contribué à faire de GitHub le centre de gravité du logiciel mondial ont levé de l'argent pour expliquer, chacune à sa manière, que les fondations ne tiennent plus. Scott Chacon, cofondateur de GitHub et auteur de Pro Git, avec GitButler. Thomas Dohmke, PDG de GitHub pendant quatre ans, parti en août 2025, avec Entire.

Leur diagnostic tient en une phrase : Git a été conçu pour des humains qui s'envoyaient des correctifs par listes de diffusion, un développeur, une branche, un terminal, un flux linéaire. Les agents ont cassé chacune de ces hypothèses en même temps.

Le constat est juste. Ce qui suit est plus intéressant que les chiffres de débit — parce que les deux, en attaquant des étages différents, finissent par pointer la même chose.

Ce qu'attaque Entire : le tuyau

Le 8 juillet 2026, Entire a ouvert la préview de son Distributed Git Network, avec des régions actives aux États-Unis, dans l'Union européenne et en Australie. Le mécanisme est volontairement peu intrusif : en une étape, on crée un miroir régional d'un dépôt GitHub existant. Le code reste sur GitHub ; ce sont les agents qui clonent et récupèrent depuis le miroir le plus proche. Le trafic de lecture — massif, concurrent, généré par des agents qui n'ont aucune raison d'attendre — cesse de taper sur le serveur central.

Dohmke résume l'argument en citant Linus Torvalds, qui déclarait en 2007 : « If you're not distributed, you're not worth using. » Sa lecture : Git était distribué par conception, l'hébergement centralisé l'a re-centralisé, et à l'ère des agents cette centralisation redevient une contrainte visible sous forme de limites de débit, de latence et de pannes.

Les chiffres publiés par l'entreprise :

Entire (chiffres annoncés, obtenus en simulation)
  clones ....... ~570 000 / heure  (1 dépôt, 200 clients, 4 villes UE)
  push ......... 586 / seconde = ~2,1 M / heure  (1 dépôt ou 1 branche)
  mixte ........ ~470 opérations / seconde (boucle clone + push)

Cursor Origin (chiffre du concurrent, tel que cité par Entire)
  push ......... ~81 360 / heure

Un mot sur la prudence à avoir, et il vient des articles eux-mêmes. Ce sont des simulations, pas des mesures en production : 200 clients simulés effectuant un clonage superficiel depuis Francfort, Paris, Londres et Dublin. La comparaison avec Cursor Origin est une comparaison faite par Entire, à partir d'un chiffre revendiqué par Cursor. Et comme le note L'Usine Digitale, la vraie épreuve n'est pas le benchmark, c'est le ramp-up : tenir la charge en conditions réelles pendant qu'on déploie l'infrastructure. Entire annonce vouloir publier son backend Git et sa suite de benchmarks en open source — c'est la bonne réponse à cette objection, et il faudra la juger sur pièces.

Pour le contexte : Entire a cinq mois, une levée d'amorçage de 60 millions de dollars menée par Felicis (avec Madrona, M12 — le fonds de Microsoft, ce qui n'est pas anodin —, Basis Set Ventures, Jerry Yang et Garry Tan), une valorisation de 300 millions, et plus de 40 salariés dans neuf pays. L'hébergement natif de nouveaux dépôts est annoncé « dans les prochains mois », avec l'objectif d'une décentralisation complète.

Ce qu'attaque GitButler : les primitives

Chacon s'en prend à un autre étage. Pas au tuyau, mais à la forme même d'un changement. GitButler a levé 17 millions de dollars en série A menée par Andreessen Horowitz en avril 2026, et publié la préversion technique de sa ligne de commande, but : branches empilées, multitâche, annulation, réorganisation des changements — utilisable indifféremment par un humain ou par un agent.

Sa formulation du problème est, à mon sens, la meilleure des deux :

« Les développeurs ne rencontrent pas de difficultés parce qu'ils ne savent pas coder. Leurs difficultés proviennent d'un manque de cohérence entre les outils, entre les personnes, et maintenant entre les personnes et les agents. La véritable difficulté n'est pas de générer des changements, mais de les organiser, de les examiner et de les intégrer sans créer de chaos. »

La réception, en revanche, a été rugueuse — et il faut la rapporter honnêtement, parce qu'elle est instructive. Sur les forums, la réponse dominante tient en une ligne : « Git n'est pas SVN, et ces problèmes sont déjà résolus. » Plusieurs voix font remarquer que la vraie cible n'est pas Git mais GitHub — le premier étant un bien commun difficile à détrôner, le second une plateforme commerciale attaquable.

Surtout, la méfiance s'est cristallisée sur un détail très concret : à l'installation, GitButler posait un hook pre-commit qui bloque git commit et redirige vers but commit, sans opt-in. Chacon est intervenu pour expliquer qu'il s'agit d'une nécessité architecturale liée à sa gestion des branches parallèles. L'explication est recevable ; la leçon reste. Sur une infrastructure critique, la tolérance à un défaut installé sans consentement est nulle. Cette réaction en dit plus long sur ce que le marché acceptera que n'importe quel benchmark.

Effet secondaire notable : la discussion a surtout profité à Jujutsu (jj), système de contrôle de versions open source utilisant Git comme backend, dont le modèle par instantanés automatiques s'accorde bien avec le développement assisté par IA — on itère librement, on remet de l'ordre après coup. Plusieurs développeurs décrivent son usage combiné avec un agent, via un hook qui déclenche un instantané à chaque modification de fichier.

Deux étages, un même diagnostic

Ces deux projets ne se concurrencent pas vraiment. Dohmke s'occupe de l'endroit où les octets circulent ; Chacon, de la forme que prend une modification. On peut parfaitement imaginer les deux dans la même chaîne.

Ce qui compte davantage que l'un ou l'autre produit, c'est le fait brut : deux personnes qui ont construit le monde actuel en sont sorties en concluant, indépendamment, que ses fondations sont désalignées. Quand des insiders de ce niveau vont chercher 77 millions de dollars pour reconstruire une couche qu'ils ont eux-mêmes rendue dominante, ce n'est pas un signal faible.

Quand le tuyau cesse d'être la limite, la limite remonte d'un étage

Prenons le chiffre au sérieux. 2,1 millions de push par heure sur un seul dépôt. Admettons que ce soit tenu en production.

Qui lit ça ?

La question n'est pas rhétorique. Le problème que documentent déjà les équipes qui travaillent avec des agents, ce sont les demandes de fusion de 10 000 lignes, la difficulté à établir la paternité d'un changement, les conflits entre branches travaillées en parallèle par plusieurs agents. Supprimer la limite de débit ne supprime pas la contrainte : elle la déplace. La ressource rare cesse d'être le débit et devient l'attention — et la décision.

Un des commentateurs cités par Developpez pose d'ailleurs la bonne question, celle qui restera quand les benchmarks seront oubliés : à mesure que les agents produisent des dizaines de commits par heure, la notion de commit comme unité de travail humain a-t-elle encore un sens ? Sincèrement, non. L'unité qui garde du sens est plus grossière : une fonctionnalité livrée, une version validée sur un environnement. Le commit redevient ce qu'il était censé être au départ — un détail d'implémentation.

L'accord inattendu : ce qui manque, c'est le pourquoi

C'est là que les deux se rejoignent, et c'est de loin la partie la plus intéressante de ces annonces.

Le fondement d'Entire n'est pas le réseau. C'est une couche de mémoire sémantique qui capture chaque session d'agent, chaque prompt, chaque appel d'outil, et les range dans le dépôt à côté du code. Elle alimente trois fonctions : Entire Blame (remonter d'une ligne de code à la conversation qui l'a produite), Entire Review (envoyer une branche à plusieurs agents en parallèle pour une revue qui connaît l'intention), et une recherche sémantique qui répond à « pourquoi ce code existe » et pas seulement à « qu'est-ce qui a changé ». Dohmke le formule sans détour :

« Les journaux de session sont désormais le deuxième artefact le plus important dans le développement logiciel, et leur place est dans le dépôt, aux côtés du code. »

Chacon, de son côté, décrit un contexte « qui se fragmente entre les outils, entre les personnes, et maintenant entre les personnes et les agents », et vise à terme des outils qui intègrent « les conversations et les décisions dans l'historique du dépôt ».

Deux chemins, une même conclusion : à l'ère des agents, le code n'est plus l'artefact rare. Il se régénère à la demande. Ce qui ne se régénère pas, c'est l'intention — la contrainte métier qui imposait ce choix, l'arbitrage qui a été tranché, ce qu'on avait essayé et écarté.

Là où nous ne sommes pas d'accord

Nous construisons Survol sur ce constat depuis le début, donc on ne va pas bouder notre plaisir de le voir formulé par ces deux-là. Mais nous en tirons des conclusions différentes sur trois points, et autant les poser clairement.

Un journal de session est une trace, pas une décision. La trace dit ce qui s'est passé. La décision dit ce qui a été écarté, par qui, et pourquoi. On peut fouiller une trace ; on ne pilote pas avec. Un prompt enregistre ce que quelqu'un a demandé à un instant donné — ce n'est pas la même chose qu'un engagement pris par une équipe, daté, discuté, éventuellement contesté. La différence n'est pas cosmétique : la première est un artefact d'exécution, la seconde est un artefact de gouvernance.

Une mémoire exhaustive n'est pas une mémoire utilisable. Les journaux de session grossissent plus vite que le code, et leur valeur décroît avec le temps. Une décision produit tient en dix lignes et reste vraie deux ans. Objection honnête à notre propre argument : la recherche sémantique est précisément la réponse d'Entire à ce problème, et c'est une bonne réponse. Reste que chercher dans un historique et consulter une liste de décisions tranchées ne demandent pas le même effort — ni la même compétence.

Sur l'endroit où cette mémoire vit, nous avons fait le choix inverse — et l'argument de Dohmke est bon. Ranger l'historique à côté du code, c'est garantir qu'il survit au changement d'outil et qu'il est cloné avec le dépôt. C'est solide. Notre parti pris est autre : le dépôt du client appartient au client, et un historique d'exécution qui y grossit est une forme d'appropriation de son espace de code. Chez nous, le rapport d'exécution est un objet de l'outil, le résumé part dans le corps de la demande de fusion — versionné chez le fournisseur de code, là où on décide de fusionner — et l'archive markdown dans le dépôt existe en option par produit, désactivée par défaut. C'est un arbitrage, pas une vérité : les deux positions se défendent.

Enfin, une chose qu'aucun des deux ne traite, et ce n'est pas un reproche — ce n'est pas leur étage. Le journal de session documente une exécution déjà faite. Ce qui l'a décidée — la spécification, l'arbitrage, la contrainte d'organisation — se passe avant, et souvent nulle part : dans la tête de la personne qui a écrit le prompt. C'est cet étage-là que nous outillons, et il reste utile quel que soit le vainqueur de la bataille du dessous.

Ce que ça change pour une équipe, cette semaine

• Le patron du miroir est peu risqué. Le code reste sur GitHub, on ajoute une copie régionale pour les lectures. Si vos agents tapent des limites de débit, s'inscrire sur la liste d'attente ne coûte rien et n'engage à rien. C'est nettement moins engageant qu'un changement de client Git.
• Ne confondez pas un problème de débit et un problème de lisibilité. Test simple : prenez vos vingt derniers changements fusionnés et essayez de dire, pour chacun, pourquoi il a été fait. Si vous n'y arrivez pas, aucune infrastructure ne réglera ça.
• La réserve sur le capital-risque est légitime, et elle vaut pour tout le monde. ZDNet la formule sobrement : on s'expose toujours en s'appuyant sur un service qui peut perdre son financement. Une valorisation de 300 millions devra rendre des comptes un jour. La règle pratique tient en deux questions : est-ce que ça laisse mon code là où il est, et qu'est-ce qui se passe si je pars ?
• Région n'est pas juridiction. Entire met en avant la résidence des données et la souveraineté. L'Usine Digitale relève le point qui manque au raisonnement : la société est basée à Seattle, donc soumise aux lois extraterritoriales américaines. Héberger à Francfort ne change pas cela. Pour une DSI européenne, c'est une distinction qui compte.

Ce qu'on en retient

1. Deux anciens de GitHub attaquent deux étages différents : Dohmke le transport (miroirs régionaux, décentralisation), Chacon les primitives (branches empilées, forme d'un changement). Ils ne se concurrencent pas.
2. Les chiffres d'Entire — 570 000 clones/heure, 2,1 millions de push/heure — sont des simulations annoncées par l'entreprise. L'ouverture promise du backend et des benchmarks est la bonne réponse ; le ramp-up reste l'épreuve réelle.
3. Supprimer la limite de débit déplace le goulot d'étranglement vers l'attention et la décision. À ce rythme, le commit cesse d'être une unité de travail signifiante.
4. Le point d'accord le plus important n'est pas technique : les deux affirment que l'artefact rare est devenu l'intention derrière le code. Nous partageons ce constat.
5. Nous divergeons sur la forme (une trace n'est pas une décision) et sur le lieu (le dépôt du client appartient au client). Ce sont des arbitrages défendables des deux côtés, pas des vérités.

Git a mis vingt ans à devenir l'infrastructure invisible sur laquelle repose l'intégralité du développement logiciel. Son successeur, quel qu'il soit, devra résoudre des problèmes techniques inédits et convaincre une communauté aussi méfiante des monopoles qu'attachée aux standards ouverts. Sur ce terrain, la partie se jouera moins sur les 2,1 millions de push par heure que sur une question plus ancienne : à qui appartient l'histoire du code ?

Sources : SiliconANGLE, 8 juillet 2026 · GeekWire, 8 juillet 2026 · L'Usine Digitale, 9 juillet 2026 · ZDNet, 10 août 2026 · Developpez, 13 avril 2026. Tous les chiffres de performance cités sont ceux communiqués par les entreprises concernées.