Le code est devenu gratuit. Décider quoi construire, jamais.

Posez la question à n'importe quel directeur technique aujourd'hui : combien de temps faut-il pour transformer une feature bien spécifiée en code qui tourne ? La réponse, il y a deux ans, se comptait en semaines. Elle se compte désormais en heures. L'exécution s'est effondrée. Et c'est précisément ce qui rend la suite déroutante pour les comités de direction : alors que la partie « écrire le code » est en train de devenir une commodité, la difficulté n'a pas disparu — elle a changé d'adresse. Elle est remontée vers l'amont.

C'est un renversement contre-intuitif. Pendant cinquante ans, la culture d'ingénierie a appris à respecter le coût de la production : on cadrait vite, on codait longtemps, on déboguait encore plus longtemps. Quand la production coûte presque zéro, la logique s'inverse. Une idée mal cadrée ne reste plus coincée des semaines dans une file de développement où quelqu'un finira par s'apercevoir qu'elle n'a pas de sens. Elle est exécutée. Vite. Et une intention floue, donnée à un agent qui exécute en quelques heures, ne produit pas un retard : elle produit un système entier construit sur un malentendu — à la vitesse de l'IA.

C'est l'angle mort de la plupart des transformations en cours. On a outillé l'exécution ; on a laissé l'amont tel quel. Or, comme le rappelle Dave Farley, figure historique du continuous delivery, « le goulot du software engineering n'a jamais été le code » : il a toujours été la compréhension du problème, sa conception, sa validation. L'IA, dit-il, « accélère exactement la partie qui n'était pas le problème » (AI Assisted Development is a TRAP Without Continuous Delivery, mai 2026). Pour un décideur, la conséquence est directe : le levier de valeur — et le levier de risque — s'est déplacé vers les deux premières phases du cycle. Là où une idée devient un contrat, et où trois explorations deviennent une décision. C'est là que l'humain pèse le plus. C'est là que se joue cet article.

Dans le SDLC piloté par l'IA tel que SFEIR le pratique — onze phases, trois gates humains, deux capitalisations — ces deux phases portent un nom : Define et Plan. Elles forment l'amont du cycle. Et elles ne sont pas des formalités à expédier : ce sont les deux endroits où une personne décide, et engage sa responsabilité.

Define : transformer une idée en contrat

La phase Define répond à une question d'apparence banale et de portée considérable : que construit-on, exactement ? Dans le cycle SFEIR, Define a un objectif précis — une idée devient un contrat. Les hypothèses sur l'utilisateur, sur le métier, sur le comportement attendu, sont rendues explicites et validées avant la spec, pas après. Les rôles mobilisés le disent : le product owner, l'expert métier, le designer d'expérience. Pas encore l'agent. L'amont est l'endroit du cycle où la voix humaine est la plus dense.

Pourquoi cette insistance sur l'explicite ? Parce que le mode d'échec numéro un de l'IA en ingénierie n'est pas la bêtise, c'est la sous-spécification. Addy Osmani, qui dirige l'ingénierie sur Chrome chez Google, l'a documenté dans son guide de référence sur les specs pour agents (How to write a good spec for AI agents, janvier 2026) : sur un large corpus de projets analysés, le piège dominant n'est ni le modèle ni l'outil, c'est la spec trop vague. Donnez à un agent une consigne ambiguë, et il ne s'arrêtera pas pour demander : il comblera le vide avec une hypothèse générique, plausible, et fausse. Osmani propose une image qui parle aux managers : traiter l'agent comme un stagiaire compétent — capable, rapide, mais qui produira exactement ce que vous avez écrit, pas ce que vous aviez en tête.

Un bon Define ne se contente donc pas de décrire un désir. Il produit un contrat dont chaque critère est vérifiable. C'est l'apport le plus opérationnel du cadre ADLC, publié indépendamment par Chris Williams : sa phase d'interrogation produit « une spec dont chaque critère d'acceptation nomme sa méthode de vérification » — et surtout, l'agent qui interroge les parties prenantes le fait après avoir lu la base de code existante, pour que les questions soient ancrées dans la réalité du système plutôt que dans des généralités. La méthode BMAD, côté francophone, dit la même chose autrement : l'agent de spécification existe pour « clarifier le besoin et produire une vraie spécification plutôt qu'un prompt flou » (Philippe Martin, février 2026).

Le contraste pour un décideur est net. L'ancien monde tolérait la spec approximative parce que le rythme humain de la production laissait le temps de corriger en chemin. Le nouveau monde ne le tolère plus : ce qui n'est pas décidé en amont est décidé par défaut par la machine, en aval, et à grande échelle. Define n'est pas une étape de documentation. C'est l'endroit où l'on choisit, consciemment, ce qui mérite d'être construit.

