Mon article en bref
Le user research, ou recherche utilisateur, rassemble les méthodes qui produisent des observations vérifiées sur les utilisateurs d’un produit. Il n’existe pas de méthode universelle : il existe une méthode adaptée à une question donnée, et tout l’enjeu consiste à formuler la question avant de choisir l’outil.
Voici les points essentiels à retenir :
- Définition : l’étude méthodique des besoins, des comportements et des blocages réels des utilisateurs, pour fonder les décisions produit sur des faits.
- Deux familles de données : le qualitatif explique pourquoi, le quantitatif mesure combien. Les deux se complètent, aucun ne remplace l’autre.
- Deux moments : la recherche générative précède la solution, la recherche évaluative juge une solution existante.
- Les méthodes de base : entretien utilisateur, observation de terrain, journal de bord, questionnaire, données d’usage, test d’utilisabilité.
- User research ≠ user testing : le test utilisateur est une méthode parmi d’autres, pas un synonyme de la discipline.
- Le critère de choix : partir de la question de recherche, jamais de la méthode que l’équipe maîtrise déjà.
Le user research, ou recherche utilisateur en français, est l’ensemble des méthodes d’investigation qui permettent de comprendre les besoins, les comportements et les difficultés réelles des utilisateurs d’un produit. Son objectif est de fonder les décisions de conception sur des observations vérifiées plutôt que sur les intuitions de l’équipe qui construit.
Reste la vraie question, celle qui bloque les équipes au moment de se lancer : quelles méthodes existent, et laquelle choisir pour la question que l’on se pose ? C’est l’objet de cet article. La phase de cadrage dans laquelle cette recherche s’inscrit, je l’ai traitée à part dans mon article sur le product discovery — ici, on parle des méthodes elles-mêmes et du critère qui permet de trancher entre elles.
Sommaire
Qu’est-ce que le user research ? Définition

Le user research regroupe les méthodes qui produisent des données sur les utilisateurs réels d’un produit : ce qu’ils cherchent à accomplir, comment ils s’y prennent, et ce qui les bloque. Ce ne sont pas des avis recueillis au fil de l’eau. Ce sont des observations obtenues dans un cadre défini, avec une question de recherche posée à l’avance et un protocole que quelqu’un d’autre pourrait rejouer.
L’objectif n’est pas de demander aux utilisateurs ce qu’ils veulent, ni de leur faire valider un projet déjà décidé. Il est de réduire l’incertitude avant d’engager du temps de développement. Une équipe qui conçoit sans recherche ne travaille pas sans hypothèses : elle travaille avec des hypothèses non vérifiées, formulées par des personnes qui ne sont pas ses utilisateurs.
User research, UX research, recherche utilisateur : le même objet
Les trois expressions désignent la même pratique. UX research met l’accent sur l’expérience produite par le produit, user research sur la personne qui l’utilise, et recherche utilisateur est simplement la forme française des deux. Dans le secteur public, on parle plutôt de recherche usager ; l’équipe design de l’État en fait d’ailleurs l’un des piliers de son approche du design centré sur les usagers. Le vocabulaire varie d’une organisation à l’autre, le périmètre non.
Une confusion mérite en revanche d’être levée : la recherche utilisateur n’est pas une étude de marché. L’étude de marché s’intéresse à un marché, à des segments et à une intention d’achat, souvent à l’échelle d’une population. La recherche utilisateur s’intéresse à l’usage : elle observe une poignée de personnes en train de se débrouiller avec un produit, ou avec le problème que ce produit prétend résoudre.
Ce que la recherche utilisateur permet de décider
Une recherche ne vaut que par la décision qu’elle éclaire. En pratique, elle en alimente trois : quel problème traiter et lequel écarter, à quoi doit ressembler la solution, et si la solution livrée tient sa promesse. C’est à ce titre qu’elle constitue l’outillage de la phase de discovery : la discovery est le cadre de travail, le user research fournit les méthodes qui le remplissent.
Elle se distingue aussi de deux dispositifs voisins avec lesquels elle est souvent confondue. Le retour client arrive spontanément, sans question posée : il signale un irritant mais ne dit ni son ampleur ni sa cause. Le voice of customer organise l’écoute en continu de ces signaux. La recherche utilisateur, elle, part d’une question choisie et va chercher la réponse là où elle se trouve.
Les principales méthodes de user research

