Antoine Pezé

Comment realiser une Evaluation heuristique


En bref

Résumé

L’évaluation heuristique est une méthode d’inspection d’interface qui consiste à analyser un produit à travers une grille de critères d’utilisabilité reconnus. Elle permet d’identifier rapidement les problèmes ergonomiques majeurs sans recruter d’utilisateurs.

Objectifs

Détecter les problèmes d’utilisabilité d’une interface de manière systématique, les hiérarchiser par sévérité et produire un rapport d’audit exploitable par l’équipe produit.


Qu’est-ce qu’une évaluation heuristique ?

Une évaluation heuristique est une méthode d’inspection de l’utilisabilité dans laquelle des experts examinent une interface en la confrontant à un ensemble de principes ergonomiques reconnus, appelés heuristiques.

La méthode a été formalisée par Jakob Nielsen et Rolf Molich en 1990, puis affinée par Nielsen en 1994 avec la publication de ses 10 heuristiques d’utilisabilité. Le principe est simple : un petit nombre d’évaluateurs experts passent en revue une interface en s’appuyant sur des principes de conception reconnus. Chaque violation d’un principe est notée, décrite et classée par niveau de sévérité.

L’objectif est de fournir à l’équipe un diagnostic rapide et structuré des problèmes d’utilisabilité, sans avoir besoin de recruter des utilisateurs. En pratique, une évaluation heuristique bien menée permet de détecter entre 60 et 80 % des problèmes d’utilisabilité majeurs d’une interface.

Pourquoi utiliser cette méthode ?

Plusieurs situations rendent l’évaluation heuristique particulièrement pertinente :

  • En début de projet : vous récupérez un produit existant et avez besoin d’un état des lieux rapide avant de planifier la recherche utilisateur.
  • Quand le budget est limité : vous n’avez pas les moyens de recruter des utilisateurs pour des tests, mais vous devez tout de même identifier les problèmes les plus critiques.
  • Avant un test utilisateur : en corrigeant les problèmes les plus évidents en amont, vous évitez que vos tests soient “pollués” par des erreurs triviales, et vous concentrez les sessions sur les vrais enjeux.
  • En complément d’une refonte : pour documenter les faiblesses de l’interface actuelle et justifier les choix de redesign auprès des parties prenantes.

Ce que l’évaluation heuristique n’est pas

Il ne faut pas confondre l’évaluation heuristique avec un test utilisateur. Dans une évaluation heuristique, ce sont des experts qui inspectent l’interface. Dans un test utilisateur, ce sont de vrais utilisateurs qui interagissent avec le produit. Les deux méthodes sont complémentaires : l’évaluation heuristique détecte les violations de principes ergonomiques. Le test utilisateur révèle les comportements réels et les incompréhensions que même un expert ne peut pas anticiper.


Les 10 heuristiques de Nielsen

Jakob Nielsen a formalisé 10 principes généraux de conception d’interface. Chacun couvre un aspect fondamental de l’utilisabilité. Voici ces 10 heuristiques, expliquées avec des exemples concrets.

1. Visibilité de l’état du système

Le système doit toujours tenir l’utilisateur informé de ce qui se passe, par un feedback approprié dans un délai raisonnable.

Exemples concrets :

  • Une barre de progression lors du téléchargement d’un fichier.
  • Un indicateur “Enregistrement en cours…” quand l’utilisateur sauvegarde un document sur Google Docs.
  • Un badge de notification sur l’icône de messagerie indiquant le nombre de messages non lus.

Violation typique : un formulaire qui se soumet sans aucun retour visuel, laissant l’utilisateur se demander si son action a bien été prise en compte.

2. Correspondance entre le système et le monde réel

Le système doit parler le langage de l’utilisateur, avec des mots, des phrases et des concepts qui lui sont familiers, plutôt que des termes orientés système. Les conventions du monde réel doivent être respectées, et les informations doivent apparaitre dans un ordre naturel et logique.

Exemples concrets :

  • Une application de e-commerce utilise le terme “Panier” plutôt que “File d’attente de commande”.
  • Une application de mail affiche les messages du plus récent au plus ancien, comme une pile de courrier.
  • Un calendrier numérique reprend les codes visuels d’un agenda papier.

Violation typique : un message d’erreur qui affiche “Erreur 500 : Internal Server Error” au lieu de “Un problème est survenu, veuillez réessayer dans quelques instants.”

3. Contrôle et liberté de l’utilisateur