Le gate spec : la première décision qu'aucune machine ne prend

Au bout de Define, le cycle s'arrête. Pas une suggestion, pas une recommandation : un gate. Une personne lit la spec, et décide si elle engage l'organisation. C'est le premier des trois gates humains du cycle SFEIR, et il n'est pas négociable.

Pourquoi un arrêt formel, et pas une validation tacite ? Parce que l'intention ne se délègue pas. Une machine optimise une fonction qu'on lui donne ; elle ne décide pas ce qui vaut la peine d'exister. C'est une distinction de nature, pas de degré. Et c'est exactement le point sur lequel les cadres construits indépendamment convergent. L'ADLC place ici sa première porte humaine — l'approbation de la spec — qu'il qualifie de « moment de valeur humaine maximale ». BMAD répète que « l'humain reste architecte en chef et maître d'ouvrage » : vision, contraintes non négociables, décisions structurantes. Quand des équipes qui ne se parlent pas posent leur premier point d'arrêt humain au même endroit, ce n'est plus une opinion d'éditeur, c'est une propriété du problème.

La mécanique du gate mérite d'être comprise par un décideur, car elle redéfinit la responsabilité. Avant ce gate, tout est exploration et proposition — l'agent peut produire, reformuler, suggérer. Après ce gate, le contrat est engagé : c'est sur cette base que la machine va construire, vérifier, livrer. Le gate est le point où le risque cesse d'être abstrait. Approuver une spec, ce n'est pas valider un document ; c'est dire « voilà ce que nous construisons, et j'en réponds ». Aucun gain de productivité ne justifie de déléguer cet acte à un agent — pour une raison simple : un agent peut approuver par réflexe ce qu'on lui présente, là où une personne dont la responsabilité est engagée a une raison de refuser.

Plan : trois explorations, pas une route au hasard

La spec validée dit quoi. La phase Plan répond au comment — et c'est ici que se commet l'erreur la plus coûteuse de l'ère agentique : croire qu'une fois la spec écrite, on peut lâcher la machine.

Kieran Klaassen, qui pilote le produit email Cora chez Every, en a fait un manifeste : Stop Coding and Start Planning (novembre 2025). Son diagnostic est cinglant — « l'IA nous a rendus négligents parce qu'elle nous a fait oublier comment planifier ». Le réflexe « fais marcher cette feature » suivi de l'espoir que l'agent prenne la bonne route débouche, dit-il, sur trois heures de débogage qu'une session de dix minutes de planification aurait évitées. Sa formule résume tout l'enjeu pour une organisation : les plans enseignent au système, le code résout un problème. Coder, c'est traiter un cas. Planifier, c'est transmettre une façon de penser réutilisable au cycle suivant.

Dans le cycle SFEIR, Plan ne consiste pas à choisir une solution. Il consiste à ouvrir trois explorations parallèles : le code existant (que sait-on déjà faire, qu'est-ce qui est réutilisable ?), les pratiques (comment l'a-t-on résolu ailleurs, dans l'état de l'art ?), et les frameworks disponibles (quels outils, quelles contraintes ?). Klaassen décrit exactement cette discipline : avant d'écrire, « rechercher dans la base de code, vérifier la bibliothèque, consulter les bonnes pratiques, puis créer un plan présentant trois approches avec leurs compromis ». Dans son retour d'expérience, cette phase de recherche a révélé un outil déjà existant et réutilisable, et les quotas d'une API externe — vingt minutes de compréhension qui ont évité des heures d'incidents en production.

Le point décisif, pour un décideur, est que ces explorations sont parallèles et bon marché. Faire chercher trois pistes par des agents ne coûte presque rien — c'est du calcul, pas du développement. L'ADLC le formule sans détour : la recherche parallèle est « quasi gratuite », là où la construction parallèle sur un état partagé est « un enfer de merge ». On peut donc se permettre d'explorer largement avant de s'engager, ce qui était un luxe quand chaque piste coûtait des jours-homme. L'amont devient le bon endroit où dépenser, précisément parce que c'est le moins cher et le plus déterminant.

Mettre les conflits sur la table avant d'écrire une ligne

Trois explorations qui reviennent, ce sont presque toujours trois recommandations qui se contredisent. La piste « réutiliser l'existant » privilégie la vitesse ; la piste « état de l'art » privilégie la robustesse ; la piste « frameworks » impose ses propres contraintes. C'est volontaire. L'objectif de Plan n'est pas de produire un consensus mou, c'est de mettre les conflits à plat — de les exposer noir sur blanc — pour que l'arbitrage soit conscient.

