La valeur migre vers la discovery : le nouveau goulot est produit

En avril 2026, Marty Cagan publie « Build to Learn vs Build to Earn » et tire la conséquence stratégique de deux ans d'agents de code : à mesure que le coût du delivery s'effondre, le goulot d'étranglement, et avec lui l'avantage concurrentiel, se déplace vers la product discovery. Le vrai enjeu devient de découvrir une solution qui vaille la peine d'être construite. Le fondateur du Silicon Valley Product Group écrit depuis vingt ans que la discovery est le cœur du métier ; ce qui change en 2026, c'est que l'économie de la production logicielle lui donne raison à grande échelle.

SFEIR outille depuis deux ans la compression du delivery : software factory, spec-driven development, cycle de production piloté par l'IA. La suite logique de cette compression se joue en amont, dans le cycle produit ; c'est l'objet du récit complet « Concevoir et fabriquer à l'ère de l'agentique », dont cet article développe le versant discovery : où va la valeur quand fabriquer devient rapide et bon marché.

Quand le delivery s'effondre, le goulot remonte

La distinction de Cagan est ancienne (« Discovery vs. Delivery », 2015) : la product discovery sert à apprendre vite (prototypes, tests, validation des hypothèses avec de vrais utilisateurs), le delivery sert à livrer en confiance un produit de qualité production. « Build to Learn vs Build to Earn » reprend cette paire sous l'angle économique : le build to learn construit pour apprendre, le build to earn construit pour gagner, et les deux exigeaient jusqu'ici d'arbitrer le temps d'ingénierie, ressource rare. Les agents cassent l'arbitrage : un prototype fonctionnel coûte désormais quelques heures d'agent, et le code de production lui-même se génère sous surveillance.

Dans le PDLC, le cycle de vie complet du produit qui va de l'idéation au retrait du marché, la case développement rétrécit. L'idéation, la validation et la conception deviennent le chemin critique : c'est là que se décide ce qui mérite d'exister, pendant que la fabrication s'exécute en heures. Une organisation qui a investi tout son effort d'industrialisation dans le delivery découvre alors un déséquilibre neuf : sa capacité à fabriquer dépasse sa capacité à savoir quoi fabriquer.

Le signal Ng : et si le ratio PM/ingénieurs s'inversait ?

Un signal donne l'échelle du déplacement. En juillet 2025, Lenny Rachitsky relaie sur X des propos tenus par Andrew Ng à l'AI Startup School de San Francisco : le travail de product management n'accélère pas au rythme de l'ingénierie, et certaines de ses équipes proposent d'inverser le ratio historique d'un PM pour quatre ingénieurs, jusqu'à deux PM par ingénieur. Précaution : ce sont des propos relayés par un tiers, sans interview formelle ni donnée publiée ; la formulation est largement reproduite, mais elle vaut comme signal de marché, pas comme mesure. Le signal reste cohérent avec ce que Ng écrit lui-même dans The Batch en juin 2026 : les ingénieurs endossent un rôle partiel de product management, preuve que le travail produit déborde de la capacité des PM en place.

Outiller la discovery : dual-track et continuous discovery

La discovery accélérée ne s'improvise pas ; ses cadres existent depuis plus de dix ans. Le dual-track agile (Jeff Patton et Cagan, autour de 2012) fait tourner deux pistes parallèles au sein d'une même équipe : la discovery valide quoi construire pendant que le delivery construit et livre. Teresa Torres a prolongé ce cadre en continuous discovery : des contacts utilisateurs hebdomadaires tenus par le trio PM, designer, ingénieur, et un opportunity solution tree qui relie chaque solution testée à une opportunité et à un outcome mesurable.

Les agents changent l'économie de ces cadres sans en changer la logique. Le prototype de discovery, autrefois arbitré contre le temps d'ingénierie, devient quasi gratuit ; la synthèse des entretiens utilisateurs, des tickets et des données d'usage s'automatise ; le PM augmenté peut enfin tenir la cadence d'apprentissage que Torres prescrivait. Nous détaillons ce nouveau profil, ses artefacts et ses evals dans PM augmenté : le Product Manager à l'ère des agents. La condition demeure inchangée : sans contact utilisateur régulier, la vélocité de prototypage tourne à vide.

Le piège : la feature factory sous stéroïdes

Le même effondrement des coûts nourrit le scénario inverse. La feature factory, terme que John Cutler a popularisé au milieu des années 2010, désigne l'organisation qui mesure son succès au nombre de features livrées (l'output) plutôt qu'à leur impact (l'outcome). L'IA la suralimente : quand livrer dix features coûte ce que coûtait une seule, une roadmap non validée par la discovery produit dix fois plus de déchets, plus vite. Cagan qualifiait déjà le modèle projet de « turbo-charged feature factory, capable of producing more bad products, faster, than ever before ». Le risque de 2026 a changé de visage : des équipes hyperactives qui livrent sans apprendre.

DORA 2025, le garde-fou

