Le remplacement de Git par Anthropic : quand le volume de code dépasse la revue humaine

Quand un outil conçu pour le rythme humain rencontre le rythme machine

Selon des informations remontant au compte rendu de ce changement par Simon Willison, Anthropic a construit son propre remplacement de Git. Le déclencheur n'était ni un bug ni un incident de sécurité. C'était le volume. Le rythme des changements arrivant dans la base de code de l'entreprise a grimpé en flèche, et en mai 2026 il atteignait en moyenne environ 2 500 requêtes par période, une charge que la gestion de versions classique n'avait pas été conçue pour supporter.

Il est facile de classer cela parmi les outils internes et de passer à autre chose. Ce serait une erreur. Git est l'un des logiciels les plus importants jamais écrits, et il repose sur un ensemble d'hypothèses sur la manière dont le code évolue, hypothèses aujourd'hui contredites dans la pratique.

Les hypothèses sur lesquelles Git a été bâti

La conception de Git encode une croyance sur le comportement humain. Les changements arrivent à un rythme qu'une personne peut examiner. Une branche représente une intention qui dure assez longtemps pour être nommée. L'historique est précieux, donc rien n'est jeté. Un mainteneur peut lire un diff et se former un avis avant de le fusionner.

Chacune de ces hypothèses s'affaiblit quand des agents écrivent du code.

Les agents ne se fatiguent pas, ils produisent donc des changements en continu plutôt qu'en lots d'une journée de travail. Ils ne conservent pas une intention pendant des jours, les branches deviennent donc assez éphémères pour que les nommer soit une charge inutile. Ils génèrent bien plus de diffs qu'un relecteur humain ne peut en lire vraiment, ce qui fait de l'étape de relecture, autour de laquelle tout le flux de travail de Git est organisé, un goulot d'étranglement plutôt qu'une garantie.

Le résultat est un système qui fonctionne bien au-delà de son domaine de conception, tandis que tout le monde insiste sur le fait que rien n'a changé. Le dépôt fonctionne toujours. Le processus qui l'entoure cesse de signifier ce qu'il signifiait.

Ce qui casse vraiment en premier

L'inquiétude naïve porte sur le stockage. C'est en réalité le moindre des problèmes. Le disque est bon marché, et Git compresse bien.

La première véritable victime est la relecture. Une pull request dont le diff de 4 000 lignes a été généré par un agent est techniquement relisible et pratiquement pas. Les relecteurs font ce que les humains font toujours en cas de surcharge : ils survolent, ils font confiance au résumé, ils approuvent. La relecture survit comme cérémonie tout en perdant sa fonction, ce qui est pire que de la supprimer, car la cérémonie crée une fausse confiance.

La deuxième victime est l'identité. L'historique de Git est un registre de qui a décidé quoi et quand. Quand la plupart des commits sont écrits par un modèle agissant sur un prompt, l'historique contient toujours des noms, mais ces noms ne répondent plus à la question pour laquelle l'historique existe. On ne peut pas demander à un agent pourquoi il a choisi telle approche il y a six semaines, parce qu'il ne s'en souvient pas, et le message de commit a été généré par le même système qui a fait le choix.

La troisième victime est la branche elle-même. Créer une branche est bon marché dans Git et coûteux en attention humaine. Si les branches se multiplient plus vite que quiconque ne peut s'en occuper, on obtient un arriéré d'intentions que personne ne porte, ce qui est un échec différent d'un conflit de fusion et plus difficile à voir.

Pourquoi un remplacement est plus qu'un Git plus rapide

Si le problème était le débit, la solution serait un serveur plus rapide. Qu'Anthropic construise quelque chose de nouveau suggère que le problème est structurel.

