Concevoir et fabriquer à l'ère de l'agentique

En avril 2026, Marty Cagan publie « Build to Learn vs Build to Earn » : quand le coût de fabrication du logiciel s'effondre, le goulot d'étranglement se déplace vers la discovery, et l'avantage concurrentiel avec lui. Au même moment, le spec-driven development s'installe comme standard de fait : GitHub Spec Kit passe d'environ 90 000 à environ 117 000 étoiles entre mai et juillet 2026, AWS Kiro est disponible mondialement depuis le 7 mai. Et le rapport DORA 2025, sur environ 5 000 répondants, mesure 90 % d'adoption de l'IA chez les développeurs, tout en montrant qu'elle amplifie les forces comme les fragilités des organisations. Trois signaux indépendants, une même conclusion : réarticuler la conception et la fabrication quand des agents exécutent l'essentiel de la production.

SFEIR et WEnvision ont structuré cette réarticulation en un cadre à trois étages. Le cycle produit, ou PDLC, garantit que l'on construit le bon produit. Le cycle logiciel, le SDLC, garantit que ce produit est bien construit. Et sous les deux, une base de connaissance gouvernée fournit la matière première, specs, décisions et claims sourcés, à partir de laquelle tout se génère. Ce cadre structure nos accompagnements comme notre propre production interne, et il tient en un schéma à trois bandes.

PDLC : construire le bon produit

Le PDLC (Product Development Life Cycle) couvre la vie entière d'un produit, de l'idéation au retrait, en passant par la validation, la conception, le lancement et la croissance. Le SDLC n'en est qu'un sous-ensemble, logé dans la phase de développement : le premier répond à « quoi construire, et pourquoi », le second à « comment le livrer de façon fiable ». Cette distinction, canonique mais souvent écrasée dans les organisations, fait l'objet d'une analyse dédiée : SDLC vs PDLC, la différence qui structure tout le reste.

À l'ère agentique, l'amont du PDLC devient l'arène de la différenciation. L'idéation identifie le bon problème, celui qui vaut la peine d'être résolu. La discovery tue les quatre grands risques formalisés par Cagan dès 2017 : la valeur (les clients l'achèteront-ils, les utilisateurs le choisiront-ils ?), l'utilisabilité (sauront-ils s'en servir ?), la faisabilité technique et la viabilité business. La conception, enfin, produit la spec et les prototypes. C'est le build to learn : avec les agents, une équipe matérialise une idée en prototype fonctionnel en quelques heures, pour apprendre vite et jeter sans regret, avant d'engager la fabrication.

Ce déplacement du centre de gravité a des témoins sérieux. Andrew Ng, dans une intervention à l'AI Startup School relayée par Lenny Rachitsky en juillet 2025, observe que le travail produit n'accélère pas au rythme de l'ingénierie, au point que certaines équipes envisagent d'inverser le ratio historique entre product managers et ingénieurs. Nous consacrons un article à ce basculement, la valeur migre vers la discovery, et un autre au rôle qui en émerge : le PM augmenté, libéré des tâches chronophages par les agents, qui évolue vers le profil de Product Builder, capable de porter une idée jusqu'au prototype testable sans mobiliser une équipe de fabrication.

Le cycle ne s'arrête pas au lancement : le suivi en production réalimente l'idéation. Un PDLC sans cette boucle de retour redevient une feature factory, qui mesure sa réussite au volume livré plutôt qu'à l'impact obtenu.

SDLC : construire le produit correctement

Deuxième étage, le build to earn : livrer en qualité production. Le SDLC agentique que nous industrialisons se resserre autour de trois moments. La porte Define, où l'humain cadre l'intention : le problème, les contraintes, les critères d'acceptation. L'exécution agentique, où les agents construisent, testent et revoient en continu, sous surveillance. La porte Ship, où l'humain valide sur preuve d'exécution, jamais sur la déclaration de l'agent. Entre les deux portes, le travail humain se déplace vers l'amont et l'aval : chez Salesforce, après la levée des limites d'usage des agents, la répartition de l'effort s'est inversée vers 80 % de planification et de revue pour 20 % d'exécution, selon les chiffres internes publiés en mai 2026.

Les ordres de grandeur publiés par les précurseurs donnent la mesure, avec la réserve d'usage qui s'impose. Intercom annonce en avril 2026 que 93,6 % de ses pull requests sont produites par des agents, avec un coût par PR divisé par deux et un backlog de défauts réduit de moitié ; Salesforce revendique +79 % de PRs mergées par développeur en un an. Ces chiffres sont auto-déclarés, mesurés avec des métriques internes, et aucun n'a été audité indépendamment. Ils indiquent une direction, pas une garantie : DORA 2025 rappelle que l'adoption de l'IA reste négativement corrélée à la stabilité de livraison quand les fondations (tests automatisés, CI/CD, plateforme interne) ne suivent pas.

