Messages d’erreur dans Windows 7

Les messages d’erreur dans Windows 7 alertent les utilisateurs des problèmes qui se sont déjà produits. En revanche, les messages d’avertissement alertent les utilisateurs de conditions susceptibles de provoquer des problèmes à l’avenir. Les messages d’erreur peuvent être présentés à l’aide de boîtes de dialogue modales, de messages sur place, de notifications ou de bulles.

Message d’erreur modal classique.

Les messages d’erreur effectifs informent les utilisateurs qu’un problème s’est produit, expliquent pourquoi il s’est produit et fournissent une solution afin que les utilisateurs puissent résoudre le problème. Les utilisateurs doivent effectuer une action ou modifier leur comportement en raison d’un message d’erreur.

Les messages d’erreur bien écrits et utiles sont essentiels à une expérience utilisateur de qualité. Les messages d’erreur mal écrits entraînent une faible satisfaction des produits et sont une cause principale des coûts de support technique pouvant être évités. Les messages d’erreur inutiles interrompent le flux des utilisateurs.

Remarque : Instructions relatives aux boîtes de dialogue , messages d’avertissement, confirmations, icônes standard, notificationset de disposition sont présentées dans des articles distincts.

Est-ce l’interface utilisateur appropriée ?

Pour décider, tenez compte de ces questions :

• L’interface utilisateur présente-t-elle un problème qui s’est déjà produit ? Si ce n’est pas le cas, le message n’est pas une erreur. Si l’utilisateur est averti d’une condition susceptible de provoquer un problème à l’avenir, utilisez un message d’avertissement.
• Le problème peut-il être évité sans provoquer de confusion ? Dans ce cas, empêchez le problème à la place. Par exemple, utilisez des contrôles qui sont contraints à des valeurs valides au lieu d’utiliser des contrôles sans contrainte qui peuvent nécessiter des messages d’erreur. En outre, désactiver les contrôles lors du clic entraînerait une erreur, tant qu’il est évident que le contrôle est désactivé.
• Le problème peut-il être corrigé automatiquement ? Dans ce cas, gérez le problème et supprimez le message d’erreur.
• Les utilisateurs sont-ils susceptibles d’effectuer une action ou de modifier leur comportement à la suite du message ? Si ce n’est pas le cas, la condition ne justifie pas l’interruption de l’utilisateur afin qu’il soit préférable de supprimer l’erreur.
• Le problème est-il pertinent lorsque les utilisateurs utilisent activement d’autres programmes ? Si c’est le cas, envisagez d’afficher le problème à l’aide d’une icône de zone de notification .
• Le problème n’est-il pas lié à l’activité de l’utilisateur actuel, ne nécessite-t-il pas une action immédiate de l’utilisateur et les utilisateurs peuvent-ils l’ignorer librement ? Dans ce cas, utilisez une notification d’échec d’action à la place.
• Le problème concerne-t-il l’état d’une tâche en arrière-plan dans une fenêtre primaire ? Si c’est le cas, envisagez d’afficher le problème à l’aide d’une barre d’état .
• Les principaux utilisateurs cibles sont-ils des professionnels de l’informatique ? Si c’est le cas, envisagez d’utiliser un autre mécanisme de commentaires, tel que fichier journal entrées ou alertes par courrier électronique. Les professionnels de l’informatique préfèrent fortement les fichiers journaux pour les informations non critiques.

Concepts de conception

Caractéristiques des messages d’erreur médiocres

Il ne devrait pas être surprenant qu’il y ait beaucoup de messages d’erreur ennuyeux, inutiles et mal écrits. Et étant donné que les messages d’erreur sont souvent présentés à l’aide de dialogues modals, ils interrompent l’activité actuelle de l’utilisateur et demandent d’être reconnus avant de permettre à l’utilisateur de continuer.

Une partie du problème est qu’il y a tellement de façons de le faire mal. Tenez compte de ces exemples à partir de la salle des messages d’erreur de la honte :

messages d’erreur inutiles

Incorrect :

Cet exemple de Windows XP peut être le pire message d’erreur jamais. Il indique qu’un programme n’a pas pu démarrer, car Windows lui-même est en cours d’arrêt. Il n’y a rien que l’utilisateur puisse faire à ce sujet ou même souhaite le faire (l’utilisateur a choisi d’arrêter Windows, après tout). Et en affichant ce message d’erreur, Windows s’empêche d’arrêter !

Le problème : Le message d’erreur lui-même est le problème. Outre l’abandon du message d’erreur, il n’y a rien à faire pour les utilisateurs.

Cause principale : Signaler tous les cas d’erreur, quels que soient les objectifs ou le point de vue des utilisateurs.

Alternative recommandée : Ne signalez pas d’erreurs dont les utilisateurs ne se soucient pas.

messages d’erreur « Réussite »

Incorrect :

Ce message d’erreur provient de l’utilisateur qui choisit de ne pas redémarrer Windows immédiatement après la suppression du programme. La suppression du programme a réussi du point de vue de l’utilisateur.

Le problème : Il n’y a aucune erreur du point de vue de l’utilisateur. Outre l’abandon du message d’erreur, il n’y a rien à faire pour les utilisateurs.

Cause principale : La tâche s’est terminée correctement du point de vue de l’utilisateur, mais a échoué du point de vue du programme de désinstallation.

Alternative recommandée : ne signalez pas d’erreurs pour les conditions que les utilisateurs considèrent acceptables.

messages d’erreur complètement inutiles

Incorrect :

Les utilisateurs apprennent qu’il y a eu une erreur, mais n’ont aucune idée de l’erreur ou de ce qu’il faut faire à ce sujet. Et non, ce n’est pas ok !

Le problème : Le message d’erreur ne pose pas de problème spécifique et aucun utilisateur ne peut le faire.

cause principale : le plus probable, le programme a une mauvaise gestion des erreurs.

Alternative recommandée : Concevoir une bonne gestion des erreurs dans le programme.

messages d’erreur incompréhensibles

Incorrect :

Dans cet exemple, l’instruction du problème est claire, mais l’explication supplémentaire est tout à fait déconcertante.

Le problème : l’instruction ou la solution du problème est incompréhensible.

Cause principale : Expliquer le problème du point de vue du code au lieu de l’utilisateur.

Alternative recommandée : écrire le texte du message d’erreur que vos utilisateurs cibles peuvent facilement comprendre. Fournir des solutions que les utilisateurs peuvent réellement effectuer. Concevoir l’expérience des messages d’erreur de votre programme n’a pas de programmeur qui compose des messages d’erreur sur place.

