Développement à décision gardée : valider le plan avant d'écrire le code

Le renversement

Quand des agents accélèrent fortement la production de code, le coût relatif bascule vers le choix du changement, sa cohérence avec l’existant et la capacité de l’équipe à le vérifier avant qu’il ne grossisse.

• Les méthodes historiques répartissent une capacité d’exécution humaine limitée.
• Les agents réduisent le temps d’écriture, mais pas celui nécessaire pour comprendre les dépendances et arbitrer.
• Un volume supérieur de code augmente la charge de revue si les choix structurants restent implicites.
• Le développement à décision gardée transforme donc le choix en artefact écrit et le soumet à un contrôle humain avant implémentation.

Les trois règles du contrôle avant code

La méthode repose sur trois règles opérationnelles qui séparent clairement l’exploration, la décision et l’écriture du code.

• Planifier par défaut : une session d’exploration produit un plan ; l’implémentation exige une demande explicite.
• Rendre le plan décision-complet : il nomme les fichiers, points de raccordement, contraintes, tests et éléments hors périmètre, sans prétendre figer chaque import ou ligne d’insertion.
• Valider avant d’écrire : un humain accepte, refuse ou demande une révision du plan avant toute modification du code ; les tests et la revue restent ensuite nécessaires.

Ce que la séparation entre plan et exécution permet

La planification se parallélise, l’implémentation non

La planification se parallélise tant que chaque session produit un artefact isolé, alors que l’implémentation doit être sérialisée ou répartie entre zones réellement indépendantes pour éviter les conflits et les incohérences.

• Plusieurs agents peuvent explorer des options, risques ou sous-systèmes sans modifier le dépôt.
• Leurs plans peuvent ensuite être comparés, fusionnés ou écartés au même point de contrôle.
• Deux écritures simultanées sur un même fichier, schéma ou contrat exigent une coordination explicite ; un écrivain unique par zone est la règle prudente.

Le plan devient l’unité de revue, pas le diff

Le plan devient une première unité de revue parce qu’il expose l’intention et l’architecture avant leur traduction en code, sans dispenser de vérifier ensuite le diff produit.

• La revue du plan contrôle le périmètre, les dépendances, les raccordements et la stratégie de test.
• La revue du diff contrôle la fidélité de l’implémentation, ses effets réels et sa qualité.
• Détecter un mauvais choix dans le plan évite son coût d’écriture ; le détecter dans le diff reste indispensable si l’exécution s’écarte du plan.

La fraîcheur devient un problème de premier ordre

Un plan approuvé reste valable seulement tant que ses prémisses correspondent au dépôt, ce qui impose une vérification de fraîcheur juste avant l’implémentation et une nouvelle validation si un choix substantiel change.

• Vérifier les fichiers, interfaces, schémas et hypothèses nommés coûte moins cher que recommencer une exploration sans guide.
• Une divergence mécanique peut être ajustée pendant l’exécution si elle ne change aucune décision.
• Une divergence de périmètre, d’architecture ou de risque renvoie le plan au contrôle humain.
• Dans l’échantillon interne de dix-sept jours, cette passe a notamment arrêté un plan fondé sur une prémisse devenue dangereuse ; cette observation illustre le mécanisme sans en mesurer la fréquence générale.

Étude de cas : dix-sept jours de registre

Ce relevé descriptif porte uniquement sur le registre de développement interne de Junyr, du 11 au 28 juillet 2026, et montre comment les éléments ont circulé dans ce dispositif sans démontrer sa performance dans d’autres équipes ou sur une période longue.

• Au jour 11, le registre comptait 260 plans, soit environ 24 par jour depuis sa création.
• Au jour 17, il en comptait 565 ; les 305 ajouts des six derniers jours représentent environ 51 plans par jour.
• Cette accélération décrit l’activité du registre pendant la fenêtre observée ; elle ne prouve ni un gain de productivité ni la stabilité future de la méthode.

Mesure	Valeur
Plans écrits	565
Plans implémentés puis clos	477
Plans abandonnés	31, dont 26 jamais réclamés en implémentation
Plans en attente de validation ou de tour	57
Idées et rapports en amont, jamais devenus des plans	144 (sur 482 entrés au registre)
Révisions de plans archivées	167
Taille médiane d’un plan	5 693 caractères

