Évaluer la maturité du Product Management d'une organisation : méthode et constats sur l'IA

Dans une organisation qui compte des dizaines d'équipes produit, une question toute bête finit par se poser : est-ce qu'on parle tous de la même chose quand on dit « faire du produit » ?

Un Product Owner peut désigner le rôle strict du Scrum Guide, ou une personne qui porte la vision, la discovery et le pilotage à elle seule. Un Product Manager peut être un stratège produit ou un chef de projet rebaptisé. Tant que ce vocabulaire n'est pas posé, comparer deux équipes n'a pas de sens : on compare des lectures individuelles, pas des pratiques.

Pendant six mois de stage chez OCTO, j'ai construit une démarche pour sortir de ce flou : un référentiel commun, quatre axes de mesure, et trois sources croisées appliquées à plus de 20 Product Owners et Product Managers en mission. Cet article n'est pas le résultat de cette étude, il présente la démarche effectuée. Parce que la question « où en sont vraiment nos équipes produit ? » se pose fréquemment dans les organisations, et qu'elle se traite rarement de façon outillée.

Et parce que le constat le plus net qui en est ressorti mérite d'être partagé : l'IA n'est plus un sujet d'anticipation pour les métiers du produit. Elle est désormais un usage ancré dans le quotidien.

La démarche

Pour garantir un diagnostic objectif, j'ai structuré ma démarche en trois étapes : partager un référentiel commun, mesurer à partir de faits observables et valider chaque constat par le croisement de plusieurs sources.

Étape 1 : poser un référentiel avant de mesurer quoi que ce soit

La première tentation est de lancer un questionnaire de maturité. C'est une erreur : si chacun répond avec sa propre définition des rôles, les réponses ne sont pas comparables.

J'ai donc commencé par l'inverse : décrire les rôles produit (Product Owner, Product Manager, Product Ops, Chief Product Officer) et les positionner sur les trois phases du cycle de vie d'un produit, la Discovery, le Delivery et la Croissance. Ce que fait chacun, à quel niveau il décide, et où passe la frontière entre le « quoi et pourquoi » et le « comment ».

Le référentiel ne dit pas ce qui est bien ou mal. Il donne un vocabulaire commun, sans lequel rien n'est comparable.

Ce travail fait déjà apparaître une confusion très répandue : le rôle appelé « Product Owner » dans beaucoup d'organisations dépasse largement celui du Scrum Guide, et correspond plutôt à un Product Manager junior.

Ce n'est pas qu'une question de vocabulaire : en attribuant le titre de Product Owner à un rôle qui s'apparente à celui d'un Product Manager, certaines organisations attendent de cette personne des responsabilités stratégiques sans lui donner l'autorité nécessaire pour les assumer.

Étape 2 : choisir quatre axes réellement observables

Un modèle de maturité produit peut compter quinze dimensions. En pratique, au-delà de quatre ou cinq, plus personne ne sait quoi en faire. J'en ai retenu quatre, choisis parce qu’ils couvrent l'ensemble du rôle et qu'ils se constatent sur le terrain :

• Stratégie : porter une vision produit à long terme, aligner les décisions sur les objectifs business, mesurer l'impact créé.
• Discovery : explorer les problèmes utilisateurs avant de construire, valider les hypothèses, ancrer les décisions dans des données terrain.
• Pilotage : définir des indicateurs de succès, mesurer l'impact après livraison, ajuster les priorités selon les résultats.
• Autonomie : décider de façon indépendante, résister aux interruptions, porter des choix sans validation systématique.

Chaque axe est décliné en questions concrètes, jamais en auto-évaluation globale. On ne demande pas « êtes-vous bon en pilotage ? » mais « quels indicateurs de succès avez-vous définis sur votre dernier epic, et où sont-ils affichés ? ».

Étape 3 : croiser trois sources, et ne rien retenir qui n'apparaisse qu'une fois

C'est le cœur de la démarche, et ce qui la distingue d'une enquête de satisfaction.

Un entretien produit un discours, et un discours produit toujours une version cohérente et rationalisée du travail. Ce n'est pas de la mauvaise foi : personne ne raconte spontanément ce qui lui paraît normal. Pour limiter ce biais, j'ai croisé trois angles qui ne regardent pas l'objet de la même hauteur :

• un questionnaire structuré sur les quatre axes,
• des entretiens semi-directifs,
• et surtout des shadows de mission, c'est-à-dire de l'observation directe de rituels (daily, sprint review, rétro, entretiens utilisateurs), sans intervenir.

