Nous avons retiré Git d'un produit en production : le développement piloté par la roadmap

Le 11 juillet, nous avons archivé .git

Le 11 juillet 2026, nous avons compressé le répertoire .git de Junyr (notre plateforme souveraine d’e-mail et de gestion d’entreprise, en production, plus de 90 fonctionnalités opérationnelles), déposé l’archive sur un serveur de sauvegarde, et supprimé Git de l’arbre de travail. Depuis, toute commande git status y répond ce qu’elle doit répondre : fatal: not a git repository.

C’est une décision documentée et réversible : l’archive existe, la procédure de restauration aussi. Elle découle d’un constat que beaucoup d’équipes feront dans les prochaines années. Quand le code n’est plus écrit par des mains humaines mais par des agents IA orchestrés, Git continue de versionner quelque chose, seulement plus la chose qui compte.

Quatre jours plus tard, au moment où nous publions : cinquante plans enregistrés au registre qui remplace Git, vingt déjà livrés, et un lot de douze plans implémenté en une journée puis promu en production le lendemain, bascule conditionnée à la santé des services, zéro retour arrière.

Cet article raconte ce que nous avons mis à la place, pourquoi cela fonctionne et, surtout, dans quels cas il ne faut pas nous imiter.

Ce que Git versionne, ce qu’il ne versionne plus

Git a été créé en 2005 par Linus Torvalds pour le développement du noyau Linux, avec un problème précis à résoudre : des centaines d’humains modifiant les mêmes fichiers en parallèle, sans autorité centrale. Toutes ses primitives (la branche, la fusion dite merge, le diff, le blame) découlent de ce problème : réconcilier le travail simultané de personnes qui tapent du texte. Pour ce problème, Git reste inégalé, et rien ici ne dit le contraire.

Mais quand des agents IA écrivent l’essentiel du code, trois déplacements silencieux se produisent.

Le diff cesse d’être l’unité de revue. Personne ne relit sérieusement un diff de 3 000 lignes générées en vingt minutes. La revue de code par lecture du diff (la fonction sociale de la pull request) était déjà morte de fait dans les équipes qui ont adopté les agents ; elle survivait comme rituel. Les chiffres publiés en mai 2026 par The Register donnent la mesure du problème : les projets générés par IA ont crû de 206 % sur un an sur GitHub, et le code généré y accumule 10,83 problèmes par pull request, contre 6,45 pour le code humain [2]. Plus de volume, moins de lisibilité, plus de défauts par lot : le contrôle ne peut plus être la relecture du texte produit. Il doit se déplacer : en amont vers la décision, en aval vers la vérification outillée.

Le commit cesse de porter l’intention. Un message de commit rédigé par un agent décrit ce qui a changé, pas ce qui a été décidé. L’intention réelle vit ailleurs : dans le prompt, dans le plan, dans la session d’orchestration. Scott Chacon, cofondateur de GitHub, le reconnaît lui-même : l’interface de Git n’a pratiquement pas changé depuis 2005, et il faut repenser le versionnement pour les humains et pour les agents. Son pari : « les meilleurs ingénieurs du futur seront les meilleurs rédacteurs » [1].

La branche cesse d’être le bon niveau de parallélisme. Le conflit de fusion est l’artefact d’un choix, celui de paralléliser au niveau du code. Si l’on parallélise au niveau des décisions (plusieurs plans instruits en même temps) et que l’on sérialise l’écriture (un seul implémenteur à la fois), le conflit de fusion ne devient pas plus facile à résoudre : il disparaît du système.

L’industrie voit le même problème et répond majoritairement par « un meilleur Git » : interfaces agentiques, branches parallèles repensées, outillage dédié [1][2]. Jusqu’à Cursor, qui a annoncé en juin 2026 Origin, un hébergeur Git « pour l’ère agentique » conçu pour des dizaines d’agents en parallèle, où la revue humaine est explicitement repensée en approbation par lots, voire déléguée à un autre agent [4]. C’est la bonne réponse pour des équipes humaines nombreuses. Dans notre contexte (un produit, un décideur humain, des agents qui écrivent), nous avons choisi la réponse radicale : retirer Git et versionner autre chose.

Le renversement : versionner l’intention, pas le texte

