Agence Quand faire des tests utilisateurs ? Les 4 situations où ils sont indispensables
Tests utilisateurs sur site existant, sur parcours problématique, sur prototype ou avant une refonte : chaque situation appelle une approche différente. Voici les 4 contextes où nous les utilisons chez Wex, avec des cas réels.
Quand faire des tests utilisateurs ? Les 4 situations où ils sont indispensables
La question n'est pas "faut-il faire des tests utilisateurs ?" La réponse est presque toujours oui. La vraie question est : quand les faire, sur quoi, et avec quel objectif ?
Un test utilisateur peut servir à diagnostiquer un site qui sous-performe, à comprendre un blocage sur un parcours précis, à valider un prototype avant de lancer le développement, ou à poser des bases solides avant d'engager une refonte complète. Ce sont quatre situations distinctes, avec des dispositifs différents et des livrables différents.
Dans notre pratique, nous utilisons presque exclusivement les tests modérés avec analyse approfondie : des sessions individuelles de 45 à 75 minutes, conduites par un modérateur expérimenté, avec des participants recrutés selon des critères précis. C'est la méthode la plus qualitative, la plus riche en enseignements, et la plus fiable pour prendre des décisions de conception éclairées. Ce que nous allons décrire ici, c'est comment cette même méthode s'adapte à chacune des quatre situations.
Situation 1 : analyse complète d'un site pour identifier les défauts et organiser la roadmap
C'est la situation la plus courante. Un site existe, il génère des résultats insuffisants (taux de conversion décevant, fort taux d'abandon, retours négatifs des équipes commerciales) ou simplement le sentiment que "quelque chose ne va pas" sans qu'on sache quoi. On ne veut pas lancer une refonte complète sans comprendre précisément ce qui dysfonctionne et ce qui mérite d'être préservé.
L'objectif des tests dans ce contexte est double : produire un diagnostic complet des forces et faiblesses de l'interface, et permettre d'organiser une roadmap priorisée (quoi corriger maintenant, quoi planifier dans une refonte, quoi laisser de côté).
Ce que ça donne en pratique : Soburo.
Soburo, fabricant de mobilier de bureau BtoB, souhaitait comprendre les performances ergonomiques de son site avant d'envisager des évolutions. Nous avons conduit 10 sessions de tests utilisateurs à distance (45 minutes par participant, 7 sur desktop et 3 sur mobile), recrutés parmi leurs clients et prospects : architectes d'intérieur, dirigeants, responsables informatiques, gestionnaires de patrimoine.
Les enseignements ont été déterminants pour orienter la roadmap. Le site était perçu comme fonctionnel en termes de navigation ("ça fait très pro"), mais il échouait sur deux dimensions critiques : la valorisation de la marque et des produits ("les visuels font 'ia', je ne sais pas à quoi ça va ressembler", "on ne ressent pas du tout la qualité de leur accompagnement réel") et la conversion directe, notamment sur la demande de devis qui était systématiquement échouée. Le score UXM a confirmé ces tensions : bonne ergonomie perçue, mais esthétique, confiance et loyauté en dessous des seuils cibles.
Ces résultats ont permis de proposer deux options claires : une refonte partielle ciblée sur le configurateur et la page produit, ou une refonte complète du site. Une décision éclairée par des données, pas par une intuition.
Ce que ce type de test produit. Un rapport d'analyse complet avec verbatims et captures annotées, une hiérarchisation des problèmes par sévérité et effort de correction, et une recommandation claire sur la suite : corrections ciblées, refonte partielle ou refonte globale.
Situation 2 : analyse d'un parcours spécifique identifié comme problématique
Un site fonctionne globalement bien, mais un parcours précis pose problème. Les analytics montrent un fort taux d'abandon sur une étape, le support reçoit des questions récurrentes sur une fonctionnalité, ou l'équipe pressent que quelque chose coince sans pouvoir l'identifier. L'enjeu n'est pas de tout tester : c'est de comprendre précisément ce qui se passe sur ce parcours, pour fournir les bons enseignements à l'équipe de conception qui va le retravailler.
Ce que ça donne en pratique : Keolis / Ilevia.
Keolis souhaitait analyser le site Ilevia.fr sur ses versions desktop et mobile, dans un contexte particulier. En parallèle du diagnostic du site existant, une nouvelle application mobile était en cours de création. L'objectif des tests était donc double : identifier les axes d'optimisation du site actuel pour organiser une roadmap d'évolutions, et s'assurer que les enseignements alimenteraient la conception de l'application mobile, pour que les deux canaux offrent une expérience cohérente.
Les parcours prioritaires ont été définis en amont avec l'équipe : navigation et page d'accueil, descente produit et achat de titres, espace compte client. Un volet accessibilité a été ajouté avec 3 participants ayant des déficiences visuelles, pour tester des parcours critiques dans des conditions plus contraintes.
Les tests ont révélé des problèmes ergonomiques sur le site actuel (points de friction sur la navigation, libellés ambigus, parcours d'achat perfectible) et ont produit une liste de "quick wins" actionnables rapidement, sans attendre la refonte complète. En parallèle, les enseignements ont directement alimenté les choix de conception de l'application mobile, pour éviter de reproduire les mêmes erreurs sur un nouveau canal.
Ce que ce type de test produit. Une analyse ciblée du parcours problématique avec identification des causes racines, des recommandations opérationnelles priorisées, et des enseignements transférables à l'équipe de conception.
Situation 3 : analyse d'un parcours spécifique sur prototype animé
La situation idéale : concevoir un nouveau parcours, le prototyper, le tester sur des utilisateurs réels avant de lancer le développement. C'est ici que le retour sur investissement des tests est le plus élevé, modifier un prototype coûtant une fraction de ce que coûte modifier une interface développée.
Le prototype animé (typiquement sous Figma) permet de simuler le parcours de façon suffisamment réaliste pour que les participants réagissent comme face à une vraie interface. On teste la logique de navigation, l'enchaînement des étapes, la clarté des libellés, la hiérarchie des informations, avant que le moindre code soit écrit.
Ce que ça donne en pratique : GMF.
Sur le parcours de demande de devis de GMF, 12 participants ont testé 4 variantes de maquettes sur mobile. En surface, les retours étaient positifs : le parcours était jugé "clair et rapide". Mais les tests modérés ont mis à nu un problème que les équipes n'avaient pas anticipé : les utilisateurs ne comprenaient pas l'utilité de l'espace prospect sécurisé proposé à l'issue du devis. Verbatim : "Je ne sais pas si c'est juste une fenêtre de chatbot, ou si c'est vraiment une messagerie personnalisée dans un espace, et du coup il va falloir créer un compte client."
Une nuance de wording, détectée avant le développement. Sans les tests sur prototype, ce problème serait apparu après le lancement, et sa correction aurait mobilisé un cycle de développement complet.
Ce que ce type de test produit. Une validation (ou invalidation) des hypothèses de conception avant développement, des corrections ciblées sur le prototype, et une base solide pour lancer le développement avec confiance.
Situation 4 : analyse complète préalable à une refonte déjà décidée
La refonte est décidée : budget validé, planning établi. La question n'est plus "faut-il refondre ?", mais "comment concevoir la nouvelle version pour qu'elle soit vraiment meilleure que l'actuelle ?"
C'est la situation où les tests utilisateurs en amont de la conception sont les plus précieux, et les plus souvent sous-estimés. L'intuition naturelle est de commencer par la conception et de tester ensuite. L'approche plus efficace est d'analyser d'abord ce qui ne fonctionne pas dans l'existant, pour que la conception parte de faits observés plutôt que d'hypothèses. C'est le meilleur moyen de ne pas reproduire les mêmes erreurs dans la nouvelle version.
Ce que ça donne en pratique : Planète Croisières.
Planète Croisières souhaitait refondre son site planete-croisiere.com (refonte technique, modernisation du design, amélioration de l'expérience utilisateur). La refonte était décidée ; la question était comment la concevoir.
Notre proposition a intégré les tests utilisateurs comme première étape du chantier UX, avant tout wireframing ou direction artistique. Les tests ont servi à comprendre précisément ce que les utilisateurs appréciaient dans le site actuel (à préserver), ce qui les bloquait (à corriger), et ce qui manquait (à concevoir). Ces enseignements ont directement alimenté la conception des wireframes et la direction artistique : chaque décision de conception étant ancrée dans une observation réelle, pas dans une convention générique.
Cette séquence (tester d'abord, concevoir ensuite) produit des refontes plus efficaces. Les équipes passent moins de temps à défendre des choix arbitraires en réunion, et plus de temps à affiner des solutions dont l'orientation est validée par les utilisateurs.
Ce que ce type de test produit. Un socle d'enseignements qui oriente toute la phase de conception : parcours prioritaires, points à préserver, problèmes à résoudre, attentes non couvertes. Et une équipe de conception qui travaille avec des certitudes plutôt qu'avec des suppositions.
Ce qui est commun à ces quatre situations
Quelle que soit la situation, notre approche repose sur les mêmes principes.
Le recrutement est clé. Des participants non représentatifs de la vraie cible produisent des enseignements trompeurs. Sur chacun de nos projets, nous définissons des critères de recrutement précis (profil, usage, familiarité avec le type d'interface, contexte d'achat ou d'utilisation) et nous prenons en charge ce recrutement. C'est là que se joue une grande part de la qualité des résultats.
La modération fait la différence. Un test bien conduit produit des insights que les données analytics ne peuvent pas révéler. Un test mal conduit produit des faux enseignements aussi coûteux que l'absence de test. La modération n'est pas une formalité, c'est une compétence experte.
Les livrables doivent être actionnables. Un rapport de tests utile, c'est un plan de recommandations priorisées, pas une liste de constats. Chaque problème identifié est accompagné d'une recommandation concrète, d'une estimation de sévérité, et quand c'est pertinent, d'une illustration de la solution proposée.
Vous vous reconnaissez dans l'une de ces quatre situations ? Un échange d'une heure suffit généralement à identifier le dispositif adapté à votre contexte.
Article publié par l'équipe de l'Agence Wex, qui conçoit et construit des produits digitaux : recherche utilisateur, UX et UI design, développement front et headless, accessibilité et maintenance applicative.
Publié par Équipe Wex