Il existe des dizaines de méthodes de recherche utilisateur, mais elles se rangent dans un petit nombre de familles. Les distinguer suffit à s’orienter : chacune répond à un type de question, et aucune ne répond à toutes. Voici les quatre familles que l’on rencontre dans la quasi-totalité des équipes produit.
L’entretien utilisateur : comprendre le pourquoi
L’entretien utilisateur est un échange individuel, semi-directif, de trente à soixante minutes, mené à partir d’un guide de questions ouvertes. C’est la méthode la plus courante, et probablement la plus mal employée : sa difficulté n’est pas de faire parler les gens, mais de les faire parler de ce qu’ils ont réellement fait, plutôt que de ce qu’ils imaginent faire. Le job to be done offre un angle d’attaque efficace pour cela : on interroge la tâche à accomplir, pas l’opinion sur le produit.
- Formuler la question de recherche — une seule, écrite noir sur blanc, avant de rédiger le guide.
- Recruter les bonnes personnes — des utilisateurs du comportement étudié, pas les cinq collègues disponibles jeudi.
- Écrire un guide, pas un questionnaire — des questions ouvertes sur le passé récent, ordonnées du général au précis. La grille QQOQCP aide à couvrir le contexte sans le suggérer.
- Mener l’entretien à deux — l’un anime, l’autre prend des notes verbatim ; l’enregistrement ne dispense pas de la prise de notes.
- Analyser à chaud — regrouper les observations en thèmes juste après, tant que le contexte est frais.
Quatre erreurs suffisent à ruiner un entretien, et elles reviennent presque toujours :
- Poser des questions sur le futur — « utiliseriez-vous cette fonctionnalité ? » ne produit que de la politesse. « Racontez-moi la dernière fois que… » produit un fait.
- Présenter la solution trop tôt — dès qu’une maquette est sur la table, l’entretien devient un test et l’exploration s’arrête.
- Chercher la confirmation — reformuler jusqu’à obtenir l’accord de l’interlocuteur revient à s’interviewer soi-même.
- Ne rien faire des notes — sans temps d’analyse partagé, un entretien reste une anecdote que chacun citera à l’appui de son avis.
La conduite d’entretien est une compétence qui s’entraîne, et la documentation du Nielsen Norman Group sur la technique d’entretien reste la référence sur le sujet. Pour l’analyse, l’affinity diagram est l’outil le plus simple : on écrit chaque observation sur une note, puis on laisse les regroupements émerger.
En vidéo : la formation d’introduction à la recherche utilisateur de l’équipe design de l’État — poser les bonnes questions, choisir les méthodes, recruter les bons participants (chaîne DesignGouv).
L’observation de terrain : voir ce que personne ne raconte
Les méthodes d’observation consistent à regarder les utilisateurs travailler dans leur environnement réel, sans scénario imposé. On y range l’observation contextuelle (l’observateur accompagne la personne sur son poste de travail), le shadowing (on suit une journée entière) et le journal de bord, ou diary study, où l’utilisateur consigne lui-même ses usages pendant plusieurs semaines.
Leur intérêt est de faire apparaître ce que l’entretien laisse toujours passer : les contournements, les tableurs parallèles, les post-it collés sur l’écran, les gestes devenus si automatiques que personne ne songe à les mentionner. C’est la famille de méthodes la plus coûteuse en temps, et la plus difficile à remplacer quand l’usage se déroule hors de l’écran. Sur un parcours long ou multicanal, ces observations alimentent directement un customer journey map.
Les méthodes quantitatives : mesurer l’ampleur
Le qualitatif explique un phénomène ; il ne dit pas combien de personnes il concerne. C’est le rôle des méthodes quantitatives : questionnaire à large échantillon, analyse des données d’usage déjà présentes dans le produit, tri par cartes en ligne, ou indicateurs de satisfaction comme le Net Promoter Score. Elles répondent à « combien », « à quelle fréquence », « quelle proportion ».
Elles ont une limite symétrique : un chiffre signale un endroit où regarder, il n’explique jamais pourquoi. Constater qu’une large majorité d’utilisateurs abandonne un formulaire ne dit pas ce qui les arrête. Le risque est alors de collectionner des indicateurs flatteurs qui ne changent aucune décision — les vanity metrics. Un chiffre utile est un chiffre qui déclenche une question qualitative.
Les méthodes évaluatives : juger une solution existante
Cette dernière famille suppose qu’il existe déjà quelque chose à évaluer : une maquette, un prototype, une version en ligne. On y trouve le test d’utilisabilité, où l’on confie une tâche à un utilisateur et où l’on observe sans l’aider ; le test de concept, qui confronte une idée à sa cible avant de la développer ; le tree testing, qui vérifie qu’une arborescence est navigable ; le test A/B, qui compare deux versions sur du trafic réel ; et la phase de beta testing, qui expose la solution à un panel élargi avant l’ouverture générale.
User research vs user testing : quelle différence ?

