Recherche utilisateur (user research)

La recherche utilisateur (user research) regroupe les méthodes qui servent à observer et interroger les personnes qui utilisent un produit, pour comprendre ce dont elles ont réellement besoin. Entretiens, tests d’utilisabilité, observation sur le terrain, analyse des comportements dans l’outil : l’objectif ne change pas d’une méthode à l’autre, il s’agit de remplacer les suppositions de l’équipe par des faits vérifiables.

Sa valeur tient à un constat un peu dérangeant : les gens décrivent mal leur propre comportement. Pas par mauvaise foi, simplement parce que personne ne se souvient précisément de ce qu’il a fait hier matin devant son écran. Une recherche bien menée mesure cet écart entre le discours et l’usage, et c’est souvent là que se cachent les décisions produit les plus rentables.

Ce que les utilisateurs disent, ce qu’ils font

Demandez à dix personnes si elles consulteraient une documentation intégrée au produit. Neuf répondront oui. Regardez ensuite les données d’usage : presque personne ne l’ouvre. L’écart n’est pas un mensonge, c’est la distance normale entre une intention et une habitude.

Toute la discipline découle de là. Les méthodes déclaratives donnent accès aux motivations, aux critères de choix et au vocabulaire employé ; les méthodes comportementales donnent accès aux gestes réels. Une équipe qui n’en utilise qu’une seule famille se fabrique une image fausse de ses utilisateurs.

Un exemple. L’entretien vous apprend pourquoi un client a choisi votre outil plutôt qu’un tableur partagé ; le test d’utilisabilité vous montre qu’il n’a jamais trouvé le bouton d’export. Les deux sont vrais en même temps et servent à des décisions différentes. C’est cette double lecture qui rend la recherche utile au travail d’UX design, pas seulement aux discussions stratégiques.

Les quatre familles de méthodes de recherche utilisateur

Christian Rohrer, du Nielsen Norman Group, a proposé une grille devenue une référence pour classer les méthodes : le déclaratif face au comportemental sur un axe, le qualitatif face au quantitatif sur l’autre. Quatre cases, chacune avec ses usages et ses angles morts.

Déclaratif et qualitatif : l’entretien utilisateur

Une conversation de quarante-cinq minutes à une heure, guidée par des questions ouvertes. La règle la plus utile tient en une ligne : ne demandez jamais ce que la personne voudrait, faites-lui raconter ce qu’elle a fait. « Racontez-moi la dernière fois que vous avez préparé ce rapport » donne de la matière exploitable. « Est-ce qu’un générateur de rapports vous intéresserait ? » donne une réponse polie.

L’intervieweur parle peu, relance sur les hésitations et note les mots exacts. Ces verbatims serviront plus tard à écrire les libellés de l’interface, ce qui évite le décalage classique entre le vocabulaire de l’équipe et celui du métier. C’est le socle de toute discovery produit sérieuse.

Comportemental et qualitatif : le test d’utilisabilité

On confie une tâche à réaliser sur le produit ou sur un prototype, puis on se tait. « Créez un projet et invitez un collègue. » Aucune aide, aucune correction. On regarde où la personne hésite, ce qu’elle cherche, ce qu’elle clique par erreur.

Cette méthode a un avantage politique rarement mentionné : elle met fin aux débats d’opinion. Trente secondes de vidéo où un utilisateur cherche un bouton, devant toute l’équipe, valent mieux que deux heures de réunion. C’est particulièrement vrai pour l’onboarding, dont les premiers écrans paraissent toujours évidents à ceux qui les ont conçus. Notre guide sur un onboarding SaaS qui convertit détaille ce que ces tests font remonter.

Comportemental et quantitatif : l’analyse des usages

Les données d’usage disent combien de personnes franchissent une étape, où elles s’arrêtent et quelles fonctionnalités dorment depuis six mois. Encore faut-il que les événements soient correctement instrumentés : un outil d’analytics mal configuré produit des courbes rassurantes et fausses, ce qui est pire que pas de données.

