Un message d’erreur apparaît lorsqu’une personne tente d’accomplir une tâche et qu’un obstacle l’en empêche. S’il se contente d’annoncer un problème, l’utilisateur ne sait pas s’il doit corriger une donnée, patienter, réessayer ou demander de l’aide. Pour les équipes produit et techniques, l’objectif n’est pas d’enjoliver l’échec : il s’agit d’aider la personne à choisir la prochaine étape et d’éviter qu’elle perde son travail ou répète une action aux conséquences importantes.
Concevoir des messages utiles suppose de connaître l’origine de l’erreur, les informations encore disponibles et les possibilités de rétablissement. Il faut également coordonner le texte avec le comportement réel de l’application. Une consigne comme « Réessayez » est nuisible si l’opération a déjà abouti ou si la répéter risque de créer un doublon.
Classer l’erreur avant de la rédiger
Commencez par déterminer ce qui empêche la tâche d’aboutir et qui peut résoudre le problème. Cette classification aide à choisir le contenu du message et l’action à proposer :
- Erreur que la personne peut corriger : un champ obligatoire est vide, le format d’une donnée n’est pas valide ou un choix ne respecte pas une condition. Expliquez ce qu’il faut vérifier et indiquez le champ concerné.
- Problème temporaire du système : l’application ne peut pas effectuer une opération en raison d’un incident ou d’une situation passagère. Précisez s’il convient d’attendre ou de réessayer, ainsi que ce qu’il adviendra des données.
- Dépendance externe : un service connecté ne répond pas ou rejette la demande. N’en attribuez pas la cause à l’utilisateur et ne promettez pas de délai de résolution. Communiquez ce que l’application sait et proposez une solution de remplacement réaliste.
- Situation nécessitant une assistance : la personne ne peut pas lever le blocage depuis l’interface ou le cas nécessite une vérification. Indiquez comment contacter le support et quelles informations utiles lui fournir.
Il n’est pas nécessaire de dévoiler l’architecture technique pour établir cette distinction. En revanche, il faut s’entendre avec l’équipe de développement sur l’état de l’opération, la sauvegarde éventuelle des modifications et la possibilité de la répéter sans risque. Sans ces informations, l’équipe éditoriale ne peut pas fournir de consignes fiables.
Expliquer la cause, les conséquences et la prochaine étape
Un message pratique répond en langage courant à trois questions : que s’est-il passé, quelles sont les conséquences et que peut faire la personne maintenant ? Si c’est pertinent, précisez également si les données ont été conservées. Inutile d’expliquer tous les détails internes ; il suffit de donner assez de contexte pour permettre à la personne d’agir.
Par exemple, « Le formulaire n’a pas pu être enregistré, car le numéro de téléphone manque. Ajoutez un numéro dans le champ Téléphone, puis enregistrez à nouveau » indique le résultat, la raison et la correction à apporter. À l’inverse, « Erreur lors du traitement de la demande » ne dit pas où intervenir. Pour un problème passager, une formulation comme « Nous n’avons pas pu charger vos résultats. Vos filtres sont toujours disponibles ; réessayez » n’est utile que si l’interface conserve réellement ces filtres.
Vérifiez chaque texte au regard de l’état réel du produit. Si vous ne pouvez pas confirmer que les données ont été enregistrées, ne dites pas qu’elles sont en sécurité. Si vous ignorez la cause, ne l’inventez pas : indiquez le résultat et proposez une action sans risque. Une explication limitée mais exacte vaut mieux qu’une promesse rassurante que l’application ne peut pas tenir.
Choisir une solution qui n’aggrave pas le problème
L’action proposée doit correspondre au type d’échec et aux conséquences d’une nouvelle tentative. Avant d’afficher un bouton ou une consigne, posez-vous les questions suivantes :
- La personne peut-elle corriger le problème ? Si oui, attirez son attention sur le champ ou le choix à modifier et conservez le reste dans la mesure du possible.
- Est-il sans risque de réessayer ? Si l’opération a pu aboutir sans que l’interface le confirme, ne proposez pas de réessayer sans vérification. Vérifiez son état ou expliquez comment le contrôler.
- Est-il possible de poursuivre autrement ? Si une autre option fonctionne, comme enregistrer un brouillon ou terminer le processus plus tard, rendez-la visible sans masquer l’action principale.
- Faut-il contacter le support ? Indiquez un moyen de contact disponible et, si utile, un identifiant de référence. N’en faites pas l’unique issue lorsque la personne peut résoudre le problème elle-même.
Pour les opérations sensibles — par exemple, envoyer une commande, effectuer un paiement ou publier du contenu — convenez avec l’équipe de développement de la manière de confirmer le résultat et d’éviter la répétition d’une action. Le message affiché doit refléter ce comportement ; le texte, à lui seul, ne peut pas garantir qu’une opération est sûre.
Rédiger clairement, sans culpabiliser
Écrivez pour la personne qui essaie d’accomplir une tâche, pas pour celle qui débogue le système. Évitez les codes internes, les noms de composants et les expressions comme « requête invalide » si elles n’indiquent pas ce qu’il faut corriger. Un code peut être utile au support, mais il doit accompagner une explication compréhensible, et non la remplacer.
Adoptez un ton direct et neutre. « Nous n’avons pas pu valider l’adresse » décrit le résultat sans accuser la personne. « Vous avez mal saisi l’adresse » lui attribue la faute, ce qui peut être inexact : le format attendu n’est peut-être pas clair. Évitez également les consignes vagues comme « Vérifiez vos informations » lorsque vous pouvez préciser quelle donnée doit être contrôlée.
La concision est utile, mais ne doit pas faire disparaître une conséquence importante. Si une réponse a été effacée, si le processus est toujours en cours ou si la personne peut réessayer sans créer de doublon, dites-le. Si vous ne savez pas laquelle de ces situations s’applique, suspendez la rédaction et demandez à l’équipe technique de définir l’état.
Veiller à ce que le message soit perceptible et utilisable
Le texte doit apparaître près de l’élément concerné ou à un endroit cohérent avec la portée du problème. Une erreur portant sur un champ est généralement plus utile à côté de celui-ci que dans une notification éloignée. Si toute la tâche est bloquée, un message général peut expliquer la situation et proposer une action principale. Ne vous appuyez pas uniquement sur la couleur pour signaler un problème : accompagnez-la d’un texte identifiable.
Vérifiez que le message est compréhensible au clavier et avec les technologies d’assistance, et que la personne peut trouver le champ correspondant sans avoir à le deviner. Dans les formulaires, vérifiez si l’erreur reste visible après la correction de la donnée et si la mise au point ou la navigation permet de poursuivre. Une phrase bien formulée ne suffit pas à garantir l’accessibilité si l’avis n’atteint pas la personne qui en a besoin.
Le moment d’affichage compte aussi : une notification qui disparaît avant d’avoir pu être lue, ou qui apparaît avant que la personne ait fini de saisir ses données, peut accroître la confusion. Validez le comportement dans l’interface réelle et dans les états pertinents, pas seulement le texte dans un document.
Documenter et valider une matrice d’erreurs
Pour éviter que le même problème donne lieu à des réponses différentes, créez une matrice partagée entre les équipes produit, design, développement et service client. Incluez au minimum :
- Le nom de l’état et l’origine connue du problème.
- La tâche que la personne effectuait et l’ampleur de l’impact.
- Les données conservées, supprimées ou dont l’état reste à confirmer.
- Le texte affiché, son emplacement et l’action proposée.
- La personne chargée de confirmer le comportement et les critères d’escalade au support.
Donnez la priorité aux erreurs qui bloquent des tâches importantes, risquent de faire perdre des données ou génèrent des demandes répétées. Testez les messages à partir de tâches réelles : observez si la personne comprend ce qui s’est passé, trouve la prochaine étape et parvient à poursuivre sans aide extérieure. Notez les endroits où elle abandonne ou réessaie, ainsi que les demandes reçues par le support, puis comparez ces indicateurs avant et après les changements. Une baisse des demandes ne prouve pas, à elle seule, que le problème est résolu : elle peut signifier que les personnes ont cessé d’essayer d’accomplir la tâche.
Mettez la matrice à jour lorsque le parcours, les dépendances ou la logique d’enregistrement changent. La qualité d’un message ne se mesure pas à son ton aimable, mais à sa capacité à décrire précisément l’état et à permettre d’agir. Lorsque le produit ne connaît pas encore le résultat, la meilleure décision peut consister à éviter une nouvelle tentative automatique, à expliquer l’incertitude et à proposer une vérification ou une assistance sans risque.