Prototyper avec les futurs utilisateurs : l'adoption se joue avant le développement

Un outil métier livré conforme au cahier des charges, recetté, déployé, et que les équipes contournent dès la deuxième semaine avec leur ancien fichier Excel. C'est le scénario que je rencontre le plus souvent sur les projets internes. Le diagnostic posé ensuite parle de résistance au changement, alors que le problème a été fabriqué bien plus tôt, au moment où personne parmi les futurs utilisateurs n'a vu l'outil avant qu'il soit construit.

Pourquoi l'adoption se décide avant la première ligne de code

Une fois le développement lancé, chaque retour d'usage devient une demande d'évolution, chiffrée, arbitrée, souvent reportée à un lot suivant. L'utilisateur qui découvre l'outil à la livraison comprend vite que ses remarques arrivent trop tard pour changer quoi que ce soit. Il en tire une conclusion rationnelle : l'outil a été conçu sans lui, il fera avec le minimum.

Associer les utilisateurs au prototypage inverse ce rapport. Ce que j'observe, et je le présente comme une observation de terrain et non comme un résultat démontré, c'est qu'une personne qui a vu un écran corrigé après sa remarque ne parle plus de « leur outil » mais d'un outil qu'elle a contribué à rendre utilisable. Une partie de la résistance se transforme en appropriation. Une partie seulement : les objections de fond sur le sens du projet ne se règlent pas avec une maquette, et elles relèvent de l'étape Desire du modèle ADKAR.

Ce principe n'a rien d'une intuition personnelle. La norme ISO 9241-210:2019 sur la conception centrée sur l'humain pose notamment une implication des utilisateurs tout au long de la conception et du développement, et un processus itératif guidé par l'évaluation. Côté public, la DINUM en fait une règle explicite sur design.numerique.gouv.fr : « Toujours tester une solution avant de la développer. »

Une maquette cliquable et des tâches réelles, pas une démonstration

Le prototype utile n'a pas besoin d'être beau. Une maquette cliquable qui enchaîne les écrans d'un parcours suffit, à condition qu'on puisse y faire quelque chose. Ce qui compte est le protocole : on confie à l'utilisateur une tâche tirée de son quotidien (« enregistrez la réclamation reçue ce matin et transmettez-la au service concerné ») et on le regarde faire, sans l'aider.

C'est là que le test se distingue de la démonstration. Une démonstration montre à l'utilisateur ce que l'outil sait faire, sur un cas préparé par celui qui l'a conçu. Un test sur tâche réelle montre à l'équipe projet ce que l'utilisateur n'arrive pas à faire. La DINUM le formule ainsi : mener des tests qualitatifs « avec des vrais usagers représentatifs et en situation réelle ».

Le choix des tâches est le travail le plus important et le plus négligé. Je les prends dans les dossiers réels de la semaine précédente, y compris les cas tordus, parce que ce sont eux qui feront revenir l'utilisateur vers son ancien fichier.

Cinq utilisateurs suffisent-ils ? Ce que dit vraiment NN/g

Le chiffre circule partout et mérite d'être cité exactement. Dans son article de mars 2000, Jakob Nielsen (Nielsen Norman Group, cabinet qui vend du conseil et de la formation en UX) explique qu'un test avec cinq participants trouve 85 % des problèmes d'utilisabilité. Ce chiffre est une moyenne issue d'un modèle mathématique établi avec Tom Landauer, qui suppose qu'un utilisateur détecte en moyenne 31 % des problèmes.

Trois limites sont dans le texte lui-même. Le modèle ne vaut que pour des utilisateurs comparables, qui se servent de l'outil de façon similaire : avec plusieurs profils très différents, Nielsen recommande trois à quatre utilisateurs par groupe. Il faut une quinzaine d'utilisateurs pour trouver la quasi-totalité des problèmes, d'où sa recommandation de trois tests de cinq plutôt qu'un seul de quinze. Et la règle concerne les tests qualitatifs : pour des mesures chiffrées, la mise à jour de 2012 recommande au moins vingt utilisateurs.

La moyenne cache aussi une dispersion. En 2003, Laura Faulkner a testé 60 utilisateurs puis tiré au hasard des groupes de cinq : certains trouvaient 99 % des problèmes, d'autres seulement 55 %. Avec dix utilisateurs, le plus faible des groupes atteignait 80 %. Ma lecture : cinq utilisateurs suffisent pour repérer l'essentiel des problèmes d'usage sur un parcours, à condition de répéter le test après correction et de ne pas confondre un tour de test avec une garantie.

Tester l'utilisabilité n'est pas faire valider par la hiérarchie

C'est la confusion qui vide la démarche de son sens. Présenter la maquette au directeur métier en comité et obtenir son accord est une validation : elle porte sur le périmètre, les priorités, le budget. Elle est nécessaire. Elle ne dit rien de la capacité d'un gestionnaire à enregistrer une réclamation sans se perdre.

La DINUM sépare d'ailleurs les rôles : un sponsor qui « valide les choix stratégiques », et une équipe métier qui « nourrit les choix de conception ». Quand le second rôle est absorbé par le premier, l'outil est validé par des gens qui ne l'utiliseront pas. Le choix des testeurs suit la même logique que celui des relais métier crédibles auprès de leurs pairs : on prend ceux qui font le travail, pas ceux qui ont levé la main.

Placer les tests entre le cadrage et le pilote

Le prototypage avec les utilisateurs se prévoit au cadrage, avec un budget et des dates, comme tout ce qui se joue dans les deux premières semaines d'un projet. Ajouté après coup, il devient une recette déguisée, au moment où plus rien ne peut changer sans avenant. Pour l'arborescence et le vocabulaire, un tri de cartes en ligne avec les futurs utilisateurs donne une base avant même la première maquette.

Je le place en trois temps : un premier tour sur maquette avant toute spécification détaillée, un second après correction, puis un pilote sur un périmètre restreint avec l'outil réel et les vrais dossiers. Le pilote ne remplace pas les tests sur maquette, il vérifie que l'usage tient dans la durée, et c'est là que l'usage réel se mesure, au-delà des comptes ouverts.

C'est cette séquence que je mets en place dans mes missions d'accompagnement à la conduite du changement : moins de communication à la livraison, plus d'observation avant le développement.

Sources : Jakob Nielsen, « Why You Only Need to Test with 5 Users », Nielsen Norman Group, 2000 ; Jakob Nielsen, « How Many Test Users in a Usability Study? », Nielsen Norman Group, 2012 ; Laura Faulkner, « Beyond the five-user assumption », Behavior Research Methods, Instruments, & Computers, 2003 ; DINUM, « Concevoir un service public numérique de qualité », design.numerique.gouv.fr ; ISO 9241-210:2019, « Ergonomics of human-system interaction, Part 210: Human-centred design for interactive systems », ISO, 2019.

Pour aller plus loin : Former vos équipes à l'IA ne suffira pas : le modèle ADKAR appliqué, Sponsor, relais, réfractaires : qui fait réellement adopter l'IA dans une équipe