Pendant longtemps, une grande partie de l’organisation Product s’est construite autour d’une contrainte assez simple : fabriquer un produit numérique coûtait cher.
Une fonctionnalité mobilisait des développeurs, du design, parfois de la data, des tests, des environnements et des cycles de validation. Cette capacité limitée imposait mécaniquement des choix. On pouvait avoir cinquante idées dans le backlog ; seules quelques-unes passeraient réellement en production. L’IA commence à modifier cette économie.
Le mouvement est encore irrégulier, mais la direction devient difficile à ignorer. Le Stanford AI Index 2026 montre par exemple qu’entre février 2025 et début 2026, la performance sur Terminal-Bench 2.0, qui mesure la capacité d’agents à accomplir de bout en bout des tâches dans un terminal, est passée de 20 % à 77,3 %. Sur SWE-bench Verified, les meilleurs systèmes évalués dans des conditions comparables approchaient 77 % début 2026.
Cela ne signifie évidemment pas que le développement logiciel vient de devenir gratuit. Dans une expérimentation randomisée de METR sur des développeurs open source expérimentés, les participants autorisés à utiliser les outils IA disponibles début 2025 ont même mis en moyenne 19 % de temps supplémentaire sur des projets qu’ils connaissaient très bien. Le résultat porte sur un contexte précis, mais il rappelle une distinction utile : réussir un benchmark et améliorer un système de production existant ne sont pas la même chose.
Le rapport DORA 2025 donne une image intermédiaire. Sur près de 5 000 professionnels de la technologie, 90 % déclaraient utiliser l’IA au travail et plus de 80 % estimaient qu’elle améliorait leur productivité. DORA observait également une relation positive entre adoption de l’IA, débit de livraison et performance produit, tout en constatant toujours une relation négative avec la stabilité de livraison. L’IA accélère davantage les équipes capables d’absorber cette accélération ; dans les autres, elle rend les faiblesses du système plus visibles.
Résumons : le coût de production, d’analyse et d’expérimentation diminue sur une partie croissante du travail numérique.
Et lorsqu’une ressource devient moins rare, la valeur se déplace.
Le Product Manager était en partie organisé autour de la rareté de production
Il faut ici distinguer le métier de Product Manager de la fonction Product.
Le premier dépend fortement de l’entreprise. Une startup de quinze personnes, une scale-up SaaS et un éditeur enterprise de 15 000 salariés peuvent répartir les mêmes responsabilités entre des rôles très différents. Le débat sur le nombre de PM dont une organisation aura besoin avec l’IA nous entraînerait donc rapidement vers les spécificités de ladite organisation.
La fonction Product est plus stable. Quelqu’un doit décider quel problème mérite une allocation de ressources, pour quel marché, avec quelle proposition de valeur, sous quelles contraintes économiques et avec quelles chances de créer un avantage durable.
Une partie importante du travail historiquement confié au PM venait néanmoins de la difficulté à transformer ces décisions en produit : collecter et synthétiser l’information, documenter, aligner plusieurs fonctions, produire des spécifications, préparer des analyses, transmettre du contexte et maintenir suffisamment de cohérence pour qu’une organisation spécialisée puisse fabriquer quelque chose. Et l’IA commence précisément à réduire ces coûts.
L’expérience menée auprès de 776 professionnels de Procter & Gamble est intéressante parce qu’elle ne portait pas simplement sur du code ou de la rédaction. Des professionnels commerciaux et R&D devaient travailler sur de vrais problèmes de développement de nouveaux produits. Une personne travaillant seule avec une IA atteignait un niveau de performance comparable à celui d’une équipe humaine de deux personnes sans IA. L’outil réduisait également certaines frontières entre expertises : les profils commerciaux amélioraient leurs réponses techniques et les profils R&D leurs réponses commerciales.
L’IA ne se contente donc déjà plus d’accélérer l’exécution. Elle participe à la synthèse, à l’analyse, à l’idéation et à la fluidification entre les domaines de connaissance.
Cela fragilise une conception du Product Manager comme interface humaine entre des spécialistes. En revanche, cela renforce une autre dimension du rôle : la responsabilité du résultat économique produit par ces capacités.
Du Product Manager au Business Owner
J’emploie ici « Business Owner » au sens large : une personne qui ne se contente pas de piloter ce qui doit être construit, mais assume la cohérence entre le problème choisi, la valeur créée pour le client et la manière dont l’entreprise transforme cette valeur en résultat économique.
Le mouvement dont il est question ici n’est d’ailleurs pas né avec l’IA. Il était déjà visible dans les organisations Product qui cherchaient à passer d’une logique d’outputs à une logique d’outcomes. McKinsey décrivait ainsi les Product Managers des organisations matures comme responsables des résultats business, de l’idée jusqu’au lancement puis au passage à l’échelle. Son étude sur les product operating models relie par ailleurs la maturité de ces modèles à des résultats économiques et insiste sur la responsabilité des équipes vis-à-vis des outcomes plutôt que de la seule livraison. Le Silicon Valley Product Group résume le même mouvement comme le passage des outputs aux outcomes.
Quand produire un prototype, analyser cent entretiens, générer plusieurs propositions ou explorer un marché demande moins de travail, la valeur du PM vient moins de sa capacité à organiser cette production. Elle vient davantage de sa capacité à répondre à une question plus inconfortable : où l’entreprise doit-elle placer ses ressources pour créer de la valeur qu’elle saura ensuite capturer ?
Cette question relève davantage du business ownership, de sa dimension tactique voire stratégique.
L’abondance de possibilités crée un problème d’allocation
Supposons qu’une équipe puisse désormais produire en deux jours un prototype qui exigeait en temps normal deux semaines. Elle peut tester cinq hypothèses là où elle n’en testait qu’une.
C’est une amélioration. Lorsqu’une décision est bon marché, réversible et rapidement observable, discuter pendant trois semaines de la meilleure option peut devenir une manière assez coûteuse d’éviter de trancher.
Mais cinq expériences génèrent aussi cinq résultats à interpréter, cinq trajectoires possibles et potentiellement cinq raisons de continuer à investir. La capacité de produire des options peut augmenter plus rapidement que l’attention disponible pour les comprendre.
La rareté se déplace alors vers l’allocation : où concentrer l’attention de l’entreprise, son capital, sa distribution et la complexité qu’elle accepte d’introduire ?
La recherche sur le problem framing fournit un socle intéressant à cette distinction. Une revue publiée en 2025 dans le Journal of Product Innovation Management insiste sur la différence entre résoudre correctement un problème et identifier le bon problème à résoudre. Le cadrage ne constitue pas une formalité précédant la solution : il détermine en partie quelles solutions seront ensuite considérées comme pertinentes.
L’IA peut contribuer à ce cadrage. Elle peut produire des hypothèses, synthétiser des interviews, analyser la concurrence, chercher des contradictions ou proposer plusieurs segmentations. Elle augmente alors simultanément notre capacité à répondre et le nombre de réponses disponibles.
Plus il devient facile de construire, plus il devient difficile de savoir ce qui mérite d’être construit.
Le mécanisme derrière le paradoxe est simple : lorsque le coût de réalisation diminue, davantage d’idées franchissent le seuil de faisabilité. La contrainte passe progressivement de « pouvons-nous le faire ? » à « est-ce l’un des meilleurs endroits où engager l’entreprise ? ».
C’est une question de Business Owner.
Le jugement Product devient un jugement économique
Le jugement consiste ici à organiser une décision sous information incomplète en reliant plusieurs niveaux qui sont souvent traités séparément.
Un client demande une fonctionnalité. Il faut comprendre ce qu’il cherche à accomplir, pourquoi le produit actuel l’en empêche, combien d’autres clients rencontrent la même contrainte et s’ils modifieraient réellement leur comportement si cette contrainte disparaissait .
Même la volonté déclarée de payer doit être interprétée avec prudence. Une méta-analyse de 77 études sur la willingness-to-pay, représentant plus de 45 000 observations entre mesures hypothétiques et réelles, trouve un biais hypothétique moyen de 21 %. Coté client : dire qu’un produit vaut quelque chose et sortir effectivement son portefeuille restent deux comportements différents.
Le Business Owner doit donc aller plus loin que la compréhension du besoin. Il doit relier le besoin à une production de valeur, un écosystème, un marché.
Quel segment suffisamment important rencontre ce problème ? À quel point est-il douloureux ? Qui paie pour le résoudre ? Comment le produit sera-t-il découvert puis adopté ? Quel prix permet de capturer une partie de la valeur créée ? Que se passe-t-il sur le revenu existant si le nouveau produit fonctionne vraiment ?
Le cas de Fin chez Intercom montre assez bien cette extension de responsabilité. Intercom explique avoir envisagé les modèles SaaS habituels avant d’écarter une tarification classique par siège pour son agent. Si Fin permet aux entreprises d’avoir besoin de moins d’agents humains, sa réussite peut précisément réduire le nombre de sièges facturables. L’entreprise a donc choisi de rapprocher son revenu du résultat produit en facturant les résolutions. Intercom explique ce raisonnement dans son retour d’expérience sur le pricing de Fin.
Impossible de séparer proprement ici Product et Business. La fonctionnalité modifie le pricing ; le pricing influence l’adoption ; l’adoption cannibalise potentiellement une métrique historique ; et le modèle économique conditionne à son tour les comportements que l’équipe cherchera à optimiser.
Le Product Manager qui se rapproche du Business Owner ne devient donc pas commercial ou financier à la place d’être Product. Il élargit son unité de raisonnement. Son produit n’est pas seulement l’expérience utilisateur. C’est aussi le système économique autour de cette expérience.
Comprendre l’achat fait partie du produit
Cette extension devient particulièrement visible en B2B enterprise.
Parler de « besoin utilisateur » y devient vite insuffisant. Celui qui utilise le produit, celui qui finance son achat, celui qui prend le risque de le déployer et celui qui peut bloquer le contrat appartiennent parfois à quatre fonctions différentes.
Une enquête Gartner auprès de 632 acheteurs B2B décrit des groupes d’achat allant de cinq à seize (!) personnes et pouvant couvrir jusqu’à quatre fonctions. 74 % des équipes interrogées présentaient ce que Gartner qualifie de conflits malsains pendant le processus de décision ; celles qui parvenaient à un consensus déclaraient 2,5 fois plus souvent avoir conclu une transaction de haute qualité.
Dans ce contexte, concevoir le bon produit sans comprendre le système de décision revient à optimiser seulement une partie du problème.
Le Business Owner doit connaître le workflow de l’utilisateur, mais aussi les conditions de l’achat : sponsor, budget, sécurité, conformité, procurement, intégration et mécanismes permettant à plusieurs décideurs de parvenir à un accord.
La distribution et le buying system cessent ainsi d’être des sujets que le Product « transmettra ensuite au go-to-market ». Ils participent à la définition même de l’opportunité.
Construire davantage peut surtout construire davantage de complexité
La diminution du coût de fabrication crée une tentation assez naturelle : puisque cette fonctionnalité ne coûte désormais que quelques jours, pourquoi ne pas la faire ?
Parce que son coût ne s’arrête pas au développement.
Une fonctionnalité acquiert des utilisateurs, une interface, des cas limites, de la documentation, du support, des dépendances, des attentes et parfois un commercial qui doit la vendre dans un contrat de trois ans. Ceci alors que techniquement, elle était bon marché.
Les travaux sur la feature fatigue publiés dans le Journal of Marketing Research datent de 2005, mais leur mécanisme devient particulièrement pertinent lorsque produire accélère. Les expériences montrent que les consommateurs accordent davantage de poids aux capacités d’un produit avant usage, puis davantage de poids à son utilisabilité après l’achat. Ajouter des fonctionnalités peut donc augmenter l’attractivité initiale tout en dégradant l’expérience et, dans le modèle étudié, la valeur vie client. L’IA ne crée pas cette tendance. Elle retire simplement une partie de la contrainte qui empêchait jusque-là de lui céder.
C’est ici qu’intervient la capacité négative : savoir ce qu’il ne faut pas construire.
Pour un Business Owner, le refus n’est pas une position esthétique en faveur des produits minimalistes. C’est un arbitrage économique. Une opportunité techniquement réalisable peut rester mauvaise si son problème est faible, sa disposition à payer insuffisante, son canal d’acquisition improbable ou la complexité qu’elle ajoute supérieure à la valeur qu’elle peut créer.
Le rôle se déplace de la bonne exécution d’une décision vers la qualité de la décision elle-même.
Renaud Joly
Même le jugement devient augmentable
Il serait pourtant simpliste de faire de cette fonction de Business Owner un dernier refuge exclusivement humain.
L’expérience de P&G montre déjà que l’IA améliore des tâches d’innovation et d’intégration entre expertises. Elle peut aussi accélérer l’analyse de marché, la segmentation, la synthèse qualitative, l’exploration d’un pricing ou la génération d’options stratégiques.
Un Product Manager dont la valeur dépend principalement de sa capacité à fabriquer manuellement un benchmark concurrentiel ou à lire lui-même 150 verbatims défend une rareté assez fragile.
L’enjeu devient la conception du système de décision dans lequel ces analyses interviennent.
- Quelles données utilisons-nous ?
- A quels signaux comportementaux accordons-nous plus de poids que les déclarations ?
- Quelles hypothèses cherchons-nous à (in)valider ?
- Quel risque économique acceptons-nous ?
- Quel niveau de preuve exigeons-nous avant de doubler l’investissement ?
L’IA peut faire une partie croissante du travail d’analyse. Elle ne supprime pas pour autant la nécessité d’allouer les ressources entre plusieurs options incompatibles. Quelqu’un doit engager l’entreprise.
Tout tester n’est pas une stratégie
Une objection demeure : si expérimenter devient suffisamment bon marché, pourquoi décider avant de construire ? Testons plusieurs solutions et regardons ce qui fonctionne.
Une décision peu coûteuse et réversible mérite probablement moins de gouvernance qu’aujourd’hui. Si modifier une interface prend quelques heures et que son effet peut être mesuré rapidement, un long processus de priorisation devient difficile à justifier.
La logique change lorsque l’expérience crée elle-même des coûts durables. Tester une landing page n’engage pas la même chose que créer un nouveau tier de pricing, ouvrir une API publique, lancer une nouvelle gamme, modifier un positionnement ou promettre une capacité à un grand compte. La baisse du coût de fabrication ne rend pas toutes les décisions faibles en coût.
Surtout, une expérimentation ne répond jamais seule à la question suivante : que faisons-nous maintenant de ce que nous venons d’apprendre ?
On ne peut pas avoir vingt priorités numéro un.
Quatre questions avant d’augmenter l’investissement
Répondre à cette nouvelle abondance par un framework de quatorze critères, trois scores pondérés et un comité supplémentaire serait une manière assez élégante de reconstruire la friction que l’IA vient de supprimer.
Un Business Owner peut commencer beaucoup plus simplement :
- Le problème est-il réel ? Quel comportement, coût ou contrainte observable existe derrière la demande exprimée ? Si le seul signal est que des utilisateurs trouvent l’idée intéressante, nous savons surtout qu’ils sont polis.
- Avons-nous une raison crédible de prendre cette direction ? Positionnement, distribution, expertise particulière, accès au marché, données, intégration dans un workflow ou compréhension du système d’achat : pourquoi cette opportunité serait-elle plus intéressante pour nous que pour n’importe quel concurrent capable d’utiliser les mêmes modèles ?
- La valeur peut-elle devenir économique ? Qui paie, pour quoi et selon quelle métrique ? Quelle willingness-to-pay peut être observée ? Quel sera le coût de service ? Que devient notre revenu existant si cette proposition fonctionne vraiment ?
- Que décidons-nous réellement en disant oui ? Au coût de fabrication s’ajoutent la complexité, le support, les dépendances et le coût d’opportunité. Quelle autre possibilité recevra moins d’attention parce que nous avons choisi celle-ci ?
Parfois il faut parler à des clients. Parfois tester un prix, un P&L. Parfois construire un prototype. Parfois vérifier un canal de distribution.
Et parfois arrêter là. Le rôle du filtre est de déterminer la prochaine quantité raisonnable d’investissement.
Quand la pénurie ne dit plus non à notre place
La baisse du coût de production ne rend donc pas la fonction Product moins importante. Elle expose une partie de son rôle qui pouvait rester masquée lorsque la rareté technique imposait naturellement la discipline. Lorsque l’équipe ne peut produire que trois initiatives, la contrainte en élimine des dizaines à sa place.
Lorsqu’elle peut en produire quinze, l’entreprise doit protéger son attention, son positionnement, son modèle économique et les quelques paris auxquels elle veut réellement donner une chance de lui procurer un avantage durable.
C’est dans ce sens que le Product se rapproche du Business Owner.
Sa responsabilité se déplace de la bonne transformation d’une intention en produit vers la bonne allocation des capacités de l’entreprise. Il ne s’agit plus seulement de demander ce que l’on peut livrer au prochain trimestre, ni même uniquement de savoir ce dont l’utilisateur a besoin. Il faut comprendre quel problème vaut un investissement, comment sa résolution deviendra adoption puis valeur économique (qui plus est dans un écosystème en mouvement), et pourquoi cette valeur pourra être capturée durablement par cette entreprise plutôt que par un concurrent.
L’IA peut augmenter presque chacune de ces capacités. Elle peut produire, chercher, synthétiser, simuler et proposer.