Organiser un test utilisateur : tâches, scénarios, testeurs

La testeuse cherche le bouton « Commander » depuis quarante secondes. Le fondateur, assis derrière elle, n’y tient plus : « C’est en haut à droite ! » Elle trouve, sourit, termine sa commande. Le test vient de perdre la seule information qui comptait.

Un test utilisateur repose sur une idée simple : de vraies personnes essaient de faire de vraies choses avec votre application, pendant que vous regardez sans intervenir. Il coûte peu, et il répond à la question que le code ne tranche jamais : les gens y arrivent-ils ?

Cet article vous donne la méthode complète, de l’objectif à la liste des corrections : recruter les bons profils, écrire des tâches qui ne soufflent pas la réponse, conduire la séance, puis analyser ce que vous avez vu. Avec un script de séance prêt à copier.

À quoi sert un test utilisateur, et quelle question lui poser ?

Ce n’est ni une démo, ni un groupe de discussion, ni un sondage d’opinion. Demander « Aimez-vous l’application ? » produit des politesses. Regarder quelqu’un échouer trois fois à saisir son adresse produit une correction.

Commencez par écrire une à trois questions de recherche, précises et vérifiables. Par exemple :

• Un nouveau client arrive-t-il à commander un repas et à le payer par mobile money, sans aide ?
• Les commerçants trouvent-ils le reçu d’un paiement qu’ils viennent de recevoir ?
• La nouvelle inscription par code SMS est-elle plus simple que l’ancienne ?

Pour chaque question, fixez un critère de réussite observable : la tâche est-elle terminée, avec ou sans erreur, avec ou sans aide ? Sans ce critère, chacun repartira de la séance avec sa propre interprétation.

Qui recruter, et combien de participants ?

Les bons profils

Recrutez des personnes qui ressemblent à vos vrais utilisateurs : ni vos collègues, ni vos proches, ni les développeurs. Les uns connaissent trop le produit, les autres vous connaissent trop pour être francs.

Définissez trois à cinq critères, par exemple :

• Usage : achète en ligne au moins une fois par mois, paie déjà par mobile money.
• Appareil : un Android d’entrée de gamme, si c’est le téléphone d’une bonne partie de votre public.
• Langue : à l’aise en français, en anglais ou dans les deux, selon votre marché.
• Exclusions : ne travaille pas dans le numérique, n’a jamais utilisé votre application si vous testez la découverte.

Pour filtrer, utilisez un court questionnaire de présélection (screener). Formulez des questions qui ne révèlent pas la « bonne » réponse : « Quels moyens de paiement avez-vous utilisés ce mois-ci ? » plutôt que « Utilisez-vous le mobile money ? ». Prévoyez un dédommagement (crédit de communication, forfait de données, bon d’achat) et un consentement écrit pour l’enregistrement.

Ce que dit vraiment la « règle des 5 utilisateurs »

En 2000, Jakob Nielsen publie « Why You Only Need to Test with 5 Users ». Son raisonnement s’appuie sur un modèle établi avec Thomas Landauer en 1993 : si chaque utilisateur révèle en moyenne une part L des N problèmes, n utilisateurs en révèlent N(1 − (1 − L)^n). Avec L = 31 %, la moyenne observée sur de nombreux projets, cinq utilisateurs font apparaître environ 85 % des problèmes.

Mais sa conclusion est souvent mal citée. Nielsen ne dit pas « cinq utilisateurs suffisent ». Il dit : plutôt qu’un test à quinze personnes, faites trois tests à cinq, en corrigeant entre chaque. Chaque tour vérifie les correctifs et va plus loin que le précédent. Il signale lui-même des exceptions, résumées dans ce tableau.

La moyenne cache aussi de grands écarts. En 2003, Laura Faulkner a testé 60 utilisateurs, puis tiré au sort des groupes de cinq : certains groupes trouvaient 99 % des problèmes, d’autres seulement 55 %. Avec dix personnes, le moins bon groupe en trouvait 80 % ; avec vingt, 95 %.

Comment écrire des tâches réalistes sans guider

Une tâche est une petite histoire : un contexte, un objectif, une fin claire. Elle ne dit jamais comment faire, et n’emploie jamais les mots de l’interface. Le tableau ci-dessous montre des erreurs courantes et leur correction.

Quelques règles de plus :

• Commencez par une tâche facile, pour mettre la personne en confiance.
• Fournissez les données nécessaires : compte de test, numéro de démonstration, adresse fictive, solde fictif. Personne ne doit payer avec son propre argent.
• Gardez le même ordre pour tous, sauf si vous comparez deux versions.
• Essayez vos tâches sur un collègue avant la première séance : une consigne ambiguë gâche toute une série.

Le script de séance, du premier mot au dernier

Un script garantit que chaque participant vit la même séance. Comptez de 45 à 60 minutes, dont 25 à 35 de tâches. Voici un modèle à adapter.

1. ACCUEIL (5 min)
« Merci d'être là. Aujourd'hui, nous testons l'application, pas vous :
il n'y a ni bonne ni mauvaise réponse. Si quelque chose vous bloque,
c'est exactement ce que nous cherchons. »
Consentement : enregistrement de l'écran et de la voix, usage interne.

