J'ai publié une phrase simple sur LinkedIn : le poste de Product Owner me semblait déjà être une aberration organisationnelle, et à l'ère de l'IA il devient franchement difficile à défendre.
66 000 impressions et une quarantaine de commentaires plus tard, je constate deux choses. La première, c'est que j'ai touché un nerf. La seconde, c'est que la moitié des désaccords portent sur un malentendu que je veux lever tout de suite.
Je ne cherchais pas la polémique — je me fiche du nombre de vues. Et surtout : j'avais exactement cette position avant l'IA. La mention de l'IA a cristallisé les réactions, mais elle n'est pas le fondement de mon argument. Elle en est l'accélérateur.
Le post d'origine et l'intégralité des échanges sont ici. Cet article est ma réponse construite à ceux qui ont pris le temps de me contredire.
Ce que je ne dis pas
Je ne dis pas que l'IA va remplacer les Product Owners.
On m'a répondu, à juste titre, qu'une IA ne comprend pas un marché, n'anticipe pas un besoin, ne défend pas une vision devant un sponsor, ne tient pas un NO GO et ne rend pas de comptes six mois plus tard. Je suis d'accord. Complètement.
Je ne dis pas non plus que les gens qui ont « PO » sur leur carte de visite ne servent à rien. J'en connais d'excellents. C'est le découpage que je critique, pas les personnes qui le subissent.
Ce que je dis : le produit, c'est ce qui est en production
Une spécification décrit une intention. Un PRD décrit un objectif, des règles attendues, des scénarios. Une maquette décrit une interface souhaitée.
Mais entre cette intention et la production, il se passe toujours quelque chose. J'ai développé ce point dans La question produit doit partir du code source :
Des compromis sont faits. Des détails sont ajustés. Des cas limites apparaissent. Des décisions sont prises pendant le développement. Des contraintes techniques obligent à modifier légèrement le comportement. Des échanges ont lieu dans une pull request ou une merge request. Des arbitrages ne remontent pas toujours dans la documentation initiale.
[...] la spec n'est pas la vérité du produit. Elle est une approximation utile à un moment donné. La vérité, c'est ce qui tourne.
Ce n'est pas grave. C'est même normal : un produit vivant ne se construit pas comme un document figé.
Mais cela a une conséquence qu'on refuse de regarder en face. Si la vérité du produit se fabrique entre l'intention et la production, alors la personne qui reste en amont de la production ne travaille pas sur le produit. Elle travaille sur une intention. Elle ne voit jamais les arbitrages qui, en réalité, définissent ce que le client va vivre.
Le client ne voit pas ta discovery. Il ne voit pas ton framework de priorisation, ni ta belle roadmap. Il voit ce qui sort en production. Et la qualité d'un produit tient dans une accumulation de petits détails — ces détails-là, tu ne les vois que si tu suis jusqu'au bout.
D'où ma conviction : la personne qui pense le produit doit être celle qui le livre et qui l'accompagne après la livraison. Une seule et même personne. Ownership complet.
L'aberration n'est pas le contenu du poste, c'est ce que son existence révèle
Ce qui rend le poste de PO indéfendable à mes yeux, ce n'est donc pas ce qu'un PO fait au quotidien. C'est le fait qu'une organisation ait jugé utile de séparer la partie « noble » — penser le produit — de la partie qu'on délègue : suivre le backlog, tenir la relation avec les développeurs, surveiller la mise en production.
C'est du taylorisme appliqué au produit.
Et on a déjà fait ce film.
Il y a eu une époque avec des analystes d'un côté et des programmeurs de l'autre. Les uns pensaient, les autres produisaient du code au kilomètre. Ce découpage a disparu. Aujourd'hui il y a des développeurs, qui prennent un problème de bout en bout : l'architecture, le code, la sécurité, la livraison, le suivi. Il y a même de moins en moins d'architectes séparés du reste de l'équipe.
Personne ne regrette les analystes-programmeurs. Personne ne défend l'idée qu'on produisait un meilleur logiciel quand la réflexion et l'exécution vivaient dans deux têtes différentes.
Je ne vois aucune raison pour que le produit échappe à ce mouvement.
Je m'impose la règle que j'impose aux développeurs
Il y a un argument que je dois affronter avant tous les autres, parce qu'il me concerne directement.
J'ai écrit dans La qualité appartient à ceux qui livrent une règle que je considère non négociable côté développement :
La règle la plus saine est simple : celui qui crée le bug le corrige.
Pas parce qu'il faut punir. Pas parce qu'il faut humilier. Parce que la responsabilité de correction doit rester attachée à la responsabilité de production.
Et plus loin :
Dans la plupart des cas, si un développeur a créé le défaut, il doit le corriger. Même s'il est passé à un sujet important. Même si cela perturbe le planning. Même si cela ralentit la feature suivante.
La qualité consomme de la capacité. La cacher ne la rend pas gratuite.
Je serais assez malvenu d'exiger ça des développeurs et de m'en exonérer moi-même.
Un PM qui conçoit, puis confie à un PO le soin de porter la chose jusqu'en production, fait exactement ce que je reproche au développeur qui livre et passe au sujet suivant. Il externalise le coût de ce qu'il a produit. Il ne voit jamais où sa compréhension était insuffisante, où la formulation était ambiguë, où l'arbitrage était bancal. La boucle ne se ferme pas.
Or c'est cette boucle qui crée de la qualité.
La qualité ne se délègue pas après coup. Ni côté code, ni côté produit.
« Vous décrivez un mauvais PO »
C'est l'objection la plus fréquente, et elle est venue de plusieurs personnes différentes : le rôle d'un PO, c'est de comprendre le besoin, de définir les fonctionnalités du point de vue client, de porter une vision, d'arbitrer des priorités contradictoires, de maximiser la valeur.
Ma réponse est constante : ça, ça s'appelle un Product Manager. Vous venez de me décrire mon métier.
Si votre définition du PO recouvre ma définition du PM, alors nous sommes d'accord sur le fond et nous nous disputons sur un mot.
Le problème, c'est que ce n'est pas ce que le marché recrute. On m'a reproché de décrire un PO qui n'existe pas. Ouvrez les offres d'emploi : alimenter le backlog, rédiger les user stories, faire l'interface entre le métier et les devs, animer les cérémonies. Ce PO-là, il est partout. Il est même majoritaire.
Et là, il y a un point que personne n'a relevé dans les commentaires.
On ne peut pas fonder un métier sur un artefact jetable
L'argument le plus souvent avancé pour défendre le rôle est celui du backlog : le PO maximise la valeur du produit en tenant, en affinant et en priorisant le backlog.
Sauf que j'ai déjà démoli cette base ailleurs, sans parler d'IA une seule fois. Dans Le backlog n'est pas un dépotoir :
Un item de backlog sert jusqu'à la livraison. Après, il perd une grande partie de sa valeur.
Les tickets se désynchronisent. Les specs se désynchronisent. Les arbitrages changent pendant la réalisation. Le comportement final en production diffère souvent de ce qui avait été écrit au départ.
[...] Le backlog n'est pas une source de vérité. C'est un support temporaire de coordination.
Et surtout, ce n'est plus l'endroit où l'on pense le produit :
Les outils comme Jira, Notion ou leurs équivalents restent souvent des outils de cartes. Des traitements de texte améliorés. [...] Ils peuvent être utiles pour coordonner l'action. Mais ils sont très faibles pour construire une réflexion produit.
[...] Le ticket n'est plus l'endroit où l'on pense. C'est l'endroit où l'on pousse le résultat d'une pensée déjà structurée.
Alors si le backlog n'est ni la mémoire du produit, ni le cerveau du produit, ni un actif durable — comment fonde-t-on un métier sur sa tenue ?
On peut fonder une fonction sur un artefact consommable. Pas un métier.
Notez que cet argument n'a rien à voir avec l'IA. Il était déjà vrai en 2020.
Le nom compte, et voilà pourquoi
On m'a objecté que PO est un rôle dans un cadre méthodologique, quand PM est un métier. Que l'important, c'est ce qu'on fait, pas comment on s'appelle.
Sur le principe, je suis d'accord. J'ai fait du project management à une époque sans savoir que ça portait un nom. Ce qu'on fait compte plus que l'étiquette.
Mais le titre fabrique le mandat.
Dans les faits, les PO ont moins d'ownership et moins d'autonomie. Quand tu es PM, tu es owner de ton scope, point. Plusieurs personnes l'ont formulé mieux que moi dans les commentaires : le titre de PO a souvent servi à cloisonner la responsabilité produit sans donner le mandat de décision.
Un PO sans mandat d'arbitrage, ce n'est pas un rôle. C'est une position inconfortable.
Et je reconnais là un mécanisme que j'ai déjà décrit dans Pourquoi les organisations préfèrent les décisions molles :
Une décision claire rend la responsabilité visible. Elle expose celui ou celle qui arbitre. Elle donne prise à la critique. Elle oblige à assumer que certaines demandes n'ont pas été retenues.
Une décision molle distribue cette responsabilité. Elle la dilue entre les participants, les réunions, les documents, les formulations prudentes, les validations successives.
Découper la responsabilité produit en deux, c'est le même réflexe appliqué à l'organigramme. Ça permet d'avoir quelqu'un qui porte la conséquence sans avoir eu le choix, et quelqu'un qui a eu le choix sans porter la conséquence.
Le procédé est confortable. C'est aussi la raison pour laquelle plus personne n'est vraiment responsable de rien.
Où l'IA entre vraiment en jeu
Mon argument sur l'IA n'est pas « elle va remplacer les PO ». Il est plus mécanique que ça.
Le découpage penseur / exécutant avait une justification économique. Le travail de traduction, de documentation, de rédaction, de mise en forme coûtait cher en temps. Assez cher pour qu'on crée un poste dédié à absorber cette tuyauterie.
Pendant longtemps, le PM a été une plaque tournante : recueillir des besoins, reformuler, produire des documents, clarifier des tickets, remettre de l'ordre, coordonner, prioriser, suivre, relancer, documenter encore. Une partie du métier consistait à compenser les frictions de l'organisation. On a fini par accepter comme normale une masse de tâches qui n'étaient pas le cœur du métier, seulement sa plomberie.
Ce coût s'effondre.
Et quand la justification économique d'une division du travail disparaît, la division du travail ne survit pas longtemps.
C'est là que mon désaccord initial et l'IA se rejoignent. L'IA ne crée pas le problème : elle retire la dernière excuse pratique qu'on avait de vivre avec. On ne peut plus dire « oui, en théorie le PM devrait suivre jusqu'en production, mais concrètement il n'a pas le temps ».
Donc continuer à recruter aujourd'hui sur une fiche de poste construite autour de la transmission d'information, c'est optimiser un circuit déjà obsolète.
La nuance sur la rédaction
On m'a répondu : « la rédaction n'a jamais été le goulot du métier ».
Sur l'arbitrage, c'est vrai. Décider n'a jamais été un problème de rédaction, et je ne prétendrai pas le contraire.
Mais au sens large, je ne suis pas d'accord. Je suis le seul PM pour toute l'entreprise. Quand il faut produire une vidéo en quinze langues avec les sous-titres, des articles en quatre ou cinq langues, les posts, les briefs sur les avantages et les points à mettre en avant — c'est un travail démentiel. L'IA me permet de faire des choses que je n'avais tout simplement pas le temps de faire. Ce n'était pas le goulot de la décision. Mais c'était bel et bien un mur.
L'IA, je la vois comme un excellent secrétaire particulier. Elle récupère ma réflexion, elle avale les sources, elle fait le travail besogneux. Mais la personne qui comprend finement, qui choisit, qui prend le risque et qui assume, c'est le PM. Pas l'IA.
Et il y a une chose qu'elle ne fera jamais : le pari.
Si tu es une startup et que la question est « on y va à 100 ou on meurt », ce choix appartient aux gens qui ont fondé l'entreprise. Une IA peut analyser l'option. Elle ne peut pas l'assumer.
Là où mes contradicteurs m'ont fait avancer
Trois choses que je retiens du débat.
Le mandat compte plus que le titre. Plusieurs personnes ont recentré le sujet là-dessus, et elles ont raison. Un PM enfermé dans l'opérationnel et la gestion d'urgences, sans latitude pour définir une stratégie produit, sera occupé sans rien produire d'utile. Renommer les postes ne règle rien si le mandat ne suit pas. Mon insistance sur le vocabulaire ne doit pas masquer ça.
On peut repenser le poste plutôt que le supprimer. Un lead technique m'a décrit son équipe, sur un logiciel de santé réglementé avec une codebase legacy : ils n'ont pas supprimé le poste, ils l'ont redéfini. Le développeur porte une partie de la vision produit, le PO conçoit. Les personnes restent, le rôle change. C'est probablement plus juste que ma formulation initiale, et ça vaut d'être dit : ce qui devient indéfendable, c'est la courroie de transmission, pas les gens.
Le vrai danger, c'est la couche d'isolement. Le problème n'est pas qu'un PO existe. C'est quand il devient la couche qui coupe les développeurs du besoin réel — sous prétexte que les devs n'auraient pas à comprendre le métier, seulement à exécuter des specs. Ça, l'IA va le rendre encore plus intenable. Chez nous, les développeurs interviewent les clients directement depuis plusieurs mois. Et il y a quelques jours, j'ai poussé ma première pull request sur notre produit principal.
Sur l'expertise métier, enfin, je corrige une idée reçue : elle n'est pas la propriété du PO. Je l'ai trouvée chez des CSM issus du terrain, chez des gens du support. Elle peut être partout — et elle doit être chez le PM. Dans mon domaine, j'avale des livres et des vidéos de maintenance industrielle. Je me dois d'être excellent sur le métier, sans quoi je n'ai rien à arbitrer.
Là où je ne bouge pas
On m'a dit que le PO que je décris est probablement celui que j'ai été. C'est possible.
Et j'ajoute une chose plus gênante à admettre : c'est très confortable de se débarrasser du backlog, du suivi des devs, des mises en production. Le PM a un intérêt objectif à ce que le poste de PO existe. On garde la partie qui se raconte bien en réunion, on délègue celle qui coûte.
C'est précisément pour ça que je m'en méfie.
Séparer ceux qui pensent de ceux qui exécutent est une aberration. Pas parce que l'IA arrive. Parce que le produit, c'est ce qui est en production — et qu'on ne délègue pas la responsabilité de ce qu'on a conçu.
L'IA ne rend pas cet argument vrai.
Elle le rend impossible à contourner.
Pour en savoir plus
La qualité appartient à ceux qui livrent Le backlog n'est pas un dépotoir : c'est un outil d'action La question produit doit partir du code source