Un système de gestion de versions optimisé pour des changements au rythme de la machine serait différent sur des points précis. Il supposerait que la plupart des changements sont éphémères et devraient être peu coûteux à créer comme à abandonner. Il traiterait le diff comme un résumé plutôt que comme l'artefact, et attacherait à chaque changement une intention lisible par machine pour qu'un agent puisse la retrouver plus tard sans lire le code. Il serait conçu pour la recherche, pas pour l'archéologie.

Il devrait aussi répondre à une question que Git n'a jamais eu à se poser. Git suppose que l'artefact intéressant est l'état final du code. Dans un flux de travail piloté par des agents, l'artefact intéressant est souvent le raisonnement qui a produit un changement et les vérifications qui l'ont validé. Si ceux-ci vivent en dehors de la gestion de versions, alors la gestion de versions n'enregistre que la moitié de l'historique.

La tenue de registre à laquelle personne ne pense avant d'en avoir besoin

La gestion de versions n'est pas seulement un système de classement. C'est le substrat de la facturation, de la conformité et de la réponse aux incidents. Les auditeurs veulent savoir qui a changé quoi et quand. Les industries réglementées veulent un registre défendable qui résiste à un examen. Les équipes de sécurité reconstituent des chronologies à partir des commits.

Si la réponse honnête à ces questions devient « un agent l'a fait, sur une branche qui n'existe plus, et le raisonnement vivait dans une fenêtre de contexte depuis jetée », alors le registre comporte un trou. Les trous dans les registres sont précisément ce que les audits sont conçus pour trouver, et un outil qui en produit sans que personne ne le remarque serait un problème sérieux bien avant de devenir un scandale.

Le signal plus large

Anthropic n'est pas la seule à ressentir cette pression, et les versions réduites de la même histoire sont déjà visibles ailleurs. GitHub a récemment retravaillé son API d'historique des étoiles de dépôt pour que les données de tendance reviennent en 24 requêtes au lieu d'environ 2 500, sans exiger un travail de base de données illimité ni exposer les utilisateurs ayant mis une étoile. GitHub a aussi livré un classifieur de détection de secrets sensible au contexte qui a augmenté le taux d'acceptation des vraies trouvailles de 11,5 pour cent tout en réduisant le temps de scan médian de 86 pour cent.

Les deux répondent à la même condition de fond : le volume de code dans le monde augmente, et l'outillage conçu à l'époque où les humains étaient les seuls auteurs commence à montrer son âge. La détection de secrets en est une bonne illustration. Le risque d'un identifiant divulgué évolue avec la quantité de code écrite, donc un système adéquat aux rythmes de production humains devient inadéquat aux rythmes de production des agents, même si rien dans sa conception n'a changé.

La partie que personne ne veut dire à voix haute

Il existe une version de cette histoire où l'IA rend les équipes logicielles nettement plus productives, l'outillage suit, et tout le monde s'en sort bien.

Il en existe une autre où le volume de code généré dépasse la capacité humaine à le comprendre, et où l'industrie finit avec des dépôts qu'aucune personne seule ne comprend, tenus ensemble par des tests que personne n'a écrits et des relectures que personne n'a faites. Le signe annonciateur de cette version n'est pas un plantage. C'est une dérive lente, où la base de code continue de fonctionner et où le nombre de personnes qui comprennent pourquoi ne cesse de baisser.

Remplacer Git est, dans cette lumière, un symptôme qui mérite d'être remarqué. Cela signifie que l'une des entreprises les plus prudentes du secteur a jugé que l'outil standard était devenu un handicap précisément à la couche où la correction est suivie. Ce n'est pas un petit aveu. C'est le signal que l'infrastructure du logiciel est appelée à changer plus vite que ses hypothèses ne peuvent suivre.

La réponse pratique pour tous les autres est peu romantique. Mesurez quelle part de votre code est écrite par une machine. Regardez si votre étape de relecture change encore quelque chose. Remarquez si votre historique peut encore répondre au pourquoi. Ce sont des questions peu coûteuses, et les réponses vous diront si vous avez besoin d'un nouvel outil ou simplement d'une nouvelle habitude.