2. PENSER À VOIX HAUTE (3 min)
« Pendant que vous utilisez l'application, dites à voix haute ce que
vous regardez, ce que vous cherchez, ce que vous pensez. »
Essai : « Montrez-moi comment vous envoyez un SMS, en commentant. »

3. QUESTIONS DE DÉPART (5 min)
« Comment commandez-vous un repas aujourd'hui ? Avec quelles applis ? »

4. TÂCHES (25 à 35 min)
Lire chaque tâche à voix haute, puis la laisser sous les yeux.
Après chaque tâche : « De 1 (très difficile) à 7 (très facile),
comment avez-vous trouvé cette tâche ? »

5. QUESTIONNAIRE FINAL (5 min)
Questionnaire SUS, rempli seul, avant toute discussion.

6. DÉBRIEF (5 min)
« Qu'est-ce qui vous a le plus gêné ? Le plus plu ? »
Remerciements et dédommagement.

Penser à voix haute et observer sans aider

Le penser à voix haute (thinking aloud) est, pour Jakob Nielsen, l’outil numéro un de l’utilisabilité : peu coûteux, robuste, utilisable du prototype papier à l’application publiée. Il a ses limites : parler sans arrêt n’est pas naturel, et certains participants filtrent leurs pensées pour paraître compétents. Relancez simplement : « Que vous dites-vous, là ? »

Le plus difficile reste de ne pas aider. Quand un participant vous pose une question, n’y répondez pas. Le Nielsen Norman Group décrit trois réflexes neutres :

• L’écho : reprendre ses derniers mots sur un ton interrogatif. « Ce bouton est bizarre ? »
• Le boomerang : lui renvoyer la question. « À votre avis ? » ou « Que feriez-vous chez vous ? »
• Columbo : commencer une question et la laisser en suspens. « Et là, vous… ? »

Fixez à l’avance une règle d’arrêt : si la personne est bloquée depuis plusieurs minutes ou visiblement mal à l’aise, notez l’échec et passez à la tâche suivante. Un blocage noté vaut mieux qu’une réussite soufflée.

À chaque tâche, notez :

• réussite, réussite avec difficulté, ou échec ;
• les hésitations, les retours en arrière, les appuis au mauvais endroit ;
• les phrases exactes (verbatims), entre guillemets ;
• le moment où la personne a failli abandonner.

Modéré ou non modéré, en salle ou à distance ?

Un test modéré se déroule avec un animateur présent, dans la même pièce ou en visio. Dans un test non modéré, le participant suit seul des consignes écrites et s’enregistre. Le tableau ci-dessous compare les trois formules courantes.

Pensez aux contraintes concrètes : une visio consomme des données, une coupure interrompt la séance. Remboursez le forfait, prévoyez un plan B (un appel téléphonique, puis un enregistrement d’écran envoyé ensuite) et vérifiez la connexion avant de commencer.

Pour les tests à distance sur de vrais téléphones, GeekTest réunit des testeurs réels et rémunérés qui utilisent leurs propres appareils Android et iPhone : vous pouvez faire tester votre application sans organiser vous-même le recrutement.

Analyser et prioriser ce que vous avez vu

1. Débriefez à chaud. Quinze minutes après chaque séance : les trois moments marquants, tant qu’ils sont frais.
2. Transformez les observations en problèmes. « Awa a cherché le bouton Payer pendant 40 secondes » devient « Sur les petits écrans, le bouton Payer n’est visible qu’après avoir fait défiler la page ».
3. Comptez combien de participants ont rencontré chaque problème.
4. Notez la gravité de 0 à 4, avec l’échelle de Nielsen présentée dans l’article sur les heuristiques appliquées au mobile.
5. Priorisez : d’abord les problèmes graves et fréquents, puis les problèmes graves et rares sur les parcours critiques (argent, données personnelles), puis le reste.
6. Montrez des preuves : un extrait vidéo et une phrase du participant pour chaque problème majeur.
7. Corrigez, puis retestez avec cinq nouvelles personnes.

Chaque problème retenu devient un ticket clair ; notre guide du rapport de bug explique comment l’écrire pour qu’il soit corrigé.

Pour aller plus loin

• Why You Only Need to Test with 5 Users (nouvel onglet) — Jakob Nielsen, NN/g (2000). L’article original, sa formule et ses exceptions.
• Beyond the five-user assumption (nouvel onglet) — Laura Faulkner, Behavior Research Methods, Instruments, & Computers (2003). L’étude sur 60 utilisateurs qui montre la variabilité des groupes de cinq.
• Thinking Aloud : The #1 Usability Tool (nouvel onglet) — Jakob Nielsen, NN/g (2012). Les avantages et les limites du penser à voix haute.
• Task Scenarios for Usability Testing (nouvel onglet) — Marieke McCloskey, NN/g (2014). Comment écrire des tâches réalistes, actionnables et sans indices.
• Talking with Users in a Usability Test (nouvel onglet) — Kara Pernice, NN/g (2014). Les techniques de l’écho, du boomerang et de Columbo.
• Remote Usability Tests : Moderated and Unmoderated (nouvel onglet) — Amy Schade, NN/g (2013). Les forces et faiblesses des tests à distance, modérés ou non.