Et une règle simple, posée avant de commencer : un constat n'est retenu que s'il se confirme dans au moins deux des trois sources.

Ce filtre paraît anodin, il est décisif. Il a fait tomber la moitié des irritants qu'on m'avait remontés en préparation, qui n'existaient que dans le discours de quelques personnes. Et il a fait remonter des écarts que les entretiens seuls n'auraient jamais donnés : ce qu'une équipe décrit comme son fonctionnement et ce qu'on voit en s'asseyant dans ses rituels ne se recouvrent jamais complètement. Non pas parce qu'on ment, mais parce qu'on décrit son intention.

Si vous ne deviez retenir qu'une chose de cette démarche : observer prend du temps mais c'est la seule source qui ne se raconte pas d'histoires.

Ce que ça produit

Une conversation, pas une note

La sortie de l'exercice n'est pas un score de maturité. C'est trois choses.

Un miroir individuel. Chaque personne reçoit son radar sur les quatre axes. L'objet n'est pas de classer, mais de nommer : beaucoup découvrent qu'elles investissent massivement un axe et pas du tout un autre, sans l'avoir décidé.

Une typologie de profils. En croisant les radars, des archétypes apparaissent : l'explorateur utilisateur, fort en discovery ; l'exécutant cadré, solide en delivery ; le visionnaire stratège ; le chef d'orchestre ; le profil équilibré sur les quatre axes. Ces archétypes sont utiles parce qu'ils dépersonnalisent la discussion : on ne parle plus de « qui est bon », mais de quelle combinaison de profils une équipe a besoin.

Une lecture collective. À l'échelle du groupe, les axes les plus et les moins pratiqués sautent aux yeux, et se recoupent avec l'outillage réellement utilisé. Le signal le plus intéressant n'est pas le score le plus bas : c'est quand l'intention est unanime et que ni les rituels ni les outils ne suivent. Ça ne se corrige pas seulement par de la formation, ni même par un nouveau rituel : le plus souvent, le rituel existe déjà, mais il ne porte pas cet axe. Le levier n'est donc pas toujours d'ajouter quelque chose, c'est aussi de faire porter un axe manquant par un rituel qui existe déjà.

Le constat le plus net : l'IA est déjà dans le quotidien

Je m'attendais à un sujet de projection. C'est un sujet du présent.

