Instructions relatives aux messages d’erreur

Un message d’erreur est un texte qui s’affiche pour décrire un problème qui s’est produit qui empêche l’utilisateur ou le système d’effectuer une tâche. Le problème peut entraîner une altération ou une perte de données. Les autres types de messages incluent les confirmations, les avertissements et les notifications. Les instructions de cette rubrique sont destinées à vous aider à écrire des messages d’erreur clairs qui sont faciles à localiser et utiles pour les clients.

Les messages d’erreur mal écrits peuvent être une source de frustration pour les utilisateurs et peuvent augmenter les coûts de support technique. Un message d’erreur bien écrit fournit les informations suivantes à l’utilisateur :

• Que s’est-il passé et pourquoi ?
• Quel est le résultat final pour l’utilisateur ?
• Que peut faire l’utilisateur pour éviter que cela ne se reproduise ?

La longueur du texte n’est pas un problème tant que le développeur gère correctement les tailles de mémoire tampon. Il est important que l’utilisateur dispose de toutes les informations nécessaires pour résoudre le problème. Si un message a plusieurs audiences, vous devrez peut-être fournir du texte distinct pour les administrateurs, les utilisateurs finaux et les développeurs.

Bonnes pratiques

Voici des façons d’améliorer vos messages d’erreur :

• Évitez les conditions d’erreur. Si vous pouvez prédire qu’une erreur se produira lorsqu’un utilisateur effectue une action spécifique, réécrire votre code afin qu’il ne puisse pas provoquer l’erreur.
• Écrivez un message d’erreur distinct pour chaque cause connue de l’erreur. N’utilisez pas un seul message générique pour expliquer toutes les raisons possibles de l’erreur, sauf si vous ne pouvez pas déterminer la cause de l’erreur lorsqu’elle se produit.
• Indiquez clairement le problème et, s’il est utile pour l’utilisateur, expliquez la cause du problème. Dans la mesure du possible, remplacez les messages génériques des ressources de la table de messages système par un message détaillé spécifique au problème.
• Fournissez à l’utilisateur une solution au problème. Si la solution comporte plusieurs étapes, reportez-vous à une rubrique d’aide expliquant la tâche en détail.
• Affichez uniquement le nom du produit, du composant ou de l’Assistant dans la barre de titre du message. Cela permet à l’utilisateur de déterminer où se trouve le problème. Ne résumez pas le problème dans la barre de titre ou n’incluez pas le mot « erreur ».
• N’utilisez pas de jargon technique, utilisez une terminologie que votre public comprend. N’utilisez pas d’argot ou d’abréviations.
• Utilisez les boutons de commande appropriés, tels que OK, Annuler, Oui, Non et Réessayer. Vous pouvez utiliser des combinaisons de ces boutons. Les boutons Oui et Non doivent toujours être utilisés en combinaison et doivent toujours être précédés d’une question.
  • Pour arrêter une opération et fermer la boîte de message, utilisez le bouton Annuler .
  • Pour fermer une boîte de message, utilisez le bouton Fermer .
  • Pour fournir plus d’informations sur la cause de l’erreur, utilisez le bouton Détails .
  • Pour fournir plus d’informations sur la solution au problème, utilisez le bouton Aide .
  • Si une action utilisateur est incluse dans le message, utilisez le bouton OK pour fermer la zone de message.
  • Les boutons Oui et Non doivent être utilisés en combinaison et doivent toujours être précédés d’une question.
• Si l’erreur est une erreur critique, écrivez-la dans le journal des événements.

Considérations relatives au style

• Utilisez des phrases complètes mais simples.
• Utilisez le temps présent pour décrire les conditions qui ont provoqué le problème ou un état qui existe toujours. Vous pouvez utiliser le temps passé pour décrire un événement distinct qui s’est produit dans le passé.
• Utilisez la voix active chaque fois que possible. Vous pouvez utiliser la voix passive pour décrire la condition d’erreur.
• Évitez le texte majuscule et les points d’exclamation.
• Ne faites pas en sorte que l’utilisateur se sente en faute même si le problème est le résultat d’une erreur de l’utilisateur.
• Ne pas anthropomorphiser. Ne signifiez pas que les programmes ou le matériel peuvent penser ou sentir.
• N’utilisez pas de mots ou d’expressions familiers. N’utilisez pas de termes qui peuvent être offensants dans certaines cultures.
• Ne composez pas plusieurs noms sans ajouter de préposition ou de sous-clause pour clarifier la signification. Par exemple, « Serveur de site serveur LDAP Service directory server » doit être remplacé par « Serveur d’annuaire pour le service LDAP du serveur de site ».
• Insérez des descripteurs avant un terme pour clarifier la signification de la phrase. Par exemple, « Spécifier InfID lorsque Détecter a la valeur Non » doit être remplacé par « Spécifier le paramètre InfID lorsque l’option Détecter est définie sur Non ».
• Évitez le mot « mauvais ». Utilisez des termes plus descriptifs pour indiquer à l’utilisateur ce qui ne va pas. Par exemple, évitez les messages tels que « Taille incorrecte ». Au lieu de cela, indiquez à l’utilisateur quels critères utiliser lors de la spécification d’une taille.
• Évitez le mot « s’il vous plaît ». Cela peut être interprété comme signifiant qu’une action requise est facultative.
• Placez les mots qui sont à la fois dans l’index et qui sont pertinents pour la signification centrale au début de la chaîne de message.