Des messages d'erreur qui indiquent aux utilisateurs et aux agents quoi faire ensuite

Ce que c'est

Un message d'erreur est la réponse de l'interface à deux questions que le cours de Google sur les messages d'erreur (cité) place en son centre : qu'est-ce qui s'est mal passé, et comment l'utilisateur peut-il le corriger. Les règles du cours consistent à expliquer le problème, identifier la cause et l'entrée invalide, préciser les exigences et les contraintes, et expliquer la solution. Les recommandations de Microsoft (citées) demandent qu'un message donne un problème, une cause et une solution, et soit rédigé du point de vue de l'utilisateur. Pour un message lu par un programme ou un agent, le même contenu doit être disponible sous forme de champs, et pas seulement sous forme de texte.

Pourquoi c'est important

Un message vague (« Requête invalide ») produit un ticket de support, une supposition, ou, de la part d'un client automatisé, une boucle de tentatives identiques. Le message est souvent la seule documentation dont dispose le lecteur à ce moment-là. L'approche du compilateur Rust (citée) montre jusqu'où cela peut être poussé : les diagnostics portent des suggestions structurées étiquetées avec un niveau d'applicabilité (MachineApplicable, HasPlaceholders, MaybeIncorrect, Unspecified), de sorte que les outils n'appliquent automatiquement que celles marquées comme mécaniquement applicables.

Comment l'appliquer

• Nommer précisément la chose en cause : le champ, le fichier et la ligne, la valeur réelle reçue, et ce qui était attendu à la place (« start_date : une date ISO 8601 telle que 2026-09-15 était attendue, 15.09.2026 a été reçu »).
• Énoncer la contrainte, pas seulement l'échec : la limite, l'ensemble autorisé, le format requis.
• Indiquer quoi faire ensuite, et si refaire la même chose peut réussir : distinguer explicitement « corriger l'entrée », « attendre puis réessayer » et « contacter l'exploitant ».
• Donner à chaque cause distincte son propre message et un identifiant stable et recherchable ; garder cet identifiant constant d'une version à l'autre même lorsque le libellé s'améliore.
• Pour les agents et les clients, fournir les éléments sous forme de champs : code, champ, valeur attendue, valeur reçue, possibilité de nouvelle tentative, lien vers la documentation ; le format Problem Details pour les API HTTP (voir l'article associé) en est un vecteur.
• Garder les corrections suggérées séparées de l'énoncé de l'erreur, et étiqueter leur degré de confiance, comme le fait le guide Rust ; une suggestion erronée appliquée automatiquement est pire que l'absence de suggestion.
• Ne jamais exposer les détails internes aux utilisateurs finaux (traces de pile, noms d'hôtes, SQL, secrets) ; journaliser ces éléments avec un identifiant de corrélation que le message affiche.
• Écrire en termes simples, sans reproche, sans double négation ni humour ; tester chaque message en se demandant « que ferais-je maintenant ? ».

Pièges

Des messages fourre-tout qui masquent la cause. Des messages dont le libellé change à chaque version et qui cassent les analyseurs. Des suggestions erronées plus souvent que correctes. Des erreurs de validation signalées une par une alors que le client a envoyé dix champs. Révéler indirectement si un compte existe au moyen de messages différents pour « mot de passe erroné » et « utilisateur inconnu ».