Porosité PDLC/SDLC : quand la spec devient le prompt

Le 7 mai 2026, AWS annonce la disponibilité mondiale de Kiro, son IDE spec-native. Deux mois plus tard, GitHub Spec Kit, le framework open source de spec-driven development publié sous licence MIT, dépasse les 117 000 étoiles environ sur GitHub (contre environ 90 000 en mai) et supporte plus de 30 agents de code. Derrière ces signaux d'adoption, une idée : la spec est le prompt. L'artefact de conception n'est plus un document que l'ingénierie traduit ; il est directement exécutable par des agents. C'est le mécanisme technique de ce que nous appelons la porosité PDLC/SDLC : une frontière qui s'efface.

SFEIR et WEnvision portent cette thèse au cœur du cadre Concevoir et fabriquer à l'ère de l'agentique : l'amont produit et l'aval ingénierie ne sont plus deux mondes reliés par un backlog, mais un continuum traversé par les mêmes artefacts. Cet article détaille le mécanisme qui rend cette porosité opérationnelle, la preuve à l'échelle, et la discipline qui l'empêche de tourner au chaos.

Du dual-track à la frontière effacée

La coordination entre produit et ingénierie a déjà son état de l'art : le dual-track agile de Jeff Patton et Marty Cagan (vers 2012) fait tourner deux pistes parallèles au sein d'une même équipe, la discovery (valider quoi construire) et le delivery (construire et livrer), que Teresa Torres a prolongées en « continuous discovery ». Ce modèle reste un modèle de coordination : deux pistes distinctes, deux types d'artefacts, une synchronisation à organiser.

La porosité va plus loin : la frontière entre les deux pistes disparaît. Quand la spécification écrite pendant la discovery est le même objet que celui qui déclenche la fabrication, il n'y a plus de « passage de relais » entre le PDLC et le SDLC, plus de traduction d'un backlog produit en tickets d'ingénierie, plus de perte en ligne entre l'intention et l'exécution. La distinction entre les deux cycles reste conceptuellement valide (nous la détaillons dans SDLC vs PDLC : quelle différence), mais leur jonction devient une membrane.

Le mécanisme : la spec est le prompt

Cette porosité est un pipeline outillé. Le spec-driven development structure le travail en artefacts exécutables : une spécification d'intention (le quoi et le pourquoi), un plan technique (le comment), des tâches dérivées, puis une implémentation par agents, chaque étape étant générée et vérifiée à partir de la précédente. GitHub Spec Kit incarne cette grammaire en open source, agnostique du modèle et de l'agent ; AWS Kiro l'intègre nativement dans l'IDE, la spec devenant l'unité de travail première, avant le code. Google Antigravity et BMAD explorent la même direction.

La conséquence organisationnelle est directe : l'artefact que produit le product manager en discovery (une spécification claire, testable, contextualisée) devient le point d'entrée direct de l'usine logicielle. Le PM augmenté n'écrit plus des user stories qui attendent un sprint ; il écrit des specs qui s'exécutent. C'est le pont concret entre les PM augmentés et les Product Builders, et la raison pour laquelle la qualité de la spécification devient la compétence la plus valorisée du cycle, côté produit comme côté ingénierie.

La preuve à l'échelle : le cas Airbnb

Le cas le plus documenté de fabrication pilotée par la spécification reste celui d'Airbnb, décrit par Charles Covey-Brandt sur le blog d'ingénierie de l'entreprise : la migration de près de 3 500 fichiers de tests de composants React du framework Enzyme vers React Testing Library. Estimation initiale en approche manuelle : environ un an et demi. Résultat en pipeline piloté par LLM, avec specs de migration, exécution par lots et boucles de retry : six semaines, à six ingénieurs, avec 97 % des fichiers migrés automatiquement, le reliquat étant traité à la main.

Ce cas fixe d'abord l'ordre de grandeur : sur un périmètre bien spécifié et vérifiable, le passage de l'intention à l'exécution machine compresse le calendrier d'un facteur dix et plus. Il fixe ensuite la condition : cette compression tient à la qualité de la spécification et du harnais de vérification qui l'entourait. Les organisations qui spécifient le mieux compressent le plus.

Du concept au prototype : le build to learn à coût quasi nul

L'autre versant de la porosité regarde vers l'amont : la product discovery. Dans le vocabulaire de Cagan, la discovery relève du « build to learn » : construire pour apprendre, au moindre coût, avant d'engager le « build to earn » de la production. Quand une spec de quelques pages se matérialise en prototype fonctionnel en heures, le coût marginal de l'apprentissage s'effondre : une idée exprimée en comité produit le lundi peut être un prototype testable par des utilisateurs le mardi. Les quatre risques produit (valeur, utilisabilité, faisabilité, viabilité) se testent sur des objets réels plutôt que sur des maquettes, et le nombre d'hypothèses qu'une équipe peut éliminer par trimestre change d'échelle.

C'est le pilier « du concept au prototype » du cadre agentique : la matérialisation instantanée des idées en premiers livrables fonctionnels. Ce pilier a un piège.

Prototype jetable, production gouvernée : la distinction qui sauve