La boucle propre à cet étage est le compound : chaque cycle enrichit la connaissance du système, conventions apprises, décisions consignées, pièges documentés, et rend le cycle suivant plus rapide. C'est ce qui distingue une équipe qui s'use d'une équipe qui capitalise.

KDLC : la connaissance, matière première

Si les agents produisent le code, les tests, les documents et les prototypes, la question devient : à partir de quelle matière ? Notre réponse est un troisième cycle à part entière : le KDLC (Knowledge Development Life Cycle), par symétrie avec le PDLC et le SDLC. Notre implémentation en est la production à base de connaissance, organisée en architecture médaillon, empruntée à l'ingénierie de données. Raw : la matière brute en lecture seule (documents, transcripts, notes, contraintes), où rien n'est jamais modifié. Bronze : l'extraction structurée et tracée, chaque élément relié à sa source par backlink. Silver : les contenus et les claims gouvernés, l'étage qui fait foi. Gold : le livrable régénéré, où rien ne s'écrit à la main. Nous détaillons ce modèle opératoire dans l'architecture médaillon appliquée à la production de connaissance.

La boucle de correction de cet étage est la plus contre-intuitive : si le livrable n'est pas bon, on ne l'édite pas. On ajoute de la matière dans raw, on promeut, on régénère. On raffine la matière, pas le livrable, et chaque chiffre du gold reste traçable jusqu'à sa source. Cette discipline est la réponse structurelle au « workslop », ce contenu généré par IA qui a l'apparence d'un travail abouti sans en avoir la substance : l'enquête BetterUp Labs et Stanford publiée par la Harvard Business Review en septembre 2025 (1 150 salariés américains, données déclaratives) estime que chaque incident coûte près de deux heures de retraitement. Sans source de vérité ni traçabilité, la génération illimitée détruit de la valeur ; nous y consacrons une analyse dédiée, la gouvernance des artefacts générés.

La porosité : l'axe qui traverse les trois bandes

La porosité PDLC/SDLC désigne l'effacement de la frontière entre concevoir et fabriquer, et elle a un mécanisme technique précis : le spec-driven development. Quand la spec est le prompt, l'artefact de conception produit dans le PDLC devient directement exécutable par les agents du SDLC. Le dual-track de Patton et Cagan coordonnait deux pistes parallèles ; ici, la frontière elle-même disparaît. Nous décortiquons ce mécanisme dans la porosité PDLC/SDLC et le spec-driven development.

La circulation verticale complète le tableau : les specs et les claims montent vers l'étage silver de la base de connaissance, où ils sont gouvernés et font foi ; les livrables gold, code compris, en redescendent comme des projections régénérables. Un deck, un rapport, une application : autant de rendus dérivés de la même matière, reconstruits à chaque évolution de celle-ci plutôt que retouchés à la main.

Le schéma ci-dessous résume cette architecture. Trois bandes horizontales : en haut, le PDLC (idéation, discovery, conception, développement) boucle du suivi vers l'idéation pour construire le bon produit ; au centre, le SDLC (porte Define, exécution agentique, porte Ship) boucle en compound pour bien le construire ; en bas, la base de connaissance en médaillon (raw, bronze, silver, gold) fournit et raffine la matière. Deux flux verticaux les relient : entre PDLC et SDLC, la porosité, où la spec est le prompt ; entre SDLC et connaissance, la montée des specs et des claims et la redescente des livrables régénérés. La conception, l'exécution agentique et l'étage silver partagent le même axe vertical : c'est la colonne vertébrale du système.

Ce qui change pour le DSI

Pour le DSI, le centre de gravité de l'usine logicielle se déplace du code vers le contexte. D'abord, l'actif à gouverner n'est plus le référentiel de code mais la base de connaissance qui le produit : specs, décisions d'architecture, doctrine, sémantique métier, versionnées et maintenues comme du code. Ensuite, les points de contrôle changent de nature : moins de revues ligne à ligne, des portes humaines nettes (Define, Ship) adossées à des preuves d'exécution, et des métriques qui incluent la stabilité, le rework et le change failure rate, pas seulement le débit. Enfin, la frontière organisationnelle avec le produit devient un flux à outiller : si la spec est le prompt, la qualité des specs devient un sujet d'ingénierie à part entière, au même titre que la CI/CD.

