Les 10 heuristiques de Nielsen appliquées au mobile

Vous venez d’envoyer 25 000 FCFA à votre cousine. L’écran tourne, puis affiche « Erreur 0x80004005 ». L’argent est-il parti ? Faut-il recommencer ? Vous appelez le service client, qui n’en sait pas plus que vous.

Ce genre de défaut ne se voit pas dans le code : chaque ligne fait exactement ce qu’on lui a demandé. Il saute aux yeux dès qu’on regarde l’application avec les yeux de celui qui s’en sert. Et pour regarder avec méthode, il existe depuis plus de trente ans une grille courte et éprouvée : les 10 heuristiques de Jakob Nielsen.

À l’heure où une application se construit en quelques jours, cette grille est votre premier filtre avant le marché. À la fin de cet article, vous saurez passer un écran mobile au crible des dix règles, noter la gravité de chaque problème et remettre à l’équipe une liste priorisée.

Qu’est-ce qu’une heuristique d’utilisabilité ?

Jakob Nielsen a formulé ses heuristiques en 1990 avec Rolf Molich, puis les a affinées en 1994 à partir de l’analyse de 249 problèmes d’utilisabilité. Le Nielsen Norman Group a rafraîchi leur formulation et leurs exemples en 2020, sans en changer le fond.

Elles ont été pensées avant le smartphone, et c’est justement leur force : elles décrivent la façon dont les humains perçoivent, comprennent et se trompent, pas une technologie. Elles s’appliquent donc telles quelles à un écran de six pouces.

Une précision avant d’aller plus loin. L’évaluation heuristique est une méthode d’inspection : des évaluateurs examinent l’interface. Elle ne remplace pas un test avec de vrais utilisateurs ; elle le prépare, en éliminant les défauts évidents pour que les séances révèlent des problèmes plus profonds. Les deux méthodes se complètent, comme le montre notre guide pour organiser un test utilisateur.

Les heuristiques 1 à 5 sur un écran de téléphone

Pour chaque règle, voici ce qu’elle demande, puis un bon et un mauvais exemple tirés d’applications mobiles. Les noms anglais sont ceux du Nielsen Norman Group.

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

Visibility of system status : l’application dit toujours ce qui se passe, et le dit vite.

• Bien : après un transfert, l’écran affiche « Envoi en cours », puis « 25 000 FCFA envoyés à Awa Ngo, référence TX4821 », et un SMS confirme.
• Mal : le bouton « Payer » ne réagit pas pendant huit secondes sur un réseau 3G lent. L’utilisateur appuie une deuxième fois et paie deux fois.

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

Match between the system and the real world : parler la langue de l’utilisateur, avec ses mots, ses unités et ses habitudes.

• Bien : « Payer avec Orange Money ou MTN MoMo », des montants écrits « 25 000 FCFA », une adresse de livraison qui accepte un point de repère (« derrière la pharmacie du carrefour »), parce que c’est ainsi que beaucoup de gens décrivent leur domicile.
• Mal : « Échec de l’authentification du jeton », ou un champ « code postal » obligatoire que vos clients ne savent pas remplir.

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

User control and freedom : une sortie de secours visible pour annuler ou revenir en arrière.

• Bien : un bandeau « Annuler » pendant quelques secondes après la suppression d’un article du panier ; le retour arrière d’Android ramène à l’écran précédent sans vider le formulaire.
• Mal : une inscription en six étapes sans retour possible, où une erreur à l’étape 5 oblige à tout recommencer.

4. Cohérence et standards

Consistency and standards : les mêmes mots et les mêmes gestes partout, et les conventions d’Android et d’iOS respectées.

• Bien : la navigation principale en bas de l’écran, les icônes que tout le monde connaît (loupe, panier, engrenage), le même mot « Panier » sur tous les écrans.
• Mal : « Panier » ici, « Sac » là, « Ma commande » ailleurs ; une icône de corbeille qui archive au lieu de supprimer.

5. Prévention des erreurs

Error prevention : mieux vaut empêcher l’erreur que bien l’expliquer.

• Bien : le clavier numérique pour un numéro de téléphone, l’indicatif +237 déjà rempli, le nom du bénéficiaire affiché avant de confirmer un transfert.
• Mal : un champ montant qui comprend « 25.000 » comme 25 FCFA ; un bouton « Supprimer mon compte » collé au bouton « Enregistrer ».

Les heuristiques 6 à 10 sur un écran de téléphone

6. Reconnaissance plutôt que rappel

Recognition rather than recall : montrer les options au lieu d’obliger à se souvenir.

• Bien : la liste des derniers bénéficiaires, les adresses de livraison enregistrées, les recherches récentes.
• Mal : demander de retaper le code marchand affiché sur l’écran précédent ; une barre d’icônes sans libellés que seul le designer sait lire.

7. Flexibilité et efficacité d’utilisation

Flexibility and efficiency of use : des raccourcis pour les habitués, sans compliquer la vie des débutants.

• Bien : « Renvoyer la même somme » sur la dernière transaction, des favoris, et un parcours guidé qui reste disponible pour les nouveaux.
• Mal : une commerçante qui encaisse cinquante paiements par jour doit traverser cinq écrans à chaque fois.

8. Design esthétique et minimaliste

Aesthetic and minimalist design : chaque élément en trop fait concurrence à l’essentiel. Minimaliste ne veut pas dire « joli », mais « sans bruit ».

• Bien : un accueil qui montre le solde et trois actions principales, rien de plus.
• Mal : un carrousel publicitaire, douze icônes, deux bannières, et le bouton « Envoyer » perdu au milieu.

