Un test utilisateur, ou test d'utilisabilité, est une méthode permettant d'évaluer un produit en le faisant tester par des utilisateurs^[1]. Le plus fréquemment, il s'agit de produits du domaine informatique (ex : logiciel, site web, intranet) dans le cadre de l'intervention ergonomique. Elle est reconnue comme une démarche indispensable dans la conception de produit, car la plus efficace pour évaluer l'ergonomie d'une application ou d'un site web. Il permet d'observer directement la façon dont l'utilisateur se sert d'une application et ainsi identifier concrètement les véritables difficultés qu'il rencontre^[2], aussi nommés problèmes d'utilisabilité. Le test utilisateur se distingue de l'audit ergonomique, ou audit expert, où un spécialiste de l'ergonomie informatique réalise une évaluation avec différentes méthodes telles que la grille d'observation, l'analyse heuristique, la check-list d'évaluation, etc. sans impliquer d'utilisateurs.
Le test utilisateur consiste à placer l'utilisateur dans une situation dite «écologique», la plus proche envisageable de l'utilisation réelle de l'application. Les fonctionnalités ne sont par conséquent pas testées individuellement comme c'est le cas lors de la recette fonctionnelle d'un logiciel. L'utilisateur doit suivre des scénario d'utilisation fabriqués pour vérifier les hypothèses identifiées auparavant. Ces scénarios correspondent le plus souvent à des tâches typiques de l'utilisateur.

Histoire du test utilisateur

Une employée du centre de recherche de Xerox à Palo Alto a rédigé que PARC utilisait des tests intensifs d'utilisabilité pour la création du Xerox Star, sorti en 1981^[3]. Pour tout autant, seules 25000 unités furent vendues, ce qui fut reconnu comme un échec commercial.

Cependant, la première évocation du test utilisateur est apparue dans le livre The Inside Intuit book (p. 22)  : "... au tout début du test utilisateur, qui deviendra plus tard une démarche standard dans l'industrie, LeFevre a recruté des gens dans la rue... et a mesuré leur temps d'utilisation de Kwik-Chek (Quicken) avec un chronomètre. Après chaque test , ... les développeurs travaillaient à perfectionner le logiciel. " (voir la citation originale : [1]). Scott Cook, co-fondateur d'Intuit a affirmé que "... nous avons réalisé des tests utilisateurs en 1984, cinq avant n'importe qui... il y a une grande différence entre le faire et laisser le faire par des gens du marketing dans le cadre de leur... façon de faire... une très grande différence entre le faire et laisser le faire par des ingénieurs qui ont été impliqué au cœur du projet^[4].

Objectifs du test utilisateur

Le principe du test utilisateur est d'observer des personnes utilisant un produit pour faire ressortir concrètement les véritables difficultés qu'ils font la connaissance de , les erreurs et points d'amélioration. Le test d'utilisabilité consiste le plus fréquemment à mesurer quatre grands points :

• Performance : Combien de temps, et combien d'étapes, sont nécessaires pour terminer différentes tâches simples ? (ex : trouver un produit, créer un compte et acheter le produit)
• Précision : Combien d'erreurs ont été faites par les utilisateurs test ? Ont-elles été rédhibitoires ou rattrapable avec la bonne information ?
• Rappel : De quels éléments et informations se souvient l'utilisateur après le test ? et après un certain temps de non-utilisation ?
• Réponse émotionnelle : Comment l'utilisateur se sent après la réalisation de tâches ? Est-il confiant, stressé ? Est-ce que l'utilisateur recommanderait ce produit à un ami ?

Le test utilisateur apporte un moyen opérationnel pour répondre concrètement aux questions qui se posent lors de la conception de l'interface.

La méthode

La méthode du test est directement dérivée des méthodes d'expérimentation scientifiques (voir aussi Plan d'expérience). Elle vise à mettre en œuvre un protocole servant à prendre des mesures objectives qui vont servir à valider une ou plusieurs hypothèses énoncées originellement.

Lorsque effectuer un test utilisateur ?

Le test utilisateur est quelquefois réalisé au démarrage du projet surtout dans le cadre de la refonte d'une application. Cependant, il est plus efficace de conduire le test sur une maquette intermédiaire afin d'obtenir des retours sur les choix de conception qui ont été effectués. Des tests sur des maquettes «papier» non finalisées permettent de valider rapidement certaines parties de l'interface. Il n'est pas indispensable de disposer de la version finale de l'application pour conduire un test utilisateur^[5].