messages d’erreur qui surcommuniquent

Incorrect :

Dans cet exemple, le message d’erreur tente apparemment d’expliquer chaque étape de résolution des problèmes.

Le problème : trop d’informations.

Cause principale : Donner trop de détails ou essayer d’expliquer un processus de résolution des problèmes complexe dans un message d’erreur.

Alternative recommandée : Éviter les détails inutiles. En outre, évitez les utilitaires de résolution des problèmes. Si un utilitaire de résolution des problèmes est nécessaire, concentrez-vous sur les solutions les plus probables et expliquez le reste en liant la rubrique appropriée dans l’aide.

messages d’erreur inutilement durs

Incorrect :

L’incapacité du programme à trouver un objet semble peu catastrophique. Et en supposant qu’il est catastrophique, pourquoi est-ce ok la réponse ?

Le problème : le ton du programme est inutilement dur ou dramatique.

Cause principale : Le problème est dû à un bogue qui semble catastrophique du point de vue du programme.

Alternative recommandée : choisir soigneusement la langue en fonction du point de vue de l’utilisateur.

messages d’erreur qui blâment les utilisateurs

Incorrect :

Pourquoi faire en sorte que les utilisateurs se sentent comme un criminel ?

Le problème : Le message d’erreur est formulé de manière à accuser l’utilisateur d’effectuer une erreur.

cause principale : formulations insensibles qui se concentrent sur le comportement de l’utilisateur au lieu du problème.

Alternative recommandée : concentrez-vous sur le problème, et non sur l’action de l’utilisateur qui a conduit au problème, en utilisant la voix passive si nécessaire.

messages d’erreur Silly

Incorrect :

Dans cet exemple, l’instruction de problème est assez ironique et aucune solution n’est fournie.

Le problème : instructions de message d’erreur qui sont idiotes ou non séquitaires.

Cause principale : Création de messages d’erreur sans prêter attention à leur contexte.

Alternative recommandée : Avez vos messages d’erreur créés et examinés par un enregistreur. Tenez compte du contexte et de l’état d’esprit de l’utilisateur lors de l’examen des erreurs.

messages d’erreur du programmeur

Incorrect :

Dans cet exemple, le message d’erreur indique qu’il existe un bogue dans le programme. Ce message d’erreur a une signification uniquement pour le programmeur.

Le problème : Messages destinés à aider les développeurs du programme à trouver des bogues sont laissés dans la version de publication du programme. Ces messages d’erreur n’ont aucune signification ni valeur pour les utilisateurs.

cause principale : programmeurs utilisant l’interface utilisateur normale pour effectuer des messages eux-mêmes.

Alternative recommandée : développeurs doivent compiler conditionnellement tous ces messages afin qu’ils soient automatiquement supprimés de la version de mise en production d’un produit. Ne perdez pas de temps à essayer de faire des erreurs comme cela compréhensible pour les utilisateurs, car leur seul public est les programmeurs.

Messages d’erreur mal présentés

Incorrect :

capture d’écran de

Cet exemple présente de nombreuses erreurs de présentation courantes.

Le problème : Obtenir tous les détails incorrects dans la présentation du message d’erreur.

cause principale : Ne pas connaître et appliquer les instructions de message d’erreur. N’utilisez pas d’enregistreurs et d’éditeurs pour créer et examiner les messages d’erreur.

La nature de la gestion des erreurs est telle que beaucoup de ces erreurs sont très faciles à faire. Il est inquiétant de se rendre compte que la plupart des messages d’erreur pourraient être des candidats pour le Hall of Shame.

Caractéristiques des bons messages d’erreur

Contrairement aux exemples incorrects précédents, de bons messages d’erreur ont :

• Un problème. Indique qu’un problème s’est produit.
• Une cause. Explique pourquoi le problème s’est produit.
• Une solution. Fournit une solution pour que les utilisateurs puissent résoudre le problème.

En outre, de bons messages d’erreur sont présentés de manière à ce qu’il s’agit de :

• Pertinent. Le message présente un problème auquel les utilisateurs s’intéressent.
• Actionable. Les utilisateurs doivent effectuer une action ou modifier leur comportement à la suite du message.
• Centré sur l’utilisateur. Le message décrit le problème en termes d’actions ou d’objectifs de l’utilisateur cible, et non pas en termes de ce que le code n’est pas satisfait.
• Bref. Le message est aussi court que possible, mais pas plus court.
• Clair. Le message utilise un langage brut afin que les utilisateurs cibles puissent facilement comprendre le problème et la solution.
• Spécifique. Le message décrit le problème à l’aide d’un langage spécifique, en donnant des noms, des emplacements et des valeurs spécifiques des objets impliqués.
• Courtois. Les utilisateurs ne devraient pas être accusés ou faits pour se sentir stupides.
• Rare. Affiché rarement. Les messages d’erreur fréquemment affichés sont un signe de conception incorrecte.

En concevant votre expérience de gestion des erreurs pour avoir ces caractéristiques, vous pouvez conserver les messages d’erreur de votre programme hors de la salle des messages d’erreur de la honte.

Éviter les messages d’erreur inutiles

Souvent, le meilleur message d’erreur n’est pas un message d’erreur. De nombreuses erreurs peuvent être évitées par le biais d’une meilleure conception et il existe souvent de meilleures alternatives aux messages d’erreur. Il est généralement préférable d’éviter une erreur que de signaler une erreur.

Les messages d’erreur les plus évidents à éviter sont ceux qui ne sont pas actionnables. Si les utilisateurs sont susceptibles d’ignorer le message sans faire ou modifier quoi que ce soit, omettez le message d’erreur.

Certains messages d’erreur peuvent être éliminés, car ils ne sont pas des problèmes du point de vue de l’utilisateur. Par exemple, supposons que l’utilisateur a essayé de supprimer un fichier déjà en cours de suppression. Même s’il peut s’agir d’un cas inattendu du point de vue du code, les utilisateurs ne considèrent pas cette erreur, car leur résultat souhaité est atteint.

Incorrect :

Ce message d’erreur doit être éliminé, car l’action a réussi du point de vue de l’utilisateur.

Pour un autre exemple, supposons que l’utilisateur annule explicitement une tâche. Pour le point de vue de l’utilisateur, la condition suivante n’est pas une erreur.

Incorrect :