Ce qui change pour le CPO

Pour le CPO ou le patron produit, le rapport de force s'inverse : la fabrication n'est plus le goulot, la discovery le devient. Un prototype fonctionnel coûte quelques heures d'agent ; en conséquence, la capacité à formuler le bon problème, à tuer les mauvaises idées vite et à écrire des specs exécutables devient le facteur limitant de toute la chaîne. Les profils évoluent dans le même sens : le PM augmenté délègue l'assemblage aux agents pour concentrer son temps sur la stratégie et la discovery, et les meilleurs deviennent des Product Builders, capables de porter un concept jusqu'au prototype sans dépendre d'une file d'attente d'ingénierie. Le risque symétrique existe : multiplier les prototypes sans discipline de discovery, c'est industrialiser la feature factory. Les quatre risques de Cagan restent le garde-fou.

Questions fréquentes

Qu'est-ce que le KDLC ?
Le KDLC (Knowledge Development Life Cycle) est le cycle de vie de la connaissance qui alimente les deux autres cycles. Dans notre implémentation en médaillon : la matière brute (raw) est extraite et tracée (bronze), gouvernée en claims qui font foi (silver), puis régénérée en livrables (gold). Sa règle : on ne corrige jamais le livrable, on enrichit la matière et on régénère.

Le PDLC remplace-t-il le SDLC ?
Non. Le SDLC reste le sous-ensemble du PDLC qui fabrique le logiciel de façon fiable. Ce qui change à l'ère agentique, c'est la frontière entre les deux : la spec produite en conception devient directement exécutable par les agents, et les deux cycles s'alimentent à la même base de connaissance.

Faut-il laisser les agents produire sans revue humaine ?
Non. Le cadre repose sur des portes humaines explicites : Define en entrée, où l'humain cadre l'intention, et Ship en sortie, où il valide sur preuve d'exécution. DORA 2025 montre que la vitesse sans fondations dégrade la stabilité ; les portes et les preuves sont ce qui rend la vitesse durable.

Par où commencer ?
Par la matière. Constituer une base de connaissance gouvernée (specs, décisions, claims sourcés) avant d'accélérer la génération : générer plus sans source de vérité produit du workslop, générer depuis un étage silver qui fait foi produit des livrables traçables et régénérables.

Le point de vue SFEIR

Nous pratiquons ce cadre au quotidien : nos supports, nos analyses et une partie de nos livrables sont générés par la chaîne médaillon décrite ici, à partir de notre veille et de nos documents internes, et notre cycle logiciel agentique tourne avec ses portes humaines chez nos clients comme en interne. À mesure que la fabrication devient une commodité, la valeur se déplace vers le jugement produit, la qualité des specs et la gouvernance de la connaissance. Les organisations qui traiteront ces trois étages comme un seul système, plutôt que comme trois silos, prendront une avance difficile à rattraper : chaque cycle y rend le suivant plus rapide.

---

Sources

• svpg.com : Marty Cagan, « Build to Learn vs Build to Earn », avril 2026 (déplacement du goulot vers la discovery).
• svpg.com : Marty Cagan, « The Four Big Risks », décembre 2017 (valeur, utilisabilité, faisabilité, viabilité business).
• dora.dev : DORA / Google Cloud, « State of AI-assisted Software Development 2025 » (adoption à 90 %, effet amplificateur, corrélation négative avec la stabilité de livraison).
• github.com : GitHub Spec Kit, trajectoire d'adoption du spec-driven development entre mai et juillet 2026.
• Andrew Ng, intervention à l'AI Startup School (San Francisco), relayée par Lenny Rachitsky sur X, juillet 2025 (évolution du ratio product managers / ingénieurs).
• Intercom, chiffres publiés en avril 2026 (part des pull requests produites par des agents, coût par PR, backlog de défauts) ; Srinivas Tallapragada, « How Engineering Became Agentic », Salesforce News, mai 2026 (+79 % de PRs mergées, répartition 80/20 de l'effort).
• hbr.org : BetterUp Labs et Stanford Social Media Lab, « AI-Generated Workslop Is Destroying Productivity », septembre 2025.

Note de fiabilité : les chiffres Intercom et Salesforce sont auto-déclarés, mesurés avec des métriques internes et non audités indépendamment. Les propos d'Andrew Ng sont relayés (post de Lenny Rachitsky), non issus d'une interview formelle. DORA 2025 établit des corrélations, non des causalités, et l'enquête workslop repose sur des données déclaratives. Le cadre en trois étages et sa lecture stratégique relèvent de l'analyse de SFEIR et WEnvision.