Le user research est la discipline entière : toutes les méthodes qui produisent de la connaissance sur les utilisateurs. Le user testing, ou test utilisateur, en est une seule méthode : faire réaliser des tâches sur une solution existante pour repérer les points de blocage. Le premier contient le second — les employer comme synonymes revient à réduire la recherche à sa phase d’évaluation.
La confusion n’est pas anodine, parce qu’elle a une conséquence pratique. Une équipe qui ne pratique que le test utilisateur teste bien, mais toujours trop tard : elle évalue des solutions déjà conçues, sur des problèmes que personne n’a vérifiés. Elle améliore l’exécution sans jamais interroger la pertinence — c’est exactement la dérive de la feature factory, où l’on livre efficacement des fonctionnalités dont l’utilité n’a jamais été établie.
Un test utilisateur vous dira si votre solution est utilisable. Il ne vous dira jamais si elle valait la peine d’être construite.
Concrètement, quatre questions échappent par construction au test utilisateur :
- Le problème est-il réel ? Le test part d’une solution ; il présuppose que le problème existe.
- Quelle est son ampleur ? Cinq participants révèlent des blocages, ils ne mesurent pas une population.
- Quelles alternatives les gens utilisent-ils déjà ? Cela s’observe sur le terrain, pas dans une salle de test.
- Que se passe-t-il après la session ? L’usage réel s’étale sur des semaines ; le test dure une heure.
Les deux termes ne s’opposent donc pas : ils ne se situent pas au même niveau. Le test utilisateur détecte vite et à peu de frais ce qui coince dans une interface ; les autres questions se traitent avec d’autres méthodes.
Comment choisir la bonne méthode de recherche ?

