Agentic Product Development Life Cycle

L'Agentic PDLC (Product Development Life Cycle) est un terme encore peu usité issu de cabinets de conseils et conçu en s'inspirant de l'Agentic SDLC.

Ce qu'il contient et que le SDLC ne contient pas

Le SDLC (Software Development Life Cycle) est plus réduit, il part d'une unité de travail définie et s'arrête à un déploiement. Il n'a pas d'avis sur l'idéation et cadrage de l'opportunité situés en amont. Décider quel problème mérite d'exister en tant que travail. Le SDLC n'a pas d'avis sur ce point : il reçoit un backlog et suppose que quelqu'un d'autre l'a rempli. Partiellement revendiqué. Dragonboat atteint ce terrain avec une couche stratégie et investissement placée au-dessus du cycle de vie. EY et Isos démarrent en aval.

Discovery. Recherche utilisateur, validation du problème, prototypage destiné à apprendre plutôt qu'à livrer. C'est le segment où les agents modifient le plus visiblement l'économie du travail : un artefact jetable qui coûtait un sprint coûte désormais un après-midi, ce qui change ce qu'il devient rentable de valider, et pas seulement la vitesse à laquelle on le valide. Revendiqué par aucune des quatre sources examinées. Employer le terme pour couvrir la discovery est une extension, et doit être annoncé comme telle.

Intake et priorisation. Transformer une opportunité en unité de travail finançable et spécifiable, et décider de ce qui ne sera pas fait. C'est la charnière entre le domaine produit et le SDLC, et l'endroit où un cycle agentique tient ou se disloque, puisque tout l'aval hérite de la qualité de cette décision. Revendiqué. Dragonboat nomme intake, planner et roadmap comme surfaces distinctes.

Spécification. Dans le SDLC, le document d'exigences est une entrée écrite pour des humains. Dans la version agentique, il devient le contrat auquel l'agent est tenu, donc un artefact exécutable plutôt que descriptif. Ce déplacement est le point le plus contesté de tout le périmètre. Revendiqué, et disputé.

Build, test, revue, déploiement. Le SDLC proprement dit. Terrain commun, vocabulaire le plus dense, et seul segment dont la terminologie a été produite par des praticiens plutôt que par des fournisseurs.

Mise sur le marché plutôt que déploiement. Déployer est un acte du SDLC. Livrer quelque chose qu'un client peut réellement adopter suppose documentation, infrastructure, supports et tests comme un livrable unique. EY en fait la distinction centrale : le PDLC livre un produit complet, prêt pour le marché, là où le SDLC se concentrait sur le code seul. Revendiqué, et c'est l'axe que les supports commerciaux mettent le plus en avant.

Exploitation, gouvernance et supervision des agents. Faire tourner le produit, et désormais gouverner les agents qui l'ont construit et qui continuent d'y toucher. Un objet réellement nouveau apparaît ici, sans équivalent dans le SDLC : l'efficacité des agents devient une chose à instrumenter, au même titre que le débit et la qualité. Revendiqué. Isos inscrit explicitement la gouvernance et l'optimisation dans son périmètre, et nomme l'efficacité des agents parmi ses métriques.

Growth. Activation, rétention, monétisation, et la boucle de retour vers l'idéation. Revendiqué par aucune des quatre sources. Employer le terme jusque-là revient à l'étendre bien au-delà de ce que ses sources affirment.

Le modèle de financement, transversal à l'ensemble. Le mode projet dispose d'un budget fermé et d'un cycle de planification long ; le mode produit est financé pour itérer en continu. EY en fait un contraste définitoire, et c'est sans doute le plus gros élément non-SDLC du terme, parce qu'il est organisationnel et non procédural, et qu'une équipe de delivery ne peut pas l'adopter seule.

Version courte : les définitions publiées sont solides au milieu et à l'arrière, faibles à l'avant, muettes sur le growth. La réputation du terme est plus large que ses sources. Cet écart est gérable s'il est énoncé, trompeur s'il ne l'est pas.

D'où vient le terme

De nulle part en particulier, et ce point compte.