Les trois signaux les plus utiles de cet échantillon interne concernent l’arrêt avant code, la sélection entre idée et plan, et la nécessité de renouveler une approbation après une révision substantielle.

• Arrêt avant code : 31 plans ont été abandonnés ; 26 n’ont jamais été demandés en implémentation, ce qui établit qu’aucun code n’a été écrit pour eux, tandis que le registre ne permet pas d’affirmer la même chose pour les cinq autres.
• Sélection amont : 144 éléments sur 482, soit 29,9 %, ne sont jamais devenus des plans ; environ trois sur dix constitue une minorité substantielle, sans autoriser une généralisation à « la majorité des idées » ni aux équipes extérieures.
• Nouvelle validation : 167 révisions ont été archivées ; dès qu’une réécriture modifie une décision approuvée, le nouveau plan doit repasser le contrôle pour que son statut reste fiable.

Outcome-driven prioritization : composer la vague suivante

Le gate décide si un plan peut être implémenté, et la priorisation par le résultat pour l’utilisateur final, ou outcome-driven prioritization, décide quels plans approuvés entrent dans la vague suivante, classés selon l’effet attendu pour les utilisateurs et corrigés par l’effet observé après la vague précédente.

• Une vague est un lot de plans approuvés implémentés puis promus ensemble en production ; le lot de douze plans promu le 14 juillet, décrit dans « Nous avons retiré Git d’un produit en production », en est une.
• Le vivier est l’ensemble des plans approuvés qui attendent leur tour, une partie des 57 plans comptés en attente dans le tableau ci-dessus.
• Le critère de classement est un résultat utilisateur : une tâche accomplie sans assistance, une erreur qui cesse de se produire, une fonctionnalité réellement utilisée, une demande de support qui disparaît.
• Le nombre de plans livrés par jour mesure une production ; l’accélération de la figure 3 ne dit rien de la valeur reçue par les utilisateurs.
• Après la promotion, le résultat observé est comparé aux observations d’acceptation que chaque plan avait nommées, et cette comparaison reclasse le vivier, renvoie un plan au gate quand sa prémisse a changé, ou abandonne un plan dont l’effet attendu a disparu.

La taille de la vague est la variable à optimiser

Une vague se dimensionne pour que son résultat reste attribuable à ses plans, parce qu’une vague trop grande brouille la lecture et qu’une vague trop petite gaspille la capacité d’écriture sérialisée.

• Regrouper les plans qui touchent la même zone, pour limiter les conflits de fraîcheur, et séparer les plans dont les effets se confondraient dans une même mesure.
• Placer un ou deux plans à fort résultat attendu dans chaque vague plutôt que la remplir d’éléments à faible risque, faciles à clore.
• Lire le résultat à intervalle fixe après la promotion, avec la même mesure d’une vague à l’autre, pour que les rangs restent comparables.

Ce que la priorisation ne fait jamais

La priorisation classe des plans approuvés et n’en approuve aucun, si bien qu’un plan à fort résultat attendu passe quand même le gate et la vérification de fraîcheur avant tout code.

• Le gate conserve la responsabilité de la décision ; la priorisation fixe le rang et rien d’autre.
• L’échantillon de registre de cet article compte des plans et ne dit rien des résultats ; la règle de classement est donc un choix de conception dont l’article ne mesure pas l’effet.
• Un rang dérivé d’un indicateur indirect, comme des pages vues ou des plans clos, retombe dans la production et doit être remplacé par une observation chez l’utilisateur.

Les trois façons dont la méthode se dégrade

La méthode perd sa fonction de contrôle lorsque l’approbation devient automatique, que le plan reste vague ou que le registre ne reflète plus l’état réel du travail.

• Le gate doit provoquer une décision attentive et traçable.
• Le plan doit contenir assez de précision pour être actionnable.
• Le registre doit être alimenté par des états et des sources fiables.

Un contrôle qui devient un tampon

Un contrôle signé sans lecture ajoute du délai sans réduire le risque, ce qui oblige à calibrer le plan pour qu’un validateur puisse réellement l’examiner.