Ce message d’erreur doit également être supprimé, car l’action a réussi du point de vue de l’utilisateur.

Parfois, les messages d’erreur peuvent être éliminés en se concentrant sur les objectifs des utilisateurs au lieu de la technologie. Dans ce cas, reconsidérer ce qu’est vraiment une erreur. Le problème est-il lié aux objectifs de l’utilisateur ou à la capacité de votre programme à les satisfaire ? Si l’action de l’utilisateur est logique dans le monde réel, elle doit également être logique dans le logiciel.

Par exemple, supposons que dans un programme de commerce électronique, un utilisateur tente de trouver un produit à l’aide de la recherche, mais la requête de recherche littérale n’a aucune correspondance et le produit souhaité est hors stock. Techniquement, il s’agit d’une erreur, mais au lieu de donner un message d’erreur, le programme peut :

• Continuez à rechercher des produits qui correspondent le plus étroitement à la requête.
• Si la recherche comporte des erreurs évidentes, recommandez automatiquement une requête corrigée.
• Gérez automatiquement les problèmes courants tels que les fautes d’orthographe, les orthographes alternatives et les cas de pluralisation et de verbes incompatibles.
• Indiquez quand le produit sera en stock.

Tant que la demande de l’utilisateur est raisonnable, un programme de commerce électronique bien conçu doit retourner des résultats raisonnables et non des erreurs.

Un autre excellent moyen d’éviter les messages d’erreur est d’éviter les problèmes en premier lieu. Vous pouvez empêcher les erreurs en :

• Utilisation de contrôles contraints. Utilisez des contrôles qui sont limités aux valeurs valides. Les contrôles tels que les listes, les curseurs, les cases d’option, les cases d’option et les sélecteurs de date et d’heure sont limités aux valeurs valides, tandis que les zones de texte ne sont souvent pas et peuvent nécessiter des messages d’erreur. Toutefois, vous pouvez limiter les zones de texte à accepter uniquement certains caractères et accepter un nombre maximal de caractères.
• Utilisation d’interactions contraintes. Pour les opérations de glissement, autorisez les utilisateurs à déposer uniquement sur des cibles valides.
• Utilisation des contrôles désactivés et des éléments de menu. Désactivez les contrôles et les éléments de menu lorsque les utilisateurs peuvent facilement déduire pourquoi le contrôle ou l’élément de menu est désactivé.
• Fournir de bonnes valeurs par défaut. Les utilisateurs sont moins susceptibles d’effectuer des erreurs d’entrée s’ils peuvent accepter les valeurs par défaut. Même si les utilisateurs décident de modifier la valeur, la valeur par défaut permet aux utilisateurs de connaître le format d’entrée attendu.
• Faire des choses juste fonctionner. Les utilisateurs sont moins susceptibles de faire des erreurs si les tâches sont inutiles ou effectuées automatiquement pour eux. Ou si les utilisateurs font de petites erreurs mais que leur intention est claire, le problème est résolu automatiquement. Par exemple, vous pouvez corriger automatiquement les problèmes de mise en forme mineure.

Fournir les messages d’erreur nécessaires

Parfois, vous devez vraiment fournir un message d’erreur. Les utilisateurs font des erreurs, des réseaux et des appareils arrêtent de fonctionner, les objets ne sont pas trouvés ou modifiés, les tâches ne peuvent pas être terminées et les programmes ont des bogues. Dans l’idéal, ces problèmes se produisent moins souvent, par exemple, nous pouvons concevoir notre logiciel pour empêcher de nombreux types d’erreurs utilisateur, mais il n’est pas réaliste d’empêcher tous ces problèmes. Et quand l’un de ces problèmes se produit, un message d’erreur utile permet aux utilisateurs de revenir rapidement sur leurs pieds.

Une croyance courante est que les messages d’erreur sont la pire expérience utilisateur et doivent être évités à tous les coûts, mais il est plus précis de dire que la confusion de l’utilisateur est la pire expérience et doit être évitée à tous les coûts. Parfois, ce coût est un message d’erreur utile.

Envisagez les contrôles désactivés. La plupart du temps, il est évident qu’un contrôle est désactivé, de sorte que la désactivation du contrôle est un excellent moyen d’éviter un message d’erreur. Toutefois, que se passe-t-il si la raison pour laquelle un contrôle est désactivé n’est pas évident ? L’utilisateur ne peut pas continuer et il n’y a aucun commentaire pour déterminer le problème. L’utilisateur est maintenant bloqué et doit déduire le problème ou obtenir un support technique. Dans ce cas, il est beaucoup mieux de laisser le contrôle activé et de donner un message d’erreur utile à la place.

Incorrect :

Pourquoi le bouton Suivant est-il désactivé ici ? Il est préférable de le laisser activé et d’éviter toute confusion de l’utilisateur en donnant un message d’erreur utile.

Si vous ne savez pas si vous devez donner un message d’erreur, commencez par composer le message d’erreur que vous pouvez donner. Si les utilisateurs sont susceptibles d’effectuer une action ou de modifier leur comportement en conséquence, fournissez le message d’erreur. En revanche, si les utilisateurs sont susceptibles d’ignorer le message sans faire ou modifier quoi que ce soit, omettez le message d’erreur.

Conception pour une bonne gestion des erreurs

Bien que la création d’un bon texte de message d’erreur puisse être difficile, il est parfois impossible sans une bonne prise en charge de la gestion des erreurs du programme. Tenez compte du message d’erreur suivant :

Incorrect :

Les chances sont que le problème est vraiment inconnu parce que le support de gestion des erreurs du programme manque.

Bien qu’il soit possible qu’il s’agit d’un message d’erreur très mal écrit, il reflète plus probablement le manque de bonne gestion des erreurs par le code sous-jacent, il n’existe aucune information spécifique connue sur le problème.

Pour créer des messages d’erreur spécifiques, actionnables et centrés sur l’utilisateur, le code de gestion des erreurs de votre programme doit fournir des informations d’erreur spécifiques et générales :

• Chaque problème doit avoir un code d’erreur unique affecté.
• Si un problème a plusieurs causes, le programme doit déterminer la cause spécifique dans la mesure du possible.
• Si le problème a des paramètres, les paramètres doivent être conservés.
• Les problèmes de bas niveau doivent être gérés à un niveau suffisamment élevé pour que le message d’erreur puisse être présenté du point de vue de l’utilisateur.