Le rapport DORA 2025 de Google Cloud (« State of AI-assisted Software Development », enquête auprès d'environ 5 000 professionnels) fournit le garde-fou chiffré. L'adoption de l'IA y atteint 90 % des répondants et corrèle positivement avec le débit de livraison et la performance produit, mais négativement avec la stabilité de livraison ; 30 % des répondants déclarent peu ou pas de confiance dans le code généré. Les auteurs résument : « AI is a mirror and a multiplier », l'IA amplifie les forces comme les dysfonctionnements. Deux réserves de lecture s'imposent : ce sont des corrélations issues d'une enquête déclarative, pas des causalités, et « amplificateur » est l'interprétation des auteurs. La leçon pour la discovery reste directe : accélérer l'amont sans stabiliser l'aval revient à découvrir plus vite ce qu'on ne saura pas livrer proprement.

Ce qui change pour le CPO et pour le DSI

Pour le CPO, le déplacement du goulot fait de la discovery le poste d'investissement prioritaire : cadence de contact utilisateur, capacité de prototypage, compétences d'évaluation des PM, et un arbitrage d'effectifs à instruire, le ratio PM/ingénieurs devenant une variable pilotable (le signal Ng donne une direction, à défaut d'une mesure). Un indicateur de vigilance simple : la part des features livrées qui ont traversé une discovery documentée. S'il baisse pendant que le débit monte, la feature factory tourne déjà.

Pour le DSI, d'abord, les métriques DORA de stabilité (change failure rate, retravail) deviennent la condition d'exploitation de la vitesse produit : sans elles, l'accélération amont se paie en instabilité aval. Ensuite, l'outillage de la discovery (prototypage par agents, environnements jetables, données de test, gouvernance des artefacts générés) entre dans son périmètre, car la frontière entre cycle produit et cycle logiciel devient poreuse, comme le montre notre analyse de l'articulation SDLC/PDLC. Le DSI qui traite la discovery comme un sujet exclusivement produit se prépare à exécuter très vite des specs jamais validées.

Questions fréquentes

La discovery sera-t-elle automatisée à son tour ?
Sa partie mécanique l'est déjà : collecte et synthèse des données d'usage, du feedback client, de l'analyse concurrentielle. Ng soutient que l'avantage de contexte reste humain : tant que l'équipe sait sur ses utilisateurs des choses que l'IA ignore, l'arbitrage de discovery ne se délègue pas. L'automatisation déplace le travail vers le jugement, elle ne le supprime pas.

Faut-il vraiment deux PM par ingénieur ?
Le chiffre est un propos relayé, pas une recommandation applicable telle quelle. La question utile pour une direction produit ou une DSI : votre capacité de discovery suit-elle votre nouvelle capacité de delivery ? Si vos agents livrent plus vite que vos équipes n'apprennent, le déséquilibre est déjà là, quel que soit le ratio affiché.

Le point de vue SFEIR

La compression du delivery est acquise ; nous la constatons chez nos clients. Le rendement de cette compression dépend désormais de l'amont : une usine logicielle 10x alimentée par une roadmap non validée produit du déchet, à l'échelle 10x. Nous recommandons de traiter la discovery comme un flux outillé (cadence de contact utilisateur, prototypage par agents, critères de sortie explicites vers le delivery) et de la gouverner avec les métriques DORA en garde-fou, débit et stabilité ensemble. C'est l'articulation que porte le schéma WEnvision « Concevoir et fabriquer à l'ère de l'agentique », et le premier diagnostic que nous posons en mission : compter, sur le dernier trimestre, les features livrées qui n'avaient jamais rencontré un utilisateur.

---

Sources

• svpg.com : Marty Cagan, « Build to Learn vs Build to Earn », avril 2026 (déplacement du goulot et de l'avantage concurrentiel vers la discovery).
• svpg.com : Marty Cagan, « Discovery vs. Delivery », 2015 (apprendre vite en discovery, livrer en confiance en delivery) ; du même auteur, la qualification du modèle projet en « turbo-charged feature factory ».
• Andrew Ng, propos tenus à l'AI Startup School (San Francisco), relayés par Lenny Rachitsky sur X, juillet 2025 (ratio PM/ingénieurs) ; et deeplearning.ai : lettre « Dear friends », The Batch n°359, 26 juin 2026 (avantage de contexte, convergence des rôles).
• Teresa Torres, Continuous Discovery Habits, 2021 (contacts utilisateurs hebdomadaires, opportunity solution tree, trio produit).
• John Cutler, écrits sur la feature factory (à partir du milieu des années 2010) : output vs outcome.
• dora.dev : DORA / Google Cloud, « State of AI-assisted Software Development 2025 » (adoption 90 %, confiance 30 %, corrélations débit/stabilité).

Note de fiabilité : les propos d'Andrew Ng sur le ratio PM/ingénieurs proviennent d'un post X de Lenny Rachitsky (juillet 2025) reprenant une intervention orale, sans interview formelle ni publication de Ng sur ce point ; ils sont à traiter comme un signal de marché, non comme une donnée. Les chiffres DORA 2025 sont des corrélations issues d'une enquête déclarative, non des causalités. Les citations anglaises sont traduites par nos soins lorsqu'elles ne sont pas reproduites telles quelles.