Le piège porte un nom dans le rapport DORA 2025 : l'adoption de l'IA corrèle positivement avec le débit de livraison, mais reste négativement corrélée à la stabilité (corrélations, non causalités, le rapport le précise). La cause probable est justement la confusion des régimes : du code de prototype, généré vite et sans gouvernance, qui glisse en production parce qu'« il marche ».

La parade est une frontière à tracer explicitement, non plus entre PDLC et SDLC, mais entre deux régimes de fabrication. Le prototype de discovery relève du build to learn : vibe coding assumé, jetable par contrat, jamais déployé tel quel. Le code de production relève du build to earn : spec-driven, gouverné, soumis aux portes humaines et à la discipline de preuve du SDLC augmenté (spécification validée, revue, preuve d'exécution capturée, capitalisation). La porosité efface la frontière organisationnelle entre produit et ingénierie ; elle exige en retour cette frontière de gouvernance entre l'exploratoire et l'industriel. Les organisations qui effacent la première sans tracer la seconde fabriquent exactement l'instabilité que DORA mesure.

Ce que cela change pour le DSI et pour le CPO

Pour le DSI, la porosité redéfinit l'interface d'entrée de son usine logicielle : le contrat n'est plus un backlog de tickets mais un standard de spécification exécutable, à outiller (Spec Kit, Kiro ou équivalent), à versionner et à auditer comme du code. Sa responsabilité nouvelle est la frontière de gouvernance : un chemin balisé du prototype vers la production, avec des portes humaines explicites, pour que la vitesse de l'exploratoire ne contamine pas la stabilité de l'industriel. Refuser la porosité ne le protège pas ; elle se fera sans lui, dans les outils que les équipes produit adoptent déjà.

Pour le CPO, la spec devient son levier d'exécution direct : la qualité de spécification de ses équipes détermine désormais la vitesse de fabrication, sans intermédiaire. Cela déplace les compétences à recruter et à former (savoir spécifier de façon testable devient une compétence produit de premier rang) et cela change son économie de la discovery : le prototypage à coût quasi nul permet de tester dix hypothèses là où l'on en testait une. En contrepartie, il lui revient d'assumer la règle du jetable : un prototype de discovery qui séduit un sponsor n'est pas un produit livrable, et le dire avant la démo coûte moins cher qu'après.

Questions fréquentes

La porosité PDLC/SDLC rend-elle le dual-track agile obsolète ?
Elle le dépasse plus qu'elle ne l'invalide. Le dual-track organise la coordination de deux pistes, discovery et delivery, au sein d'une équipe ; la porosité supprime la traduction entre les deux, la spécification de discovery devenant directement exécutable par des agents. Les habitudes du dual-track (discovery continue, validation avant engagement) restent pertinentes ; c'est la frontière artefactuelle entre les pistes qui disparaît.

Le spec-driven development impose-t-il un outil particulier ?
Non. GitHub Spec Kit est open source (licence MIT) et se veut agnostique du modèle et de l'agent, avec plus de 30 agents supportés ; AWS Kiro intègre la démarche dans un IDE dédié ; d'autres approches existent. L'essentiel est la discipline : une spécification versionnée, testable, qui sert de source unique de l'intention, et un harnais de vérification qui capture des preuves d'exécution.

Le point de vue SFEIR

La porosité PDLC/SDLC est à nos yeux la thèse la plus structurante du cycle produit-logiciel en 2026 : elle transforme la spécification en actif exécutable et fait de la frontière produit-ingénierie une membrane. Mais nous la vendons toujours avec sa contrepartie : une frontière de gouvernance nette entre prototype jetable et production gouvernée, adossée aux portes humaines de notre SDLC augmenté. Effacer la première frontière sans tracer la seconde, c'est convertir un gain de vitesse en dette de stabilité. Notre accompagnement couvre les deux gestes, avec les PM augmentés d'un côté et la Software Factory de l'autre, connectés par la spec.

---

Sources

• github.com : GitHub Spec Kit, framework open source de spec-driven development (licence MIT, environ 117 000 étoiles en juillet 2026, plus de 30 agents supportés).
• kiro.dev : AWS Kiro, IDE spec-native, disponibilité mondiale annoncée le 7 mai 2026.
• medium.com/airbnb-engineering : Charles Covey-Brandt, « Accelerating Large-Scale Test Migration with LLMs » (environ 3 500 fichiers Enzyme vers RTL, six semaines, 97 % automatisé).
• dora.dev : DORA / Google Cloud, « State of AI-assisted Software Development 2025 » (corrélation négative entre adoption IA et stabilité de livraison).
• svpg.com : Marty Cagan, « Discovery vs. Delivery » (build to learn vs build to earn) ; dual-track agile de Jeff Patton et Marty Cagan, vers 2012.
• addyosmani.com : Addy Osmani, Shubham Saboo, Sokratis Kartakis (Google), « The New SDLC With Vibe Coding », whitepaper, mai 2026 (spectre vibe coding / agentic engineering).

Note de fiabilité : les comptes d'étoiles GitHub sont approximatifs et évoluent en continu ; les chiffres Airbnb proviennent du blog d'ingénierie de l'entreprise, sans audit indépendant ; les résultats DORA 2025 sont des corrélations issues d'une enquête déclarative, non des causalités établies. La thèse de la porosité et la distinction prototype/production relèvent de l'analyse de SFEIR et WEnvision, appuyée sur ces sources.