La nature des tests et des scénarios d'évaluation dépend du niveau d'interactivité de la maquette. Sur une maquette statique, le test , dit «de perception», portera sur la compréhension et la visibilité des zones de l'écran. Par la suite, une maquette semi-fonctionnelle sert à conduire plusieurs scénarios prédéfinis et par conséquent de valider la navigation dans l'interface. Finalement, une maquette fonctionnelle ou prototype, présentant une partie significative des fonctionnalités de l'application, offre une plus grande liberté de navigation à l'utilisateur et permet une exploration libre du logiciel ou du site. En général, l'objectif du test est d'identifier les problèmes d'utilisabilité et non de mesurer la capacité de l'utilisateur à se servir de l'application.

Le protocole

Bien qu'en apparence, un test utilisateur puisse sembler simple à mettre en place, sa qualité va dépendre en grande partie de la rigueur avec laquelle son protocole est élaboré. Le suivi d'un protocole de test précis sert à généraliser les résultats à la totalité de la population visée et minimiser les risques dans les développements qui vont être planifiés suite au test . Un protocole de test rigoureux nécessite :

• Des objectifs clairs et des hypothèses qui en découlent : ils sont définis avec l'équipe projet selon la nature de l'interface, du type de tâche demandée et des questions soulevées par l'équipe en charge de la conception. Le test doit permettre de valider une ou plusieurs hypothèses associées aux objectifs, en supposant que l'interface réponde correctement à ces objectifs
• Des mesures servant à vérifier ces hypothèses, effectuées lors des scénarios d'utilisation : il s'agit de questions ou d'actions réalisées par l'utilisateur. Selon la réponse à ces questions ou selon la réussite de l'action identifiée, l'hypothèse est validée ou non. Sur une application, les mesures le plus souvent réalisées concernent : la réussite de la tâche, le temps de réalisation de la tâche, le nombre d'erreur, le nombre de clics, etc.
• Un panel d'utilisateurs représentatif de la population visée à la fois en nombre et en profil : généralement, il s'agit des utilisateurs finaux de l'application, mais il peut être intéressant d'intégrer aussi dans le panel des personnes qui ne connaissent pas l'application (ils apporteront le point de vue des novices), ou alors des utilisateurs d'un produit concurrent.

Lors de la passation du test utilisateur, il est préférable de définir des besoins et des exigences à satisfaire sous la forme de mesures qualitatives et quantitatives telles que :

