Tests d'utilisabilité sans laboratoire : guide du débutant

Par l'équipe FabricLoop  ·  Mai 2026  ·  4 min de lecture

Les tests d'utilisabilité ont une réputation d'être coûteux et lents, injustifiée. Quand on parle de « recherche utilisateur », on imagine un miroir sans tain, un modérateur avec son bloc-notes et un calendrier de deux semaines. Cette version des tests existe et a son utilité — mais ce n'est pas celle dont la plupart des équipes produit ont besoin la plupart du temps.

La version dont la plupart des équipes ont besoin est plus simple : cinq utilisateurs, un prototype Figma ou un environnement de préproduction, un appel vidéo et 45 minutes par session. Bien menée, elle met au jour la majorité des problèmes d'utilisabilité sérieux avant la mise en production. Pratiquée régulièrement — ne serait-ce qu'une fois par sprint — elle produit une amélioration cumulative de la qualité du produit qu'aucune analyse post-lancement ne peut égaler.

Voici comment la mettre en place de zéro.

Une session de test en quatre étapes

Étape 1 : recruter — qui vous testez compte plus que le nombre

Cinq participants, c'est le bon nombre pour la plupart des tests d'utilisabilité. Les recherches de Jakob Nielsen ont établi que cinq utilisateurs révèlent environ 85 % des problèmes d'utilisabilité, avec des rendements décroissants ensuite. Mener trois sessions de cinq utilisateurs à différents moments du processus de conception a plus de valeur qu'une seule session avec quinze.

Les critères de recrutement comptent plus que le nombre. Un test d'utilisabilité avec cinq personnes qui correspondent de près à votre utilisateur cible révélera de vrais problèmes. Un test avec quinze personnes qui ne correspondent pas ne produira que du bruit. Définissez deux ou trois critères de sélection — rôle, contexte d'utilisation, aisance technique — et tenez-vous-y.

La voie de recrutement la plus rapide pour la plupart des équipes consiste à écrire aux utilisateurs existants qui ont accepté d'être contactés. Proposez une contrepartie modeste — une carte cadeau de £20 suffit pour une session de 45 minutes. Essayez de programmer les sessions dans la même semaine ; plus l'écart entre le recrutement et le test est long, plus le taux d'absence est élevé.

Étape 2 : rédiger le script — des scénarios, pas des instructions

L'erreur la plus courante dans la rédaction du script est d'écrire les tâches comme des instructions : « Cliquez sur Paramètres, puis allez dans Notifications, et changez votre préférence pour... » Cela dit à l'utilisateur quoi faire, ce qui signifie que vous testez sa capacité à suivre des consignes, et non le caractère intuitif de l'interface.

Rédigez plutôt les tâches sous forme de scénarios : « Imaginez que vous receviez trop de notifications et que vous souhaitiez n'être alerté que lorsqu'on vous mentionne directement. Montrez-moi ce que vous feriez. » L'utilisateur a ainsi un objectif réaliste, et vous pouvez observer comment il navigue réellement — y compris là où il se perd.

Étape 3 : mener la session — votre rôle est d'observer, pas d'aider

Le plus difficile, quand on anime un test d'utilisabilité, est de résister à l'envie d'aider. Quand un utilisateur est perdu, tout votre instinct vous pousse à intervenir et à lui montrer où cliquer. Mais cette confusion, ce sont les données. Un utilisateur qui peine vous dit que quelque chose cloche dans l'interface — et dès que vous intervenez, vous perdez le signal.

Demandez aux utilisateurs de penser à voix haute tout au long de la session : « Au fur et à mesure, dites-moi simplement ce que vous regardez et ce que vous pensez. » Vous obtenez ainsi un flux continu de données sur leur modèle mental. Notez non seulement les erreurs, mais aussi les hésitations — un utilisateur qui marque une pause de trois secondes avant de cliquer sur le bon bouton a malgré tout révélé un problème de conception, même s'il a fini par y arriver.

Étape 4 : faire la synthèse — des tendances, pas des citations

L'étape de synthèse est celle où se crée l'essentiel de la valeur — et celle où la plupart des équipes font des économies de bouts de chandelle. Les notes brutes de cinq sessions ne sont pas des résultats. Elles le deviennent lorsque vous faites un débriefing en équipe, regroupez les observations par thème et attribuez un niveau de gravité.

Faites le débriefing le jour même des sessions, tant que les observations sont fraîches. Classez les problèmes en trois catégories : critiques (les utilisateurs n'ont pas pu accomplir la tâche), modérés (les utilisateurs ont accompli la tâche, mais avec une difficulté importante ou une erreur) et mineurs (une gêne qui n'a pas empêché d'aller au bout). Les problèmes critiques doivent être corrigés avant le lancement. Les problèmes modérés doivent être priorisés lors du prochain sprint. Les problèmes mineurs vont dans le backlog.

Consignez les résultats sur une seule page : les trois principaux problèmes critiques, avec des éléments observés chez au moins deux participants pour chacun, et une modification de conception proposée pour chacun. Tout ce qui demande plus de place va dans un document à part.