Product Owner à l'ère de l'IA : quelles compétences deviennent indispensables ?

Ce qui change réellement dans le métier

Un Product Owner qui travaille sur un produit comportant une brique IA ne change pas de métier : il continue de porter une valeur utilisateur, un backlog, des arbitrages et une relation avec les parties prenantes. Ce qui change, c'est la nature de l'objet piloté. Une fonctionnalité classique se décrit par des règles : si l'utilisateur fait ceci, le système répond exactement cela. Une fonctionnalité qui repose sur un modèle de langage ou un système de recommandation produit un comportement, pas une règle. Deux formulations proches peuvent donner deux réponses différentes, et la même formulation peut donner une réponse acceptable un jour et médiocre le lendemain, simplement parce que le contexte fourni a changé.

La conséquence est concrète : un PO ne peut plus se contenter de valider une fonctionnalité en la testant une fois. Il doit apprendre à décrire ce qui est attendu en moyenne, ce qui est intolérable dans tous les cas, et ce qui doit se produire quand le système se trompe. C'est une compétence de spécification et d'évaluation, pas une compétence d'ingénierie.

Le PO n'a pas besoin de savoir entraîner un modèle ni de lire du code d'inférence. Il doit savoir formuler un problème, définir ce que « bien répondre » veut dire et décider quel niveau d'erreur le métier peut absorber.

Cadrer le cas d'usage avant de parler de modèle

La demande arrive rarement sous forme de problème. Elle arrive sous forme de solution : « on veut un assistant », « on veut résumer automatiquement les tickets », « on veut un agent qui traite les demandes ». Le premier travail du PO est de remonter d'un cran : quelle décision ou quelle tâche humaine cherche-t-on à accélérer, qui la fait aujourd'hui, combien de fois par jour, et que se passe-t-il si elle est mal faite ?

• Quelle tâche précise est visée, et à quel moment du parcours elle intervient.
• Qui est l'utilisateur réel : un client final, un conseiller, un opérateur interne.
• Quel est le résultat attendu : un texte, une classification, une suggestion, une action.
• Quelle est la conséquence d'une erreur : perte de temps, mauvaise décision, risque contractuel.
• Quelle alternative existe déjà, et pourquoi elle ne suffit pas.

Ce cadrage détermine tout le reste. Un assistant de rédaction interne dont l'utilisateur relit systématiquement la sortie tolère un taux d'imperfection élevé. Un système qui envoie directement une réponse à un client ne le tolère pas. Ce n'est pas une question de modèle, c'est une question de responsabilité.

Définir la valeur utilisateur, pas la prouesse technique

Beaucoup de fonctionnalités IA sont livrées parce qu'elles sont possibles, pas parce qu'elles sont utiles. Le PO reste le garant de la question de valeur : qu'est-ce que l'utilisateur peut faire après la mise en production qu'il ne pouvait pas faire avant, et comment le verra-t-on ? La réponse doit être observable : un délai réduit, une étape supprimée, une information trouvée sans changer d'outil, une décision documentée plus vite.

Un indicateur de valeur ne se confond pas avec un indicateur de qualité du modèle. Le second mesure le comportement du système, le premier mesure l'effet sur le travail réel. Un système peut avoir d'excellents scores internes et n'être jamais utilisé, parce qu'il arrive trop tard dans le parcours ou parce que l'utilisateur ne lui fait pas confiance.

Des critères d'acceptation aux critères évaluables

Un critère d'acceptation classique est binaire : la fonctionnalité le respecte ou non. Sur un comportement probabiliste, la question devient : sur un ensemble de cas représentatifs, quelle proportion de sorties est acceptable, et selon quelle définition d'« acceptable » ? Le PO n'a pas besoin de connaître les métriques statistiques, mais il doit fournir la matière qui permet de les construire : des exemples réels, des sorties attendues, et des exemples de sorties inacceptables.

Constituer un jeu de tests et travailler les cas limites