Les messages d’erreur corrects ne sont pas seulement un problème d’interface utilisateur, ils sont un problème de conception de logiciel. Une bonne expérience de message d’erreur n’est pas quelque chose qui peut être acked ultérieurement.

résolution des problèmes (et comment l’éviter)

Résolution des problèmes lorsqu’un problème avec plusieurs causes différentes est signalé avec un message d’erreur unique.

Incorrect :

diagramme

correct :

diagramme

Résolution des problèmes lorsque plusieurs problèmes sont signalés avec un message d’erreur unique.

Dans l’exemple suivant, un élément n’a pas pu être déplacé, car il a déjà été déplacé ou supprimé, ou l’accès a été refusé. Si le programme peut facilement déterminer la cause, pourquoi mettre le fardeau sur l’utilisateur pour déterminer la cause spécifique ?

Incorrect :

Qu’est-ce que c’est ? À présent, l’utilisateur doit résoudre les problèmes.

Le programme peut déterminer si l’accès a été refusé. Ce problème doit donc être signalé avec un message d’erreur spécifique.

correct :

Avec une cause spécifique, aucune résolution des problèmes n’est nécessaire.

Utilisez des messages avec plusieurs causes uniquement lorsque la cause spécifique ne peut pas être déterminée. Dans cet exemple, il serait difficile pour le programme de déterminer si l’élément a été déplacé ou supprimé. Par conséquent, un message d’erreur unique avec plusieurs causes peut être utilisé ici. Toutefois, il est peu probable que les utilisateurs s’occupent si, par exemple, ils n’ont pas pu déplacer un fichier supprimé. Pour ces causes, le message d’erreur n’est même pas nécessaire.

Gestion des erreurs inconnues

Dans certains cas, vous ne connaissez pas réellement le problème, la cause ou la solution. S’il ne serait pas judicieux de supprimer l’erreur, il est préférable d’être à l’avant-plan de l’absence d’informations que de présenter des problèmes, des causes ou des solutions qui peuvent ne pas être appropriées.

Par exemple, si votre programme a une exception non gérée, le message d’erreur suivant convient :

Si vous ne pouvez pas supprimer une erreur inconnue, il est préférable d’être à l’avant de l’absence d’informations.

D’autre part, fournissez des informations spécifiques et exploitables s’il est susceptible d’être utile la plupart du temps.

Ce message d’erreur convient à une erreur inconnue si la connectivité réseau est généralement le problème.

Déterminer le type de message approprié

Certains problèmes peuvent être présentés comme une erreur, un avertissement ou des informations, en fonction de l’accentuation et de la formulation. Par exemple, supposons qu’une page Web ne peut pas charger un contrôle ActiveX non signé en fonction de la configuration actuelle de Windows Internet Explorer :

• Erreur. « Cette page ne peut pas charger un contrôle ActiveX non signé ». (Phrased en tant que problème existant.)
• Avertissement. « Cette page peut ne pas se comporter comme prévu, car Windows Internet Explorer n’est pas configuré pour charger des contrôles ActiveX non signés » ou « Autoriser cette page à installer un contrôle ActiveX non signé ? » Cela peut endommager votre ordinateur à partir de sources non approuvées. (Les deux expressions sont des conditions susceptibles d’entraîner des problèmes futurs.)
• Information. « Vous avez configuré Windows Internet Explorer pour bloquer les contrôles ActiveX non signés. » (Expression sous la forme d’une déclaration de fait.)

Pour déterminer le type de message approprié, concentrez-vous sur l’aspect le plus important du problème sur lequel les utilisateurs doivent savoir ou agir. En règle générale, si un problème empêche l’utilisateur de continuer, vous devez le présenter comme une erreur ; si l’utilisateur peut continuer, le présenter en tant qu’avertissement. Créez l'instruction principale ou tout autre texte correspondant en fonction de ce focus, puis choisissez une icône ( standard ou autre) qui correspond au texte. Le texte et les icônes d’instruction principaux doivent toujours correspondre.

présentation de message d’erreur

La plupart des messages d’erreur dans les programmes Windows sont présentés à l’aide de boîtes de dialogue modales (comme la plupart des exemples de cet article), mais il existe d’autres options :

• Sur place
• Ballons
• Notifications
• Icônes de zone de notification
• Barres d’état
• Fichiers journaux (pour les erreurs destinées aux professionnels de l’informatique)

Le fait de placer des messages d’erreur dans les boîtes de dialogue modales offre l’avantage d’exiger l’attention immédiate et l’accusé de réception de l’utilisateur. Toutefois, il s’agit également de leur principal inconvénient si cette attention n’est pas nécessaire.

Avez-vous vraiment besoin d’interrompre les utilisateurs afin qu’ils puissent cliquer sur le bouton Fermer ? Si ce n’est pas le cas, envisagez d’utiliser une boîte de dialogue modale.

Les dialogues modals sont un excellent choix lorsque l’utilisateur doit reconnaître le problème immédiatement avant de continuer, mais souvent un mauvais choix sinon. En règle générale, vous devez préférer utiliser la présentation de poids la plus légère qui fait bien le travail.

Éviter la surcommunication des

En règle générale, utilisateurs ne lisent pas, ils analysent. Plus il y a de texte, plus le texte est difficile à analyser, et plus les utilisateurs risquent de ne pas lire le texte du tout. Par conséquent, il est important de réduire le texte à ses éléments essentiels et d’utiliser des liens de divulgation et d’aide progressifs si nécessaire pour fournir des informations supplémentaires.

Il existe de nombreux exemples extrêmes, mais examinons un exemple plus classique. L’exemple suivant présente la plupart des attributs d’un bon message d’erreur, mais son texte n’est pas concis et nécessite une motivation à lire.

Incorrect :

capture d’écran de message détaillé

Cet exemple est un bon message d’erreur, mais il surcommunie.

Qu’est-ce que tout ce texte dit vraiment ? Quelque chose comme ceci :

correct :

Ce message d’erreur contient essentiellement les mêmes informations, mais est beaucoup plus concis.

En utilisant l’aide pour fournir les détails, ce message d’erreur comporte un style pyramide inversé de présentation.

Pour plus d’instructions et d’exemples sur la surcommunication, consultez texte de l’interface utilisateur.

Si vous ne faites que huit choses

