Product Owner : l’IA va-t-elle supprimer le rôle ? Ce que Marty Cagan voit venir (et ce qu’il oublie)

Le 6 novembre 2026, Marty Cagan (Silicon Valley Product Group, auteur d’Inspired et d’Empowered) a publié la version écrite de sa keynote au Product Leader Summit : AI and the Future of the Product Role. Une phrase y fait l’effet d’une grenade dans la communauté agile : avec l’IA qui automatise et accélère le travail d’ingénierie, et une grande partie du processus de sprint devenue superflue, le rôle de product owner est déjà en train d’être supprimé. Plus loin, il enfonce le clou : selon lui, le rôle de product owner dédié « va se résoudre de lui-même ».

Stefan Wolpers en a fait l’un des titres de sa newsletter Food for Agile Thought #569 (« End of Product Owners »), lue par plus de 35 000 praticiens. Le sujet est partout. Et comme souvent, il est mal compris : beaucoup lisent « Scrum est mort » ou « l’IA remplace les PO ». Ce n’est pas ce que dit Cagan. Ce qu’il décrit est plus dérangeant, parce que ça concerne la façon dont votre organisation fabrique ses produits, pas un intitulé de poste.

Si vous êtes PO, scrum master, manager d’une équipe de développement ou dirigeant qui finance une transformation agile, cet article vous concerne directement.

Le vrai sujet : trois rôles différents cachés derrière un seul mot

L’apport principal de Cagan n’est pas la prédiction, c’est la clarification. Derrière les mots « product manager » et « product owner », il distingue trois rôles qui n’ont presque rien en commun. Et ce qui les sépare, ce n’est pas la méthode agile utilisée, c’est le modèle opérationnel de l’entreprise.

Dans le modèle « projet »

La roadmap liste des fonctionnalités et des projets, chacun étant une solution espérée à un problème rarement explicité. On finance, on staffe, et le succès se mesure au fait d’avoir livré. Deux rôles y cohabitent souvent :

• Le feature team product manager : il coordonne les ressources pour concevoir, construire, tester et livrer la solution déjà décidée. Concrètement, c’est de la gestion de projet. Il écrit de la doc un jour, fait de la recette le lendemain.
• Le product owner au sens où Cagan l’entend : un rôle dans le processus de delivery (Scrum, Kanban, SAFe), qui gère le backlog de livraison et se coordonne avec les développeurs avant, pendant et après les sprints.

Dans le modèle « produit »

La stratégie identifie les problèmes les plus importants à résoudre, et les leaders confient à des équipes un problème associé à un résultat attendu (un outcome). Le succès, c’est l’atteinte de ce résultat, pas la livraison. Le rôle clé y est l’empowered team product manager, responsable de découvrir une solution qui résout réellement le problème.

Point crucial souvent oublié : Cagan précise en note que, quand les équipes utilisent un processus agile, le product manager couvre normalement les responsabilités de product owner. Ce qu’il annonce comme condamné, c’est le product owner dédié, celui qui existe à côté (ou à la place) d’un vrai responsable produit.

Pourquoi l’IA accélère la fin du product owner « scribe de backlog »

L’argument est mécanique. Les entreprises cherchent à automatiser la delivery avec de l’IA agentique, jusqu’à viser une véritable « usine logicielle » où des agents prennent en charge ce que faisaient développeurs, testeurs, release managers et chefs de projet, sous la supervision des ingénieurs. Or la delivery est faite de workflows bien définis. Et tout ce qui est un workflow bien défini est automatisable.

Regardez honnêtement la semaine type d’un PO dans beaucoup de grandes entreprises IT :

• découper des epics en user stories et rédiger les critères d’acceptation ;
• tenir le backlog à jour et réordonner les priorités demandées par les parties prenantes ;
• préparer le refinement, répondre aux questions de l’équipe de développement sur une fonctionnalité ;
• produire le reporting d’avancement pour le comité de pilotage.

Un agent connecté à Jira fait déjà une bonne partie de ce travail de mise en forme. Stefan Wolpers propose d’ailleurs des exercices pour construire des agents qui préparent le refinement ou génèrent les rapports pour les parties prenantes. Si votre valeur ajoutée tient dans cette liste, la question n’est pas de savoir si votre poste va évoluer, mais quand.

Les fonctionnalités se génèrent de plus en plus vite. Mais construire un produit qui compte, c’est autre chose. Ce qui ne s’automatise pas, selon Cagan, c’est la découverte produit : elle relève moins du workflow que du jugement et du « product sense ». Tester une idée sur des utilisateurs (valeur, utilisabilité), auprès des parties prenantes (viabilité) et avec les ingénieurs (faisabilité), ça reste un métier.

Ce que Cagan oublie (ou préfère ne pas dire)

Sur le fond, difficile de lui donner tort. Mais son analyse appelle trois nuances que les managers français devraient garder en tête avant de supprimer des postes.

1. Le product owner du Scrum Guide n’a jamais été un scribe

Dans Scrum, le product owner (souvent abrégé PO) est responsable de maximiser la valeur du produit issue du travail de l’équipe. Il porte l’objectif produit, arbitre, dit non. Sur le papier, c’est bien plus proche de l’empowered product manager de Cagan que du gestionnaire de tickets. Ce qui meurt, ce n’est donc pas le rôle de product owner tel que pensé par Scrum, c’est sa version dégradée : le « proxy PO » sans pouvoir de décision, nommé pour faire tourner la machine pendant que les vraies décisions se prennent ailleurs.

