Retirer Git du flux actif sans perdre le rollback : notre pilotage par roadmap

Une bascule réversible, pas une disparition de l’historique

Le 11 juillet 2026, Junyr a retiré le répertoire .git de l’arbre de travail utilisé par ses agents, après l’avoir archivé avec sa procédure de restauration, ce qui a réduit leur exposition quotidienne à Git sans effacer l’historique accumulé avant cette date.

• Le périmètre concerné est Junyr, plateforme d’e-mail et de gestion d’entreprise alors décrite en interne comme comptant plus de 90 fonctionnalités opérationnelles.
• L’archive conserve le dépôt tel qu’il existait au moment de la bascule ; elle ne crée pas un historique Git détaillé des changements effectués ensuite.
• Les versions livrées après la bascule restent récupérables par images de déploiement et archives quotidiennes de code, avec une granularité différente de celle des commits.
• L’expérience relatée couvre quatre jours, du 11 au 15 juillet 2026, et ne constitue ni une comparaison contrôlée ni une recommandation générale.

Les premiers chiffres internes décrivent un démarrage dense mais très court, utile pour comprendre le dispositif plutôt que pour conclure à sa supériorité.

• 50 plans figuraient dans le registre au 15 juillet, dont 20 livrés.
• Un lot de 12 plans approuvés avait été implémenté le 13 juillet puis promu en production le lendemain.
• La bascule de ce lot avait satisfait le contrôle de santé et n’avait pas nécessité de rollback.
• Ces données proviennent du registre Junyr et n’ont pas fait l’objet d’une authentification indépendante.

Ce que l’on retire réellement en sortant Git du chemin d’écriture

Git a été créé en 2005 pour le noyau Linux avec, parmi ses objectifs initiaux, la vitesse, le fonctionnement distribué et le soutien à des milliers de branches parallèles ; retirer son interface d’un flux agentique revient donc à redistribuer plusieurs fonctions, et non à les faire disparaître [1].

• Les branches et worktrees organisent des lignes de travail concurrentes.
• Les commits et diffs conservent des états successifs du texte et permettent leur inspection.
• Le log, le blame et le bisect aident à reconstruire puis localiser l’origine d’un changement.
• Les remotes répliquent l’historique, tandis que les sauvegardes servent à récupérer des données après perte ou corruption.

Dans notre configuration, la décision était devenue plus lisible dans le plan approuvé que dans le volume de code produit, mais ce constat interne justifie seulement le déplacement du gate de revue, pas l’idée qu’un diff généré serait par nature inutile.

• Le plan expose l’objectif, les choix structurants, les contrats et les exclusions avant que le code existe.
• Les tests, contrôles statiques et règles anti-régression évaluent ensuite des propriétés exécutables du résultat.
• Un diff ponctuel peut toujours être produit entre deux instantanés pour l’enquête, même si aucune pull request ne structure le flux quotidien.
• Une équipe qui tire une information réelle des revues de code doit conserver ce contrôle, avec Git ou un outil équivalent.

Le modèle réduit les conflits de fusion en déplaçant le parallélisme vers l’instruction des décisions puis en sérialisant l’écriture, au prix d’un plafond de débit et d’un point de coordination explicite.

• Plusieurs sessions peuvent explorer des sujets et soumettre des plans en même temps.
• Une seule session d’orchestration détient le droit d’appliquer les modifications au code.
• Les analyses, tests et revues peuvent rester distribués sans multiplier les auteurs concurrents du même arbre de travail.
• Si l’écriture doit rester parallèle, Git ou une gestion d’état concurrente reste mieux adaptée ; STORM détecte par exemple les conflits au moment de l’écriture dans un espace partagé [4].

L’écosystème explore d’autres réponses que la sérialisation, comme Origin de Cursor, désormais présenté par l’éditeur comme une forge Git pour l’ère agentique et disponible en bêta anticipée sur ses offres payantes [3].

• Cette approche conserve le dépôt Git comme infrastructure centrale.
• Elle vise les contextes où plusieurs agents produisent simultanément.
• La page éditeur consultée le 6 septembre 2026 n’établit pas, à elle seule, un gain indépendant de qualité ou de productivité.

Versionner les décisions en plus des artefacts

Le spec-driven development fournit un cadre voisin en traitant la spécification comme source de vérité et le code comme artefact généré ou vérifié, avec trois niveaux proposés dans un article de 2026 : spec-first, spec-anchored et spec-as-source [2].

• Spec-first place la spécification avant l’implémentation.
• Spec-anchored maintient la spécification comme référence vivante.
• Spec-as-source pousse le modèle jusqu’à ne plus maintenir directement le code.
• L’article propose une taxonomie et des cas d’usage ; il n’établit pas que cette organisation convient à chaque produit.

Notre développement piloté par la roadmap retient une unité plus concise, le plan décision-complet, afin de soumettre au décideur les choix qui engagent le produit sans prétendre que le registre remplace tous les artefacts techniques.