Les utilisateurs choisissent souvent des fonctions par erreur et ont besoin d’une “sortie de secours” clairement identifiée pour quitter l’état non désiré, sans avoir à passer par un processus complexe. Le système doit permettre d’annuler et de refaire.

Exemples concrets :

  • Le raccourci Ctrl+Z pour annuler une action dans n’importe quel éditeur.
  • Un bouton “Retour” visible à chaque étape d’un tunnel d’achat.
  • La possibilité de récupérer un email supprimé dans la corbeille pendant 30 jours.

Violation typique : un processus d’inscription en 5 étapes sans possibilité de revenir en arrière pour modifier une information saisie précédemment.

4. Cohérence et standards

Les utilisateurs ne doivent pas avoir à se demander si des mots, des situations ou des actions différents signifient la même chose. Suivez les conventions de la plateforme et du domaine.

Exemples concrets :

  • Tous les boutons d’action principale utilisent la même couleur à travers l’application.
  • Le logo en haut à gauche ramène systématiquement à la page d’accueil.
  • Les liens hypertextes sont soulignés ou d’une couleur distincte du texte courant.

Violation typique : une application mobile dans laquelle le geste de “swipe” vers la gauche supprime un élément sur un écran, mais archive un élément sur un autre écran.

5. Prévention des erreurs

Plutôt que de concevoir de bons messages d’erreur, il vaut mieux empêcher les erreurs de se produire. Éliminez les conditions propices aux erreurs ou proposez une option de confirmation avant que l’utilisateur ne s’engage dans une action.

Exemples concrets :

  • Un champ de date avec un sélecteur de calendrier plutôt qu’un champ de saisie libre.
  • La désactivation du bouton “Valider” tant que tous les champs obligatoires ne sont pas remplis.
  • Une confirmation “Êtes-vous sûr de vouloir supprimer cet élément ?” avant une action destructrice.

Violation typique : un formulaire qui accepte n’importe quel format de numéro de téléphone et renvoie une erreur seulement après la soumission.

6. Reconnaissance plutôt que rappel

Minimisez la charge mnésique de l’utilisateur en rendant les objets, les actions et les options visibles. L’utilisateur ne devrait pas avoir à se souvenir d’informations d’un écran à l’autre.

Exemples concrets :

  • L’historique des recherches récentes affiché dans un moteur de recherche.
  • Un tunnel d’achat qui affiche le récapitulatif de la commande à chaque étape.
  • Les suggestions d’autocomplétion dans un champ de recherche.

Violation typique : un processus de configuration en plusieurs étapes où l’utilisateur doit se souvenir des choix faits aux étapes précédentes sans aucun récapitulatif visible.

7. Flexibilité et efficacité d’utilisation

Des accélérateurs, invisibles pour l’utilisateur novice, permettent à l’utilisateur expert d’accélérer son interaction avec le système. Le système doit servir aussi bien les utilisateurs novices que les utilisateurs expérimentés.

Exemples concrets :

  • Les raccourcis clavier dans Figma ou Photoshop.
  • La possibilité de créer des modèles réutilisables dans un outil d’emailing.
  • Les commandes slash dans Notion ou Slack.

Violation typique : une application de gestion de projet dans laquelle chaque tâche doit être créée via un formulaire en 4 étapes, sans possibilité de saisie rapide.

8. Design esthétique et minimaliste

Les dialogues ne doivent pas contenir d’information non pertinente ou rarement nécessaire. Chaque unité d’information supplémentaire entre en compétition avec les informations pertinentes et diminue leur visibilité relative.

Exemples concrets :

  • La page d’accueil de Google : un logo, un champ de recherche, deux boutons.
  • Un tableau de bord qui affiche les indicateurs clés en premier plan et relègue les détails dans des pages secondaires.
  • Un formulaire d’inscription qui ne demande que l’email et le mot de passe, sans champs superflus.

Violation typique : une page d’accueil surchargée de bannières promotionnelles, de widgets et de contenus secondaires qui noient l’action principale attendue de l’utilisateur.

9. Aide à la reconnaissance, au diagnostic et à la correction des erreurs

Les messages d’erreur doivent être exprimés en langage clair (pas de codes), indiquer précisément le problème et suggérer une solution de manière constructive.

Exemples concrets :

  • “Ce mot de passe est trop court. Utilisez au moins 8 caractères, dont un chiffre et une lettre majuscule.”
  • “Cette adresse email est déjà utilisée. Souhaitez-vous vous connecter ou réinitialiser votre mot de passe ?”
  • Un champ de formulaire qui passe en rouge avec un message explicatif dès que l’utilisateur quitte le champ.

