SDLC vs PDLC : quelle différence, et pourquoi l'IA change tout

En avril 2026, Marty Cagan publie « Build to Learn vs Build to Earn » et met des mots sur un basculement que beaucoup de directions techniques constatent sans le nommer : à mesure que le coût de fabrication du logiciel s'effondre, le goulot d'étranglement migre vers la découverte du bon produit. Pour raisonner sur ce basculement, il faut d'abord distinguer deux cycles que le vocabulaire courant confond en permanence : le SDLC, qui livre du logiciel fiable, et le PDLC, qui réussit un produit sur son marché.

SFEIR documente depuis des mois le SDLC augmenté, notre cycle d'ingénierie à 11 phases piloté par l'IA, et la Software Factory 10x, l'usine qui l'industrialise. Cet article couvre un terrain volontairement différent : non pas le versant ingénierie, mais la distinction entre les deux cycles et leur articulation. C'est le socle du cadre complet que nous décrivons dans Concevoir et fabriquer à l'ère de l'agentique.

Le SDLC : construire le logiciel correctement

Le SDLC (Software Development Life Cycle) est le cadre qui structure la production de logiciel. Ses phases canoniques : recueil des besoins et planification, conception et architecture, développement, tests et assurance qualité, déploiement, maintenance et opérations. Il est standardisé au niveau international par l'ISO/IEC/IEEE 12207 (« Systems and software engineering : Software life cycle processes »), dont l'édition 2017 organise les processus en quatre groupes (accord, processus organisationnels habilitants, gestion technique, processus techniques) et dont une édition 2026, publiée cette année, rapproche le standard des pratiques agiles et itératives.

Les modèles historiques se succèdent sans s'annuler : le waterfall (1970), séquentiel et documenté, survit dans les contextes réglementés à périmètre fixe ; le cycle en V apparie chaque phase de développement à une phase de test, ce qui le maintient dans les environnements critiques ; les approches itératives et la spirale centrent chaque tour sur l'analyse de risque ; l'agile (Manifeste de 2001) impose le feedback continu ; DevOps puis DevSecOps (à partir de 2009 environ) transforment le cycle en boucle continue, CI/CD et sécurité intégrée dès la conception. La finalité, elle, ne varie pas : construire le logiciel correctement et de façon fiable. Qualité, sûreté des releases, disponibilité.

Le PDLC : réussir un produit sur son marché

Le PDLC (Product Development Life Cycle) est le cadre englobant : il court de l'idée jusqu'au retrait du marché. Ses stades : idéation et discovery, validation et étude de marché, prototypage, développement, lancement, croissance, maturité, déclin et retrait. Il mobilise des acteurs bien au-delà de l'ingénierie : product management, design, recherche utilisateur, marketing, ventes, support.

Autre confusion fréquente : le PDLC (comment on construit et fait vivre un produit) n'est pas le PLC marketing, le « product life cycle » popularisé par Theodore Levitt dans « Exploit the Product Life Cycle » (Harvard Business Review, novembre 1965) : introduction, croissance, maturité, déclin, avec des stratégies marketing distinctes par stade. Le PLC de Levitt décrit la trajectoire commerciale d'un produit sur son marché ; le PDLC décrit le processus qui le conçoit, le construit et le fait évoluer. Le second englobe des décisions que le premier se contente d'observer.

Les différences, dimension par dimension

Le consensus des sources spécialisées est net : le PDLC est le processus englobant centré sur le produit dans son ensemble, le SDLC en est un sous-ensemble. Le tableau suivant résume les différences.

Dimension	SDLC	PDLC
Périmètre	Le logiciel (sous-ensemble)	Le produit entier (englobant)
Finalité	Construire correctement et fiablement	Construire le bon produit, réussir sur le marché
Question	« Comment le livrer ? »	« Quoi construire, et pourquoi ? »
Acteurs	Ingénierie, QA, ops	PM, design, growth, marketing, ventes
Métriques	Vélocité, lead time, qualité, métriques DORA (débit, stabilité, MTTR, change failure rate)	Adoption, rétention, revenus, product-market fit, NPS
Horizon	La release, le sprint	La vie complète du produit (des années)
Risques adressés	La faisabilité technique	Valeur, utilisabilité, faisabilité, viabilité business