• Le registre conserve le motif, l’approche, les contrats, les dépendances et le hors-périmètre.
• Le code reste nécessaire à l’exécution, à l’inspection technique et aux tests.
• Les schémas, spécifications réglementaires ou documents d’architecture restent distincts lorsqu’ils sont nécessaires.
• Le journal de livraison relie ensuite la décision approuvée au résultat effectivement déployé.

Deux registres, six états et un droit d’écriture

L’infrastructure décrite ici associe une base dédiée, deux tables et une CLI shell de quelques centaines de lignes, chaque composant couvrant une responsabilité identifiable.

• L’inbox reçoit idées, backlog, notes et rapports de bug remontés de production, puis enregistre leur rejet ou leur promotion en plan.
• Le registre des plans stocke identifiant, texte intégral, dépendances, risque, état et approbations.
• Le journal en ajout seul consigne ce qui a été livré, quand, pour quel motif et avec quels suivis.
• La CLI impose les transitions au lieu de laisser chaque agent modifier directement ces données.

Le cycle principal fait passer un plan de draft à done, avec abandoned comme sortie terminale et une approbation liée au texte exact examiné.

• draft : le sujet est encore en cours d’instruction.
• ready : les choix nécessaires sont exposés pour revue.
• approved : le décideur humain autorise cette version précise du plan.
• doing : une session a réclamé le droit d’écriture.
• done ou abandoned : le travail est livré et journalisé, ou arrêté avec sa raison.

roadmap next                 # prochain identifiant libre
roadmap submit T-042.md      # soumettre le texte intégral du plan
roadmap approve T-042        # autoriser cette version précise
roadmap claim T-042          # réserver le droit d'écriture
roadmap done T-042           # consigner la livraison vérifiée

Quatre règles relient ce registre au code et empêchent qu’une approbation ancienne soit réutilisée après un changement de fond.

• Les sessions planifient par défaut et n’implémentent qu’après un ordre explicite.
• Le gate humain couvre fichiers concernés, mécanismes réutilisés, contrats, tests et hors-périmètre.
• Après le claim, une passe de fraîcheur vérifie que les hypothèses du plan correspondent encore au code ; sinon, le plan est soumis à nouveau.
• Toute nouvelle soumission invalide l’approbation précédente, puis la livraison est inscrite au journal seulement après les contrôles prévus.

Le modèle STORM traite autrement l’état périmé : ses auteurs font médiatiser chaque accès à un espace partagé pour détecter les conflits à l’écriture et rapportent +18,7 points sur Commit0-Lite et +1,4 sur PaperBench face à leur baseline par worktrees Git [4].

• Les résultats portent sur les tâches, modèles et protocoles de cette étude, pas sur Junyr.
• Notre passe de fraîcheur agit sur un plan avant l’implémentation, alors que STORM arbitre des écritures concurrentes.
• Les deux mécanismes répondent au risque d’un état périmé, mais ils ne sont ni identiques ni directement comparés.

Une couverture fonctionnelle, avec des pertes assumées

Le registre, les tests, les images et les sauvegardes couvrent une partie des usages quotidiens de Git, mais la correspondance reste imparfaite et doit être évaluée fonction par fonction.

Fonction auparavant portée par Git	Mécanisme utilisé dans ce flux	Limite conservée
Branches et worktrees	Plans instruits en parallèle, écriture sérialisée	Débit d’écriture plafonné à une session
Pull request et revue de diff	Approbation du plan avant écriture, vérifications après écriture	Moins de lecture humaine ligne par ligne
Log	Registre des plans et journal de livraison	Pas d’état source commit par commit après la bascule
Blame	Décisions, fichiers concernés et auteur de l’approbation	Pas d’attribution ligne par ligne
Revert de production	Redéploiement d’une image précédente	Ne restaure pas à lui seul le code source courant
Bisect	Journaux, observabilité, tests et comparaison d’instantanés	Pas de recherche binaire native entre commits
Remote et réplication	Archives hors site du code et export du registre	Instantanés sans graphe de versions Git

Cette séparation évite de confondre trois opérations différentes : remettre le service en état, restaurer les sources et expliquer l’origine d’une régression.

• Le rollback opérationnel redéploie une image connue lorsque la nouvelle version échoue au contrôle de santé.
• La restauration récupère un instantané de code et le registre associé après perte ou corruption.
• L’enquête s’appuie sur plans, journal, observabilité, tests et différences entre instantanés disponibles.
• Si le bisect ou le blame précis est une exigence, ce dispositif ne remplace pas Git.

Ce que montrent quatre jours d’exploitation, et seulement cela

Au 15 juillet 2026, le registre interne montrait 50 plans répartis entre livraison, exécution et attente d’une décision, ce qui documente l’adoption du flux sans mesurer son effet causal sur la qualité ou le délai.

• 20 plans étaient livrés.
• 10 étaient en cours.
• 7 étaient approuvés et attendaient leur implémentation.
• 13 attendaient le gate humain, auxquels s’ajoutait une quarantaine d’éléments dans l’inbox.

Le lot de 12 plans fournit un exemple concret du chemin suivi entre autorisation et production, avec des observations internes limitées à ce déploiement.