Ce renversement a un nom académique. Début 2026, un courant baptisé spec-driven development s’est structuré : la spécification devient la source de vérité, le code un artefact dérivé, généré ou vérifié contre elle. La littérature distingue trois degrés de rigueur : spec-first (la spec précède le code), spec-anchored (la spec reste le référentiel vivant), spec-as-source (le code n’est plus maintenu directement du tout) [3]. GitHub, AWS et les principaux outils d’agents ont chacun leur déclinaison.

Notre variante déplace légèrement le curseur : nous ne versionnons pas des spécifications complètes, nous versionnons des décisions. La nuance est pratique. Une spécification exhaustive vieillit mal et se relit difficilement ; une décision (quel mécanisme réutiliser, quelle approche retenir, quels contrats respecter, qu’est-ce qui est explicitement hors-périmètre) vieillit bien et se relit en un écran. Le code, lui, est devenu ce que la fonte est à un moule : régénérable, vérifiable, remplaçable. Ce qui est rare et précieux, c’est le moule.

D’où le nom que nous donnons à la méthode : le développement piloté par la roadmap (roadmap-driven development). La roadmap devient le registre opérationnel par lequel passe chaque changement du produit, mise à jour en continu plutôt que revue par trimestre.

Concrètement : deux tables, une CLI, six états

L’infrastructure de remplacement tient en une phrase : une base de données dédiée, deux tables, une CLI shell de quelques centaines de lignes.

La première table est l’inbox, tout le matériau amont : idées, éléments de backlog, notes, et rapports de bug des utilisateurs bêta remontés automatiquement de la production. Chaque élément est trié explicitement : écarté, ou promu en plan.

La seconde table est le registre des plans. Chaque plan porte un identifiant (T-001, T-002…), ses dépendances, son niveau de risque, et son texte intégral. Il traverse six états : draft → ready → approved → doing → done (plus abandoned). Le cycle de vie complet :

roadmap next                 # prochain identifiant libre
roadmap submit T-042.md      # le plan entre au registre, le brouillon devient jetable
roadmap approve T-042        # gate humain : rien ne s'implémente sans ça
roadmap claim T-042          # UN SEUL implémenteur à la fois
roadmap done T-042           # livré, vérifié, consigné au journal

Quatre règles font tenir l’ensemble.

1. Toute session d’agent planifie par défaut. Aucune n’implémente sans ordre explicite. N sessions de planification tournent en parallèle ; chacune explore le code, instruit son sujet et soumet un plan. Le plan doit être « décision-complet », actionnable sans nouvelle exploration : fichiers exacts, mécanismes existants à réutiliser, contrats (signatures, schémas), tests à écrire, hors-périmètre explicite. Pas de code complet : un à trois écrans. Un plan trop risqué est découpé en plans chaînés par dépendances.

2. Le gate humain est absolu. Un plan non approuvé ne s’implémente jamais. C’est la revue de code déplacée là où elle redevient possible : relire une décision d’un écran plutôt qu’un diff de 3 000 lignes. L’approbation engage ; c’est l’application au développement du principe que nous défendons pour tous les agents : l’agent propose, l’humain engage.

3. Un seul écrivain (single-writer). L’implémentation est portée par une seule session d’orchestration à la fois, multi-agents à l’intérieur, selon la boucle UltraCoding : implémenteurs parallèles, revue adversariale, vérification avant livraison. Première étape après le claim, une passe de fraîcheur : vérifier à peu de frais que les fichiers et mécanismes nommés par le plan existent encore tels que décrits. Si le code a bougé depuis la rédaction du plan, le plan retourne en soumission et repasse le gate. Et toute re-soumission d’un plan déjà approuvé invalide mécaniquement son approbation : on ne peut pas glisser un changement sous une signature ancienne. La recherche explore la voie opposée : plusieurs agents écrivant dans le même espace de travail, chaque écriture validée contre l’état courant des fichiers et rejetée si la vue de l’agent est périmée. Le cadre STORM (mai 2026) gagne ainsi 18,7 points sur un benchmark de code face à l’isolation par worktrees Git [5]. C’est notre passe de fraîcheur, appliquée en continu, fichier par fichier ; nous avons préféré sérialiser : un peu de débit en moins, une classe entière de conflits en moins à gouverner.

