Mon article en bref
Le test d’utilisabilité consiste à confier des tâches à un utilisateur et à l’observer les accomplir sans l’aider. Toute la valeur de la méthode tient dans son protocole : des tâches bien écrites, un observateur silencieux, et une restitution que l’équipe peut transformer en décisions.
Voici les points essentiels à retenir :
- Définition : l’observation d’utilisateurs réels en train d’accomplir des tâches définies sur un produit ou une maquette.
- Le principe du protocole : on écrit des tâches, jamais des questions. « Trouvez… » et non « que pensez-vous de… ».
- La règle de l’observateur : ne pas aider, ne pas expliquer, ne pas répondre. Le silence est l’outil de mesure.
- Le nombre de participants : le Nielsen Norman Group recommande cinq par profil, puis d’itérer — une recommandation, pas une loi.
- La restitution : un problème coté par gravité, formulé comme un problème et non comme une solution, prêt à entrer au backlog.
Un test d’utilisabilité, ou usability testing, est une méthode d’évaluation qui consiste à confier des tâches précises à des utilisateurs représentatifs, puis à observer comment ils s’y prennent sur un produit, un site ou une maquette. L’objectif n’est pas de recueillir leur avis : il est de repérer les endroits exacts où ils échouent, hésitent ou renoncent.
La méthode est simple à décrire et facile à rater. Ce qui sépare une session qui produit une décision d’une session qui produit une conversation aimable, c’est le protocole : la façon d’écrire les tâches, la tenue de l’observateur, le nombre de participants et la forme de la restitution. C’est ce que détaille cet article.
Sommaire
Qu’est-ce qu’un test d’utilisabilité ?
Le test d’utilisabilité — également appelé test utilisateur, test d’usabilité ou test d’ergonomie — évalue la facilité d’usage d’une interface en situation réelle. La norme ISO 9241-11 définit l’utilisabilité comme le degré selon lequel un produit permet à des utilisateurs identifiés d’atteindre des buts définis avec efficacité, efficience et satisfaction. Le test met ces trois dimensions à l’épreuve.
Il ne suppose pas un produit fini : un wireframe imprimé sur papier suffit à révéler qu’un libellé est incompréhensible ou qu’une étape manque. C’est l’intérêt principal de la méthode — elle se pratique tôt, pendant la phase de product discovery, quand corriger ne coûte qu’un déplacement de rectangle. Le test n’est du reste qu’une des méthodes du user research, la recherche utilisateur, qui compte aussi l’entretien, l’observation de terrain ou le questionnaire.
Il répond à une seule famille de questions : les gens y arrivent-ils, et où butent-ils ? Il ne dit ni si la fonctionnalité méritait d’être construite, ni combien d’utilisateurs sont concernés. Il se distingue à ce titre du retour client, qui arrive sans tâche ni cadre, et du beta testing, qui expose une version quasi finie sans observateur.
Test modéré ou non modéré : deux protocoles distincts
En test modéré, un animateur est présent — en salle ou en visioconférence — et peut relancer. En test non modéré, le participant reçoit les consignes par écrit et son écran est enregistré sans témoin. Le second rassemble plus de sessions à moindre coût, mais il interdit toute relance : ses consignes doivent être autoportantes. Un protocole modéré recopié tel quel dans un outil non modéré produit presque toujours des sessions inexploitables.
Écrire des tâches, pas des questions
C’est le point de bascule du protocole, et celui que la plupart des équipes traitent la veille des sessions. Une tâche demande d’agir ; une question demande d’opiner. « Que pensez-vous de cette page ? » met le participant en position d’expert bienveillant : il commentera les couleurs. « Vous voulez réserver un vol pour Genève demain matin : montrez-moi comment vous faites » le met en position d’utilisateur, et son échec devient visible par toute la salle.
Un test d’utilisabilité ne demande pas un avis : il met quelqu’un en difficulté et regarde comment il s’en sort.
Dès que la consigne dit « cliquez sur l’icône de compte », vous ne testez plus la découvrabilité de l’icône : vous testez la capacité à suivre une instruction.
L’anatomie d’une tâche testable
Une tâche exploitable tient en deux ou trois phrases et réunit quatre ingrédients, que la grille QQOQCP aide à vérifier :
- Un contexte crédible — la raison pour laquelle cette personne ferait cela dans la vraie vie, en une phrase.
- Un objectif exprimé comme un résultat et non comme un chemin : « obtenir un devis », pas « remplir le formulaire de devis ».
- Un critère de réussite observable, écrit à l’avance, qui permet de trancher sans débat pendant l’analyse.
- Le vocabulaire du domaine métier, jamais celui de la maquette : ni nom de bouton, ni nom d’onglet, aucun terme affiché à l’écran.
Leur choix ne s’improvise pas davantage : on les tire des parcours critiques, ceux que décrit un customer journey map ou que priorise la spec produit. Un test qui explore des recoins secondaires est un test bien mené sur un sujet sans enjeu.
| Ce qu’on écrit spontanément | La tâche équivalente | Pourquoi c’est mieux |
|---|---|---|
| « Que pensez-vous de la page d’accueil ? » | « Vous arrivez sur ce site pour la première fois. Dites-moi ce que cette entreprise vend, et à qui. » | Rend la compréhension mesurable au lieu de la commenter |
| « Est-ce que le tunnel de commande est clair ? » | « Commandez ce produit en taille M, livré chez vous samedi. » | Produit un parcours observable, avec un critère de réussite net |
| « Trouvez-vous facilement vos factures dans l’espace client ? » | « Vous devez justifier une dépense de mars : récupérez la facture correspondante. » | Ne dit pas où chercher, donc teste la navigation |
| « Cliquez sur Mot de passe oublié et réinitialisez-le. » | « Vous ne vous souvenez plus de votre mot de passe. Reprenez la main sur votre compte. » | Supprime l’indice contenu dans la consigne |
Combien de tâches, et dans quel ordre
Une séance tient rarement au-delà d’une heure : quatre à six tâches constituent un volume raisonnable, en gardant du temps pour les silences et les hésitations, qui sont ce que vous êtes venu voir. Commencez par la plus proche d’un usage naturel, gardez pour la fin les zones que vous soupçonnez fragiles, et veillez à ce qu’aucune tâche ne dépende du succès de la précédente : sinon un échec initial rend toute la suite inexploitable.
Votre tâche est-elle prête à être testée ?
Cochez ce que votre consigne respecte réellement, telle qu’elle est écrite.
La consigne d’ouverture et le silence de l’observateur
Les cinq premières minutes déterminent la qualité de l’heure qui suit. Un participant qui croit passer un examen cherchera à réussir plutôt qu’à se comporter normalement, et masquera ses difficultés.
Le script d’ouverture, point par point
Ce script se lit presque mot à mot d’une session à l’autre, pour que tous partent du même cadre. Il tient en cinq messages :
- Le but, sans le détail — « nous améliorons ce service et nous avons besoin de voir comment il s’utilise ». Pas un mot sur les hypothèses testées.
- C’est le produit qui est évalué, pas vous — ce qui ne fonctionne pas est une information utile.
- Pensez à voix haute — dites ce que vous cherchez, ce que vous attendez, ce qui vous surprend.
- Je ne vous aiderai pas — annoncé d’emblée, le silence cesse d’être vécu comme de la froideur.
- Le consentement — ce qui est enregistré, qui le verra, combien de temps, et l’accord écrit avant d’enregistrer.
L’invitation à penser à voix haute est le cœur du dispositif : elle rend visible le raisonnement, et pas seulement le clic. Le Nielsen Norman Group la présente comme l’outil le plus rentable de la boîte à outils UX. En pratique, elle demande à être relancée : on se tait dès qu’on se concentre.
Ne pas aider : la discipline la plus difficile
Voir quelqu’un chercher pendant quarante secondes un bouton que l’on a soi-même positionné est physiquement inconfortable — et c’est l’observation la plus précieuse de la séance. La règle est absolue : l’observateur ne montre pas, ne nomme pas, ne confirme pas. Et il ne répond pas aux questions : il les retourne.
- « Est-ce que c’est là qu’il faut cliquer ? » → « Qu’est-ce que vous feriez si vous étiez seul chez vous ? »
- « Je ne trouve pas, c’est où ? » → « Où est-ce que vous vous attendiez à le trouver ? »
- Le participant se tait et s’arrête → laissez passer un silence complet : beaucoup de blocages se dénouent seuls, et le déblocage est instructif.
- Le participant abandonne → notez l’abandon comme un résultat, puis débloquez-le.
💡 Tenir la séance à deux — un animateur qui parle, un noteur qui se tait. Celui qui anime ne peut pas prendre de notes fidèles, et celui qui note n’a pas à gérer la relation. Si les décideurs du produit veulent assister, placez-les en observateurs muets : avoir vu un utilisateur échouer vaut tous les comptes rendus écrits.
En vidéo : la préparation d’un test utilisateur pas à pas (chaîne Psychologie numérique). Le cadre s’apprend surtout en le pratiquant : l’équipe Design de l’État propose un atelier de test avec les usagers.
Combien de participants, et pourquoi ?
C’est la première question posée dans toutes les équipes, et la réponse qui circule — « cinq » — est devenue un chiffre magique détaché de son raisonnement d’origine. Or le raisonnement est plus utile que le nombre.
La recommandation des cinq participants du Nielsen Norman Group
Le chiffre vient d’un article de Jakob Nielsen publié en 2000 par le Nielsen Norman Group, qui recommande de tester avec cinq utilisateurs plutôt que d’organiser une seule grande étude. Son modèle estime qu’à cinq participants on a rencontré l’essentiel des problèmes qu’un tel test peut révéler, les suivants apportant surtout de la redondance. D’où une conséquence souvent oubliée : mieux vaut trois études de cinq personnes, entrecoupées de corrections, qu’une seule de quinze.
C’est une recommandation issue d’un modèle, pas une loi. Elle suppose un public homogène et une intention qualitative — repérer des problèmes, non les quantifier. L’article prévoit lui-même l’exception : dès que le produit sert des groupes très différents, cinq ne suffisent plus. Et si l’objectif est de mesurer un taux de réussite, on quitte le registre qualitatif pour un échantillon d’une autre nature.
Cinq par profil, pas cinq en tout
C’est l’erreur de lecture la plus fréquente. Si votre produit sert un acheteur et un gestionnaire de stock, vous avez deux profils dont les tâches et le vocabulaire n’ont rien à voir : cinq personnes au total en donneront deux ou trois par groupe, donc rien de solide sur aucun des deux. Le compte se fait par profil, et le nombre de profils se décide avant le recrutement — dont la qualité compte d’ailleurs davantage que le volume : cinq utilisateurs réellement concernés valent mieux que douze personnes disponibles, et les collègues connaissent le vocabulaire maison, ce qui les disqualifie.
Le test pilote, la session qu’on ne compte pas
Avant la première vraie session, faites tourner le protocole complet avec une personne qui n’a pas participé à sa rédaction. Ce pilote révèle ce qu’on ne voit jamais sur le papier : une tâche comprise de travers, une consigne qui contient un indice, un compte de test inexistant. Ses résultats ne sont pas analysés — ils corrigent le protocole, et cette demi-journée évite de gâcher cinq sessions.
Quoi noter pendant la session
Sans grille préparée, la prise de notes dérive vers ce qui frappe l’observateur et l’analyse tourne au concours d’anecdotes. Une grille d’observation écrite avant la première session force à consigner la même chose pour chacun : c’est ce qui rend les sessions comparables.
La grille d’observation, tâche par tâche
Une ligne par tâche et par participant, avec les mêmes colonnes pour tous. Cinq entrées suffisent, et il faut résister à l’envie d’en ajouter : une grille trop riche ne sera pas remplie.
- Résultat — réussi seul, réussi avec difficulté, réussi après relance, échoué, abandonné. Ces cinq états valent mieux qu’un binaire : « réussi avec difficulté » est le signal le plus intéressant.
- Durée — non pour la comparer à une norme, mais pour repérer les écarts entre participants.
- Chemin emprunté — les étapes réelles, retours en arrière compris, qui racontent l’hésitation mieux qu’un commentaire.
- Verbatim — les mots exacts du participant, entre guillemets, sans reformulation. C’est ce matériau qui rendra la restitution incontestable.
- Moment de friction — l’endroit précis, écran et élément, où la personne a marqué un temps d’arrêt.
Séparer le fait de l’interprétation
C’est la règle d’hygiène qui sauve une analyse. « Elle a cliqué trois fois sur l’image avant d’ouvrir la fiche » est un fait ; « l’image ne semble pas cliquable » est une hypothèse ; « il faut ajouter un bouton » est une solution. Les trois sont utiles, mais ne se mélangent pas : tenez une colonne de faits et notez les hypothèses à part.
Faites-le à chaud : un débriefing de dix minutes entre animateur et noteur, avant le participant suivant, vaut mieux qu’une relecture d’enregistrements trois semaines plus tard.
Restituer des résultats actionnables
Un test bien mené dont la restitution finit dans un document de quarante pages n’a rien changé. Une restitution n’est pas un compte rendu : c’est la liste des problèmes, classée et prête à entrer dans un arbitrage.
Coter la gravité pour pouvoir arbitrer
Une liste non hiérarchisée renvoie l’arbitrage à celui qui parle le plus fort en réunion. Trois critères suffisent à coter chaque problème : sa fréquence (combien de participants l’ont rencontré), son impact (a-t-il ralenti la personne ou l’a-t-il arrêtée) et sa contournabilité (existe-t-il un autre chemin). Le croisement donne trois niveaux lisibles par tous : bloquant, gênant, cosmétique.
Le regroupement précède la cotation : plusieurs observations décrivent souvent le même problème sous des angles différents. Un affinity diagram suffit — une observation par note, puis on laisse les paquets se former.
Un problème, une entrée de backlog
Pour être actionnable, un résultat doit franchir la frontière du backlog sans traduction supplémentaire. Chaque problème retenu s’écrit donc sous une forme fixe : le comportement observé, sur quelle tâche, chez combien de participants, avec un verbatim et le niveau de gravité. La solution vient après, discutée avec ceux qui construisent — et se traduit alors en acceptance criteria vérifiables.
⚠️ Le piège de la solution déguisée en constat — « il faut déplacer le bouton en haut » n’est pas un résultat de test, c’est une proposition. Écrivez le problème : « quatre participants sur cinq ont cherché le bouton dans l’en-tête avant de le trouver en pied de page ». La première formulation ferme la discussion, la seconde l’ouvre en donnant à l’équipe de quoi trancher.
Reste l’erreur qui ruine les meilleures restitutions : la présenter comme la démonstration que les concepteurs se sont trompés. Elle déclenche la défense, la contestation de la méthode et le fameux « ce participant n’était pas représentatif ». Le remède : montrer plutôt que raconter. Trois extraits vidéo de trente secondes où l’on voit trois personnes buter au même endroit produisent une adhésion qu’aucune diapositive n’obtient.
À mon sens, c’est là que se joue la rentabilité de la méthode : un test coûte peu, mais mené sans protocole il se solde par trois semaines de débat sur la validité de ce qu’on a vu.
FAQ — Tout savoir sur le test d’utilisabilité
Quelle différence entre test d’utilisabilité et test utilisateur ?
Dans l’usage courant, aucune : « test d’utilisabilité », « test utilisateur », « test d’usabilité » et « test d’ergonomie » désignent le même dispositif. « Utilisabilité » renvoie à la propriété évaluée, définie par la norme ISO 9241-11 ; « test utilisateur » renvoie à la personne observée. Le terme anglais correspondant est usability testing.
Combien de participants pour un test d’utilisabilité ?
Le Nielsen Norman Group recommande cinq participants par profil d’utilisateur, puis d’itérer : trois études de cinq personnes plutôt qu’une seule de quinze. C’est une recommandation issue d’un modèle, valable pour un test qualitatif sur un public homogène. Si votre produit sert des publics très différents, comptez cinq personnes pour chacun.
Combien de temps doit durer un test d’utilisabilité ?
Une séance dépasse rarement une heure sans que l’attention du participant se dégrade. Prévoyez quatre à six tâches, un temps d’accueil pour la consigne d’ouverture et le consentement, et une marge pour les silences et les questions de fin. Mieux vaut peu de tâches bien observées que beaucoup de tâches expédiées.
Pourquoi demander au participant de penser à voix haute ?
Parce que l’écran ne montre que le résultat de la décision, jamais le raisonnement qui y mène. Entendre « je cherche mon panier, d’habitude c’est en haut à droite » explique un clic que l’enregistrement seul rendrait incompréhensible. Cette consigne demande à être relancée en cours de séance : les gens se taisent dès qu’ils se concentrent.
Peut-on faire un test d’utilisabilité sans produit fini ?
Oui, et c’est même là qu’il rapporte le plus. Une maquette cliquable, un wireframe imprimé ou un prototype papier suffisent à révéler un libellé incompréhensible ou une étape manquante. Plus le test arrive tôt, moins la correction coûte : attendre la mise en production revient à payer le prix maximal de chaque enseignement.
À quoi ressemble un exemple de protocole de test d’utilisabilité ?
Un protocole tient sur deux ou trois pages : l’objectif du test et les questions auxquelles il doit répondre, le profil des participants recherchés et leur nombre, le script d’ouverture, la liste des tâches avec leur critère de réussite, la grille d’observation vierge, et la méthode d’analyse prévue. Il se valide sur un test pilote avant la première vraie session.