La méthode se déduit de la question, jamais l’inverse. Écrivez d’abord ce que vous cherchez à savoir en une phrase, puis situez cette phrase sur deux axes : cherchez-vous à comprendre ou à mesurer, et travaillez-vous avant ou après l’existence d’une solution ? Le croisement des deux réponses désigne la méthode.
Les deux axes qui suffisent à trancher
Le premier axe oppose le qualitatif au quantitatif : le qualitatif explique un comportement à partir d’un petit nombre d’observations directes, le quantitatif le dénombre à partir d’un instrument de mesure. Le second axe oppose la recherche générative, qui explore un problème avant qu’une solution existe, à la recherche évaluative, qui juge une solution déjà formulée. Le Nielsen Norman Group formalise ce raisonnement dans son panorama des méthodes de recherche UX et de leurs usages, qui distingue en outre les phases générative, formative et sommative d’un produit.
| Votre question | Type de recherche | Méthodes adaptées |
|---|---|---|
| « Quel problème mérite d’être traité ? » | Qualitative, générative | Entretien utilisateur, observation de terrain, journal de bord |
| « Combien d’utilisateurs sont concernés ? » | Quantitative, générative | Questionnaire, analyse des données d’usage, tri par cartes |
| « Pourquoi bloquent-ils à cette étape ? » | Qualitative, évaluative | Test d’utilisabilité modéré, test de concept, entretien post-test |
| « Cette version fait-elle mieux que l’autre ? » | Quantitative, évaluative | Test A/B, tunnel de conversion, questionnaire de satisfaction |
Quelle méthode pour votre question ?
Le piège du déclaratif
Un troisième axe, plus discret, explique bien des recherches décevantes : la différence entre ce que les gens disent et ce qu’ils font. Un questionnaire, un focus group ou un entretien mal mené recueillent des déclarations ; un test d’utilisabilité, une observation de terrain ou des données d’usage enregistrent des comportements. Les deux sont utiles, mais on ne les traite pas de la même façon, et on ne décide jamais d’un investissement lourd sur la seule base du déclaratif.
💡 Le test de la décision — avant de lancer une étude, écrivez la décision qu’elle doit permettre de prendre et les deux issues possibles. Si aucun résultat ne changerait quoi que ce soit à ce que l’équipe va faire, l’étude n’a pas besoin d’être menée.
Combiner plutôt qu’opposer
Dans la pratique, les méthodes fonctionnent en séquence. Les données d’usage repèrent une anomalie, quelques entretiens en expliquent la cause, un test d’utilisabilité valide la correction envisagée, un test A/B en mesure l’effet. C’est cette alternance qui donne sa robustesse à la démarche : le quantitatif indique où chercher, le qualitatif explique ce qu’on y trouve.
À mon sens, l’erreur la plus coûteuse n’est pas de choisir une méthode mal adaptée : c’est de choisir une méthode avant d’avoir écrit la question. Une équipe qui formule sa question de recherche en une phrase trouve presque toujours la méthode toute seule — et découvre parfois qu’elle connaissait déjà la réponse.
FAQ — Tout savoir sur le user research
Quelle différence entre UX research et user research ?
Aucune en pratique : les deux expressions désignent l’étude méthodique des utilisateurs pour éclairer la conception. « UX research » insiste sur l’expérience produite, « user research » sur la personne observée. « Recherche utilisateur » est la traduction française employée pour les deux.
Quelles sont les principales méthodes de user research ?
Quatre familles couvrent l’essentiel des besoins : l’entretien utilisateur, l’observation de terrain (observation contextuelle, shadowing, journal de bord), les méthodes quantitatives (questionnaire, données d’usage, tri par cartes) et les méthodes évaluatives (test d’utilisabilité, test de concept, tree testing, test A/B).
Combien de participants faut-il pour une recherche utilisateur ?
Cela dépend du type de recherche. En qualitatif, le Nielsen Norman Group recommande de tester avec cinq utilisateurs par profil, puis d’itérer plutôt que d’allonger la session. En quantitatif, la logique est inverse : il faut un échantillon suffisant pour que la mesure soit exploitable.
Comment mener un entretien utilisateur ?
Formulez une question de recherche unique, recrutez des personnes réellement concernées, rédigez un guide de questions ouvertes portant sur le passé récent, menez la séance à deux, et analysez les notes juste après. Évitez toute question sur les intentions futures : elles ne produisent que des réponses polies.
Quelle est la différence entre user research et user testing ?
Le user research est la discipline, le user testing est l’une de ses méthodes. Le test utilisateur évalue une solution existante en observant des utilisateurs accomplir des tâches ; il ne dit rien de la pertinence du problème traité, ni de l’ampleur de ce problème dans la population.
Qui réalise la recherche utilisateur dans une équipe produit ?
Un UX researcher lorsque le poste existe, sinon le designer produit ou le Product Owner, souvent en binôme. L’essentiel n’est pas le titre : c’est que les personnes qui décident du produit assistent aux séances, car un compte rendu écrit ne remplace jamais le fait d’avoir vu un utilisateur échouer.