• Les plans avaient été approuvés avant leur claim.
• L’implémentation s’est déroulée le 13 juillet et la promotion le 14.
• Le contrôle de santé a accepté la bascule et aucun rollback n’a été déclenché.
• Ces faits ne renseignent ni le taux de défauts ultérieurs ni la performance comparée d’un flux Git équivalent.

La réversibilité reposait sur plusieurs couches testées séparément, et non sur la seule conservation d’une archive .git.

• L’ancien dépôt complet permettait de revenir au modèle Git et à son historique antérieur.
• La version précédente de l’application restait disponible comme image de rollback.
• Le code courant et le registre étaient exportés hors site selon le calendrier interne annoncé.
• La procédure de restauration avait été testée le jour de la bascule ; sa portée ultérieure dépend de la qualité continue des archives.

Les conditions qui rendent ce choix défendable

Sortir Git du chemin actif n’est cohérent que dans une configuration étroite où l’équipe accepte explicitement les capacités perdues et démontre que chaque fonction critique dispose d’un mécanisme de remplacement suffisant.

• Écriture sérialisable : une seule autorité modifie le code à un instant donné ; les équipes multi-auteurs gardent Git ou une gestion concurrente équivalente.
• Gate adapté : la décision peut être examinée dans un plan, tandis que les propriétés du résultat sont contrôlées par tests et analyses.
• Production immuable : aucune correction n’est faite directement en production et une image précédente peut être redéployée.
• Diagnostic acceptable : l’organisation accepte de ne plus disposer du blame et du bisect fins sur les changements postérieurs à la bascule.
• Restauration éprouvée : code, registre, artefacts et procédure sont sauvegardés puis restaurés lors d’exercices réels.

Les cas incompatibles dépendent précisément des capacités que Git rassemble dans un même graphe de versions.

• Plusieurs développeurs ou agents doivent intégrer des modifications concurrentes.
• Les pull requests servent de support de revue, de conformité ou de contribution externe.
• Une exigence d’audit réclame l’état exact du code et son auteur à chaque modification.
• L’exploitation s’appuie régulièrement sur revert, blame ou bisect pour traiter les incidents.

La leçon de gouvernance au-delà du développement

L’élément transposable est la séparation entre intention autorisée, artefact produit, preuve d’exécution et chemin de récupération lorsque des agents interviennent dans un processus métier.

• Le registre décrit ce que l’agent est autorisé à accomplir et les limites de cette autorisation.
• Le gate identifie la personne qui engage la décision avant l’action sensible.
• Les contrôles vérifient des propriétés observables du résultat.
• Le journal relie autorisation, exécution, résultat et suites à traiter.

Un dirigeant peut évaluer ce dispositif en demandant une réponse concrète pour chaque couche.

• Où réside la version approuvée de l’intention ?
• Qui peut autoriser, modifier ou abandonner cette intention ?
• Quelles vérifications empêchent la livraison si le résultat s’écarte du plan ?
• Quels artefacts permettent de revenir en service, de restaurer les données et d’expliquer l’incident ?

Le principe à retenir

Lorsque le plan devient le principal objet de la décision humaine, il mérite son propre historique, mais ce registre complète les mécanismes de version, de déploiement, de sauvegarde et d’enquête au lieu de les abolir.

• Versionner l’intention améliore la traçabilité des choix.
• Conserver des états restaurables protège la capacité de récupération.
• Nommer les fonctions perdues évite de présenter un compromis local comme une règle générale.

L’audit de maturité IA Junyr propose une visio gratuite de 30 minutes, sans engagement, pour situer votre organisation et choisir un premier chantier.

Prolonger la réflexion

Deux articles complètent ce retour d’expérience en détaillant la chaîne d’implémentation et la place du gate humain.

• Le vibe coding est mort : place à l’UltraCoding.
• Ingénierie des systèmes agentiques : l’humain dans la boucle.

Paul-Antoine TUAL, AI Transformation Leader · Croissance et Transitions (SAS) · Junyr Method™ · Junyr Mail™ · Junyr Agents™

---

Sources consultées au 6 septembre 2026

[1] Git, « A Short History of Git », documentation officielle : origine en 2005, objectifs initiaux et développement non linéaire.

[2] Deepak Babu Piskala, « Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants », arXiv:2602.00180, soumis le 30 janvier 2026 : spécification comme source de vérité et niveaux spec-first, spec-anchored, spec-as-source.

[3] Cursor, « Origin », page éditeur consultée le 6 septembre 2026 : forge Git « for the agentic era », bêta anticipée annoncée sur les offres payantes.

[4] Mengyang Liu et al., « Multi-agent Collaboration with State Management », arXiv:2605.20563, soumis le 19 mai 2026 : médiation d’un espace partagé, détection des conflits à l’écriture et résultats rapportés sur Commit0-Lite et PaperBench.

Les nombres propres à Junyr restent des observations internes attribuées au registre du 15 juillet 2026 plutôt que des résultats indépendamment authentifiés.

• Ils couvrent les fonctionnalités annoncées, les 50 plans et leur répartition, le lot de 12, les contrôles et les restaurations.
• Ils décrivent les quatre premiers jours du flux et ne mesurent pas un effet causal sur la qualité, le délai ou la productivité.