Violation typique : un message “Erreur de validation” sans aucune indication sur le champ concerné ni sur la nature du problème.

10. Aide et documentation

Même s’il est préférable que le système soit utilisable sans documentation, il peut être nécessaire de fournir de l’aide. Cette information doit être facile à trouver, centrée sur la tâche de l’utilisateur, fournir des étapes concrètes et ne pas être trop volumineuse.

Exemples concrets :

  • Des infobulles au survol des icônes dans une barre d’outils.
  • Un centre d’aide avec une barre de recherche et des articles classés par thématique.
  • Un assistant d’onboarding qui guide l’utilisateur lors de sa première utilisation.

Violation typique : une application complexe sans aucune aide contextuelle, avec uniquement un PDF de 200 pages en guise de documentation.


Les critères de Bastien-Scapin : l’alternative francophone

En parallèle des travaux de Nielsen, les chercheurs français Christian Bastien et Dominique Scapin de l’INRIA ont proposé en 1993 une grille alternative composée de 8 critères ergonomiques. Ces critères sont particulièrement utilisés dans le monde francophone et offrent un niveau de détail plus fin que les heuristiques de Nielsen, avec 18 sous-critères au total.

1. Guidage

Tous les moyens utilisés pour conseiller, orienter, informer et guider l’utilisateur quand il interagit avec le système.

Sous-critères :

  • Incitation : les éléments qui guident l’utilisateur vers les actions attendues (labels, instructions, exemples de saisie).
  • Groupement et distinction entre items : l’organisation visuelle des éléments par localisation et format (proximité, séparateurs, couleurs).
  • Feedback immédiat : la réponse du système à chaque action de l’utilisateur.
  • Lisibilité : les caractéristiques lexicales de présentation de l’information (taille des caractères, espacement, contraste).

2. Charge de travail

La réduction de la charge perceptive, mnésique et physique de l’utilisateur.

Sous-critères :

  • Brièveté : limiter le travail de saisie et de lecture (valeurs par défaut, abréviations autorisées).
  • Densité informationnelle : ne pas surcharger l’écran d’informations inutiles.

3. Contrôle explicite

Le contrôle que l’utilisateur a sur le traitement de ses actions.

Sous-critères :

  • Actions explicites : le système exécute uniquement les actions demandées par l’utilisateur, et seulement quand il le demande.
  • Contrôle utilisateur : l’utilisateur doit pouvoir interrompre, annuler, reprendre ou abandonner un traitement en cours.

4. Adaptabilité

La capacité du système à s’adapter au contexte et aux besoins de l’utilisateur.

Sous-critères :

  • Flexibilité : les différentes manières d’atteindre un même objectif.
  • Prise en compte de l’expérience de l’utilisateur : le système s’adapte au niveau d’expertise (novice vs expert).

5. Gestion des erreurs

Les mécanismes de prévention, détection et récupération des erreurs.

Sous-critères :

  • Protection contre les erreurs : empêcher les erreurs de se produire.
  • Qualité des messages d’erreur : pertinence, lisibilité et précision des messages.
  • Correction des erreurs : les moyens mis à disposition pour corriger les erreurs.

6. Homogénéité et cohérence

La constance des choix de conception (codes, dénominations, formats, procédures) d’un écran à l’autre.

7. Signifiance des codes et dénominations

L’adéquation entre un objet ou une information affichée et son référent. Les codes et noms doivent être significatifs pour l’utilisateur.

8. Compatibilité

L’adéquation entre les caractéristiques des utilisateurs (mémoire, perceptions, habitudes) et l’organisation des interactions du système (entrées, sorties, dialogues).

Nielsen ou Bastien-Scapin ?

Les deux grilles sont valables. Mon conseil : utilisez Nielsen si vous travaillez dans un contexte international ou avec une équipe habituée au vocabulaire anglo-saxon. Utilisez Bastien-Scapin si vous travaillez dans un contexte francophone académique ou si vous avez besoin d’un niveau de granularité plus fin, notamment sur les questions de guidage et de charge de travail. Dans la pratique, je commence souvent par Nielsen pour sa simplicité et je complète avec Bastien-Scapin quand j’ai besoin de creuser un aspect spécifique.


Comment conduire une évaluation heuristique pas à pas

Etape 1 : Définir le périmètre de l’évaluation (1 à 2 heures)