1. Concevez votre programme pour la gestion des erreurs.
2. Ne donnez pas de messages d’erreur inutiles.
3. Évitez toute confusion de l’utilisateur en donnant les messages d’erreur nécessaires.
4. Assurez-vous que le message d’erreur présente un problème, une cause et une solution.
5. Assurez-vous que le message d’erreur est pertinent, actionnable, bref, clair, spécifique, courtois et rare.
6. Concevoir des messages d’erreur du point de vue de l’utilisateur, et non du point de vue du programme.
7. Évitez d’impliquer l’utilisateur dans la résolution des problèmes d’utiliser un message d’erreur différent pour chaque cause détectable.
8. Utilisez la méthode de présentation de poids la plus légère qui effectue le travail correctement.

modèles d’utilisation

Les messages d’erreur ont plusieurs modèles d’utilisation :

Étiquette	Valeur
problèmes système Le système d’exploitation, l’appareil matériel, le réseau ou le programme a échoué ou n’est pas dans l’état requis pour effectuer une tâche.	De nombreux problèmes système peuvent être résolus par l’utilisateur : Les problèmes d’appareil peuvent être résolus en activant l’appareil, en reconnectant l’appareil et en insérant un média. Les problèmes réseau peuvent être résolus en vérifiant la connexion au réseau physique et en exécutant Diagnostic et réparation du réseau. Les problèmes de programme peuvent être résolus en modifiant les options du programme ou en redémarrant le programme. Dans cet exemple, le programme ne peut pas trouver de caméra pour effectuer une tâche utilisateur. capture d’écran Dans cet exemple, une fonctionnalité requise pour effectuer une tâche doit être activée.
problèmes de fichier Un fichier ou un dossier requis pour une tâche initiée par l’utilisateur n’a pas été trouvé, est déjà utilisé ou n’a pas le format attendu.	Dans cet exemple, le fichier ou le dossier ne peut pas être supprimé, car il n’a pas été trouvé. Dans cet exemple, le programme ne prend pas en charge le format de fichier donné.
problèmes de sécurité L’utilisateur n’a pas l’autorisation d’accéder à une ressource ou de disposer d’un privilège suffisant pour effectuer une tâche initiée par l’utilisateur.	Dans cet exemple, l’utilisateur n’a pas l’autorisation d’accéder à une ressource. Dans cet exemple, l’utilisateur n’a pas le privilège d’effectuer une tâche.
problèmes de tâche Il existe un problème spécifique lors de l’exécution d’une tâche initiée par l’utilisateur (autre qu’un système, un fichier introuvable, un format de fichier ou un problème de sécurité).	Dans cet exemple, les données du Presse-papiers ne peuvent pas être collées dans Paint. Dans cet exemple, l’utilisateur ne peut pas installer de mise à niveau logicielle.
problèmes d’entrée utilisateur L’utilisateur a entré une valeur incorrecte ou incohérente avec d’autres entrées utilisateur.	Dans cet exemple, l’utilisateur a entré une valeur de temps incorrecte. Dans cet exemple, l’entrée utilisateur n’est pas au format correct.

Lignes directrices

Présentation

• Utiliser des boîtes de dialogue de tâche chaque fois que cela convient pour obtenir une apparence et une disposition cohérentes. Les boîtes de dialogue de tâche nécessitent Windows Vista ou version ultérieure, de sorte qu’elles ne conviennent pas aux versions antérieures de Windows. Si vous devez utiliser une boîte de message, séparez l’instruction principale de l’instruction supplémentaire avec deux sauts de ligne.

Erreurs d’entrée utilisateur

• Dans la mesure du possible, empêchez ou réduisez les erreurs d’entrée utilisateur par :
  • Utilisation de contrôles limités aux valeurs valides.
  • La désactivation des contrôles et des éléments de menu lors du clic entraîne une erreur, tant qu’il est évident que le contrôle ou l’élément de menu est désactivé.
  • Fournir de bonnes valeurs par défaut.

Incorrect :

d’étiquette de volume du haut-parleur

Dans cet exemple, une zone de texte non contrainte est utilisée pour l’entrée contrainte. Utilisez plutôt un curseur.

• Utiliser la gestion des erreurs sans mode (erreurs ou bulles sur place) pour les problèmes d’entrée utilisateur contextuels.
• Utiliser des bulles pour les problèmes d’entrée utilisateur à point unique non critiques détectés dans une zone de texte ou immédiatement après qu’une zone de texte perd le focus.bulles ne nécessitent pas d’espace d’écran disponible ou la disposition dynamique requise pour afficher les messages sur place. Affichez une seule bulle à la fois. Étant donné que le problème n’est pas critique, aucune icône d’erreur n’est nécessaire. Les bulles disparaissent en cas de clic, lorsque le problème est résolu ou après un délai d’expiration.

Dans cet exemple, une bulle indique un problème d’entrée tout en restant dans le contrôle.

• Utiliser des erreurs sur place pour la détection différée des erreurs, généralement des erreurs trouvées en cliquant sur un bouton de validation. (N’utilisez pas erreurs sur place pour les paramètres qui sont immédiatement validés.) Il peut y avoir plusieurs erreurs sur place à la fois. Utilisez du texte normal et une icône d’erreur de 16 x 16 pixels, en les plaçant directement en regard du problème dans la mesure du possible. Les erreurs sur place ne s’éloignent pas, sauf si l’utilisateur valide et qu’aucune autre erreur n’est trouvée.

Dans cet exemple, une erreur sur place est utilisée pour une erreur trouvée en cliquant sur le bouton valider.

• Utiliser la gestion des erreurs modales (boîtes de dialogue de tâche ou boîtes de message) pour tous les autres problèmes, y compris les erreurs impliquant plusieurs contrôles ou sont des erreurs non contextuelles ou non-entrées trouvées en cliquant sur un bouton de validation.
• Lorsqu’un problème d’entrée utilisateur est signalé, définissez le focus d’entrée sur le premier contrôle avec les données incorrectes. Faites défiler le contrôle dans l’affichage si nécessaire. Si le contrôle est une zone de texte, sélectionnez l’intégralité du contenu. Il doit toujours être évident à quoi fait référence le message d’erreur.
• Ne effacez pas l’entrée incorrecte. Au lieu de cela, laissez-le afin que l’utilisateur puisse voir et corriger le problème sans recommencer.
  • exception : effacer les zones de texte de mot de passe et de code confidentiel incorrectes, car les utilisateurs ne peuvent pas corriger efficacement l’entrée masquée.

Dépannage

