Recherche UX : tests d’utilisabilité de sites et d’apps

Les questions auxquelles répond cette étude

Les utilisateurs parviennent-ils à accomplir les tâches clés, comme trouver un produit, s’inscrire ou payer, et combien de temps chacune prend-elle ?
Où exactement hésitent-ils, se trompent-ils ou abandonnent-ils ?
Notre navigation et nos libellés correspondent-ils à la manière dont les utilisateurs se représentent le contenu ?
Comment notre utilisabilité se compare-t-elle à celle d’un concurrent ou de la version précédente ?
Quels problèmes les développeurs doivent-ils corriger en priorité ?
Un nouveau prototype fait-il mieux que le site en ligne avant même que nous le développions ?
Existe-t-il des obstacles pour les utilisateurs âgés ou les personnes qui recourent à des technologies d’assistance ?

Dans quels cas en avez-vous besoin

La recherche UX apporte le plus à trois moments : avant une refonte, pour établir une situation de référence ; pendant la conception, pour tester des prototypes tant que les changements coûtent peu ; après le lancement, pour confirmer que la nouvelle version fonctionne. D’autres déclencheurs : une étape de votre analytics où les utilisateurs décrochent, des tickets de support qui reviennent sans cesse sur la même fonctionnalité, de faibles scores de satisfaction client pour l’application, ou l’arrivée sur un nouveau marché.

Les publics n’ont pas tous la même expérience du numérique. Selon Eurostat, 89,5 % des personnes de l’UE utilisaient internet tous les jours en 2025, contre 82,7 % en Bulgarie et 98,4 % aux Pays-Bas. Un service testé uniquement auprès d’utilisateurs assidus peut échouer auprès des autres : recrutez donc en fonction de votre base d’utilisateurs réelle.

L’accessibilité a désormais aussi une portée juridique : l’acte européen sur l’accessibilité s’applique depuis juin 2025 à de nombreux services numériques destinés aux consommateurs, dont le commerce électronique et la banque.

Pour départager deux variantes en ligne sur du trafic réel, lancez un test A/B et vérifiez le résultat avec notre calculateur de significativité des tests A/B. Savoir si les gens veulent seulement du produit relève du test de concept, et les problèmes qui traversent plusieurs canaux appellent une étude du parcours client.

Exemple de sommaire

Synthèse pour la direction
les problèmes majeurs, le verdict global et les gains rapides
Objectifs et tâches
ce qui a été testé et comment la réussite a été définie
Participants
critères de recrutement, questionnaire de sélection et profils
Méthode
modéré ou non modéré, appareils, prototype ou site en ligne
Résultats par tâche
taux de réussite, durée et erreurs pour chaque tâche
Problèmes d’utilisabilité
chacun avec sa gravité, sa fréquence et ses preuves
Architecture de l’information
résultats du tri de cartes et du tree testing
Scores SUS et de facilité
par rapport à la référence ou à la version précédente
Observations d’accessibilité
obstacles relevés pendant les sessions
Recommandations
modifications classées par gravité et par effort
Montage des temps forts
courts extraits des moments les plus révélateurs

Méthodologie et sources

Tests d’utilisabilité modérés

Les participants pensent à voix haute en accomplissant des tâches réalistes avec un modérateur, à distance ou en salle de test. Pour détecter des problèmes, cinq à huit participants par groupe d’utilisateurs distinct et par série suffisent généralement. Plusieurs petites séries entrecoupées de corrections en révèlent davantage qu’une seule grande série. Mobile et ordinateur sont testés séparément lorsque les comportements diffèrent.

Tests à distance non modérés

Des groupes plus larges accomplissent les tâches seuls, sur leurs propres appareils, ce qui convient aux benchmarks de réussite et de durée des tâches. Les petits échantillons donnent des intervalles larges : avec 20 utilisateurs, un taux de réussite de 50 % s’accompagne d’une marge d’erreur d’environ ±22 points au seuil de confiance de 95 %, qui tombe à environ ±10 points avec 100 utilisateurs.

Tri de cartes et tree testing

Le tri de cartes ouvert révèle comment les utilisateurs regroupent les contenus et comment ils les nomment ; le tri fermé vérifie une structure proposée. Le tree testing mesure si les gens trouvent des éléments dans un menu dépouillé de tout design visuel, et il exige des échantillons plus larges que les tests modérés.

Mesures standard

La SUS comprend dix affirmations notées sur une échelle en cinq points et produit un score de 0 à 100 ; 68 est la moyenne de référence couramment utilisée. Une question unique sur la facilité après chaque tâche montre où se concentrent les difficultés.

Recrutement et déontologie

Un questionnaire de sélection retient des utilisateurs réels ou ciblés, jamais des collègues. Les sessions ne sont enregistrées qu’avec un consentement éclairé, stockées de manière sécurisée et supprimées après une durée convenue, conformément au RGPD.

Ce que vous recevez

Rapport d’utilisabilité où chaque problème est noté selon sa gravité
Extraits vidéo des temps forts, partagés avec le consentement des participants
Indicateurs par tâche sous Excel : réussite, durée et erreurs
Matrice de similarité du tri de cartes et résultats du tree testing
Score SUS comparé à la référence
Écrans annotés avec recommandations de design
Atelier de restitution avec les équipes design et développement

Déroulement du projet

