Organiser un test utilisateur avec des personnes handicapées
Un audit de conformité mesure le respect de règles. Il ne mesure pas la qualité du parcours — et une part significative des blocages réels ne correspond à aucun critère en échec. Seul un test utilisateur les révèle. Voici le protocole, et les erreurs qui l'invalident.
Quand le programmer
Après l'audit de conformité et après la première vague de corrections. Tester avec des utilisateurs un site dont les blocages absolus n'ont pas été traités revient à leur faire constater ce qu'on savait déjà, et à consommer leur temps pour rien.
Étape 1 : définir les parcours
Trois à cinq tâches réelles, formulées comme un objectif et non comme une suite d'actions. « Trouvez le montant de l'aide à laquelle vous avez droit » plutôt que « cliquez sur Aides puis sur Simulateur ».
Ces parcours sont ceux qui conditionnent un droit, un achat ou une démarche — pas la consultation d'un article.
Étape 2 : recruter
| Profil | Ce qu'il fait remonter |
|---|---|
| Lecteur d'écran, cécité | Structure, intitulés, annonces dynamiques |
| Agrandisseur, malvoyance | Comportement au zoom, contrastes, longueur des parcours |
| Clavier seul ou commande adaptée | Pièges, focus, nombre d'actions nécessaires |
| Trouble cognitif | Clarté du vocabulaire, prévisibilité, messages d'erreur |
Quatre à six personnes suffisent à faire remonter l'essentiel. Au-delà, les observations se répètent.
Passer par des associations ou des structures spécialisées, et rémunérer la participation. Un test utilisateur est un travail, pas une faveur — et une participation bénévole biaise le recrutement vers les personnes les plus militantes, donc les plus expertes, donc les moins représentatives.
Étape 3 : observer sans guider
C'est l'étape où tout se joue, et la plus difficile à tenir. La tentation d'aider est forte, et elle fausse tout.
- On énonce la tâche, puis on se tait.
- On note ce qui bloque, ce qui ralentit, ce qui est abandonné.
- On n'intervient que si la personne le demande, et on note l'intervention.
- On ne justifie jamais un choix de conception pendant la session.
Étape 4 : qualifier les blocages
Chaque observation est rapprochée du critère RGAA correspondant quand il en existe un, et signalée comme défaut d'usage quand il n'en existe pas.
Une part significative des blocages observés ne correspond à aucun critère en échec. Ce sont ceux-là qui ont le plus de valeur : ils ne seraient jamais remontés autrement, et ils expliquent souvent un taux d'abandon que les statistiques constataient sans l'expliquer.
Étape 5 : faire assister les équipes
C'est le bénéfice le plus sous-estimé du dispositif. Voir une personne échouer sur un formulaire que l'équipe jugeait limpide produit un effet qu'aucun rapport ne reproduit.
Associer les développeurs et les contributeurs en observation directe, et pas seulement leur transmettre la synthèse, est de loin le levier le plus efficace pour faire adopter le sujet en interne — bien plus qu'un exposé sur les sanctions.
Les quatre erreurs qui invalident l'exercice
- Tester avant d'avoir corrigé les blocages absolus.
- Guider pendant la session.
- Ne recruter qu'un seul profil, généralement lecteur d'écran, en oubliant le cognitif.
- Traiter les résultats comme des avis plutôt que comme des observations.