L'expression n'a pas d'auteur attribuable. Elle apparaît en parallèle, en 2025 et 2026, dans la communication de quatre organisations sans source commune.

EY commercialise une offre, EY.ai PDLC, décrite comme un modèle orchestré par l'IA et piloté par l'intention, destiné à livrer des produits logiciels complets en jours plutôt qu'en mois, portée par un associé identifié, Rakesh Malhotra.

Forte Group a présenté une mise en œuvre avec son client Xceptor sous le titre « We Built an Agentic PDLC. Here's What Actually Happened », lors d'un CTO Craft en mars 2026 puis dans une seconde partie en juin. C'est la seule des quatre qui documente ce qui s'est passé plutôt que ce qui est promis.

Dragonboat, plateforme de gestion de portefeuille produit, emploie « the OS for the agentic PDLC » comme accroche principale et publie une étude de cas client sous ce label.

Isos Technology, partenaire Atlassian, vend une AI-Native PDLC Transformation sous forme de programme de modernisation en cinq phases.

Il s'agit d'un label de catégorie produit par un marché, non d'un concept produit par un auteur. Écrire que le terme a été forgé par une personne ou une firme identifiée revient à inventer une filiation.

Le sigle sous-jacent est plus ancien. PDLC désigne depuis des années, en gestion de produit, le chemin de l'idée au lancement puis à l'itération. Seul le qualificatif est nouveau.

Pourquoi aucune communauté de praticiens ne l'a produit

Les cabinets vendent une transformation à l'échelle d'une organisation entière, et ont donc besoin d'un nom couvrant une organisation entière. Les communautés de praticiens nomment la partie qu'elles pratiquent, et n'ont jamais eu besoin d'un terme parapluie.

La conséquence est visible dans les sources elles-mêmes. Isos construit son programme en partie sur l'agentic engineering, terme produit par des praticiens, enveloppé dans un cadre de cabinet. L'enveloppe est légitime. Présenter l'enveloppe comme si elle portait le même poids probatoire que son contenu ne l'est pas.

Le seul segment doté d'une provenance réelle

Le segment build possède une histoire courte et datable.

En octobre 2025, Simon Willison constate un trou terminologique : vibe coding s'est imposé pour désigner la façon rapide, relâchée et irresponsable de construire avec l'IA, ce qui ne laisse aucun nom pour l'autre extrémité du spectre, celle des professionnels expérimentés qui accélèrent leur travail tout en restant comptables de ce qu'ils livrent. Il propose vibe engineering, à demi sérieusement.

En février 2026, Addy Osmani rapporte qu'Andrej Karpathy a proposé agentic engineering dans la semaine, et adopte le terme, estimant qu'après des mois de débat le mot vibe traîne trop de connotations : annoncer à un CTO qu'on fait du vibe engineering sur son système de paiement produit une réaction lisible. Sa définition : orchestrer des agents qui exécutent, testent et affinent le code, pendant que l'humain tient les rôles d'architecte, de relecteur et de décideur.

Le 23 février 2026, Willison amende son propre billet pour concéder que le terme l'emporte.

Cette filiation doit être citée avec précision et parcimonie. Les deux mêmes mots désignent aussi l'ingénierie des systèmes agentiques, qui est une autre discipline, et un terme presque identique, AI engineering, désigne déjà la construction d'applications sur des modèles de fondation.

Le spec-driven development se place à l'entrée de ce segment et constitue la pratique la plus contestée du périmètre. Ses partisans voient dans la spécification ce qui rend le travail des agents relisible et reproductible. Ses détracteurs y voient le retour de la conception amont sous un nom neuf, trop rigide pour le travail exploratoire que les agents sont censés rendre bon marché. Les deux positions sont tenues par des gens sérieux.

Confusions à désamorcer

PDLC et cycle de vie du produit. En marketing, le cycle de vie du produit désigne la trajectoire commerciale qui va du lancement au déclin en passant par la croissance et la maturité. Concept différent, nom presque identique, et une partie du lectorat connaît d'abord ce sens. La collision est plus forte en français qu'en anglais, puisque la traduction littérale du sigle produit exactement l'expression déjà occupée. C'est une raison de conserver le sigle anglais et de définir le périmètre à la première occurrence.