L’A/B testing appartient à la même famille. Il tranche entre deux variantes sur un objectif mesurable, mais il réclame du volume. En dessous de quelques milliers de visiteurs par variante, l’écart observé relève surtout du hasard.

Déclaratif et quantitatif : les questionnaires

Rapides, peu coûteux, pratiques pour mesurer une satisfaction ou dimensionner un segment. Leur limite est structurelle : un questionnaire ne découvre rien, il confirme ou infirme ce que vous saviez déjà formuler comme question. Il vient après les entretiens, jamais à leur place.

Deux méthodes complètent utilement ce tableau. Le tri de cartes (card sorting) fait organiser les contenus par les utilisateurs eux-mêmes et sert à concevoir la navigation. L’observation en contexte, plus exigeante, consiste à passer une demi-journée assis à côté de quelqu’un pendant qu’il travaille. C’est la seule technique qui révèle les tableurs parallèles, les copier-coller et les contournements que personne ne pense à mentionner en entretien parce qu’ils sont devenus invisibles.

Combien de participants faut-il vraiment

Pour un test d’utilisabilité, la règle des cinq utilisateurs formulée par Jakob Nielsen en 2000 tient toujours : cinq personnes font apparaître environ 85 % des problèmes d’une interface, et les suivantes répètent largement les mêmes constats. Un détail change tout, pourtant, et il est souvent oublié : ce chiffre vaut par profil. Si votre produit sert à la fois des administrateurs et des utilisateurs finaux, comptez cinq de chaque.

Pour des entretiens exploratoires, visez plutôt dix à quinze personnes par segment. Le bon critère d’arrêt n’est pas un nombre mais la saturation : quand deux entretiens consécutifs n’apportent plus rien de neuf, continuez sur un autre profil.

Pour tout ce qui est quantitatif, la logique s’inverse : quelques centaines de réponses au minimum pour un questionnaire, plusieurs milliers d’utilisateurs par variante pour un test A/B. Une expérimentation lancée sur 200 visiteurs ne mesure rien, même si l’outil affiche un gagnant.

Le recrutement, vrai goulot d’étranglement

Les équipes se trompent rarement de méthode. Elles se cassent les dents sur un point beaucoup plus prosaïque : trouver des gens à qui parler. C’est ce qui transforme une étude de trois semaines en chantier de deux mois.

Les sources qui fonctionnent, par ordre de facilité : les clients actuels, que votre support sait identifier en cinq minutes ; les utilisateurs qui viennent de partir, de loin les plus instructifs et étonnamment disponibles ; les prospects perdus en fin de cycle commercial ; les panels payants quand rien d’autre n’est accessible. Prévoyez une contrepartie, même symbolique, et un taux de désistement autour de 30 %.

Un point juridique passe souvent à la trappe. Enregistrer un entretien suppose d’informer la personne de l’usage prévu, de recueillir son accord et de fixer une durée de conservation : le RGPD s’applique aux verbatims comme au reste des données personnelles. Une phrase claire en ouverture de session et une case à cocher suffisent, mais elles ne sont pas optionnelles.

Transformer les observations en décisions

Une recherche qui se termine en document de quarante pages n’a servi à rien. Le seul critère de réussite qui compte, c’est le nombre de décisions qu’elle a modifiées.

Les livrables efficaces sont courts. Un persona tient sur une page et décrit un comportement, pas une couleur de cheveux. Une carte de parcours montre où la friction se concentre. Un rapport d’insights liste trois à cinq problèmes majeurs, classés par fréquence, avec les citations qui les illustrent.

Le reste est une affaire de circulation. Les user stories écrites à partir d’observations gardent la trace de leur origine et se discutent mieux. Les extraits vidéo de vingt secondes voyagent plus loin qu’une synthèse écrite. Et la priorisation des fonctionnalités devient nettement moins politique quand la moitié de l’équipe a entendu les mêmes utilisateurs dire la même chose.

Ce que l’IA a changé depuis 2024

Deux gains sont bien réels. La transcription et le premier tri thématique d’une dizaine d’entretiens demandaient deux à trois jours de travail ingrat ; ils tiennent aujourd’hui dans une heure. Les plateformes de test non modéré, elles, permettent de lancer une série de sessions le mardi et de regarder les vidéos le mercredi, sans caler d’agendas.

