Une personne observe un utilisateur manipuler une interface, un carnet à la main.

Pourquoi vos utilisateurs ne vous disent pas la vérité

Publié le

Valider une idée auprès d'utilisateurs enthousiastes, lancer le développement, et réaliser trop tard que personne ne se sert de l'outil... C'est le grand classique du Product Management. Et quand ça arrive, on cherche souvent la faute ailleurs : le design manquait de clarté, le lancement a été mal communiqué, les utilisateurs ont manqué de temps. Parfois, c'est vrai. Mais souvent, la réponse est plus simple : ils vous ont répondu une chose, et ils en ont fait une autre.

Personne ne sait ce qu'il fera demain

Demandez à quelqu'un s'il utiliserait une fonctionnalité hypothétique, dans un futur hypothétique, avec un contexte inconnu. Il va vous répondre. Il va même vous répondre avec assurance.

En fait, tout le monde est mauvais pour prédire ce qu'il fera demain. Quand quelqu'un vous dit “oui, je l'utiliserais”, il le pense sincèrement.

Ils essaient de vous rendre service

La plupart des utilisateurs que vous interrogez essaient de vous aider. Et vous aider, dans une conversation, ça veut souvent dire : deviner ce que vous voulez entendre, et vous le dire. C'est un biais de politesse. Ça se voit encore plus quand vous êtes le fondateur, ou quand la personne en face sait que vous avez passé six mois sur le sujet.

⚠ Une question qui ne vous apprendra rien : « Est-ce que vous utiliseriez cette fonctionnalité ? » La réponse est presque toujours oui.

Le cerveau adore réécrire son propre quotidien

Quand vous demandez à quelqu'un comment il fait aujourd'hui pour accomplir une tâche, il vous décrit une version rationalisée de ce qu'il fait. Il oublie les étapes pénibles, il simplifie les contournements, il reconstruit un récit cohérent.

C'est simplement le fonctionnement de la mémoire. Le cerveau stocke des histoires plutôt que des événements. Et l'histoire qu'il vous raconte est celle qui le fait paraître compétent, organisé, efficace. Le vrai processus, celui avec les huit onglets ouverts et le copier-coller entre deux outils, vous l'aurez en observant.

L'écart entre ce que les gens disent et ce qu'ils font

Les gens disent qu'ils vont au sport. Ils paient un abonnement et ils y vont une fois par mois. Les gens disent qu'ils lisent. Ils regardent Netflix. Les gens disent qu'ils veulent une fonctionnalité. Ils l'ouvrent une fois et l'oublient.

C'est toute la différence entre l'intention et l'action. Toutes les études le montrent : ce que les gens racontent et ce qu'ils font au quotidien n'ont presque rien à voir. Bâtir sa roadmap sur des déclarations d'intention, c'est construire sur du sable. La seule matière valable, c'est le terrain.

"Compliments are the fool's gold of customer learning: shiny, distracting, and worthless."
, Rob Fitzpatrick, The Mom Test

Arrêtez de leur faire deviner l'avenir

« Utiliseriez-vous cette fonctionnalité ? » est une question presque inutile. « Racontez-moi la dernière fois que vous avez eu ce problème » c'est déjà beaucoup plus utile, elle porte sur un événement réel, avec des détails vérifiables, des émotions, des contournements, des gens impliqués.

Trouvez les contournements

Le meilleur indicateur de besoin, c'est ce qu'ils font déjà malgré vous. Le fichier Excel qu'ils ont construit pour compenser votre outil. Le post-it collé sur l'écran. Le canal Slack parallèle. Le script maison bricolé un vendredi soir et utilisé par toute l'équipe.

Si les utilisateurs ont développé des rustines pour contourner votre produit, c'est qu'il y a un vrai problème.

✓ Ce qu'il faut regarder. Regardez ce que les gens font quand ils ignorent que vous regardez. Le contournement, la rustine, le détour. C'est là que se trouve le besoin réel.

Écouter, c'est accepter les mauvaises nouvelles

Quand on fait de la discovery, on a toujours envie d'entendre ce qu'on espère. Vous posez la question en espérant le feu vert, le client vous le donne, et vous repartez rassuré. Sauf que la discovery, ce n'est pas chercher une validation c'est un processus de compréhension.

Et parfois, comprendre, c'est entendre que le produit rate sa cible, que le besoin est marginal, que les gens s'en fichent. C'est douloureux, surtout quand on a déjà investi. Mais c'est le travail. Chercher des confirmations, c'est se conforter. Comprendre, c'est apprendre.

La décision vous revient

Au fond, vos utilisateurs font de leur mieux pour ne pas vous froisser. Mais ce n'est pas à eux de concevoir votre roadmap. Écoutez-les, observez-les, comprenez leurs galères, mais trancher, c'est votre job.

Vous voulez comprendre ce que vos utilisateurs vous disent à demi-mot ?

Interviews, observation, analyse des contournements : parfois un regard extérieur aide à voir ce que les entretiens laissent dans l'ombre.

Prenons contact
Développeur avec une tasse de café
Post-it de user stories sur un tableau agile, avec un point d'interrogation au centre Le PO n'est pas un designer (et autres vérités bonnes à dire sur l'agilité)

Avec la structure "En tant que… je veux… afin de", le PO se retrouve trop souvent à orienter la solution. Retour sur ce que devrait vraiment être son rôle, et pourquoi le POURQUOI change tout.

Une personne qui observe un tableau de bord de métriques, puis ajuste sa stratégie sur un tableau blanc. Inspection et Adaptation : Le principe qui change tout

L'inspection et l'adaptation ne sont pas réservées aux équipes agiles. Découvrez comment ce principe fondamental transforme la gestion de produit, la stratégie commerciale — et bien au-delà.

Chien avec des lunettes devant un écran Comment prendre du recul sur sa maquette quand on a le nez dedans

On passe des heures dans Figma et on perd le recul. À force de déplacer des pixels, on ne sait plus si ce qu'on fait est utile. Quelques méthodes pour retrouver un regard neuf sur sa maquette.