Cette mise à plat est ce qui distingue une planification sérieuse d'un théâtre de planification. Un plan qui cache ses tensions n'a rien tranché : il a juste reporté la décision au moment de l'exécution, c'est-à-dire au pire moment, quand la correction coûte le plus cher. L'intuition de Farley vaut ici aussi : sans cadre, le code généré devient une « bombe à complexité à retardement », et chaque arbitrage non fait en amont est une dette qui explose en aval. À l'inverse, exposer les compromis avant d'écrire une ligne est ce qui rend l'arbitrage rapide, documenté, et surtout réversible dans la décision plutôt que dans le code.

C'est pourquoi, dans le cycle SFEIR, les décisions d'architecture sont versionnées. Le plan n'est pas un brouillon qu'on jette : c'est un artefact qui rejoint la mémoire du projet. Et c'est là que l'amont rejoint la logique de capitalisation que nous détaillons ailleurs — un plan bien fait n'enseigne pas seulement au cycle courant, il enrichit les cycles suivants. Comme le dit Klaassen, planifier est « l'activité à plus fort levier » du développement assisté par IA : une heure investie à améliorer le système de planification rend chaque heure future plus productive. Le code est jetable ; le plan, lui, se capitalise.

Deux gates, ou trois ? L'arbitrage que l'industrie sépare

Quand le plan est posé et ses conflits arbitrés, le cycle s'arrête une seconde fois. C'est le deuxième gate humain : l'architecte et le lead tranchent. Et c'est ici que se loge la nuance la plus instructive de toute la convergence des cadres autour du développement agentique.

Le cadre ADLC, qui sert de référence externe à cette série, tient deux gates humains — c'est même sa formule de signature : « l'intention est vérifiée exactement deux fois », une fois à l'approbation de la spec, une fois à l'acceptation du comportement en exécution. Entre les deux, tout est vérifié par la machine. C'est une position rigoureuse, et SFEIR la partage sur l'essentiel : l'humain décide l'intention, la machine prouve le reste.

Mais le cycle SFEIR tient trois gates — spec, plan, et validation des modifications avant livraison. L'écart tient entièrement à un choix : isoler le plan d'architecture comme un point de décision distinct, plutôt que de le fondre dans l'approbation de la spec. Ce n'est pas un détail de comptage. C'est une conviction sur la nature de la décision d'architecture. Décider quoi construire (la spec) et décider comment l'architecturer (le plan) sont deux engagements de nature différente, qui mobilisent des personnes différentes — le product owner et le métier d'un côté, l'architecte et le lead de l'autre — et qui échouent différemment. Les fusionner, c'est risquer qu'une bonne intention soit servie par une mauvaise architecture sans que personne ne l'ait explicitement validée.

Le lecteur attentif notera qu'on ne mélange surtout pas les chiffres : « deux gates » est une caractéristique du cadre ADLC, étiquetée comme telle ; « trois gates » est la structure SFEIR. Cet écart n'oppose pas les deux approches — il éclaire un choix de conception. Nous l'explorons en détail dans l'article dédié à la convergence des cadres et à la validation externe, qui montre pourquoi des équipes indépendantes dessinent le même cycle — et où, exactement, elles divergent. Pour un décideur, la leçon est celle-ci : le nombre de gates n'est pas une question d'orthodoxie, c'est une question de granularité de la responsabilité. Plus une décision engage l'organisation, plus elle mérite son propre point d'arrêt.

Sans amont discipliné, l'IA est un piège

Il faut nommer le risque sans détour, car c'est ce qui fait de l'amont un sujet de comité de direction et non d'équipe technique. Sans discipline en amont, l'IA n'accélère pas la création de valeur — elle accélère la production de complexité. C'est tout l'argument de Farley : le paradoxe de Jevons appliqué au logiciel. Quand produire devient bon marché, on produit davantage ; davantage de code, c'est davantage de points d'intégration, de comportements à évaluer, de surface à maintenir. Sa formule mérite d'être affichée dans toute DSI engagée dans cette transformation : « l'IA ne supprime pas le besoin d'ingénierie logicielle ; elle expose les équipes qui ne faisaient pas vraiment d'ingénierie au départ. » L'amont discipliné est précisément ce qui sépare une équipe qui fait de l'ingénierie d'une équipe qui empile des prototypes.