La contrepartie mérite d’être connue. Un modèle de langage lisse ce qu’il résume : il conserve les thèmes récurrents et gomme les exceptions, alors que la remarque isolée d’un seul participant est parfois le signal le plus précieux de toute l’étude. Servez-vous de l’IA pour dégrossir le matériau, jamais pour trancher à votre place. Et méfiez-vous des utilisateurs simulés vendus comme substituts aux vrais : ils produisent des réponses moyennes et plausibles, exactement l’inverse de ce qu’on cherche en recherche utilisateur.

Les erreurs qui reviennent le plus souvent

Chercher une validation plutôt qu’une information arrive en tête. Se présenter en entretien avec une solution à faire approuver garantit un retour positif et sans valeur. La bonne posture consiste à essayer activement de se tromper.

N’interroger que les utilisateurs contents vient juste après. Ceux qui restent confirment vos hypothèses ; ceux qui sont partis au bout de trois semaines expliquent ce qui manquait, sans ménagement. Ce sont les entretiens les plus désagréables et les plus rentables.

Attendre la fin du développement pour tester limite mécaniquement les corrections possibles : quand le code est écrit, on ajuste des libellés et des marges, pas une architecture de navigation.

Garder les résultats pour soi annule tout le travail. Une restitution courte avec des verbatims bruts fait plus d’effet qu’un rapport complet que personne n’ouvrira.

FAQ recherche utilisateur

Quelle différence entre recherche utilisateur et discovery produit ?

La recherche utilisateur est une discipline et une boîte à outils : entretiens, tests d’utilisabilité, analyse des comportements, questionnaires. La discovery produit est le processus de décision qui mobilise ces outils pour choisir quoi construire. Toute discovery s’appuie sur de la recherche utilisateur ; toute recherche utilisateur ne débouche pas sur une décision de développement, certaines servent simplement à comprendre un usage.

Peut-on faire de la recherche utilisateur sans chercheur dédié ni budget ?

Oui, et c’est le cas dans la grande majorité des PME et des startups. Cinq tests d’utilisabilité menés par le fondateur sur un prototype cliquable coûtent une journée et changent souvent le périmètre d’une version. Les deux compétences à acquérir sont la formulation de questions non orientées et la discipline de ne pas aider le participant pendant un test. Le livre Just Enough Research d’Erika Hall reste une bonne porte d’entrée pour débuter.

À quelle fréquence faut-il mener de la recherche utilisateur ?

En continu plutôt qu’en campagnes. Deux à quatre conversations utilisateurs par semaine suffisent à maintenir une équipe au contact du terrain, et ce rythme évite l’effet photo périmée d’une étude menée une fois au lancement. Entre ces sessions, le feedback utilisateur spontané remonté par le support fournit la matière pour choisir les prochains sujets à creuser.

Comment Polara Studio pratique la recherche utilisateur

Chez Polara Studio, aucun projet ne démarre sans avoir parlé aux utilisateurs finaux. Pas aux commanditaires, aux utilisateurs finaux : confondre les deux est à l’origine de beaucoup de produits que personne n’adopte.

Nous menons dix à quinze entretiens en début de mission, et les développeurs assistent à une partie des sessions. Cela allonge un peu les premières semaines, et cela change la qualité des solutions proposées ensuite : une équipe technique qui a entendu le problème propose souvent plus simple que ce qui était prévu au cadrage.

Pendant la conception, chaque flux critique passe par cinq tests d’utilisabilité sur maquette cliquable avant d’être développé. Corriger un parcours à ce stade prend une demi-journée. Après le lancement, la boucle continue avec les données d’usage d’un côté, les entretiens avec les utilisateurs actifs et les partants de l’autre.

Ce fonctionnement sert directement à cadrer un MVP sur des besoins vérifiés plutôt que sur une liste d’envies, et c’est ce qui raccourcit le chemin vers le product-market fit. Notre guide sur la création d’un MVP détaille la manière dont ces observations se traduisent en périmètre de première version.