• Le taux de succès pour la réalisation des tâches à effectuer
• Le nombre d'erreurs effectuées (et peut-être les contournements réalisés)
• Le temps d'exécution de chaque tâche (et peut-être, les différences de temps pour une même tâche répétée)
• Le nombre d'étapes nécessaires à la complétion de la tâche
• Le recours éventuel à un support ou une aide interne ou externe au produit (ex : l'animateur de la session de test )
• Le rythme d'apprentissage
• La satisfaction des utilisateurs…

La conduite du test

Le script précise le déroulement du test dans tous ces détails (ex : tâches demandées, consignes, questions) pour conduire le test dans les mêmes conditions avec l'ensemble des participants. Il précise aussi les artifices employés par l'animateur pour placer l'utilisateur dans une situation réaliste (ex : documents factices). Le script autorise l'observateur de noter les réponses et les données récoltées directement (ex : réussite de la tâche, nombre d'erreurs, temps de saisie, etc. ).

Le déroulement

Le test est conduit dans un contexte le plus proche envisageable de l'utilisation réelle. Le test est réalisé dans la mesure du possible, sur le lieu de travail des utilisateurs, ou dans un local dédié. Dans ce dernier cas de figure, les salles de test disposent le plus souvent d'une pièce attenante scindée par une glace sans tain depuis laquelle les membres de l'équipe projet peuvent assister au test . Il est préférable que l'observateur se tienne à coté du participant, un peu en retrait, afin d'établir une relation de confiance qui facilitera les échanges et l'observation. Le principal intérêt du test est d'observer l'utilisateur dans le contexte réel d'utilisation. Il est par conséquent essentiel de ne pas l'aider, sauf évidemment en cas d'impasse. En effet, afin d'identifier clairement les problèmes, il faut le laisser «se débrouiller» comme il le fera lorsqu'il sera seul face au produit. Par contre, une fois la source de l'erreur identifiée, pour mettre à nouveau en confiance l'utilisateur, il convient de le tranquilliser en lui indiquant que l'erreur vient du produit et non de lui. L'observateur doit rester le plus neutre envisageable pour ne pas influencer les réponses et les actions de l'utilisateur.

La verbalisation

Au cours du test , l'utilisateur doit être incité à verbaliser pour traduire en mots ce qu'il fait et ce qu'il pense. On lui pose des questions qui vont le conduire à éliciter ses processus mentaux :

• Que voulez-vous faire ? (objectifs
• Comment faîtes-vous cela ? (mode opératoire)
• Que fait le logiciel ? Qu'attendiez-vous que le logiciel fasse ? (réponse attendue)
• Pourquoi a-t-il fait cela ? Que veut dire ce message ? (compréhension)

Ces différentes réponses peuvent faire l'objet, une fois le test terminé, d'une analyse «à chaud» avec l'utilisateur pour mieux comprendre les causes des problèmes. Des solutions originales naissent quelquefois de ces échanges.

Combien d'utilisateurs sont nécessaires?

Au début des années 1990, Nielsen, alors chercheur chez Sun Microsystems, a popularisé le principe de n'utiliser qu'un petit nombre d'utilisateurs test , à savoir 5 participants à chaque étape du processus de développement. Son argument, basé sur de nombreux tests qu'il a réalisé, repose sur l'idée que le test utilisateur est une évaluation qualitative et les problèmes d'utilisabilité viennent du logiciel et non des utilisateurs. De fait, cinq utilisateurs permettraient de lever au moins 80 % des problèmes d'utilisabilité^[6].

Le principe de "Cinq utilisateurs suffisent" a ensuite été décrit par une formule mathématique^[7], qui définit la proportion de problèmes non-levés U.

U = 1 − (1 − p) ⁿ

où p est la probabilité qu'un utilisateur identifie un problème spécifique et n le nombre d'utilisateurs (ou session de test ). Cette formule peut être représentée sous la forme d'une graphique asymptotique tendant vers le nombre de vrais problèmes existants.

Cependant, certaines études indiquent que 5 utilisateurs ne suffisent pas forcément pour obtenir une couverture significative de l'application, il est préférable de prévoir 10 à 20 utilisateurs par test^[8]. Dans ces conditions, la conduite de tests comprend différents profils et 5 utilisateurs par profil, donnant la possibilité d'alors d'obtenir des résultats significatifs généralisables à la totalité de la population.

D'autres travaux de recherche ont contesté la proposition de Nielsen par des preuves empiriques et des formules mathématiques avancées^[9]. Deux points surtout sont contestés :

1. Étant donné que l'utilisabilité est liée surtout à un groupe d'utilisateurs, ce petit échantillon n'est certainement pas représentatif de la population généralement et les données recueillies ne reflètent certainement que ce groupe d'utilisateurs.
2. Tous les problèmes d'utilisabilité ne sont pas détectables aussi aisément les uns les autres. Des problèmes insolubles peuvent subvenir et altérer la tâche dans son ensemble. Dans ces conditions, la progression d'une tâche peut être nettement moins approfondie que ne le prédit la formule de Nielsen^[10].

Références

Liens externes

• A Brief History of the Magic Number 5 in Usability Testing
• La méthode du test utilisateur en ergonomie informatique
• Site du groupe de recherche sur l'explicitation

Principaux mots-clés de cette page : utilisateur - test - tâches - produit - application - problèmes - utilisabilité - nombre - logiciel - méthode - utilisation - temps - erreurs - interface - hypothèses - objectifs - réponse - questions - mesures - maquette - scénario - réalisé - protocole - conduire - usability - site - conception - ergonomie - évaluation - grande -

---

Ce texte est issu de l'encyclopédie Wikipedia. Vous pouvez consulter sa version originale dans cette encyclopédie à l'adresse http://fr.wikipedia.org/wiki/Test_utilisateur.
Voir la liste des contributeurs.
La version présentée ici à été extraite depuis cette source le 04/11/2010.
Ce texte est disponible sous les termes de la licence de documentation libre GNU (GFDL).
La liste des définitions proposées en tête de page est une sélection parmi les résultats obtenus à l'aide de la commande "define:" de Google.
Cette page fait partie du projet Wikibis.

---