Dans une équipe Scrum, le product owner tient le backlog, écrit ou fait écrire les user stories, fixe les critères d'acceptation et accepte ce que l'équipe livre. Le Scrum Guide de 2020 le décrit comme une seule personne, responsable de maximiser la valeur du produit. L'intitulé recouvre pourtant des postes différents : PO applicatif qui a remplacé l'AMOA, proxy PO qui relaie un PO du métier, PO d'un produit numérique vendu à des clients. Les questions d'entretien de product owner partent de ce périmètre.
Beaucoup de CV de PO viennent de l'AMOA ou du business analysis. Ces profils rédigent bien, parfois trop : des stories de deux pages, découpées par couche technique, et un backlog qui joue le rôle de cahier des charges. Un product owner refuse des demandes, découpe pour livrer tôt et mesure l'effet après la mise en production. Les certifications PSPO I ou CSPO montrent qu'il connaît le cadre Scrum. Elles ne disent rien de ses arbitrages.
Le plus efficace en entretien reste de travailler sur un morceau du backlog réel : une fonctionnalité à découper, trois demandes à classer. Le PDF ajoute 30 questions sur six axes, un cas de 20 minutes et une grille de 1 à 4.
Les pratiques et outils du quotidien d'un product owner
Product backlog et objectif produit
La liste ordonnée de tout ce que l'équipe peut construire, tenue par le product owner. Depuis 2020, le Scrum Guide y rattache un objectif produit (Product Goal) qui sert à trier. Un backlog de 600 éléments jamais nettoyé dit beaucoup sur la personne qui le tient.
User stories et critères d'acceptation
Une story décrit un besoin du point de vue d'un utilisateur, avec des critères qui disent quand elle est terminée. Les critères INVEST servent de repère, et beaucoup d'équipes écrivent les critères en Gherkin (Étant donné, Quand, Alors), ce qui facilite leur automatisation en tests.
Story mapping et découpage vertical
Le story mapping range les stories sous les étapes du parcours utilisateur, puis découpe des releases successives. Le découpage vertical produit des morceaux qui traversent toutes les couches et livrent chacun quelque chose d'utilisable. C'est le geste qui distingue le plus vite un PO expérimenté.
Méthodes de priorisation
MoSCoW pour négocier un périmètre, RICE pour comparer des idées, WSJF pour classer par coût du retard rapporté à la taille. Aucune ne décide seule. Une décision réelle prise avec l'une d'elles est attendue.
Définition de fini et revue de sprint
La définition de fini fixe le niveau de qualité commun à tout incrément. La revue de sprint est une séance de travail avec les parties prenantes, où l'on regarde le résultat et où l'on adapte le backlog. Un PO qui la vit comme une simple démonstration passe à côté.
Jira, Azure DevOps et Confluence
Les outils les plus cités dans les offres pour le backlog, les sprints et la documentation fonctionnelle. Leur maîtrise s'apprend vite. La qualité d'un backlog se juge sur son contenu, pas sur la configuration de l'outil.
Figma et prototypes
Les maquettes et prototypes, souvent produits par un designer, permettent de valider un besoin avant de le développer. Le PO s'en sert en atelier avec les utilisateurs et pour rédiger des critères précis.
Mesure d'usage
Matomo, Google Analytics 4, Amplitude ou simplement les logs applicatifs : ces outils disent si une fonctionnalité est utilisée. Le PO prévoit les mesures dans la story, avec l'équipe data et dans le respect du RGPD.
On trouve des product owners chez les éditeurs de logiciels, dans les équipes produit des entreprises et dans les directions informatiques qui ont remplacé l'AMOA par des équipes agiles. Les prestataires en placent aussi en mission, souvent comme proxy PO aux côtés d'un PO métier. Le périmètre va d'une application interne pour quelques centaines d'agents à un produit utilisé par des milliers de clients. Selon les organisations, le PO travaille avec un product manager qui porte la stratégie, ou cumule les deux rôles. Les certifications PSPO I (Scrum.org) et CSPO (Scrum Alliance) sont fréquentes sur les CV. Elles attestent la connaissance du cadre. Le savoir-faire se vérifie sur un backlog réel.
Les compétences d'un PO évaluées en entretien
- Vision produit et objectifs mesurables
- Priorisation du backlog
- User stories et critères d'acceptation
- Découpage et planification des releases
- Validation des incréments et recette
- Mesure de la valeur et arbitrages métier
Questions pour un product owner, avec la réponse attendue
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Le métier demande « un export Excel de toutes les commandes, filtrable ». Découpez cette demande en user stories livrables séparément.
Une bonne réponseD'abord l'usage : qui ouvre ce fichier et pour en faire quoi (rapprochement comptable, relance de clients, suivi des retards). Ensuite un découpage vertical, chaque story livrable et testable seule : l'export des commandes du jour sans filtre, puis le filtre par période, puis par statut, puis la gestion des gros volumes (génération en arrière-plan, envoi d'un lien). Chaque story a ses critères d'acceptation : colonnes, formats de date et de montant, droits d'accès. Si l'usage réel est un suivi quotidien, il propose un écran ou un tableau de bord à la place.
Signal d'alerteUn découpage par couche (le back, le front, les tests), ou une seule story « En tant qu'utilisateur, je veux un export ». Ne jamais demander à quoi servira le fichier.
Question 2 · senior
Trois demandes arrivent la même semaine : une obligation réglementaire à respecter dans quatre mois, une fonctionnalité réclamée par le plus gros client, une refonte demandée par l'équipe pour réduire les incidents. Comment les classez-vous ?
Une bonne réponseIl évalue pour chacune la valeur, le coût du retard et la taille. L'obligation a une date fixe : il planifie à rebours avec une marge, sans forcément la traiter en premier. Pour la refonte, il chiffre ce que coûtent les incidents (temps de l'équipe, tickets, utilisateurs bloqués). Pour le gros client, il vérifie si d'autres clients ont le même besoin et ce qui a été promis commercialement. La méthode est explicite (WSJF ou coût du retard divisé par la taille), la décision tracée et expliquée, et le découpage permet souvent d'avancer sur deux sujets à la fois.
Signal d'alerte« Le plus gros client passe d'abord », ou « tout est prioritaire ». Laisser la refonte de côté parce qu'elle ne se voit pas, ou appliquer une formule sans regarder la date réglementaire.
Question 3 · confirmé
Story « réinitialiser son mot de passe » : quels critères d'acceptation écrivez-vous ?
Une bonne réponseDes scénarios concrets, souvent en Gherkin (Étant donné, Quand, Alors). L'utilisateur reçoit un e-mail avec un lien à usage unique et à durée limitée. Le message affiché est le même que l'adresse existe ou non, pour ne pas révéler les comptes. Le nouveau mot de passe respecte les règles fixées, l'ancien ne fonctionne plus. Un lien expiré ou déjà utilisé affiche un message clair. Les demandes répétées sont limitées. Il fait relire les règles de sécurité par l'équipe ou le référent sécurité.
Signal d'alerteUne reformulation de la story (« l'utilisateur peut réinitialiser son mot de passe »), aucun cas d'erreur, aucune règle de sécurité.
Question 4 · confirmé
En revue de sprint, l'équipe présente une story qui respecte tous ses critères d'acceptation, mais le métier dit que ce n'est pas ce qu'il voulait. Que faites-vous ?
Une bonne réponseLa story respecte ses critères et la définition de fini : elle est terminée, l'équipe a fait ce qui était demandé. L'écart devient un nouvel élément du backlog, priorisé comme les autres. Il cherche ensuite pourquoi le besoin a été mal compris : métier absent de l'affinage, critères écrits sans exemple, pas de maquette. Il corrige le processus (exemples concrets, maquette validée avant le sprint, démonstration en cours de sprint). La revue sert à adapter le backlog, et c'est ce qu'il fait.
Signal d'alerteRefuser la story et demander à l'équipe de la refaire dans le sprint sans changer le reste. Rejeter la faute sur le métier ou sur les développeurs.
Question 5 · confirmé
Votre équipe a livré il y a un mois une nouvelle recherche de dossiers. Qu'est-ce qui vous dit qu'elle a changé quelque chose pour les utilisateurs ?
Une bonne réponseL'objectif a été posé avant le développement, avec un indicateur et une cible : part des utilisateurs visés qui s'en servent, temps de traitement d'un dossier, baisse des appels au support. La story prévoyait les événements à mesurer (logs ou outil d'analytics). Il compare avant et après, ajoute des retours qualitatifs (entretiens, tickets) et décide : continuer à l'améliorer, la laisser telle quelle ou la retirer.
Signal d'alerte« Elle est livrée sans bug, donc c'est réussi. » Citer le nombre de stories livrées ou la vélocité comme preuve de valeur.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Product owner : les questions qui reviennent
Product owner et product manager : quelle différence ?
Le product owner est un rôle Scrum, centré sur le backlog, les stories et l'acceptation des livraisons avec une équipe. Le product manager porte la stratégie du produit : marché, positionnement, roadmap à plus long terme, parfois le prix. Dans une petite structure, une seule personne fait les deux. Dans une grande, le PM travaille avec plusieurs PO. Savoir qui fixe la roadmap, c'est ce qui change le profil.
Une certification PSPO ou CSPO est-elle indispensable ?
Non, elle ne doit pas filtrer les candidatures. La PSPO I de Scrum.org se passe en ligne : 80 questions en 60 minutes, 85 % de bonnes réponses, sans date d'expiration. La CSPO de Scrum Alliance s'obtient après une formation. Les deux montrent que le cadre Scrum est connu. Un candidat sans certification mais avec un backlog qu'il sait expliquer vaut mieux qu'un certifié qui n'a jamais refusé une demande.
Quel test technique est donné à un product owner ?
Un exercice sur la matière réelle de l'équipe fonctionne mieux qu'un questionnaire. Le candidat reçoit une demande métier réelle et la découpe en stories, avec les critères d'acceptation de l'une d'elles. Ou bien il classe cinq demandes accompagnées de quelques chiffres. L'exercice dure 30 à 45 minutes, en direct. Le raisonnement, les questions posées sur l'usage et la qualité du découpage comptent plus que le résultat exact.
Un business analyst peut-il devenir product owner ?
Souvent, oui. Il connaît déjà le métier, rédige des spécifications et sait tester. Ce qui lui manque en général, c'est la décision : classer, refuser, découper pour livrer une première version modeste, puis mesurer. En entretien, il raconte une demande qu'il a refusée ou repoussée, et comment il a mesuré l'effet d'une fonctionnalité livrée. Les réponses montrent vite s'il a déjà tenu le rôle.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
