“C’est quoi la différence entre un PM classique et un PO IA ?” On me pose cette question régulièrement. La réponse courte : beaucoup plus que ce que la plupart des gens pensent.
Ce qui est pareil
Les fondamentaux du product management restent les mêmes :
- Comprendre les besoins utilisateurs
- Prioriser le backlog
- Définir la vision produit
- Communiquer avec les stakeholders
- Mesurer les résultats
Si vous êtes un bon PM, vous avez déjà 50% du travail. Mais l’autre 50% est vraiment différent.
Ce qui change : la nature de l’incertitude
Un PM classique gère de l’incertitude sur ce qu’il faut construire. L’équipe sait généralement comment construire ce qui est décidé.
Un PO IA gère aussi de l’incertitude sur si c’est possible et dans quelle mesure. Un agent IA qui “fonctionne à 85%” est-il acceptable ? Ça dépend du cas d’usage. Mais définir ce seuil, le mesurer, et décider quand c’est “assez bon” pour aller en prod — c’est un nouveau type de décision.
Ce qui change : les specs
Une spec classique décrit un comportement déterministe. “Quand l’utilisateur clique sur X, Y se passe.”
Une spec pour un agent IA décrit un comportement probabiliste. “Dans la majorité des cas, l’agent doit faire X. Dans ces cas limites, il doit faire Y. Dans ces cas d’erreur, il doit Z.” Et il faut définir ce que “majorité” veut dire, et comment on le mesure.
Sans background technique, écrire ce type de spec est très difficile. Vous devez comprendre pourquoi un LLM peut interpréter votre instruction différemment selon le contexte.
Ce qui change : l’évaluation
Un PM classique évalue la qualité d’un produit via des métriques business (conversion, rétention, satisfaction) et des tests fonctionnels (ça marche / ça ne marche pas).
Un PO IA doit aussi évaluer la qualité du modèle lui-même : taux de précision, taux d’hallucination, cohérence des sorties, comportement sur les cas limites. Ce sont des compétences proches de ce qu’on appelle le “ML evaluation” — pas du dev, mais pas du PM classique non plus.
Ce qui change : la relation avec l’équipe technique
Un PM classique travaille avec des devs qui implémentent des specs. La frontière est relativement claire.
Un PO IA travaille avec des devs qui font des choix de modèle, de prompt engineering, d’architecture d’agent qui ont un impact direct sur ce que le produit peut faire. La frontière est floue. Si vous ne comprenez pas ces choix, vous ne pouvez pas prendre de bonnes décisions produit.
C’est là où mon background dev devient un avantage concret. Je peux participer à ces décisions, pas juste les subir.
Ce qui change : la gestion des attentes
Les LLMs ont créé des attentes disproportionnées dans les organisations. “L’IA peut tout faire” est une croyance répandue. Le PO IA se retrouve souvent dans le rôle ingrat de ramener la réalité : non, l’agent ne sera pas parfait, voici ce qu’on peut garantir et à quel coût.
Savoir communiquer les limites de l’IA sans démotiver les équipes ni décevoir les stakeholders — c’est une compétence à part entière.
Ce qu’un bon PO IA doit maîtriser
Pas besoin de coder des agents. Mais il faut comprendre :
- Comment fonctionne un LLM (à un niveau conceptuel)
- Ce qu’est un prompt système et comment il influence les sorties
- Comment évaluer un agent de façon rigoureuse
- Les coûts et la latence des différentes options
- Les risques spécifiques à l’IA (hallucinations, biais, dérives)
C’est un nouveau métier. Pas juste un PM avec une spécialisation.
Stéphanie Caumont
Product Owner IA · En savoir plus