Avant de commencer, cadrez précisément ce que vous allez évaluer. Un audit complet d’un produit entier est rarement pertinent. Concentrez-vous sur les parcours critiques.

  1. Listez les parcours utilisateurs principaux du produit (inscription, achat, recherche, configuration, etc.).
  2. Identifiez les 3 à 5 parcours les plus critiques pour le business ou les plus utilisés par vos utilisateurs.
  3. Pour chaque parcours, listez les écrans qui le composent.
  4. Documentez ces parcours dans un tableau ou sur Miro pour que chaque évaluateur suive le même chemin.

A la fin de cette étape, vous devez avoir une liste claire des écrans et parcours à évaluer, partagée avec tous les évaluateurs.

Etape 2 : Constituer l’équipe d’évaluateurs (variable)

La recherche de Nielsen a montré qu’un seul évaluateur ne détecte en moyenne que 35 % des problèmes d’utilisabilité. Avec 3 évaluateurs, on monte à environ 60 %. Avec 5 évaluateurs, on atteint environ 75 %. Au-delà de 5, le rendement marginal diminue fortement.

Ma recommandation : 3 à 5 évaluateurs.

Les évaluateurs doivent avoir un minimum de connaissances en ergonomie ou en UX. Ce peuvent être des UX designers, des product designers, des chefs de projet formés à l’UX, ou des ergonomes. Si vous n’avez pas assez d’experts en interne, vous pouvez former rapidement des membres de l’équipe produit aux heuristiques de Nielsen : 30 minutes de présentation suffisent pour qu’ils comprennent les principes et soient capables de détecter les violations les plus évidentes.

Point important : chaque évaluateur doit travailler seul. Si les évaluateurs discutent entre eux pendant l’inspection, ils risquent de s’influencer et de converger vers les mêmes conclusions. Cela réduit le nombre total de problèmes détectés.

Etape 3 : Préparer la grille d’évaluation (30 minutes)

Créez un tableau (Google Sheets, Notion, Excel) avec les colonnes suivantes :

#ÉcranHeuristique violéeDescription du problèmeRecommandationSévérité (0-4)Évaluateur
1Page d’accueilH1 - Visibilité de l’état du systèmeL’utilisateur ne sait pas si sa recherche est en coursAjouter un indicateur de chargement (spinner)3A. Dupont

L’échelle de sévérité est la suivante :

  • 0 - Pas un problème d’utilisabilité : violation esthétique mais sans impact sur l’usage.
  • 1 - Problème cosmétique : à corriger seulement si le temps le permet.
  • 2 - Problème mineur : gêne légère, priorité basse.
  • 3 - Problème majeur : gêne significative, priorité haute. L’utilisateur peut être bloqué ou très ralenti.
  • 4 - Problème catastrophique : l’utilisateur est bloqué ou quitte le produit. Correction impérative avant mise en production.

Partagez cette grille à chaque évaluateur avec des instructions claires : parcourez chaque écran dans l’ordre défini, notez chaque violation dans une ligne séparée, même si c’est la même heuristique qui est violée plusieurs fois.

Etape 4 : Conduire l’évaluation individuelle (1 à 2 heures par évaluateur)

Chaque évaluateur parcourt l’interface seul, à son rythme. Je recommande de faire deux passes :

  1. Première passe (30 à 45 minutes) : parcourir l’ensemble des écrans pour se familiariser avec le produit, comprendre la logique de navigation et le périmètre fonctionnel.
  2. Seconde passe (30 à 60 minutes) : reprendre chaque écran en détail et noter systématiquement les violations en s’appuyant sur la grille d’heuristiques.

Pour chaque violation identifiée, l’évaluateur doit :

  • Identifier l’écran concerné.
  • Citer la ou les heuristiques violées.
  • Décrire le problème de manière factuelle.
  • Proposer une recommandation concrète si possible.
  • Attribuer un score de sévérité provisoire.

Conseil pratique : faites des captures d’écran et annotez-les directement. Un outil comme Markup Hero, Shottr ou même les outils d’annotation natifs de votre système suffisent. Cela rend le rapport beaucoup plus parlant pour les parties prenantes non-UX.

Etape 5 : Consolider les résultats (1 à 2 heures)

