Nombre d’applications, et site web utilisent des messages génériques pour indiquer à l’utilisateur qu’une erreur est survenue. L’utilisateur peut alors se trouver dans une impasse. Il lui est impossible de savoir ce qui s’est passé et ne peut faire que des suppositions.

À mon sens, il y a là un défaut d’accessibilité, car l’utilisateur est dans l’incapacité d’utiliser l’application. S’ajoute à cela la frustration qui fait que votre utilisateur risque de faire l’impasse sur votre service. Sans compter le stress produit s’il s’agit d’un service critique que celui-ci ne peut pas éviter (stress et la perte d’orientation sont des critères que l’on associe de plus en plus à l’accessibilité).

Peut-on y remédier ? Oui, et peut-être non ...

Parfois, le message générique est le produit d’un léger relâchement des développeurs ou d’un manque d’anticipation (cahier des charges incomplet, cas d’erreurs non listés…). Dans ce cas, il suffit de se remonter les manches et de clarifier chaque message. C’est du travail, mais cela garantit la qualité de l’application. Cela aurait donc dût être travaillé en amont. Dommage.

Dans certains cas, le message générique est présent pour des raisons de sécurité.

Exemple : Pour une page d’authentification. Il est hors de question de dire à un utilisateur que l’identifiant saisi n’existe pas, ou que le mot de passe n’est pas associé à celui-ci. Cela consisterait à fournir bien trop d’informations à un éventuel attaquant.

Le message peut cependant évoluer après quelques tentatives infructueuses, pour inviter l’utilisateur à demander une réinitialisation de son mot de passe (en fournissant le lien adéquat dans le message).

Mais vous pouvez être dans la situation d’une erreur totalement imprévue. C’est le cas quand une erreur se produit et qu’aucun code n’existe pour la capturer. Dans ce cas, on affiche souvent une page d’erreur à défaut (pages 403, 404, 505) ou une boite de dialogue. Le message générique s’impose.

Comment s’en sortir ?

Si le message générique s’impose, il y a toujours une solution pour sortir l’utilisateur de l’impasse.

Voici trois règles que l’on peut appliquer pour limiter les dégâts :

• Tenter de donner une forme propre, respectueuse, voir sympathique au message d’erreur. Respecter le style de votre application tout en n’abusant pas trop du rouge agressif et des majuscules. Ajouter une illustration propre, voire humoristique, peut parfois détendre l’utilisateur.
• Ajouter une zone de saisie avec un message invitant l’utilisateur à décrire l’action qu’il souhaitait entreprendre. Traiter sa réponse par mail (ou par Log) et lui répondre de la bonne prise en charge de ses informations (des remerciements sont de rigueur). Un petit mail envoyé automatiquement avec un identifiant d’incident appuie le soutien que vous apportez à vos utilisateurs.
• Permettre à l’utilisateur de revenir dans la situation qui a précédé l’erreur. Rien de pire qu’une saisie perdue ou une page que l’on ne peut plus atteindre à la suite d’une erreur.

J’ai déjà produit une page d’erreur avec plusieurs images affichées suivant un cycle (un personnage qui prenait différentes postures pour demander pardon). À chaque nouvelle erreur, une nouvelle image était affichée. Les utilisateurs ont apprécié et étaient plus détendus lors de la remontée de bugs.

Conclusion

Comme je le dis souvent, la prise en compte de l’accessibilité n’est pas qu’un sujet de handicap. C’est bien souvent un problème de conception qui met l’utilisateur dans l’impasse. Évitez les zones d’ombre sur vos projets et discutez des erreurs rencontrées plutôt que de les camoufler derrière un message d’erreur énigmatique. Il y a toujours une solution pour cela.