Le jeu de tests est l'actif le plus durable qu'un PO puisse produire sur un produit IA. Il survit aux changements de modèle, de prompt et de fournisseur. Il doit rester petit mais représentatif : des cas ordinaires, des cas fréquents mais pénibles, et des cas limites choisis pour leur conséquence, pas pour leur bizarrerie.

• Cas nominaux : ce que le système rencontrera la majorité du temps.
• Cas ambigus : information partielle, formulation vague, demande contradictoire.
• Cas hors périmètre : ce à quoi le système doit refuser de répondre.
• Cas sensibles : données personnelles, engagement contractuel, montants, santé, droit.
• Cas de régression : les erreurs déjà constatées, conservées pour toujours.

Chaque cas est accompagné d'une attente exprimée en langage métier. C'est cette collection, relue régulièrement, qui permet à l'équipe technique de comparer objectivement deux versions du système.

Hallucinations, réponses incorrectes et niveau de qualité acceptable

Un système génératif peut produire une réponse fausse formulée avec assurance. C'est un comportement attendu du type de système, pas un bug isolé que l'on corrigerait une fois pour toutes. Le rôle du PO est donc de décider, cas d'usage par cas d'usage, ce qui est absorbable et ce qui ne l'est pas, puis d'organiser le produit autour de cette décision.

• Erreur visible et corrigeable par l'utilisateur : souvent acceptable si le coût de correction est faible.
• Erreur invisible qui se propage dans un autre système : rarement acceptable sans contrôle.
• Erreur portant sur un engagement, un prix, une obligation légale : à exclure par conception, pas par consigne.

Trois leviers produits existent avant tout travail sur le modèle : restreindre le périmètre de la fonctionnalité, exiger que la réponse cite sa source, et prévoir explicitement le cas « je ne sais pas ». Un système capable de s'abstenir est presque toujours plus exploitable qu'un système qui répond toujours.

Décider où placer l'humain dans la boucle

Le human-in-the-loop n'est pas une case à cocher, c'est un choix de conception qui a un coût. Faire relire chaque sortie protège la qualité mais annule souvent le gain de temps. Ne rien relire maximise le gain mais transfère le risque à l'utilisateur final. Entre les deux, il existe des positions intermédiaires que le PO doit choisir explicitement : relecture des seuls cas signalés incertains, relecture par échantillon, validation obligatoire uniquement avant une action irréversible.

Une bonne question de cadrage : « quelle est la dernière action après laquelle l'erreur devient coûteuse ? » Le contrôle humain se place juste avant cette action, pas partout.

Arbitrer entre qualité, latence et coût

Sur un produit IA, trois variables bougent ensemble. Une réponse plus fiable demande souvent plus de contexte, plus d'étapes ou un modèle plus lourd : elle coûte plus cher et arrive plus tard. Ces arbitrages ne sont pas techniques, ils sont produits. Le PO doit être capable de dire dans quelle situation l'utilisateur préfère attendre, et dans quelle situation une réponse imparfaite immédiate vaut mieux qu'une réponse parfaite tardive.

Le coût mérite d'être traité comme une contrainte de conception dès le cadrage, au même titre qu'une contrainte de performance. Une fonctionnalité dont le coût unitaire dépasse la valeur qu'elle crée ne passera pas l'échelle, même si la démonstration est réussie.

Données, dépendances et travail avec l'équipe

Une fonctionnalité IA dépend rarement du seul modèle. Elle dépend surtout des données qu'on lui donne : documents à jour, périmètre de droits, fraîcheur, qualité de structuration. Un PO qui ignore l'état réel des sources s'expose à découvrir tard que le produit promis n'est pas alimentable.

• Quelles sources sont nécessaires, et qui en est responsable dans l'organisation.
• Qui a le droit de voir quoi : un assistant ne doit jamais élargir les droits d'un utilisateur.
• À quelle fréquence les données changent, et ce que devient une réponse fondée sur une version périmée.
• Quelles traces sont conservées pour comprendre une réponse a posteriori.