9. Aider à reconnaître, diagnostiquer et corriger les erreurs

Help users recognize, diagnose, and recover from errors : un message d’erreur dit ce qui ne va pas, en langage simple, et comment s’en sortir.

• Bien : « Ce numéro semble incomplet : il manque un chiffre. » Le champ fautif est signalé, le reste du formulaire est conservé.
• Mal : « Erreur 500 » ou « Une erreur est survenue », et un formulaire entièrement vidé.

10. Aide et documentation

Help and documentation : idéalement, on n’en a pas besoin ; sinon, l’aide est facile à trouver, centrée sur la tâche et concrète.

• Bien : un lien « Où trouver mon code marchand ? » juste sous le champ, une aide lisible sans connexion, un contact WhatsApp du support.
• Mal : une FAQ de quarante questions sans recherche, ou un PDF à télécharger avec un forfait presque vide.

Comment mener une évaluation heuristique en 5 étapes

Le Nielsen Norman Group recommande trois à cinq évaluateurs qui travaillent chacun de leur côté. Dans les travaux de Nielsen portant sur six projets, un évaluateur seul ne trouvait en moyenne qu’environ 35 % des problèmes : personne ne voit tout.

1. Délimitez le périmètre. Un parcours, pas toute l’application : par exemple « de l’ouverture au premier paiement ». Notez l’appareil, le système et la version testés.
2. Préparez des conditions réelles. Un téléphone d’entrée de gamme, une connexion lente, l’usage à une main, dehors si possible. Une interface confortable sur un téléphone haut de gamme en Wi-Fi peut devenir pénible ailleurs (voir le test de compatibilité sur appareils).
3. Faites deux passages. Le premier pour comprendre le parcours, le second pour confronter chaque écran aux dix heuristiques et noter chaque écart.
4. Travaillez seul, puis mettez en commun. Chacun remplit sa grille sans voir celle des autres. On regroupe ensuite les doublons et on discute des désaccords.
5. Notez la gravité, puis priorisez. C’est l’objet de la section suivante.

Comment noter la gravité d’un problème

Tous les problèmes ne se valent pas. Nielsen propose une échelle de 0 à 4, qui reste la référence. Le tableau ci-dessous la résume, avec la décision qui en découle.

Pour choisir la note, Nielsen combine trois facteurs : la fréquence (le problème est-il courant ?), l’impact (est-il difficile à surmonter ?) et la persistance (gêne-t-il une fois, ou à chaque usage ?). Il y ajoute l’impact sur le marché : un défaut facile à contourner peut quand même faire fuir les clients.

Une note donnée par une seule personne est peu fiable. Faites noter chaque problème par au moins trois évaluateurs, chacun de son côté, et retenez la moyenne.

La grille d’évaluation prête à l’emploi

Copiez ce tableau dans un tableur ou un document partagé. Il donne, pour chaque heuristique, la question à se poser devant chaque écran ; ajoutez une ligne par problème trouvé.

Pour chaque problème, consignez au moins ces informations :

Problème n° 7
Écran : Paiement > Confirmation
Heuristique : 1. Visibilité de l'état du système
Constat : aucun indicateur après l'appui sur « Payer » (Android d'entrée de gamme, réseau 3G)
Conséquence : double appui, double débit observé
Gravité : 4 (moyenne de trois évaluateurs)
Piste : désactiver le bouton et afficher « Paiement en cours »

Pour transformer chaque ligne en ticket que l’équipe corrigera vraiment, suivez notre guide du rapport de bug efficace.

Les erreurs fréquentes et les limites de la méthode

• Confondre goût personnel et heuristique. « Je n’aime pas ce bleu » n’est pas un constat. Chaque problème doit citer une règle et un effet sur l’utilisateur.
• Évaluer seul. Un évaluateur unique passe à côté de la plupart des problèmes.
• Évaluer sur le téléphone du développeur. Grand écran, Wi-Fi rapide, compte de test bien rempli : ce sont les conditions les plus favorables, donc les moins révélatrices.
• Oublier les états rares. Liste vide, réseau coupé, session expirée, texte plus long en anglais : beaucoup de violations se cachent là.
• S’arrêter à l’inspection. Les évaluateurs connaissent trop le produit ou le métier. Certains problèmes n’apparaissent qu’avec de vrais utilisateurs, et certains défauts signalés par les experts ne gêneront personne. Seul un test utilisateur tranche.
• Croire que les dix règles couvrent tout. Elles ne remplacent ni le test d’accessibilité ni les tests de performance.

Si vous voulez un regard neuf et extérieur, les testeurs GeekTest peuvent passer votre application au crible sur leurs propres téléphones : il suffit de commander un test.

Pour aller plus loin

• 10 Usability Heuristics for User Interface Design (nouvel onglet) — Jakob Nielsen, Nielsen Norman Group. La formulation actuelle des dix heuristiques, leur histoire et des exemples illustrés.
• Heuristic Evaluations : How to Conduct (nouvel onglet) — Kate Moran et Kelley Gordon, NN/g (2023). La méthode pas à pas : préparation, évaluation individuelle, mise en commun.
• Severity Ratings for Usability Problems (nouvel onglet) — Jakob Nielsen, NN/g. L’échelle de gravité de 0 à 4 et les facteurs à combiner pour choisir une note.
• The Theory Behind Heuristic Evaluations (nouvel onglet) — Jakob Nielsen, NN/g. Pourquoi un évaluateur seul ne suffit pas, avec les données de six projets.