4. Le journal fait foi. Ce qui est livré est consigné dans un journal en ajout seul : ce qui a shippé, quand, pourquoi, avec quels suivis. L’historique du produit se lit comme un récit de décisions datées, pas comme un log de commits.

La table d’équivalence

La question honnête est « qu’est-ce qui assure chacune des fonctions de Git ? ». Voici la correspondance, fonction par fonction :

Fonction assurée par Git	Ce qui la remplace
Branches, worktrees : paralléliser le travail	Plans instruits en parallèle ; écriture sérialisée (single-writer). Le conflit de fusion disparaît du système, pas seulement résolu
Pull request : relire avant d’intégrer	Approbation humaine du plan avant implémentation, plus vérification outillée après (tests, lint, contrôles)
Log, blame : comprendre le passé	Registre des plans et journal en ajout seul : l’historique des décisions, pas des lignes
Revert : revenir en arrière	Déploiement par images complètes, version précédente étiquetée rollback, bascule conditionnée à la santé des services
Bisect : retrouver l’origine d’une régression	Plus de 200 règles anti-régression numérotées et exécutables, un portique de près de 700 contrôles, plus les suites de tests sur base réelle
Remote, push : sauvegarder	Archive quotidienne du code hors site et export automatique du registre à chaque écriture (restauration testée, pas supposée)

La ligne la plus importante est celle du bisect. Git permet de retrouver le commit fautif après coup ; les règles anti-régression exécutables interdisent à la régression connue de revenir, à chaque vérification. C’est le même déplacement que pour la revue : du contrôle rétrospectif sur le texte au contrôle permanent sur le comportement.

Quatre jours plus tard : les chiffres

La bascule date du 11 juillet 2026. Au 15 juillet : 50 plans au registre (20 livrés, 10 en cours, 7 approuvés en attente d’implémentation, 13 en attente du gate), et une quarantaine d’éléments dans l’inbox, dont les rapports de bug bêta remontés de production. Le 13 juillet, l’orchestrateur a implémenté un lot de 12 plans approuvés en une journée ; le 14, le lot est parti en production : bascule saine du premier coup, zéro rollback.

Ce que la friction supprimée a rendu : plus de worktrees à monter, plus de fusions entre sessions d’agents, plus de rebase. Les sessions de planification ne se marchent jamais dessus : elles n’écrivent que dans le registre. Et le goulot d’étranglement du système est devenu exactement celui qu’on veut : le temps de décision humain au gate, quelques minutes par plan.

Deux filets restent tendus en permanence : les archives .git complètes, la décision est réversible en une commande, et l’export du registre embarqué chaque nuit dans la sauvegarde hors site ; la procédure de restauration a été testée le jour même de la bascule.

L’honnêteté : quand il ne faut surtout pas nous imiter

Cette méthode fonctionne parce que cinq conditions sont réunies. Qu’une seule manque, et retirer Git est une bêtise.

1. Un seul décideur humain. Deux humains qui modifient le même code ont besoin de fusion : c’est précisément le problème que Git résout mieux que tout. Une équipe de développeurs humains doit garder Git.
2. La revue de diff avait déjà cessé d’être le contrôle réel. Chez nous, le code est écrit par des agents et contrôlé par des tests, des règles exécutables et une vérification systématique. Si vos développeurs relisent réellement les diffs, la pull request est votre outil de revue. Gardez-la.
3. Une production « promote-only », jamais éditée directement, avec un chemin de retour arrière éprouvé (images, bascule conditionnée à la santé).
4. Un filet exécutable dense : tests sur base réelle, règles anti-régression, portique de contrôles. Sans lui, supprimer Git, c’est supprimer votre dernier filet.
5. Des sauvegardes testées : le mot important est « testées ».

Il faut aussi nommer ce qu’on perd vraiment : le bisect fin quand une régression échappe aux règles, le blame ligne à ligne, l’outillage de contribution externe. Un projet open source vit par les pull requests et ne peut pas s’en passer. Si l’un de ces usages est vital pour vous, mieux vaut suivre la voie que trace l’industrie qu’imiter notre choix : un Git repensé pour les agents [1].

Ce que ça dit pour un dirigeant, au-delà du code

Vous ne retirerez probablement jamais Git de vos systèmes. Le sujet réel est le déplacement que cette histoire illustre, et il dépasse le logiciel.