2. Le problème n’est pas le rôle, c’est le modèle projet

Cagan le reconnaît lui-même : beaucoup d’entreprises, sans doute la majorité, n’abandonneront jamais le modèle projet, à cause de leur besoin de prévisibilité. Résultat probable : on va retirer les product owners, garder la roadmap de fonctionnalités imposée par le haut, et demander aux ingénieurs de piloter des agents pour livrer plus vite des choses dont personne n’a vérifié l’utilité. Ce n’est pas une transformation, c’est de l’accélération de gaspillage.

3. Livrer plus vite n’a jamais été le problème des utilisateurs

Dans la même édition de Food for Agile Thought, Pavel Samsonov rappelle qu’on noie déjà les utilisateurs sous des mises à jour et des tableaux de bord que personne n’a demandés, et que des résumés générés par l’IA ne les sauveront pas : l’attention reste rare. Si l’IA supprime le goulot de la livraison, il faut quelqu’un pour dire non. C’est exactement le travail que beaucoup de PO n’ont jamais eu le droit de faire.

« Les product managers qui ont toujours vu leur rôle comme « mon job principal, c’est d’exécuter » ont beaucoup plus de mal à se faire embaucher dans les meilleures entreprises que ceux qui le voient comme « mon job principal, c’est de faire réussir le produit ». »
Shreyas Doshi, cité par Marty Cagan (traduction Corporate Mavericks)

Product owner ou product manager : quelle différence, concrètement ?

C’est la question que tout le monde se pose, et la réponse dépend de votre organisation plus que des définitions. Un test simple : regardez qui décide du problème à résoudre et comment on mesure le succès.

• Si un comité vous transmet une liste de fonctionnalités et que votre succès se mesure à leur livraison dans les délais, vous faites de la gestion de projet, quel que soit le titre sur votre badge.
• Si on vous confie un problème client avec un résultat business à atteindre, et que vous pouvez renoncer à une fonctionnalité qui ne sert à rien, vous faites du produit.

Le rôle du product owner, dans beaucoup d’organisations, c’est la responsabilité sans l’autorité. Un product manager « empowered » a les deux. Le titre importe peu : c’est ce glissement de la livraison vers la découverte qui va séparer ceux qui progressent de ceux qui seront remplacés par un agent.

Product owner en 2026 : 5 leviers pour rester indispensable

Cagan dit avoir encouragé les PO à monter en compétences « aussi vite que possible ». Voici ce que ça veut dire concrètement, sans attendre que l’entreprise change de modèle.

1. Faire l’inventaire honnête de votre semaine

Listez vos tâches et classez-les : workflow répétable (rédaction de stories, reporting, mise à jour du backlog) ou jugement (arbitrer, dire non, comprendre un client). Déléguez la première colonne à l’IA, volontairement, avant qu’on le fasse à votre place. Le temps libéré doit aller vers la seconde.

2. Passer de la livraison à la découverte

Parlez à des utilisateurs chaque semaine. Prototypez pour apprendre (« build to learn ») avant de construire pour livrer (« build to earn »). Avec l’IA, un prototype coûte quelques heures : il n’y a plus d’excuse pour développer une fonctionnalité sans l’avoir testée.

3. Réclamer des résultats, pas des listes

À chaque demande d’une partie prenante, posez la question : quel problème, quel indicateur doit bouger ? Transformer une demande de fonctionnalité en objectif mesurable est la compétence la plus rare et la plus protectrice du métier.

4. Muscler le business et le domaine

Selon Cagan, le product manager doit connaître en profondeur le marché, le client et les dimensions de la viabilité : ventes, marketing, finance, juridique, conformité, sécurité. Un développeur assisté par l’IA couvre la faisabilité. Personne ne couvre la valeur et la viabilité si vous ne le faites pas.

5. Devenir le gardien des évaluations IA

Pour les produits probabilistes (ceux qui embarquent de l’IA), Cagan place le product manager au centre du processus d’évaluation : décider quand une réponse est acceptable ou non. C’est un terrain neuf, où le PO qui connaît finement les usages a une vraie longueur d’avance.

Faut-il encore devenir product owner ?

Oui, à condition de viser le bon métier. Pour réussir, un product owner doit désormais savoir parler de résultats autant que de livraison. La certification Scrum ou SAFe reste une porte d’entrée utile pour comprendre le cadre, mais elle ne fera plus la différence sur un CV. Ce qui fera la différence : des preuves que vous savez découvrir un problème, tester une solution et faire bouger un indicateur. Pour devenir product owner aujourd’hui, investissez autant dans les entretiens utilisateurs, la lecture de données et la compréhension d’un compte de résultat que dans la maîtrise de Jira.

Côté marché, les offres d’emploi intitulées « product owner » ne vont pas disparaître du jour au lendemain, notamment dans les grands groupes en modèle projet. Mais l’écart de salaire et de trajectoire entre le PO « exécutant » et le responsable produit orienté résultat va se creuser. C’est précisément le message de Doshi.

Questions fréquentes sur le product owner et l’IA