Le développement à décision gardée : quand le goulot passe de l'exécution à la décision

Le déplacement

Pendant soixante ans, écrire du logiciel a coûté cher et décider a coûté peu. Toutes nos méthodes en découlent. On estime, on planifie, on priorise, on découpe, parce que l’exécution est la ressource rare : il faut la répartir avec soin.

Les agents ont inversé ce rapport. Écrire cent lignes correctes ne coûte plus grand-chose. Décider lesquelles écrire coûte désormais tout. Le goulot d’étranglement s’est déplacé de l’exécution vers la décision, et la plupart des équipes continuent d’optimiser l’ancien goulot.

Le symptôme est facile à reconnaître. Une équipe qui adopte des agents produit d’abord beaucoup, puis se retrouve à relire du code qu’elle n’a pas pensé, à débattre après coup de choix architecturaux déjà implémentés, et à découvrir des décisions structurantes prises implicitement par une machine à trois heures du matin. Le volume monte, la maîtrise baisse.

Le développement à décision gardée traite ce problème par une inversion simple. La décision devient un artefact, et elle passe un point de contrôle humain avant que quoi que ce soit ne soit écrit.

Trois règles, et rien d’autre

La méthode tient en trois règles. Leur intérêt n’est pas leur sophistication, c’est qu’elles sont tenables.

Première règle. Par défaut, on planifie, on n’implémente pas. Toute session de travail produit un plan, pas du code. L’implémentation n’est autorisée que si elle est demandée explicitement. Dans le doute, on planifie. Cette règle paraît bureaucratique jusqu’au moment où l’on mesure ce qu’elle évite : du code écrit sur une intention mal comprise, qu’il faudra défaire.

Deuxième règle. Un plan n’est pas une idée. Une idée est gratuite et vit dans une boîte d’entrée. Un plan est le produit d’une exploration : il nomme les fichiers exacts, les points de raccordement à réutiliser, les règles qu’il ne doit pas casser, les tests à écrire. Il est actionnable sans nouvelle exploration. La barre est précise, complet en décisions, pas complet en détails. Le plan fige les choix, qui vieillissent bien ; il laisse le résidu mécanique à l’exécution, qui vieillit vite.

Troisième règle. Un seul point de passage humain, et il ne se contourne pas. Un plan non approuvé ne s’implémente pas. Le contrôle n’est pas une relecture de code après coup, c’est une validation de décision avant coup. C’est là, et uniquement là, que l’humain est irremplaçable.

Ce que la méthode rend possible, et qui est contre-intuitif

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

C’est le renversement le plus utile. On peut lancer autant de sessions de planification simultanées qu’on veut, elles ne se marchent pas dessus, puisqu’elles ne produisent que des décisions écrites. En revanche l’implémentation reste portée par un seul écrivain à la fois, parce que deux agents qui modifient le même fichier s’écrasent en silence.

L’intuition dit l’inverse. On croit spontanément que penser est séquentiel et que produire se parallélise. Avec des agents, c’est le contraire.

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

Relire un plan de six mille caractères qui annonce les fichiers touchés, les raccordements réutilisés et les tests à écrire prend quelques minutes. Relire le diff correspondant en prend beaucoup plus, et surtout arrive trop tard : au moment où l’on découvre un mauvais choix d’architecture dans un diff, il est déjà écrit.

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

Un plan approuvé vieillit. Le code bouge sous lui. D’où une étape que rien ne remplace : avant d’implémenter, on vérifie à peu de frais que les fichiers et les raccordements nommés existent encore tels que décrits. Vérifier un plan précis coûte des minutes ; dériver une approche depuis une idée coûte une exploration entière.

Cette étape n’est pas décorative. Sur ces dix-sept jours, elle a intercepté plusieurs plans dont une prémisse s’était révélée fausse entre l’écriture et l’exécution, dont un qui s’apprêtait à détruire des données en croyant les réparer.

Étude de cas : dix-sept jours de registre

Les chiffres ci-dessous sont ceux d’un registre réel, mesurés le 28 juillet 2026, sur dix-sept jours d’existence continue depuis sa création. Une première mesure avait été prise le 21 juillet, à onze jours : entre les deux, le volume a plus que doublé (260 à 565 plans) sans que la méthode elle-même change d’une règle. Le rythme a lui-même accéléré, pas seulement le volume : environ 24 plans par jour sur les onze premiers jours, environ 51 par jour sur les six suivants (voir Figure 3). C’est aussi une donnée : une méthode qui tient sous une charge croissante, pas seulement au démarrage.

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

Trois enseignements se lisent directement dans ces chiffres.