Une fois que tous les évaluateurs ont terminé leur inspection individuelle, rassemblez les résultats dans un unique tableau consolidé.

  1. Dédupliquez les problèmes identiques. Plusieurs évaluateurs auront probablement détecté les mêmes problèmes. Fusionnez-les en une seule ligne et notez le nombre d’évaluateurs ayant identifié ce problème. Plus un problème est détecté par un grand nombre d’évaluateurs, plus il est probablement sévère et visible.

  2. Harmonisez les scores de sévérité. Pour chaque problème, calculez la moyenne des scores attribués par les différents évaluateurs. En cas de désaccord important (par exemple, un évaluateur note 1 et un autre note 4), organisez une discussion courte pour trancher.

  3. Triez par sévérité décroissante. Les problèmes de sévérité 4 et 3 doivent apparaitre en premier.

  4. Catégorisez par heuristique. Cela permet d’identifier les “familles” de problèmes récurrents. Si vous avez 12 violations de l’heuristique 1 (Visibilité de l’état du système), cela indique un problème systémique de feedback dans le produit.

Etape 6 : Rédiger le rapport et prioriser (2 à 3 heures)

A la fin de l’évaluation, vous devez avoir un rapport contenant :

  • Un résumé exécutif : nombre total de problèmes identifiés, répartition par sévérité, les 3 à 5 problèmes les plus critiques.
  • La grille consolidée avec tous les problèmes, triés par sévérité.
  • Des captures d’écran annotées pour les problèmes majeurs et catastrophiques.
  • Des recommandations priorisées : que corriger en premier ?

Pour la priorisation, je recommande une matrice simple : impact (sévérité du problème) vs effort de correction estimé. Les problèmes à forte sévérité et faible effort de correction sont les “quick wins” à traiter en priorité.


Les erreurs courantes à éviter

1. Faire l’évaluation seul. C’est l’erreur la plus fréquente. Un seul évaluateur ne détecte qu’un tiers des problèmes. Si vous êtes seul, votre audit aura une couverture insuffisante. Impliquez au minimum deux autres personnes.

2. Confondre évaluation heuristique et test utilisateur. L’évaluation heuristique repose sur le jugement d’experts, pas sur l’observation d’utilisateurs réels. Les deux méthodes ont des forces différentes. L’évaluation heuristique est rapide et peu couteuse. Le test utilisateur révèle des problèmes que même les experts ne voient pas.

3. Évaluer sans grille. Parcourir une interface “au feeling” en notant ce qui semble problématique n’est pas une évaluation heuristique. Sans grille de référence, vous risquez de passer à côté de catégories entières de problèmes. Choisissez Nielsen ou Bastien-Scapin et suivez la grille.

4. Négliger la sévérité. Lister 150 problèmes sans les hiérarchiser est contre-productif. L’équipe de développement a besoin de savoir par où commencer. Utilisez systématiquement l’échelle de sévérité.

5. Ne pas prendre en compte le contexte d’usage. Une violation qui semble critique dans l’absolu peut être mineure si la fonctionnalité concernée est très rarement utilisée. Croisez vos résultats avec les données d’usage (analytics, feedback utilisateurs) si elles sont disponibles.

6. Oublier les parcours mobiles. Si votre produit est utilisé sur mobile, évaluez l’interface mobile séparément. Les problèmes d’ergonomie mobile (taille des zones de tap, navigation au pouce, temps de chargement) sont souvent différents de ceux de la version desktop.


Quand utiliser l’évaluation heuristique vs le test utilisateur ?

CritèreÉvaluation heuristiqueTest utilisateur
Qui évalue ?Des experts UXDe vrais utilisateurs
Durée1 à 2 jours1 à 3 semaines (avec recrutement)
CoûtFaible (temps des experts)Modéré à élevé (recrutement, incentives)
Ce qu’on détecteViolations de principes ergonomiquesComportements réels, incompréhensions
Ce qu’on rateLes problèmes spécifiques au contexte utilisateurLes violations de principes non liées au scénario testé
Quand l’utiliserEn amont, quand on a besoin d’un diagnostic rapideQuand on veut valider des hypothèses avec des utilisateurs

Ma recommandation : commencez par une évaluation heuristique pour identifier et corriger les problèmes les plus évidents, puis enchainez avec des tests utilisateurs pour explorer les comportements réels. L’évaluation heuristique permet de “nettoyer” l’interface avant les tests, pour que les sessions se concentrent sur les vrais enjeux d’usage.


Pour aller plus loin


Envie d'aller plus loin ?

Je propose du coaching individuel pour approfondir ces sujets et les appliquer à votre contexte.

Prendre rendez-vous