• Évitez de créer des problèmes de résolution des problèmes. Ne vous fiez pas à un seul message d’erreur pour signaler un problème avec plusieurs causes détectables différentes.
• Utilisez un message d’erreur différent (généralement une instruction supplémentaire différente) pour chaque cause détectable. Par exemple, si un fichier ne peut pas être ouvert pour plusieurs raisons, fournissez une instruction supplémentaire distincte pour chaque raison.
• Utilisez un message avec plusieurs causes uniquement lorsque la cause spécifique ne peut pas être déterminée. Dans ce cas, présentez les solutions afin de résoudre le problème. Cela permet aux utilisateurs de résoudre le problème plus efficacement.

Icônes

• Les boîtes de dialogue de message d’erreur modale n’ont pas d’icônes de barre de titre. Les icônes de barre de titre sont utilisées comme distinction visuelle entre les fenêtres primaires et les fenêtres secondaires.

• Utilisez une icône d’erreur. Exceptions:

  • Si l’erreur est un problème d’entrée utilisateur affiché à l’aide d’une boîte de dialogue modale ou d’une bulle, n’utilisez pas d’icône. Cela est contre le ton encourageant de Windows. Toutefois, les messages d’erreur sur place doivent utiliser une petite icône d’erreur (16 x 16 pixels) pour les identifier clairement en tant que messages d’erreur.

    

    

    Dans ces exemples, les problèmes d’entrée utilisateur n’ont pas besoin d’icônes d’erreur.

    

    Dans cet exemple, un message d’erreur sur place nécessite une petite icône d’erreur pour l’identifier clairement en tant que message d’erreur.

• Si le problème concerne une fonctionnalité qui a une icône (et non un problème d’entrée utilisateur), vous pouvez utiliser l’icône de fonctionnalité avec une superposition d’erreurs. Si vous effectuez cette opération, utilisez également le nom de la fonctionnalité comme objet de l’erreur.

  

  Dans cet exemple, l’icône de fonctionnalité comporte une superposition d’erreurs et la fonctionnalité est l’objet de l’erreur.

• N’utilisez pas d’icônes d’avertissement pour les erreurs. Cela est souvent fait pour rendre la présentation moins grave. Les erreurs ne sont pas des avertissements.

  Incorrect :

  

  Dans cet exemple, une icône d’avertissement est utilisée de manière incorrecte pour rendre l’erreur moins grave.

Pour plus d’instructions et d’exemples, consultez icônes standard.

Divulgation progressive

• Utilisez un bouton Afficher/Masquer les détails de divulgation progressive pour masquer les informations avancées ou détaillées dans un message d’erreur. Cela simplifie le message d’erreur pour une utilisation classique. Ne masquez pas les informations nécessaires, car les utilisateurs peuvent ne pas le trouver.

Dans cet exemple, le bouton de divulgation progressive permet aux utilisateurs d’explorer plus en détail s’ils le souhaitent ou de simplifier l’interface utilisateur si ce n’est pas le cas.

• N’utilisez pas afficher/masquer les détails, sauf s’il y a vraiment plus de détails. Ne restez pas simplement les informations existantes dans un format plus détaillé.
• N’utilisez pas afficher/masquer les détails pour afficher les informations d’aide. Utilisez plutôt des liens d’aide.

Pour obtenir des instructions d’étiquetage, consultez contrôles de divulgation progressive.

Ne plus afficher ce message

• Si un message d’erreur a besoin de cette option, reconsidérer l’erreur et sa fréquence. S’il présente toutes les caractéristiques d’une bonne erreur (pertinente, actionnable et peu fréquente), il ne doit pas être judicieux pour les utilisateurs de le supprimer.

Pour plus d’instructions, consultez boîtes de dialogue.

Valeurs par défaut

• Sélectionnez la réponse la plus sûre, la moins destructrice ou la plus sécurisée pour être la réponse par défaut. Si la sécurité n’est pas un facteur, sélectionnez la commande la plus probable ou la plus pratique.

Aide

• Concevoir des messages d’erreur pour éviter la nécessité de l’aide. En règle générale, les utilisateurs ne doivent pas avoir à lire du texte externe pour comprendre et résoudre le problème, sauf si la solution nécessite plusieurs étapes.
• Assurez-vous que le contenu de l’aide est pertinent et utile. Il ne doit pas s’agir d’un repos détaillé du message d’erreur plutôt, il doit contenir des informations utiles qui dépassent la portée du message d’erreur, telles que des moyens d’éviter le problème à l’avenir. Ne fournissez pas de lien d’aide simplement parce que vous pouvez.
• Utilisez des liens d’aide spécifiques, concis et pertinents pour accéder au contenu de l’aide. N’utilisez pas de boutons de commande ou de divulgation progressive à cet effet.
• Pour les messages d’erreur que vous ne pouvez pas rendre spécifiques et actionnables, envisagez de fournir des liens vers du contenu d’aide en ligne. Ainsi, vous pouvez fournir aux utilisateurs des informations supplémentaires que vous pouvez mettre à jour après la publication du programme.

Pour plus d’instructions, consultez Aide.

Codes d’erreur

• Pour les messages d’erreur que vous ne pouvez pas rendre spécifiques et actionnables ou qu’ils tirent parti de l’aide, envisagez également de fournir des codes d’erreur. Les utilisateurs utilisent souvent ces codes d’erreur pour rechercher des informations supplémentaires sur Internet.
• Fournissez toujours une description textuelle du problème et de la solution. Ne dépendez pas uniquement du code d’erreur à cet effet.

Incorrect :

Dans cet exemple, un code d’erreur est utilisé comme substitut d’un texte de solution.

• Attribuez un code d’erreur unique pour chaque cause différente. Cela évite de résoudre les problèmes.
• Choisissez des codes d’erreur facilement pouvant faire l’objet d’une recherche sur Internet. Si vous utilisez des codes 32 bits, utilisez une représentation hexadécimale avec un « 0x » de début et des caractères majuscules.

correct :

1234

0xC0001234

Incorrect :

-1

-67113524

• Utilisez Afficher/Masquer les détails pour afficher les codes d’erreur. Expression en tant que code d’erreur : <error code>.

Dans cet exemple, un code d’erreur est utilisé pour compléter un message d’erreur qui peut tirer parti d’informations supplémentaires.

Son

• N’accompagnez pas les messages d’erreur avec un effet sonore ou un bip. Cela est inutile.
  • Exception : lire l’effet sonore arrêt critique si le problème est essentiel au fonctionnement de l’ordinateur, et l’utilisateur doit prendre des mesures immédiates pour éviter les conséquences graves.