L'emboîtement : le SDLC vit sous la phase développement

Les deux cycles sont emboîtés : le SDLC est logé sous la phase développement du PDLC. Quand une équipe produit atteint le stade « développement », c'est tout un SDLC (conception, build, tests, revue, déploiement) qui se déroule à l'intérieur de cette case. Cet emboîtement explique la dernière ligne du tableau. Dans le cadre des « quatre grands risques » formalisé par Cagan (« The Four Big Risks », décembre 2017, toujours référencé dans ses articles de 2026), la product discovery existe pour éliminer quatre risques avant d'engager la capacité d'ingénierie : le risque de valeur (les clients l'achèteront-ils, les utilisateurs le choisiront-ils ?), d'utilisabilité (sauront-ils s'en servir ?), de faisabilité (nos ingénieurs peuvent-ils le construire ?) et de viabilité business (la solution fonctionne-t-elle pour toutes les dimensions de l'entreprise ?).

La répartition est explicite chez Cagan : le PM répond des risques de valeur et de viabilité, le designer de l'utilisabilité, le lead engineer de la faisabilité. Autrement dit, le SDLC ne traite nativement qu'un risque sur quatre. Une organisation qui excelle en SDLC et ignore le PDLC produit très bien des logiciels dont personne ne veut : c'est la « feature factory » décrite par John Cutler, qui mesure le succès au nombre de fonctionnalités livrées (output) plutôt qu'à l'impact obtenu (outcome).

Pourquoi l'IA change tout

L'IA générative comprime d'abord le SDLC, et massivement. Le whitepaper Google « The New SDLC With Vibe Coding » (Osmani, Saboo, Kartakis, mai 2026) rapporte, sur données JetBrains, qu'environ 85 % des développeurs professionnels utilisent régulièrement des agents de code et qu'environ 41 % du nouveau code est généré par IA (chiffres d'enquête, à prendre comme des ordres de grandeur déclaratifs). L'implémentation passe de semaines à heures ; les besoins, l'architecture et la vérification restent au rythme humain.

Mais la compression n'est pas uniforme. Le rapport DORA 2025 de Google Cloud (enquête auprès d'environ 5 000 professionnels) mesure une adoption de l'IA à 90 % et une corrélation positive avec le débit de livraison, mais une corrélation qui reste négative avec la stabilité (corrélations, pas causalités : le rapport lui-même y insiste). Surtout, quand le coût du delivery s'effondre, le goulot d'étranglement se déplace vers l'amont : décider quoi construire. Cagan le formule en avril 2026 ; Andrew Ng l'illustrait dès juillet 2025 à l'AI Startup School (propos relayés par Lenny Rachitsky) en rapportant que certaines de ses équipes proposent d'inverser le ratio historique d'un PM pour quatre ingénieurs, jusqu'à deux PM par ingénieur. Le PDLC devient l'arène de la différenciation : jugement produit, discovery rapide, orchestration.

Le mouvement va plus loin qu'un simple transfert de charge : la frontière entre les deux cycles elle-même devient poreuse. Quand la spécification produit devient directement exécutable par des agents, l'artefact de conception du PDLC alimente le SDLC sans rupture. Ce mécanisme, le spec-driven development, fait l'objet d'une analyse dédiée : la porosité PDLC/SDLC, quand la spec devient le prompt.

Ce que cela change pour le DSI et pour le CPO

Pour le DSI, la conséquence est frontale : optimiser le SDLC seul ne suffit plus à créer de l'avantage. Un SDLC augmenté bien outillé devient la norme de marché, pas un différenciateur ; le risque nouveau est de produire plus vite des fonctionnalités non validées, ce que DORA 2025 traduit en instabilité et en retravail. Le DSI doit donc instrumenter la jonction avec le produit : exiger des spécifications exécutables en entrée de son usine, partager ses métriques (lead time, change failure rate) avec les métriques d'outcome du produit, et refuser le rôle de « fournisseur de features » que le modèle projet lui assigne.

Pour le CPO ou le patron produit, le déplacement du goulot vers la discovery est une promotion et une mise en demeure. Promotion : le jugement produit redevient la ressource rare, et l'inversion du ratio PM/ingénieurs évoquée par Ng en est le signal. Mise en demeure : un PDLC artisanal face à un SDLC industrialisé crée un déséquilibre intenable. Le CPO doit outiller sa discovery (prototypage par agents, validation accélérée des quatre risques) au niveau où le DSI a outillé son delivery, faute de quoi c'est lui, désormais, qui tient le chemin critique de l'entreprise.

Questions fréquentes

Le PDLC remplace-t-il le SDLC ?
Non. Les deux cycles sont emboîtés : le SDLC est le sous-ensemble du PDLC logé sous sa phase développement. Le SDLC garantit que le logiciel est bien construit ; le PDLC garantit que c'est le bon produit qui est construit. L'IA comprime le premier et déplace la valeur vers le second, mais aucun des deux ne disparaît.

Quelle différence entre PDLC et product life cycle (PLC) ?
Le PLC, popularisé par Theodore Levitt en 1965, décrit la trajectoire commerciale d'un produit sur son marché (introduction, croissance, maturité, déclin) et guide les stratégies marketing. Le PDLC décrit le processus de conception, de construction et d'évolution du produit, de l'idéation au retrait. Le PLC observe une courbe ; le PDLC organise un travail.

Le point de vue SFEIR

L'entreprise qui industrialise son SDLC sans repenser son PDLC construit une usine ultra-performante branchée sur un carnet de commandes artisanal. Le cycle à 11 phases et la Software Factory 10x règlent le versant ingénierie ; le levier suivant est l'articulation des deux cycles, portée par le cadre « Concevoir et fabriquer à l'ère de l'agentique » : PM augmenté sur l'amont, porosité entre conception et fabrication, gouvernance de bout en bout. À mesure que le code devient une commodité, la marge se déplace vers le jugement produit et la gouvernance. Nous industrialisons les deux.

---

Sources

• svpg.com : Marty Cagan, « The Four Big Risks », décembre 2017 (valeur, utilisabilité, faisabilité, viabilité business).
• svpg.com : Marty Cagan, « Build to Learn vs Build to Earn », avril 2026 (déplacement du goulot vers la discovery).
• ISO/IEC/IEEE 12207, « Systems and software engineering : Software life cycle processes », éditions 2017 et 2026.
• hbr.org : Theodore Levitt, « Exploit the Product Life Cycle », Harvard Business Review, novembre 1965 (le PLC marketing, à distinguer du PDLC).
• dora.dev : DORA / Google Cloud, « State of AI-assisted Software Development 2025 » (adoption, corrélations débit et stabilité).
• addyosmani.com : Addy Osmani, Shubham Saboo, Sokratis Kartakis (Google), « The New SDLC With Vibe Coding », whitepaper, mai 2026.
• Andrew Ng, intervention à l'AI Startup School (San Francisco), relayée par Lenny Rachitsky sur X, juillet 2025 (ratio PM/ingénieurs).

Note de fiabilité : les chiffres d'adoption (85 % de développeurs sur agents, 41 % de code généré, 90 % d'adoption DORA) proviennent d'enquêtes déclaratives ; les résultats DORA sont des corrélations, non des causalités. Les propos d'Andrew Ng sont relayés via un post de Lenny Rachitsky, non une interview formelle. La lecture stratégique (déplacement du goulot, déséquilibre PDLC/SDLC) relève de l'analyse de SFEIR, appuyée sur ces sources.