Product discovery : conduire des entretiens qui orientent le produit
4 minutes de lecture environ
La product discovery réduit l’incertitude avant d’engager du développement. Les entretiens y sont utiles lorsqu’ils éclairent des comportements, des contraintes et des décisions réelles. Demander au client quelles fonctionnalités il souhaite produit souvent une liste de solutions difficiles à arbitrer.
Partez d’un épisode récent vécu par la personne interrogée. Reconstituez ce qu’elle a fait avant de présenter votre solution ; vous pourrez ensuite tester une hypothèse précise.
Dans cet article
Donner une décision à la recherche
Écrivez la question qui justifie les entretiens : comprendre un abandon, choisir un segment ou vérifier une dépendance du parcours. La recherche n’a pas besoin de couvrir tout le produit à chaque cycle. Le guide GOV.UK consacré aux entretiens approfondis décrit leur préparation et la construction d’un échange centré sur l’expérience des utilisateurs.
Précisez ce que les réponses peuvent changer. Si toutes les décisions sont déjà prises, l’entretien risque de devenir une présentation commerciale déguisée. Réservez une place aux constats qui conduiraient à réduire, modifier ou abandonner une fonctionnalité.
Pour approfondir : GOV.UK — conduire des entretiens approfondis
Recruter des situations différentes
Sélectionnez les participants selon leur expérience du problème. Incluez des utilisateurs actifs, des personnes qui ont abandonné et, lorsque cela sert la question, des prospects ayant choisi une alternative. Les clients les plus disponibles ne représentent pas automatiquement le public visé.
Préparez les informations nécessaires au consentement et à la confidentialité des échanges. Demandez uniquement les documents utiles, en évitant les données sensibles lorsque leur présence n’apporte rien à l’analyse. Un enregistrement peut faciliter la synthèse, mais il n’est pas indispensable à chaque entretien.
Reconstituer un épisode plutôt qu’une préférence
Commencez par « Racontez la dernière fois où… », puis suivez la chronologie : déclencheur, personnes impliquées, outils, difficulté, résolution. Demandez ce qui s’est passé lorsque l’étape a échoué. Les conséquences concrètes renseignent sur l’importance du problème.
Évitez les questions qui contiennent leur réponse, comme demander si une automatisation serait utile. Cherchez plutôt ce que la personne a déjà essayé, le temps mobilisé et les validations nécessaires. Une proposition de fonctionnalité devient une piste à examiner, pas une commande à ajouter directement au backlog.
| Parole entendue | Question à approfondir | Test possible |
|---|---|---|
| Il faut un export | À qui sert le fichier ? | Observer la transmission |
| Le produit est lent | À quelle étape et avec quelle donnée ? | Mesurer le parcours réel |
| Je voudrais une alerte | Quelle décision attend l’information ? | Tester le moment et le destinataire |
Cas pratique : une demande d’export révèle un autre besoin
Scénario fictif : plusieurs utilisateurs réclament un export supplémentaire. L’équipe suppose qu’un nouveau format suffira. Les entretiens montrent que les fichiers servent à obtenir une validation auprès d’un responsable qui ne possède pas de compte sur le produit.
Deux solutions deviennent alors comparables : améliorer l’export ou créer un parcours de lecture et de validation adapté. La recherche n’a pas choisi à la place de l’équipe ; elle a révélé la tâche à accomplir et les contraintes. Un prototype limité peut départager les options avant développement.
Synthétiser sans gommer les contradictions
Distinguez observation, citation, interprétation et hypothèse. Regroupez les situations comparables, puis examinez les divergences. Une personne peut avoir un accès administrateur qu’une autre n’a pas ; cette différence explique parfois davantage que son opinion sur l’interface.
Conservez la provenance de chaque constat dans des notes accessibles aux personnes autorisées. Ne transformez pas quelques entretiens qualitatifs en pourcentages représentatifs du marché. La répétition d’un mécanisme mérite un test, tandis qu’un cas isolé peut rester critique s’il bloque une opération essentielle.
Passer du constat à un essai produit
Formulez une hypothèse avec un public, un changement et un résultat attendu. Définissez ce qui permettrait de la contredire. Un test de prototype vérifie la compréhension et l’usage prévu ; un usage réel permet ensuite d’examiner les contraintes de travail et les résultats obtenus.
Reliez l’apprentissage à la feuille de route. Le livrable n’est pas seulement une présentation d’entretiens : c’est une décision, ses preuves et les questions restantes. Ce suivi évite de redécouvrir le même problème quelques mois plus tard.
Votre plan d’action
- Associer les entretiens à une décision ouverte.
- Recruter selon les situations vécues.
- Reconstituer des épisodes récents.
- Séparer observations et interprétations.
- Définir le prochain essai à partir des constats.
Sources et références
Notions utiles dans le lexique
Startup & produit
Backlog
Liste ordonnée des éléments de travail envisagés pour un produit ou un service.
Faites des entretiens un outil de décision produit.
Vous recevez des demandes contradictoires ou souhaitez mieux comprendre vos utilisateurs ? Contactez StartHub pour vous faire accompagner dans la préparation des entretiens, leur analyse et le choix des tests produit.
Contacter StartHub