Quand des agents produisent (du code, mais aussi des propositions commerciales, des campagnes, des reportings), la ressource rare qui mérite un registre, des états et une signature n’est plus l’artefact produit. C’est la décision humaine. Le pilotage par roadmap n’est rien d’autre que cela : un registre d’intentions dont chaque entrée est explicite, approuvée, datée et traçable ; l’agent instruit, l’humain engage, l’exécution est vérifiée, le journal fait foi.

C’est la même boucle que nous installons chez nos clients avec la Méthode MATIA™, fonction par fonction : la génération devient abondante partout ; la gouvernance de la décision devient le standard partout. La question à poser à vos équipes (ou à votre prestataire) porte moins sur « utilisez-vous l’IA ? » que sur la gouvernance qui l’entoure : où est le registre de ce que vos agents ont le droit de faire, qui a signé chaque autorisation, et qu’est-ce qui vérifie l’exécution ? Une organisation qui répond en montrant un outil a compris l’époque. Une organisation qui répond « c’est dans les commits », ou pire « dans l’historique du chat », a un problème de gouvernance, pas un problème d’outillage.

En une phrase

Git versionnait le travail des mains humaines ; quand les mains deviennent des agents, ce qu’il faut versionner (et garder sous signature humaine), ce sont les décisions.

Pour installer cette boucle de gouvernance (registre d’intentions, gate humain, exécution vérifiée) dans vos projets IA, voir la Méthode MATIA™ et le Diagnostic IA Express.

Pour aller plus loin

• Dans la même série : Le vibe coding est mort : place à l’UltraCoding, la chaîne de production qui implémente les plans, et Ingénierie des systèmes agentiques : l’humain dans la boucle, le principe « l’agent propose, l’humain engage » appliqué à tous les agents.

Paul-Antoine TUAL, AI Transformation Leader · Croissance et Transitions (SAS) · Méthode MATIA™ · Junyr Mail™ · Junyr Agents™

---

Sources : vérifiées, juillet 2026

[1] a16z Podcast, « Rethinking Git for the Age of Coding Agents », entretien avec Scott Chacon (cofondateur de GitHub, CEO de GitButler), 21 avril 2026, interface de Git quasi inchangée depuis 2005, versionnement à repenser pour humains et agents, « the best engineers of the future will be the best writers ». https://a16z.com/podcast/rethinking-git-for-the-age-of-coding-agents-with-github-cofounder-scott-chacon/ [2] Joab Jackson, « Git is unprepared for the AI coding tsunami », The Register, 15 mai 2026, +206 % de projets générés par IA sur GitHub en un an (2025) ; 10,83 problèmes par pull request pour le code généré contre 6,45 pour le code humain ; Scott Chacon : « run locally, mirrored globally ». https://www.theregister.com/devops/2026/05/15/git-is-unprepared-for-the-ai-coding-tsunami/5241480 [3] Deepak Babu Piskala, « Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants », arXiv:2602.00180, 30 janvier 2026, la spécification comme source de vérité, le code comme artefact dérivé ; les trois degrés spec-first / spec-anchored / spec-as-source. https://arxiv.org/abs/2602.00180 [4] Cursor (Anysphere), « Origin », hébergeur Git « pour l’ère agentique », annoncé à la conférence Compile le 17 juin 2026, conçu pour des agents en parallèle (démonstration éditeur : 22,6 commits par seconde sur un dépôt), revue pensée en approbation par lots ; liste d’attente, sortie annoncée pour l’automne 2026. https://cursor.com/origin [5] Mengyang Liu, Taozhi Chen, Zhenhua Xu, Xue Jiang, Yihong Dong, « Multi-agent Collaboration with State Management » (cadre STORM, STate-ORiented Management), arXiv:2605.20563, 19 mai 2026, écritures concurrentes d’agents validées contre l’état courant de l’espace de travail partagé, écriture périmée rejetée à la volée ; +18,7 points sur Commit0-Lite et +1,4 sur PaperBench face à l’isolation par worktrees Git. https://arxiv.org/abs/2605.20563

Les chiffres internes (50 plans, lot de 12, délais, contrôles) sont issus du registre de développement de Junyr, relevés le 15 juillet 2026, quatre jours après la bascule décrite.