PDLC comme chaîne de caractères. Le sigle possède un homographe sans rapport en science des matériaux, où il désigne un cristal liquide dispersé dans un polymère. Une recherche sur le sigle seul est peu fiable. Écrire l'expression complète au moins une fois par document règle le problème.

Enchaînement de phases ou modèle de capacités. Savoir si un agentic PDLC est une séquence d'étapes définies ou un ensemble de capacités mobilisées sans ordre imposé n'est pas tranché. Les supports commerciaux penchent vers les étapes, parce que les étapes se vendent.

Recommandations Employer le terme, et le signaler dès la première occurrence comme un terme émergent d'origine consultante. Sa faiblesse visible est un avantage : elle pousse le lecteur à demander ce qu'il y a dedans plutôt qu'à le supposer. Énoncer explicitement le périmètre, et signaler où il dépasse ce que les sources revendiquent, c'est-à-dire la discovery à l'avant et le growth à l'arrière. Ne jamais l'attribuer. Apparition parallèle sans auteur est la description exacte. Tenir distinctes la couche cabinet et la couche praticiens. Quand un composant possède une provenance réelle, citer cette provenance séparément plutôt que de laisser le terme parapluie se l'approprier. Marquer les segments selon leur maturité. Le build est dense et contesté. Discovery, exploitation et growth sont minces. Présenter le spec-driven development comme contesté, parce qu'il l'est. Écarter les chiffres. Les supports commerciaux avancent des gains sans méthodologie associée. Ce sont des arguments de vente, pas des résultats. Sources

Les quatre usages d'origine

EY, « AI-native PDLC: reinventing software delivery », ey.com/en_us/services/consulting/ai-native-pdlc-reinventing-software-delivery. Avance, sans source, des produits livrables jusqu'à 80 fois plus tôt et des coûts réduits jusqu'à 70 %. À traiter comme du marketing. EY, « AI-native software delivery: CIOs and the PDLC », ey.com/en_us/insights/ai/ai-native-software-delivery-cios-and-the-pdlc (juillet 2026). Cite Rakesh Malhotra, Principal, Digital and Emerging Technologies, Ernst and Young LLP. EY, « Rise of AI is reshaping product development », ey.com/en_us/insights/ai/rise-of-ai-is-reshaping-product-development (juin 2026). Source de la distinction de périmètre entre PDLC et SDLC. Forte Group et Xceptor, « We Built an Agentic PDLC. Here's What Actually Happened », parties une et deux, youtube.com/watch?v=EKkKTDmV6Gs (juin 2026), issu du CTO Craft « Operationalising AI », mars 2026. Dragonboat, dragonboat.io, accroche principale, et « What is Product Operating Ontology and Why It Matters in AI Era », dragonboat.io/blog/what-is-product-operating-ontology (juillet 2026), qui mentionne une transformation Agentic PDLC chez une fintech du Fortune 500. Isos Technology, « AI-Native PDLC Transformation », isostech.com/solution/ai-native-pdlc-transformation, et le billet d'annonce sur blog.isostech.com.

Le segment build

Simon Willison, « Vibe engineering », simonwillison.net/2025/Oct/7/vibe-engineering (7 octobre 2025), y compris la mise à jour de l'auteur du 23 février 2026. Addy Osmani, « Agentic Engineering », addyosmani.com/blog/agentic-engineering (4 février 2026). Source primaire de l'attribution à Karpathy, laquelle repose sur le compte rendu d'Osmani et non sur une publication de Karpathy consultée ici.

Note de méthode

L'affirmation d'une apparition parallèle repose sur l'absence de source commune entre quatre organisations indépendantes, non sur une preuve positive de cette indépendance. Résumés de conférence, supports internes et publications sur les réseaux s'indexent mal : une occurrence antérieure, ou une origine unique, peut exister sans avoir été retrouvée.

Cet en-tête est saisi à la main, comme toute cette page : elle est rédigée de bout en bout, et ne porte aucun bloc calculé.