Lancement, objectifs et définition des tâches — 2 à 3 jours
Recrutement et sélection — 1 semaine
Script de test et session pilote — 2 à 3 jours
Sessions de test — 2 à 5 jours
Analyse et notation de la gravité — 3 à 5 jours
Restitution et plan d’itération — 1 jour

Exemple fictif, à titre d’illustration

Exemple détaillé

Exemple : un éditeur SaaS hypothétique qui vend un logiciel de facturation aux petites entreprises constate que beaucoup d’utilisateurs en période d’essai n’envoient jamais leur première facture. L’analytics produit montre où ils s’arrêtent, mais pas pourquoi.

L’entreprise mène des tests d’utilisabilité modérés sur ordinateur avec huit comptables et huit dirigeants de petites entreprises, ainsi qu’un tree testing à distance d’un nouveau menu proposé. Les sessions révèlent trois points de blocage : l’écran de paramétrage de la TVA emploie un jargon comptable, les utilisateurs confondent « Clients » et « Contacts », et le produit demande les coordonnées bancaires avant que la première facture puisse être créée. Les dirigeants donnent un score SUS inférieur à la référence de 68, alors que les comptables trouvent le produit facile.

L’équipe déplace l’étape des coordonnées bancaires après la première facture, fusionne les deux entrées de menu et réécrit l’écran TVA en langage clair. Lors d’une deuxième série sur le prototype révisé, les six dirigeants testés créent tous leur première facture ; les modifications sont ensuite déployées sous test A/B sur l’activation des essais.

Erreurs fréquentes et comment les éviter

Tester avec des collègues ou des amis. Ils connaissent le produit et le jargon ; recrutez de vrais utilisateurs à l’aide d’un questionnaire de sélection.
Formuler des tâches directives. « Cliquez sur Produits » donne la réponse ; décrivez l’objectif et laissez les utilisateurs trouver le chemin.
Ne tester qu’une fois, à la fin. Les problèmes découverts après le développement coûtent cher à corriger ; testez des prototypes précoces et itérez.
Rapporter des opinions plutôt que des comportements. « J’aime les couleurs » ne prouve rien sur l’utilisabilité ; observez ce que font les utilisateurs.
Citer des pourcentages tirés de cinq utilisateurs. Les petites séries qualitatives détectent les problèmes ; elles ne mesurent pas leur fréquence.

À qui s’adresse cette étude

Adapté pour	Pourquoi
Sites e-commerce et de distribution	La recherche interne, les fiches produit et le tunnel de paiement décident de la conversion
Produits SaaS et fintech	L’onboarding et la première utilisation déterminent si les essais se transforment
Banques, assureurs et opérateurs télécoms	Des espaces en libre-service qui fonctionnent réduisent les appels au service client
Services numériques publics	Les services doivent fonctionner pour tous, y compris pour les utilisateurs en situation de handicap
Équipes qui préparent une refonte	Les tests de référence et de prototype réduisent le risque d’un relancement raté

Questions fréquentes

Combien d’utilisateurs faut-il pour un test d’utilisabilité ?

Pour détecter des problèmes, cinq à huit participants par groupe d’utilisateurs et par série suffisent généralement. Pour des benchmarks qui présentent des taux de réussite ou des scores SUS avec intervalles de confiance, prévoyez plusieurs dizaines de participants, voire davantage. Notre calculateur de marge d’erreur montre comment la précision évolue avec la taille de l’échantillon.

Combien de temps dure un projet de recherche UX ?

Une série unique de tests modérés prend généralement deux à trois semaines du lancement à la restitution, le recrutement étant l’étape la plus longue. Les projets qui combinent tri de cartes, tree testing et deux séries de tests prennent quatre à cinq semaines. Les utilisateurs difficiles à joindre, comme les médecins ou les directeurs financiers, demandent un délai de recrutement supplémentaire.

Quelle est la différence entre recherche UX et test A/B ?

La recherche UX explique pourquoi les utilisateurs peinent, à partir d’un petit nombre de sessions observées. Le test A/B mesure laquelle de deux versions en ligne donne les meilleurs résultats sur du trafic réel, mais il n’explique pas ce résultat. Utilisés ensemble, la recherche suggère les améliorations et le test A/B confirme leur effet.

Qu’est-ce qui influe sur le coût d’une recherche UX ?

Le nombre de groupes d’utilisateurs et de séries, la difficulté à recruter les bons participants, le choix entre sessions modérées et non modérées, le nombre d’appareils et de langues, et l’ajout éventuel d’un tri de cartes ou d’un tree testing. Présentez-nous votre produit et demandez un devis.

Comment traitez-vous les enregistrements et les données personnelles ?

Les participants reçoivent une information claire et signent un formulaire de consentement avant le début de l’enregistrement. Enregistrements et notes sont conservés sur des systèmes sécurisés, partagés uniquement avec les membres de votre équipe désignés et supprimés à l’issue de la durée de conservation convenue. Nous agissons conformément au RGPD et au Code international ICC/ESOMAR.

Pouvez-vous tester un prototype avant tout développement ?

Oui, et c’est le moment le moins coûteux pour trouver des problèmes. Nous testons des prototypes cliquables issus d’outils de design, et même des maquettes papier ou statiques pour les premières questions de navigation. Les tests de prototype permettent aussi de comparer côte à côte deux orientations de design avant le début du développement.

Sources

Mis à jour le: 9 nov. 2026

Recherche UX : tests d’utilisabilité, tri de cartes et benchmarks SUS pour sites et applications