Ces chiffres sont déclaratifs : ils viennent de l'estimation que les personnes interrogées font elles-mêmes de leur gain de temps, pas d'une mesure outillée (aucun tracking du temps réel n'a été mis en place). C'est une limite à garder en tête, mais la cohérence entre plusieurs témoignages indépendants, et avec les études du secteur, donne un signal qu'il serait difficile d'ignorer.

100 % des PO et PM observés utilisent l'IA, et l'immense majorité des répondants déclarent utiliser au moins un outil d'IA dans leur quotidien. Dans le classement des outils les plus cités dans le questionnaire mené dans le cadre de cette étude, trois outils d'IA (Claude, Copilot, ChatGPT) figurent désormais dans le top 3, aux côtés des outils de documentation et de gestion de projet utilisés depuis des années.

Les gains sont réels sur les tâches de production : environ la moitié du temps gagné sur la rédaction, des critères d'acceptation produits trois fois plus vite, une user story qui passe de trente à quarante-cinq minutes à une dizaine. Des ordres de grandeur cohérents avec ce que publient les études du secteur, autour de 40 % de gains de productivité sur les tâches de rédaction et de synthèse.

Mais les chiffres bruts cachent trois choses que le terrain montre bien.

Le coût d'entrée est réel. Le consultant qui a obtenu ces gains a passé quatre mois à construire son workflow et ses fichiers de contexte avant d'atteindre un résultat satisfaisant, et a fini par abandonner l'IA sur les règles de gestion, trop coûteuses à corriger. Ce qu'on cherche à produire n'est pas un livrable généré, c'est un processus reproductible.

Le travail se déplace, il ne disparaît pas. Le gain se confirme, mais il s'accompagne d'un nouveau coût : la supervision qualité. Un PO, lors d'une expérimentation de conception assistée par agents, le résume ainsi :

“L'IA produisait plus vite que nous ne pouvions suivre.”

Le rôle glisse de la production vers l'arbitrage et la revue critique ; cela suppose de savoir juger un livrable qu'on n'a pas écrit.

Le temps libéré ne retourne pas dans la production. Il retourne vers la discovery, les parties prenantes et l'arbitrage. Plusieurs personnes interrogées le formulent comme un repositionnement :

“Ma valeur ajoutée, c'est la communication, la transparence, la coordination.”

La frontière est assez nette. Un modèle produit du plausible, pas du vrai : il ne valide pas une hypothèse, il ne lit pas les non-dits d'une organisation, et il ne porte pas la responsabilité d'un arbitrage. Le terrain reste indispensable.

Là où ça devient intéressant : le PM devient orchestrateur

Une deuxième vague est en train d'arriver, et elle ne concerne plus l'assistance à la rédaction. Des frameworks de développement piloté par la spécification permettent de transformer un besoin métier en spécifications structurées, puis de les faire porter par des agents jouant les rôles de Product Manager, designer, architecte ou développeur.

Le déplacement est de nature différente : on ne délègue plus une tâche, on pilote une chaîne de production. Le Product Manager passe de producteur de livrables à orchestrateur ; ce qui suppose des compétences que peu de fiches de poste mentionnent aujourd'hui, à commencer par la capacité à structurer un contexte exploitable par une machine.

Et à la marge, des organisations expérimentent la suppression pure et simple du rôle. Le modèle observé chez certaines startups IA repose sur une responsabilité temporaire attribuée par sujet : une personne, souvent ingénieur ou designer, prend l'entière responsabilité d'une initiative, et l'équipe se constitue autour du problème plutôt qu'autour d'un organigramme.

Je ne pense pas que ce modèle soit généralisable ; il suppose une culture de l'accountability rare et des équipes très seniors. Mais il pose la bonne question : si l'IA absorbe une partie de la production, qu'est-ce qui justifie encore le rôle ? La réponse tenait, dans presque tous mes entretiens, aux mêmes éléments : la décision dans l'ambiguïté, l'alignement des parties prenantes, la vision long terme et l'esprit critique. Aucun n'est un livrable.

Ou, dans les mots d'un Product Owner interviewé :

“Le risque n'est pas d'être remplacé par l'IA, mais par quelqu'un qui sait l'utiliser.”

Ce que je retiens six mois plus tard

Que la valeur de l'exercice n'est pas dans le verdict, mais dans le fait de rendre discutable quelque chose qui ne l'était pas. Avant, chacun avait une opinion sur la maturité produit de son organisation ; après, on a un vocabulaire, quatre axes, et des observations qu'on peut poser sur la table.

Mais ce que j'ai observé sur l'IA en cours de route interroge la méthode elle-même. Les quatre axes mesurent des pratiques humaines : porter une vision, explorer, piloter, décider. Si une partie croissante du delivery est produite par des agents, la question change de nature. Ce n'est plus seulement « cette équipe pratique-t-elle bien la discovery ? », mais « comment évaluer la maturité d'une organisation produit quand une partie de ses tâches est réalisée par de l'IA ? » Faudrait-il, à terme, interroger aussi les pratiques des agents eux-mêmes ? Et même si un agent peut techniquement « remplir » les quatre axes, générer des hypothèses, des indicateurs, des priorités, comment évaluer qu'il le fait avec justesse, et pas seulement avec vraisemblance ? C'est une question que je n'ai pas encore les moyens de trancher, mais qui va devenir centrale plus vite qu'on ne le pense.

Et une question que je n'ai pas fini de creuser, plus large encore : comment faire évoluer le référentiel de rôles lui-même à mesure que l'IA absorbe une partie du delivery ? Est-ce que le Product Owner de demain ressemble encore à celui d'aujourd'hui ?

Je n'ai pas de réponse toute faite à ces deux questions, seulement la conviction qu'elles vont devenir aussi structurantes que celle de la maturité produit elle-même. En attendant, la démarche que j'ai construite reste un point de départ solide, y compris pour commencer à les poser.

Si vous voulez rejouer la démarche dans votre organisation, elle tient en cinq mouvements :

1. Posez le référentiel d'abord. Rôles et phases du cycle de vie, avant toute mesure.
2. Limitez-vous à quatre axes, formulés en questions concrètes plutôt qu'en auto-évaluation.
3. Croisez au moins deux sources, dont une d'observation directe. Sans shadow, vous mesurez des intentions.
4. Fixez la règle de rétention avant de collecter, sinon vous retiendrez ce qui confirme vos hypothèses de départ.
5. Restituez en miroir, pas en note. Un radar ouvre une conversation ; un score la ferme.

Et si vous ne deviez poser qu'une seule question à vos équipes produit pour commencer :

“Sur votre dernière livraison, comment savez-vous qu'elle a servi à quelque chose ?”

La réponse – ou les difficultés à y répondre – en dira souvent plus sur la maturité produit que n'importe quel questionnaire.