Vis-à-vis de l'équipe AI Engineering et Data, le PO gagne à séparer clairement ce qu'il exige (comportement attendu, cas interdits, seuils) de ce qu'il n'impose pas (architecture, choix de modèle, stratégie de récupération d'information). Cette frontière évite la double peine : imposer une solution technique et rester responsable du résultat métier.

Cas concret : une user story qui ne tient pas

Une équipe support veut proposer une réponse pré-rédigée aux conseillers. La story initiale : « En tant que conseiller, je veux qu'une réponse me soit proposée automatiquement afin de gagner du temps. Critère d'acceptation : la réponse proposée est correcte. » Cette story est intestable : « correcte » n'est pas défini, aucun périmètre n'est posé, aucun comportement n'est prévu en cas de doute, et rien ne dit ce qui se passe si la réponse s'appuie sur une procédure obsolète.

Le même besoin, cadré autrement, devient exploitable :

• Périmètre : uniquement les demandes de suivi de commande, en français, sur les commandes des 90 derniers jours.
• Sources autorisées : base de procédures publiée et statut de commande ; aucune autre source.
• Comportement attendu : la proposition cite la procédure utilisée et le numéro de commande.
• Abstention : si le statut est introuvable ou la procédure ambiguë, le système propose un modèle vide et signale l'incertitude au lieu d'inventer.
• Interdits absolus : aucun engagement de délai, de remboursement ou de geste commercial dans la proposition.
• Contrôle : la réponse n'est jamais envoyée automatiquement ; le conseiller valide ou modifie.
• Évaluation : sur 80 conversations réelles anonymisées, au moins 60 propositions sont envoyées avec au plus une correction mineure, et zéro proposition contient un engagement interdit.
• Suivi : taux d'utilisation réel, taux de réécriture lourde, signalements des conseillers.

Rien dans cette version ne suppose de compétence technique. Tout y est produit : périmètre, sources, comportement en cas de doute, interdits, dispositif de contrôle et mesure. C'est exactement ce qu'une équipe IA attend d'un PO.

Du POC à une fonctionnalité réellement exploitable

Une démonstration réussie prouve qu'un comportement est possible sur quelques exemples choisis. Une fonctionnalité exploitable suppose autre chose : un comportement stable sur des cas non choisis, un traitement des erreurs, une trace des décisions, un coût maîtrisé et une équipe capable de la faire évoluer. Le passage de l'un à l'autre est le moment où beaucoup de projets IA s'arrêtent, souvent parce que la marche n'avait pas été anticipée au cadrage.

Après la mise en production

Un produit IA se dégrade sans que personne ne touche au code : les usages dérivent, les documents changent, les utilisateurs formulent autrement. Le suivi post-production fait donc partie du périmètre du PO, au même titre que le backlog.

• Usage réel : qui utilise la fonctionnalité, à quelle fréquence, et qui l'a abandonnée.
• Signalements : un moyen simple de remonter une réponse problématique, relu régulièrement.
• Réévaluation : rejouer le jeu de tests à chaque changement de modèle, de prompt ou de source.
• Coût : suivi du coût par usage et de son évolution avec le volume.
• Décisions : ce qui a été changé, quand, et l'effet observé.

Les questions qu'un PO doit savoir poser

• Sur quelles données la réponse s'appuie-t-elle, et comment sont-elles sélectionnées ?
• Que fait le système quand il ne trouve pas l'information ?
• Comment saurons-nous qu'une nouvelle version est meilleure que l'actuelle ?
• Quels cas avons-nous décidé de ne pas traiter, et est-ce visible pour l'utilisateur ?
• Quel est le coût d'un appel, et comment évolue-t-il si l'usage double ?
• Combien de temps met une réponse dans le pire cas, pas en moyenne ?
• Que pouvons-nous expliquer à un utilisateur qui conteste une réponse ?
• Quelle partie du comportement dépend d'un fournisseur externe, et que se passe-t-il s'il change ?

Ces questions ne servent pas à contrôler l'équipe technique : elles servent à rendre explicites des choix qui, sinon, sont faits implicitement — et souvent découverts en production.

• Produit IA
• Cadrage de cas d'usage
• Évaluation