SMS

général

• Supprimez le texte redondant. Recherchez-le dans les titres, les instructions principales, les instructions supplémentaires, les liens de commande et les boutons de validation. En règle générale, laissez le texte intégral dans les instructions et les contrôles interactifs et supprimez toute redondance des autres emplacements.
• Utilisez des explications centrées sur l’utilisateur. Décrivez le problème en termes d’actions ou d’objectifs utilisateur, et non pas en termes de ce que le logiciel n’est pas satisfait. Utilisez la langue que les utilisateurs cibles comprennent et utilisent. Évitez le jargon technique.

Incorrect :

correct :

Dans ces exemples, la version correcte parle la langue de l’utilisateur alors que la version incorrecte est trop technique.

• n’utilisez pas les mots suivants :
  • Erreur, échec (problème d’utilisation à la place)
  • Échec de l’utilisation (l’utilisation ne peut pas être utilisée à la place)
  • Illégal, non valide, incorrect (utiliser incorrect à la place)
  • Abandonner, tuer, arrêter (utiliser l’arrêt à la place)
  • Catastrophique, fatal (utilisation grave à la place)

Ces termes sont inutiles et contraires au ton encourageant de Windows. Lorsque utilisé correctement, l’icône d’erreur indique suffisamment qu’il existe un problème.

Incorrect :

correct :

Dans l’exemple incorrect, les termes « catastrophiques » et « échec » sont inutiles.

• N’utilisez pas de formulation qui blâme l’utilisateur ou implique une erreur utilisateur. Évitez de vous utiliser et votre dans la formulation. Bien que la voix active soit généralement préférée, utilisez la voix passive lorsque l’utilisateur est l’objet et peut se sentir accusé de l’erreur si la voix active a été utilisée.

Incorrect :

d’ouverture de session incorrecte

correct :

L’exemple incorrect blâme l’utilisateur à l’aide de la voix active.

• Soyez spécifique. Évitez les formulations vagues, telles que l’erreur de syntaxe et l’opération illégale. Fournissez des noms, des emplacements et des valeurs spécifiques des objets impliqués.

Incorrect :

Fichier introuvable.

Le disque est plein.

Valeur hors plage.

Le caractère n’est pas valide.

Appareil non disponible.

Ces problèmes seraient beaucoup plus faciles à résoudre avec des noms, des emplacements et des valeurs spécifiques.

• Ne donnez peut-être pas de problèmes, de causes ou de solutions peu probables dans une tentative d’être spécifique. Ne fournissez pas de problème, de cause ou de solution, sauf s’il est susceptible d’être correct. Par exemple, il est préférable de dire qu’une erreur inconnue s’est produite que quelque chose qui est susceptible d’être incorrect.
• Évitez le mot « s’il vous plaît », sauf dans les situations où l’utilisateur est invité à faire quelque chose d’inconvenient (par exemple en attente) ou le logiciel est à blâmer pour la situation.

correct :

Veuillez patienter pendant que Windows copie les fichiers sur votre ordinateur.

• Utilisez le mot « désolé » uniquement dans les messages d’erreur qui entraînent de graves problèmes pour l’utilisateur (par exemple, perte de données ou incapacité d’utiliser l’ordinateur). Ne vous excusez pas si le problème s’est produit pendant le fonctionnement normal du programme (par exemple, si l’utilisateur doit attendre qu’une connexion réseau soit trouvée).

correct :

Désolé... Nous sommes désolés, mais Fabrikam Backup a détecté un problème irrécupérable et a été arrêté pour protéger les fichiers sur votre ordinateur.

• Reportez-vous aux produits en utilisant leurs noms courts. N’utilisez pas de noms complets de produits ou de symboles de marque. N’incluez pas le nom de la société, sauf si les utilisateurs associent le nom de la société au produit. N’incluez pas les numéros de version du programme.

Incorrect :

correct :

Dans l’exemple incorrect, les noms complets de produits et les symboles de marque sont utilisés.

• Utilisez des guillemets doubles autour des noms d’objets. Cela facilite l’analyse du texte et évite les instructions potentiellement embarrassantes.
  • Exception : chemins d’accès de fichier complets, URL et noms de domaine n’ont pas besoin d’être entre guillemets doubles.

correct :

Dans cet exemple, le message d’erreur serait confus si le nom de l’objet n’était pas entre guillemets.

• Évitez de commencer des phrases avec des noms d’objets. Cela est souvent difficile à analyser.
• N’utilisez pas de marques d’exclamation ou de mots avec toutes les lettres majuscules. Les marques d’exclamation et les lettres majuscules font sentir que vous criez à l’utilisateur.

Pour plus d’instructions et d’exemples, consultez Style et Ton.

titres

• Utilisez le titre pour identifier la commande ou la fonctionnalité à partir de laquelle l’erreur provient. Exceptions:
  • Si une erreur s’affiche par de nombreuses commandes différentes, envisagez d’utiliser le nom du programme à la place.
  • Si ce titre serait redondant ou déroutant avec l’instruction principale, utilisez plutôt le nom du programme.
• n’utilisez pas le titre pour expliquer ou résumer le problème c’est l’objectif de l’instruction principale.

Incorrect :

Dans cet exemple, le titre est utilisé de manière incorrecte pour expliquer le problème.

• Utilisez la mise en majuscules de style titre, sans mettre fin à la ponctuation.

instructions principales

• Utilisez l’instruction principale pour décrire le problème en langage clair, simple et spécifique.
• Soyez concis utiliser une seule phrase complète. Analysez l’instruction principale jusqu’aux informations essentielles. Vous pouvez laisser l’objet implicite s’il s’agit de votre programme ou de l’utilisateur. Incluez la raison du problème si vous pouvez le faire de manière concise. Si vous devez en expliquer d’autres, utilisez une instruction supplémentaire.

Incorrect :

Dans cet exemple, le message d’erreur entier est placé dans l’instruction principale, ce qui rend difficile la lecture.

• Être spécifique s’il y a des objets impliqués, donnez leurs noms.
• Évitez de placer des chemins d’accès et des URL de fichier complets dans l’instruction principale. Utilisez plutôt un nom court (par exemple, le nom de fichier) et placez le nom complet (par exemple, le chemin d’accès du fichier) dans l’instruction supplémentaire. Toutefois, vous pouvez placer un chemin d’accès ou une URL de fichier complet unique dans l’instruction principale si le message d’erreur n’a pas besoin d’une instruction supplémentaire.

