Test utilisateur

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 souvent, il s'agit de produits du domaine informatique (par exemple : un logiciel ou un site web) dans le cadre de l'intervention ergonomique. Elle est considérée 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^[2]. 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^[3], aussi appelées 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 à l'aide de 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 possible de l’utilisation réelle de l’application. Les fonctionnalités ne sont donc pas testées individuellement comme c’est le cas lors de la recette fonctionnelle d’un logiciel. L'utilisateur doit suivre des scénarios d’utilisation construits afin de vérifier les hypothèses identifiées précédemment. Ces scénarios correspondent généralement à des tâches typiques de l’utilisateur.

Crédit image:

Andreas Bohnenstengel

licence CC BY-SA 3.0 de 🛈

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

Toutefois, 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 à améliorer le logiciel. » (voir la citation originale : [1]). Scott Cook, cofondateur d'Intuit a affirmé que « ... nous avons réalisé des tests utilisateurs en 1984, cinq avant tout le monde... 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és au cœur du projet »^[5].

Le principe du test utilisateur est d'observer des personnes utilisant un produit afin de faire ressortir concrètement les véritables difficultés qu'ils rencontrent, les erreurs et points d'amélioration. Le test d'utilisabilité consiste le plus souvent à 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 fournit un moyen opérationnel pour répondre concrètement aux questions qui se posent lors de la conception de l’interface.

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 permettant de prendre des mesures objectives qui vont servir à valider une ou plusieurs hypothèses énoncées initialement.

Le test utilisateur est parfois réalisé au démarrage du projet en particulier dans le cadre de la refonte d’une application^[6]. Toutefois, 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 nécessaire de disposer de la version finale de l’application pour conduire un test utilisateur^[7].

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. Ensuite, une maquette semi-fonctionnelle permet de conduire plusieurs scénarios prédéfinis et donc 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. D'une manière générale, 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.

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 permet de généraliser les résultats à l’ensemble de la population visée et minimiser les risques dans les développements qui vont être planifiés à la suite du 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 en fonction de la nature de l’interface, du type de tâche demandée et des questions soulevées par l’équipe chargée 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 permettant de 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 généralement 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 : en général, il s’agit des utilisateurs finaux de l’application, mais il peut être intéressant d’intégrer également dans le panel des personnes qui ne connaissent pas l’application (ils apporteront le point de vue des novices), voire 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 éventuellement les contournements réalisés) ;
• le temps d'exécution de chaque tâche (et éventuellement, 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…

Le script précise le déroulement du test dans tous ses détails (ex : tâches demandées, consignes, questions) afin de conduire le test dans les mêmes conditions avec tous les participants. Il précise également les artifices employés par l’animateur pour placer l’utilisateur dans une situation réaliste (ex: documents factices). Le script permet à 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 test est conduit dans un contexte le plus proche possible 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 généralement d’une pièce attenante séparé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 à côté du participant, légèrement en retrait, afin d’établir une relation de confiance qui favorisera 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 donc essentiel de ne pas l’aider, sauf bien entendu en cas d’impasse. En effet, afin d’identifier clairement les problèmes, il faut le laisser « se débrouiller » comme il le fera quand il sera seul face au produit. Par contre, une fois la source de l’erreur identifiée, afin de 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 possible afin de ne pas influencer les réponses et les actions de l’utilisateur. Chaque session dure au maximum 60 minutes afin de s'assurer de l'attention et de l'objectivité optimale du participant.

Pendant le test, l'utilisateur doit être incité à verbaliser afin de 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 faites-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 afin de mieux comprendre les causes des problèmes. Des solutions originales naissent parfois de ces échanges.

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és, 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é^[8].

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

${\displaystyle U=1-(1-p)^{n}}$

où p est la probabilité qu'un utilisateur identifie un problème particulier 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.

Toutefois, certaines études indiquent que 5 utilisateurs ne suffisent pas toujours pour obtenir une couverture significative de l’application, il est préférable de prévoir 10 à 20 utilisateurs par test^[10]. Dans ces conditions, la conduite de tests comprend différents profils et 5 utilisateurs par profil, permettant alors d’obtenir des résultats significatifs généralisables à l’ensemble 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^[11]. Deux points en particulier sont contestés :

1. Dans la mesure où l'utilisabilité est liée en particulier à un groupe d'utilisateurs, ce petit échantillon n'est probablement pas représentatif de la population en général et les données recueillies ne reflètent probablement que ce groupe d'utilisateurs.
2. Tous les problèmes d'utilisabilité ne sont pas détectables aussi facilement 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 beaucoup moins approfondie que ne le prédit la formule de Nielsen^[12].
3. Le nombre de problèmes d'utilisabilité détectables a tendance à tendre vers l'infini. Une série d'études^[13]montre qu'avec l'augmentation du nombre de participants et plus les techniques varient, de nouveau problèmes apparaissent quasiment à l'infini.
4. Le nombre de participants pour un test utilisateurs peut être calculé sur la base d'un pré-test à l'aide d'une formule mathématique.

• Ergonomie
• Ergonomie informatique
• Utilisabilité
• Intervention ergonomique
• Prototypage
• Méthode de la pensée à voix haute
• Entretien d'explicitation
• But d'utilisabilité

• Portail du travail et des métiers
• Portail de l’informatique