Produit & IA : nouvelles organisations, et un "Pourquoi" plus vital que jamais
Disclaimer : cet article a été rédigé sur base de nos retours d’expérience mission, et travaux de R&D. L'IA a contribué à la mise en forme, au challenge analytique et aux références. Les convictions, elles, sont 100% humaines — il nous semblait honnête de le préciser dans un article sur le sujet !
L'IA générative arrive dans les équipes Produit avec une promesse simple : aller plus vite. Le problème, c'est que cette accélération ne touche pas tout le monde de la même façon. En attaquant simultanément la Discovery et le Delivery, l'IA ne déplace pas seulement les outils — elle repose la question de la valeur de chaque rôle. Le tryptique classique PM/PO — Designer — Tech, pensé pour rester petit, complet et rapide, tient encore. Mais ses équilibres internes bougent. Cet article explore ce qui change vraiment, ce qui ne change pas, et les nouveaux profils et formes d'organisation qui émergent en réponse.[2][3]
Le modèle Agile standard : un statu quo solide, que l'IA commence à bousculer
Depuis des années, beaucoup d’équipes Produit ont tenu sur un équilibre relativement stable : un PM/PO pour cadrer et prioriser, un Designer pour concevoir, une équipe Tech pour construire. La taille exacte variait selon les contextes, mais l’idée restait la même : une équipe assez petite pour se parler, assez complète pour délivrer.[4][5]
Un modèle Agile dominant qui repose sur trois piliers, pensé pour rester petit, complet, rapide
Cet équilibre n’était pas qu’une affaire d’organigramme. Il répartissait aussi les zones de responsabilité : au Produit le sens et la stratégie, au Design la forme, à la Tech la faisabilité. L’IA ne supprime pas ce tryptique ; elle le rend moins stable, moins étanche, et parfois moins nécessaire dans sa forme actuelle.[6][2]
La Discovery va plus vite, ce n’est pas toujours une bonne nouvelle
En Discovery, l’IA est redoutablement efficace pour accélérer tout ce qui ressemble à de la compression informationnelle : synthèse d’entretiens, regroupement de verbatims, premières hypothèses de personas (“person[IA]”), structuration d’insights, exploration de pistes. Ce qu’une équipe faisait hier en plusieurs jours peut parfois sortir en quelques heures.[7][6]
Le problème, c’est que cette accélération peut produire une illusion de compréhension. Parce qu’un matériau est bien reformulé, bien structuré, bien présenté, on se persuade plus facilement qu’il est juste. L’IA aide à traiter le matériau de la Discovery ; elle ne garantit ni la qualité du cadrage, ni la pertinence du problème posé, ni la justesse de l’interprétation.[2][6]
Elle crée même un risque supplémentaire : l’ancrage prématuré. Quand on peut produire très tôt des artefacts crédibles — proto-personas, parcours, interfaces, flows — il devient plus difficile de revenir en arrière. On ne confond plus seulement vitesse et valeur ; on confond aussi mise en forme et apprentissage.[8][6]
Prototyper vite avec l'IA, oui - mais un proto crédible n'est pas un design validé
Le vrai piège des outils génératifs en conception n’est pas qu’ils soient mauvais. C’est qu’ils sont souvent suffisamment bons pour convaincre trop tôt. Un PM peut désormais bricoler un prototype en quelques heures avec un outil de génération, là où il fallait hier mobiliser plus de monde et plus de temps.[7][6]
C’est une excellente nouvelle pour explorer large. C’en est une beaucoup moins bonne si l’on en déduit que le Design devient une couche optionnelle. Les interfaces générées aujourd’hui par IA restent souvent génériques, et surtout elles disent peu de la qualité d’interaction réelle, de la cohérence d’ensemble, ou de la capacité à tenir dans le temps. Le PM devient plus facilement builder ; il ne devient pas designer par décret.[6][2]
Autrement dit : l’IA démocratise le prototype, pas le discernement ni le besoin d’expertise Design pour co-concevoir un produit impactant. Et dans un monde où tout le monde peut produire quelque chose qui “a l’air produit”, la valeur du regard critique augmente, elle ne baisse pas.[2][6]
Discovery : un sparring partner puissant, mais pas un remplaçant
Quand l'IA court-circuite la chaîne PM → PO → ticket → dev
Côté delivery, la rupture n’est pas seulement une histoire de génération de code. Elle tient surtout au fait que l’IA compresse la chaîne qui reliait jusqu’ici l’intention produit à l’exécution technique. L’espace entre “ce qu’on veut faire” et “quelque chose de testable existe” se réduit.[9][8]
C’est ce que montrent des approches émergentes comme BMAD (“Breakthrough Method for Agile AI-Driven Development”), qui structurent une logique de développement pilotée par spécifications et agents IA. Il faut rester prudent : BMAD n’est pas un standard installé du delivery Agile, mais plutôt un signal faible devenu suffisamment visible pour illustrer une tendance plus large. Cette tendance, elle, est bien réelle : une partie du travail de traduction, de découpage et de reformulation qui occupait le milieu de la chaîne devient automatisable.[8][9][6]
Le backlog ne disparaît pas. Mais il cesse peu à peu d’être le centre de gravité naturel du rôle Produit. Quand une machine peut transformer des verbatims en stories, enrichir des critères d’acceptance ou assister la validation, écrire des tickets ne suffit plus à définir une fonction.[6][8]
Le PO “machine à tickets” entre en sursis
C’est probablement la conséquence organisationnelle la plus nette. Dans beaucoup d’environnements, le PO a été progressivement rabattu vers un rôle d’opérateur du flux : écrire, clarifier, prioriser localement, coordonner le delivery, faire tourner le backlog. Or ce sont précisément les activités les plus exposées à l’automatisation.[2][6]
Il faut éviter le raccourci paresseux : non, tous les POs ne vont pas disparaître. Dans des organisations complexes, la coordination transverse, la gestion des dépendances et la cohérence du delivery ne s’évaporent pas parce qu’un assistant sait mieux rédiger des stories. Mais le PO delivery pur devient plus difficile à défendre comme rôle autonome et durable.[4][6]
La question n’est donc plus vraiment de savoir si ce rôle change. Elle est de savoir dans quelle direction il bifurque.[6][2]
L'IA ne remplace pas le PO — elle rend obsolète le PO "flux"
Le vrai sujet n’est pas l’automatisation, c’est la conviction
On peut faire produire beaucoup de choses à une IA. On ne peut pas lui faire porter une conviction. Elle peut synthétiser, comparer, projeter, prioriser à partir de critères donnés ; elle ne décide pas ce qui mérite d’exister.[2]
C’est là que beaucoup de discours sur l’IA ratent le sujet. Ils parlent du coût marginal de production qui baisse, mais beaucoup moins du coût politique et cognitif de la décision produit. Or un produit n’émerge pas seulement d’une optimisation. Il émerge d’un pari, d’une lecture du réel, d’un arbitrage, parfois d’un désaccord assumé.[10][2]
Dit plus brutalement : l’IA peut aider à fabriquer plus. Elle n’aide pas mécaniquement à vouloir mieux. Et si une organisation n’a déjà plus grand-chose à dire sur le “pourquoi”, elle utilisera surtout l’IA pour industrialiser sa confusion.[7][2]
De Waterfall à l'IA : plus la livraison s'accélère, plus la Vision produit devient critique
La gouvernance reste un sport de contact
L’autre fantasme commode consiste à croire que les organisations vont “absorber” l’IA comme un outil de plus. En réalité, les organisations absorbent surtout de nouveaux risques, de nouveaux contournements et de nouveaux arbitrages. Le Shadow AI en est le symptôme le plus parlant. En 2025, 27% des employés interrogés dans le rapport annuel 1Password reconnaissaient avoir utilisé des outils IA non approuvés par leur entreprise, et 37% disaient ne pas toujours respecter les politiques internes d’usage de l’IA.[11][1]
Ce chiffre dit quelque chose de simple : si l’expérience interne est médiocre, les usages réels partiront ailleurs. Il ne suffit donc pas de poser un cadre ; encore faut-il fournir des outils et des pratiques suffisamment utiles pour éviter que chacun reconstruise sa pile d’IA dans son coin.[12][1]
C’est ici que la gouvernance Produit retrouve des épaules. Pas une gouvernance de papier, faite de comités et de slides, mais une gouvernance capable d’articuler risque, usage, conformité, sécurité, expérience et vitesse. L’IA ne sait ni négocier avec un COMEX, ni rassurer un juridique, ni arbitrer des tensions entre Produit, Design, Tech et conformité. Ces “tâches ingrates” restent très humaines.[12][2]
La conviction ne se génère pas par prompt, la politique non plus
PM, PO : le retour du flou
À mesure que le milieu de chaîne s’automatise, les rôles Produit sont poussés vers les extrémités. Moins de gestion de flux, plus de recul stratégique d’un côté ; plus de capacité à prototyper et expérimenter directement de l’autre. C’est mécaniquement ce qui floute à nouveau la frontière entre PM et PO.[6][2]
Ce flou n’a rien de scandaleux. Dans beaucoup de startups, il n’a d’ailleurs jamais vraiment disparu. Ce qui change ici, c’est qu’il ne vient plus seulement d’une contrainte de taille ou de moyens ; il vient d’une reconfiguration de la chaîne de valeur elle-même.[2][6]
Pour autant, il faut résister à la tentation du “tout fusionner”. La distinction PM/PO créait aussi une tension cognitive utile, une divergence de perspectives, parfois une friction saine. À l’heure où l’IA tend déjà à homogénéiser les formulations et les raisonnements, trop simplifier les rôles pourrait produire des équipes plus fluides, mais aussi plus plates.[8][2]
De nouvelles trajectoires émergent pour les profils Produit
Pour sortir de l’alternative stérile entre “le PM stratège” et “le PO exécuteur”, on voit se dessiner de nouvelles trajectoires possibles.
La première est celle du Product Shaper. Ce n’est pas un titre de poste stabilisé, mais un archétype utile : un profil centré sur la vision, le cadrage, la conviction, les arbitrages, la narration stratégique, la lecture du marché et la gestion des parties prenantes. Plus le “comment” devient accessible, plus ce profil prend de la valeur.[2]
La seconde est celle du Product Builder. Là encore, il s’agit d’un archétype, pas d’une nomenclature RH. C’est le profil capable de transformer lui-même une intuition en prototype, d’exploiter un design system, de s’appuyer sur des outils génératifs et, dans certains contextes, de pousser très loin des boucles courtes de build-test-learn. Ce profil devient particulièrement puissant en early discovery ou sur des produits matures déjà bien outillés.[9][6]
Ces deux pôles ne sont pas exclusifs. Beaucoup de profils navigueront entre les deux selon les contextes. Mais ils ont le mérite de rendre visible une bifurcation : demain, la valeur Produit se jouera probablement moins dans la tuyauterie du milieu que dans la force du point de vue ou dans la capacité à builder vite sans perdre le sens.[8][2]
Product Shaper & Product Builder : deux pôles vers lesquels les profils Produit peuvent évoluer
Des équipes à géométrie variable, pas un nouveau dogme
Il serait tentant de conclure qu’il existe désormais une nouvelle taille idéale d’équipe, ou un nouveau modèle standard d’organisation Produit à l’ère de l’IA. Ce serait confortable. Ce serait surtout faux.[3][4]
Sur un produit naissant, l’IA peut réduire le coût du prototypage et augmenter le poids relatif de la Discovery et du Design. Sur un produit mature en growth, elle peut permettre à des profils Produit plus outillés d’expérimenter davantage. Sur du legacy ou des environnements très contraints, la densité technique, la dette et la complexité d’intégration restent déterminantes, avec ou sans IA.[3][6]
La bonne lecture n’est donc pas “l’IA impose une nouvelle recette”. La bonne lecture est plus inconfortable : elle oblige chaque organisation à regarder où se crée encore la valeur, où se cachent les frictions utiles, et quelles couches de son fonctionnement servent surtout à faire circuler l’information d’un silo à l’autre.[6][2]
De nouveaux modèles d’organisation possibles selon le contexte Produit
Ce que l’IA révèle, surtout, c’est la faiblesse de certains “Pourquoi”
L’IA n’annule pas le Produit. Elle le met au pied du mur. Plus le “comment” devient facile, plus les organisations qui avaient remplacé la pensée produit par de la gestion de flux se retrouvent exposées.[6][2]
C’est une mauvaise nouvelle pour les structures qui avaient transformé le Produit en machine de traduction entre métiers et backlog. C’est une bonne nouvelle pour celles qui savent encore produire de la conviction, de la confrontation au réel, du débat et de l’arbitrage.[2]
Le risque, au fond, n’est pas seulement l’automatisation. Le risque, c’est la standardisation molle : des équipes qui produisent plus vite, mais pensent moins ; des produits qui sortent plus vite, mais racontent moins ; des organisations qui gagnent en exécution ce qu’elles perdent en intention. À l’ère où le “comment produire” devient de plus en plus accessible, le pouvoir revient moins à ceux qui savent demander qu’à ceux qui savent encore décider pourquoi.[8][2]
Et maintenant, on fait quoi ?
"On veut de l'IA" n'est pas une stratégie. C'est un point de départ. Ce qui suit — quels rôles, quels outils, quelle gouvernance, pour quel contexte — dépend de paramètres qui vont de la culture d'entreprise à la maturité de chaque équipes. Il n'y a pas de recette miracle. Il y a un diagnostic. Et des choix à assumer.
Sources
1. https://www.infosecurity-magazine.com/news/shadow-ai-employees-use-unapproved/
2. https://www.forbes.com/sites/forrester/2025/03/26/are-ai-product-managers-the-role-of-the-future/
3. https://www.actuia.com/en/news/a-metr-study-reveals-that-ai-slows-down-experienced-developers/
4. https://www.scrum.org/forum/scrum-forum/69150/scrum-team-size
5. https://finance.yahoo.com/news/jeff-bezos-two-pizza-rule-140941215.html
6. https://docs.bmad-method.org
7. https://www.forbes.com/councils/forbesbusinesscouncil/2025/08/29/how-ai-is-revolutionizing-product-management-time-to-get-on-board/
8. https://dev.to/extinctsion/bmad-the-agile-framework-that-makes-ai-actually-predictable-5fe7
9. https://github.com/bmad-code-org/BMAD-METHOD
10. https://www.forbes.com/sites/forrester/2025/10/17/the-next-phase-of-ai-moving-beyond-hype-to-meaningful-application/
11. https://1password.com/blog/the-enterprise-ai-crisis-unsanctioned-tools-and-unenforced-policies
12. https://www.tomsguide.com/ai/nearly-two-in-five-workers-use-unauthorized-ai-tools-at-work-heres-why-companies-are-concerned