Dans cet exemple, seul le nom de fichier se trouve dans l’instruction principale. Le chemin d’accès complet se trouve dans l’instruction supplémentaire.

• Ne donnez pas du tout le chemin d’accès et l’URL complets du fichier s’il est évident à partir du contexte.

Dans cet exemple, l’utilisateur renomme un fichier à partir de l’Explorateur Windows. Dans ce cas, le chemin complet du fichier n’est pas nécessaire, car il est évident à partir du contexte.

• Utilisez les tensions présentes chaque fois que possible.
• Utilisez la mise en majuscules de style phrase.
• N’incluez pas de périodes finales si l’instruction est une instruction. Si l’instruction est une question, incluez un point d’interrogation final.

modèles d’instructions principaux

Bien qu’il n’existe pas de règles strictes pour la formulation, essayez d’utiliser les modèles d’instructions principaux suivants dans la mesure du possible :

• [nom d’objet facultatif] ne peut pas [effectuer une action]
• [nom d’objet facultatif] ne peut pas [effectuer une action] car [raison]
• [nom d’objet facultatif] ne peut pas [effectuer l’action] sur « [nom de l’objet] »
• [nom d’objet facultatif] ne peut pas [effectuer une action] sur « [nom de l’objet] » car [raison]
• Il n’y a pas suffisamment [ressource] pour [effectuer une action]
• [Nom de l’objet] n’a pas de [nom d’objet] requis pour [usage]
• [Appareil ou paramètre] est désactivé afin que [résultats non souhaités]
• [L’appareil ou le paramètre] n’est pas [disponible | trouvé | activé | activé]
• « [nom de l’objet] » n’est actuellement pas disponible
• Le nom d’utilisateur ou le mot de passe est incorrect
• Vous n’avez pas l’autorisation d’accéder à « [nom de l’objet] »
• Vous n’avez pas le privilège de [effectuer une action]
• [nom du programme] a rencontré un grave problème et doit se fermer immédiatement

Bien sûr, apportez des modifications si nécessaire pour que l’instruction principale soit correcte et conforme aux instructions principales.

instructions supplémentaires

• Utilisez l’instruction supplémentaire pour :
  • Donnez des détails supplémentaires sur le problème.
  • Expliquer la cause du problème.
  • Répertorier les étapes que l’utilisateur peut effectuer pour résoudre le problème.
  • Fournir des mesures pour empêcher le problème de se reproduire.
• Dans la mesure du possible, proposez une solution pratique et utile afin que les utilisateurs puissent résoudre le problème. Toutefois, assurez-vous que la solution proposée est susceptible de résoudre le problème. Ne gaspillez pas le temps des utilisateurs en suggérant des solutions possibles, mais improbables.

Incorrect :

Dans cet exemple, alors que le problème et sa solution recommandée sont possibles, ils sont très peu probables.

• Si le problème est une valeur incorrecte que l’utilisateur a entrée, utilisez l’instruction supplémentaire pour expliquer les valeurs correctes. Les utilisateurs ne doivent pas avoir à déterminer ces informations à partir d’une autre source.
• Ne fournissez pas de solution si elle peut être déduite de manière triviale de l’instruction de problème.

Dans cet exemple, aucune instruction supplémentaire n’est nécessaire ; la solution peut être déduite trivialement de l’instruction du problème.

• Si la solution comporte plusieurs étapes, présentez les étapes dans l’ordre dans lequel elles doivent être effectuées. Toutefois, évitez les solutions en plusieurs étapes, car les utilisateurs ont des difficultés à mémoriser plus de deux ou trois étapes simples. Si d’autres étapes sont requises, reportez-vous à la rubrique d’aide appropriée.
• Gardez les instructions supplémentaires concises. Fournissez uniquement ce que les utilisateurs doivent savoir. Omettez les détails inutiles. Visez un maximum de trois phrases de longueur modérée.
• Pour éviter les erreurs lorsque les utilisateurs effectuent des instructions, placez les résultats avant l’action.

correct :

Pour redémarrer Windows, cliquez sur OK.

Incorrect :

Cliquez sur OK pour redémarrer Windows.

Dans l’exemple incorrect, les utilisateurs sont plus susceptibles de cliquer sur OK par accident.

• Ne recommandez pas de contacter un administrateur, sauf s’il s’agit d’une solution la plus probable au problème. Réservez de telles solutions pour les problèmes qui ne peuvent vraiment être résolus que par un administrateur.

Incorrect :

Dans cet exemple, le problème est probablement lié à la connexion réseau de l’utilisateur. Il n’est donc pas utile de contacter un administrateur.

• Ne recommandez pas de contacter le support technique. La possibilité de contacter le support technique pour résoudre un problème est toujours disponible et n’a pas besoin d’être promue par le biais de messages d’erreur. Au lieu de cela, concentrez-vous sur l’écriture de messages d’erreur utiles afin que les utilisateurs puissent résoudre des problèmes sans contacter le support technique.

Incorrect :

Dans cet exemple, le message d’erreur recommande incorrectement de contacter le support technique.

• Utilisez des phrases complètes, des majuscules de style phrase et une ponctuation de fin.

boutons Valider

• Si le message d’erreur fournit des boutons de commande ou des liens de commande qui résolvent le problème, suivez leurs instructions respectives dans boîtes de dialogue.
• Si le programme doit se terminer en raison de l’erreur, fournissez un bouton Quitter le programme. Pour éviter toute confusion, n’utilisez pas Close à cet effet.
• Sinon, fournissez un bouton Fermer. N’utilisez pas OK pour les messages d’erreur, car cette formulation implique que les problèmes sont OK.
  • Exception : Utiliser OK si votre mécanisme de création de rapports d’erreurs a des étiquettes fixes (comme avec l’API MessageBox.)

Documentation

Lorsque vous faites référence à des erreurs :

• Reportez-vous aux erreurs par leur instruction principale. Si l’instruction principale est longue ou détaillée, résumez-la.
• Si nécessaire, vous pouvez faire référence à une boîte de dialogue de message d’erreur en tant que message. Reportez-vous à un message d’erreur uniquement dans la programmation et d’autres documents techniques.
• Si possible, mettez en forme le texte en gras. Sinon, placez le texte entre guillemets uniquement si nécessaire pour éviter toute confusion.

Exemple : Si vous recevez un Il n’existe aucun disque CD dans le message lecteur, insérez un nouveau disque CD dans le lecteur et réessayez.