• Adapter la longueur à la complexité et au risque du changement.
• Faire ressortir les décisions, hypothèses et conséquences irréversibles.
• Refuser l’approbation si le temps ou la compétence nécessaires manquent.

Un plan qui décrit une intention plutôt qu’il ne décide

Un document qui promet une direction sans nommer les surfaces de changement ni les preuves attendues reste une idée, même s’il porte le titre de plan.

• Identifier les fichiers, services, contrats ou données concernés.
• Nommer les raccordements existants à réutiliser et les règles à préserver.
• Définir les tests ou observations qui permettront d’accepter le résultat.

Un registre qui ment par omission

Un registre incomplet peut afficher une situation plausible tout en orientant les décisions vers un travail caduc, une source partiellement lue ou un indicateur mal défini.

• Lier chaque statut à un événement vérifiable plutôt qu’à une interprétation implicite.
• Signaler les plans périmés, remplacés ou en attente d’une nouvelle validation.
• Auditer périodiquement les compteurs contre les artefacts sources.

Le rapport à la transformation des entreprises

Le développement à décision gardée transpose au travail d’ingénierie un principe de la Méthode Junyr™ : déléguer l’exécution exige de rendre explicites la responsabilité, les critères de décision et les contrôles associés.

• À l’échelle du dépôt, le plan consigne le changement et le gate attribue la décision.
• À l’échelle de l’organisation, le cadre relie les usages de l’IA à des responsabilités et à des contrôles adaptés.
• Dans les deux cas, le dispositif reste indépendant d’un logiciel précis et ne garantit pas à lui seul la qualité, la sécurité ou la conformité.

Ce que je ne prétends pas

La méthode traite la qualité de la décision avant code et doit être proportionnée au risque, car elle ne choisit ni l’agent ni l’architecture et ne remplace aucune vérification technique.

• Conserver les tests, la revue de code, les contrôles de sécurité et l’observabilité nécessaires.
• Alléger ou supprimer le plan formel pour une correction triviale, locale et facilement réversible.
• Renforcer la précision et l’approbation lorsque le volume, les dépendances, le coût d’erreur ou l’irréversibilité augmentent.
• Classer les plans approuvés par résultat utilisateur sans laisser le rang remplacer le gate, ni lire un effet mesuré dans un échantillon qui ne compte que des plans.

Le principe à retenir

Lorsque la production de code dépasse la capacité de décision et de revue, consigner le choix, le faire approuver puis vérifier sa fraîcheur redonne à l’équipe un point de contrôle avant l’exécution.

• Le registre conserve la décision et son état.
• Le gate humain engage la responsabilité avant le changement.
• Les tests et la revue établissent ensuite ce que l’implémentation fait réellement.
• Le résultat utilisateur mesuré après chaque vague ordonne la suivante.

Situez votre organisation avec l’audit de maturité IA Junyr gratuit.

Pour aller plus loin

• Nous avons retiré Git d’un produit en production : la bascule dont ce registre est issu.
• UltraCoding : la chaîne de production qui implémente les plans approuvés.
• Ingénierie des systèmes agentiques : l’humain dans la boucle : le contrôle des actions qu’un agent peut engager.

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

---

Sources

Les statistiques de cet article proviennent exclusivement de deux relevés du registre interne Junyr et doivent se lire comme une description de ce périmètre, tandis que le contexte externe reste documenté dans la bibliographie de « Nous avons retiré Git d’un produit en production ».

• 21 juillet 2026 : 260 plans après onze jours d’existence du registre.
• 28 juillet 2026 : 565 plans écrits, 477 livrés, 31 abandonnés dont 26 jamais demandés en implémentation, 57 en attente, 167 révisions archivées et une taille médiane de 5 693 caractères.
• Sélection amont au 28 juillet : 144 éléments sur 482, soit 29,9 %, jamais transformés en plans ; ce dénominateur est distinct des 565 plans écrits.
• 14 juillet 2026 : un lot de douze plans approuvés, implémentés le 13 juillet et promus ensemble le lendemain, exemple de vague utilisé dans la section de priorisation, documenté dans l’article Git.