Trente et un plans abandonnés, dont vingt-six sans qu’aucune ligne de code n’ait été écrite. C’est le rendement de la méthode, mesuré prudemment : ces vingt-six n’ont jamais été réclamés pour implémentation, donc zéro code n’a été produit avec certitude ; les cinq restants ont été réclamés puis abandonnés, le plus souvent parce que la passe de fraîcheur qui précède toute implémentation a trouvé une prémisse fausse avant d’écrire quoi que ce soit de substantiel. Chacun de ces trente et un représente une exploration menée, une décision prise, et un travail qui n’a pas eu lieu parce qu’on a compris à temps qu’il ne fallait pas le faire.

Cent quarante-quatre éléments en amont sur quatre cent quatre-vingt-deux entrés au registre, jamais devenus des plans. L’écart mesure la sélection. Une idée n’est pas un plan, et la majorité des idées ne le deviennent jamais : elles restent lisibles, datées, et éventuellement rouvrables sur un signal précis.

Cent soixante-sept révisions. Un plan approuvé qu’on réécrit substantiellement n’est plus le plan approuvé. Le contrôle doit alors se rejouer, sinon il ne contrôle plus rien. C’est le défaut le plus subtil de la méthode, et celui qui se manifeste le plus silencieusement : un tableau de bord qui affiche du travail prêt alors qu’il ne l’est plus.

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

Une méthode se juge à ses modes de panne, pas à ses réussites.

Un contrôle qui devient un tampon

Si le validateur approuve sans lire, il ne reste que la bureaucratie sans le bénéfice. Le seul remède est la taille : un plan qui tient en trois écrans se lit vraiment ; un plan de quinze écrans se signe sans être lu.

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

Le symptôme est facile à repérer : le plan ne nomme aucun fichier, aucun point de raccordement, aucun test. Il vend une direction. Le validateur croit alors valider une décision, alors qu’il valide une envie.

Un registre qui ment par omission

C’est le pire cas, parce qu’il ne produit aucune erreur visible. Un tableau qui présente comme disponible un travail qui ne l’est plus, une source de rapports qui n’est lue qu’à moitié, un compteur qui affiche zéro parce qu’il compte la mauvaise chose. Rien ne casse, et la confiance dans l’instrument se dégrade sans que personne ne le remarque.

Le rapport à la transformation des entreprises

Cette méthode est le pendant ingénierie d’un cadre plus large, la Méthode Junyr™, qui décrit comment une entreprise traverse sa transformation par l’IA sur cinq paliers de maturité.

Les deux répondent à la même question à deux échelles. La Méthode Junyr™ demande : à mesure que l’IA prend en charge l’exécution, qui décide, sur quelles bases, et avec quelles garanties ? Le développement à décision gardée apporte la réponse au niveau du poste de travail d’ingénieur : on garde la décision, on délègue l’exécution, et on rend le point de passage explicite plutôt qu’implicite.

La Méthode Junyr™ est indépendante des outils. Cette méthode d’ingénierie l’est aussi : elle demande un registre, une barre de précision et un contrôle humain, pas un logiciel particulier.

Ce que je ne prétends pas

La méthode ne dit rien de la qualité du code produit, ni du choix des agents, ni de l’architecture. Elle ne remplace ni les tests ni la revue. Elle traite un seul problème, celui du goulot déplacé, et elle n’a de valeur que pour les équipes qui l’ont effectivement rencontré.

Elle a un coût, honnêtement. Écrire un plan de six mille caractères pour une correction de trois lignes est absurde, et personne ne devrait le faire. La méthode se justifie à partir du moment où le volume produit dépasse la capacité de relecture. En dessous, elle est du cérémonial.

En une phrase

Le goulot n’est plus l’exécution, il est la décision. Ce qui mérite un registre, un gate et une signature, ce n’est plus le code, c’est le choix.

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

Pour aller plus loin

• Dans la même série : Nous avons retiré Git d’un produit en production, le récit de la bascule dont ce registre est issu, 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 Junyr™ · Junyr Mail™ · Junyr Agents™

---

Sources

Les chiffres du registre (565 plans écrits, 477 livrés, 31 abandonnés dont 26 jamais réclamés en implémentation, 57 en attente de validation ou de tour, 144 idées sur 482 jamais devenues des plans, 167 révisions archivées, taille médiane 5 693 caractères) sont issus du registre de développement de Junyr, relevés le 28 juillet 2026, dix-sept jours après sa création. Une première mesure avait été prise le 21 juillet 2026 (260 plans, onze jours). Pour le contexte externe (retrait de Git, spec-driven development, forges pensées pour des agents), voir la bibliographie de « Nous avons retiré Git d’un produit en production ».