Un message d'erreur doit dire quoi faire
« Une erreur est survenue » ne renseigne personne et déclenche un appel au support. Un bon message coûte le même nombre de lignes de code.
Un message d’erreur est une phrase écrite à quelqu’un qui est déjà contrarié, pressé, et qui ne comprend pas ce qui se passe. C’est le pire moment pour lui parler mal.
Et pourtant : « Une erreur est survenue. Veuillez réessayer ultérieurement. »
Trois éléments, toujours
Ce qui s’est passé, en termes compréhensibles. Pourquoi, si la raison est connue et actionnable. Ce qu’il faut faire maintenant.
« Le fichier dépasse la taille maximale de 5 Mo. Réduisez-le ou envoyez-le en plusieurs parties. » couvre les trois en deux phrases, et supprime un appel au support.
Distinguer deux familles
L’erreur de l’utilisateur est réparable par lui. Le message doit être précis, désigner le champ concerné, et rester neutre de ton. Pas de « vous avez oublié » : le formulaire n’a pas à juger.
La panne technique n’est pas réparable par lui. Inutile de lui montrer une trace d’exécution : il ne peut rien en faire, et cela expose des informations sur le système. Le message utile annonce que le problème est enregistré, donne un identifiant d’incident, et propose une voie de contournement — un numéro, une adresse.
L’identifiant d’incident est le détail qui transforme le support : la personne le communique, et le journal retrouve immédiatement l’événement exact.
Ne pas faire perdre ce qui a été saisi
Le pire message d’erreur est celui qui s’accompagne d’un formulaire vidé. Le contenu saisi doit revenir, y compris dans les champs corrects.
Sur les formulaires longs, la sauvegarde locale du brouillon évite qu’une déconnexion détruise vingt minutes de travail.
Placer le message dans le champ de vision
Un message en haut de page, sur un formulaire de deux écrans de haut, est invisible pour qui vient de valider en bas. Le message général en tête, doublé d’un message précis à côté de chaque champ concerné, et le focus déplacé sur le premier champ en erreur.
Ce déplacement du focus sert autant l’utilisateur pressé que la personne qui navigue au clavier ou avec un lecteur d’écran.
Ce qu’il ne faut pas écrire
Les codes techniques seuls, les termes internes — « échec de la validation du schéma » —, les excuses interminables, et l’humour. Une plaisanterie sur une page d’erreur est drôle une fois, et pénible à la troisième rencontre en essayant de payer.
Les relire une fois par an
Les messages s’écrivent au fil du développement, par des personnes différentes, et le ton diverge. Les extraire et les relire d’un bloc prend une heure, et révèle des incohérences que personne ne voit dans le flux normal du travail.