L'enjeu n'est pas théorique. Quand un cabinet comme McKinsey annonce une bascule « du conseil pur vers un modèle basé sur les résultats » et revendique un effectif de « 60 000 personnes — 40 000 humains et 20 000 agents » (Bob Sternfels, janvier 2026), le message pour les directions est clair : la part automatisable du travail intellectuel est déjà en production, et la valeur résiduelle se concentre sur ce que la machine ne fait pas — cadrer, arbitrer, engager. C'est-à-dire l'amont.

Cela impose aussi une honnêteté sur les limites. L'amont discipliné suppose qu'une spec soit possible. L'inédit sans spec reste humain : quand on explore un territoire dont on ne connaît pas encore les contours, l'IA aide à prototyper, mais elle ne décide pas l'intention. Klaassen le théorise dans son cas le plus complexe — ce qu'il appelle le vibe planning : pour les sujets épais et incertains, on construit des prototypes jetables non pour les livrer, mais pour clarifier l'intention, avant de revenir à une planification rigoureuse. L'amont n'élimine pas l'incertitude ; il la met au bon endroit, tôt, là où elle coûte le moins.

Par où commencer : muscler l'amont

Pour une direction qui veut agir, l'erreur serait de chercher le bon outil. Le levier n'est pas là. Voici par où commencer.

Installer un gate spec digne de ce nom. Pas une case à cocher dans un workflow, mais un arrêt réel où une personne identifiée engage sa responsabilité sur ce qui sera construit. Le critère de qualité d'une spec n'est pas sa longueur : c'est que chacun de ses critères d'acceptation nomme la façon dont il sera vérifié. Une spec qu'on ne peut pas tester n'est pas une spec, c'est un vœu.

Rendre les hypothèses explicites avant la spec, pas après. Les hypothèses sur l'utilisateur et le métier sont la matière première de Define. Tant qu'elles restent implicites, la machine les remplit à votre place. La discipline consiste à les écrire — et à les valider avec ceux qui détiennent le métier.

Exiger trois pistes au plan, et leurs conflits sur la table. Un plan à une seule option n'a rien arbitré. La règle simple : pas de décision d'architecture sans trois explorations comparées et leurs compromis exposés. Le coût de cette discipline est dérisoire — les explorations sont parallèles et bon marché ; le coût de son absence se paie en aval, au prix fort.

Standardiser le contexte et la preuve, pas l'outil. C'est le principe directeur. On capture la sortie réelle de chaque étape plutôt que la déclaration de l'agent — un principe de fonctionnement, pas un indicateur de performance. Le goulot se déplace alors de l'écriture du code vers la spec et la validation, c'est-à-dire vers ce que l'humain fait de mieux.

Sur ce dernier point, SFEIR assume un parti pris dans sa stratégie AI for IT — le 10x : se l'appliquer d'abord à elle-même, avec un objectif de 850 consultants pleinement augmentés par l'IA, avant de le déployer chez ses clients. Car la promesse n'est pas un meilleur assistant de code. C'est un cycle où le code est le sous-produit, et où l'actif réel est la connaissance que le projet accumule — à commencer par les décisions prises en amont.

Revenons à la question de départ. Le coût d'écrire du code s'est effondré ; il continuera de baisser. Ce qui ne baisse pas, c'est le coût de décider quoi construire et comment l'architecturer — parce que ces décisions engagent une responsabilité, et qu'aucune machine ne porte de responsabilité. La vraie question pour une direction n'a jamais été « quel agent déployer ? ». Elle est, et restera : dans notre cycle, qui décide — et où ? L'amont, c'est la réponse.

Cet article fait partie d'une série sur le SDLC piloté par l'IA. Voir aussi : la convergence des cadres et la validation externe, la capitalisation (Compound), et « Écrire du code est un anti-pattern ».

Sources

1. SFEIR — SDLC piloté par l'IA — le cycle 10x (Define, Plan, gates humains), matière first-party, 2026.
2. Dave Farley, AI Assisted Development is a TRAP Without Continuous Delivery — youtube.com, 13 mai 2026.
3. Addy Osmani, How to write a good spec for AI agents — addyosmani.com, 13 janvier 2026.
4. Chris Williams, Two Human Gates and Everything Between Is Machine-Checked (cadre ADLC) — voodootikigod.com, 12 juin 2026.
5. Philippe Martin, BMAD-Method : le plan d'urbanisme qui apprivoise l'IA agentique dans votre SDLC — martinphilippe.wixsite.com, 4 février 2026.
6. Kieran Klaassen, Stop Coding and Start Planning — every.to, 6 novembre 2025.
7. Bob Sternfels (McKinsey), McKinsey Now Has 60,000 People, But 20,000 Of Them Are AI Agents — officechai.com, 14 janvier 2026.