Messages d’erreur dans Windows 7

Notes

Ce guide de conception a été créé pour Windows 7 et n’a pas été mis à jour pour les versions plus récentes de Windows. La plupart des conseils s’appliquent toujours en principe, mais la présentation et les exemples ne reflètent pas nos recommandations actuelles en matière de conception.

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 des 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 efficaces 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 à la suite d’un message d’erreur.

Des messages d’erreur utiles et bien écrits sont essentiels à une expérience utilisateur de qualité. Les messages d’erreur mal écrits entraînent une faible satisfaction du produit et sont une cause principale de coûts de support technique évitables. Les messages d’erreur inutiles interrompent le flux des utilisateurs.

Note: Les instructions relatives aux boîtes de dialogue, aux messages d’avertissement, aux confirmations, aux icônes standard, aux notifications et à la disposition sont présentées dans des articles distincts.

S’agit-il de l’interface utilisateur appropriée ?

Pour vous décider, posez-vous les questions suivantes :

• 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 entraîner de confusion ? Si c’est le cas, évitez le problème à la place. Par exemple, utilisez des contrôles qui sont limités à des valeurs valides au lieu d’utiliser des contrôles sans contrainte qui peuvent nécessiter des messages d’erreur. En outre, la désactivation des contrôles lors d’un 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 ? Si c’est le 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. Il est donc préférable de supprimer l’erreur.
• Le problème est-il pertinent lorsque les utilisateurs utilisent activement d’autres programmes ? Dans ce 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é actuelle de l’utilisateur, ne nécessite-t-il pas une action immédiate de l’utilisateur et peut-il librement l’ignorer ? Si c’est le cas, utilisez plutôt une notification d’échec d’action .
• Le problème est-il lié à la status d’une tâche en arrière-plan dans une fenêtre principale ? Dans ce cas, envisagez d’afficher le problème à l’aide d’une status barres.
• Les utilisateurs cibles principaux sont-ils des professionnels de l’informatique ? Dans ce cas, envisagez d’utiliser un autre mécanisme de commentaires, tel que les entrées de fichier journal ou les alertes par e-mail. Les professionnels de l’informatique préfèrent vivement les fichiers journaux pour les informations non critiques.

Principes de conception

Caractéristiques des messages d’erreur médiocres

Il n’est pas surprenant qu’il existe de nombreux messages d’erreur ennuyeux, inutiles et mal écrits. Et étant donné que les messages d’erreur sont souvent présentés à l’aide de boîtes de dialogue modales, ils interrompent l’activité actuelle de l’utilisateur et demandent à ê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. Considérez ces exemples 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 enregistré. Cela indique qu’un programme n’a pas pu être lancé, 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 de s’arrêter !

Le problème : Le message d’erreur lui-même est le problème. À part ignorer le message d’erreur, les utilisateurs n’ont rien à faire.

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 les erreurs dont les utilisateurs ne se soucient pas.

Messages d’erreur « Réussite »

Incorrect :

Ce message d’erreur est dû au fait que l’utilisateur a choisi 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 pas d’erreur du point de vue de l’utilisateur. À part ignorer le message d’erreur, les utilisateurs n’ont rien à faire.

Cause principale : La tâche s’est terminée avec succès 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 donne pas de problème spécifique et les utilisateurs ne peuvent rien faire à ce sujet.

Cause principale : Très probablement, le programme a une mauvaise gestion des erreurs.

Alternative recommandée : Concevez 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 totalement 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 plutôt que de celui de l’utilisateur.

Alternative recommandée : Écrivez 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 de message d’erreur de votre programme ne permet pas aux programmeurs de composer 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 : Donnez trop de détails ou essayez d’expliquer un processus de résolution des problèmes complexe dans un message d’erreur.

Alternative recommandée : Évitez les détails inutiles. Évitez également 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 lisant la rubrique appropriée dans l’aide.

Messages d’erreur inutilement sévères

Incorrect :

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

Le problème : Le ton de l’émission 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 : Choisissez la langue avec soin 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’avoir fait une erreur.

Cause principale : Formulation insensible qui se concentre sur le comportement de l’utilisateur plutôt que sur le problème.

Alternative recommandée : Concentrez-vous sur le problème, et non sur l’action de l’utilisateur à l’origine du problème, en utilisant la voix passive si nécessaire.

Messages d’erreur idiots

Incorrect :

Dans cet exemple, l’énoncé du problème est assez ironique et aucune solution n’est fournie.

Le problème : Instructions de message d’erreur qui sont stupides ou non séquitors.

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

Alternative recommandée : Créez et examinez vos messages d’erreur par un rédacteur. 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 : Les messages destinés à aider les développeurs du programme à trouver des bogues sont conservés dans la version finale du programme. Ces messages d’erreur n’ont aucune signification ou valeur pour les utilisateurs.

Cause principale : Programmeurs utilisant une interface utilisateur normale pour se faire des messages.

Alternative recommandée : Les développeurs doivent compiler de manière conditionnelle 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 de telles erreurs compréhensibles pour les utilisateurs, car leur seul public est les programmeurs.

Messages d’erreur mal présentés

Incorrect :

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

Le problème : Obtention de 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 de rédacteurs et d’éditeurs pour créer et examiner les messages d’erreur.

La nature de la gestion des erreurs est telle que bon nombre de ces erreurs sont très faciles à faire. Il est troublant de se rendre compte que la plupart des messages d’erreur pourraient être des candidats au Hall de la honte.

Caractéristiques des bons messages d’erreur

Contrairement aux exemples incorrects précédents, les 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 permettant aux utilisateurs de résoudre le problème.

En outre, les bons messages d’erreur sont présentés de la manière suivante :

• Pertinent. Le message présente un problème qui intéresse les utilisateurs.
• 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 en termes de ce que le code n’est pas satisfait.
• Bref. Le message est aussi court que possible, mais pas plus court.
• Effacer. Le message utilise un langage simple 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’une langue spécifique, en donnant des noms, des emplacements et des valeurs spécifiques des objets impliqués.
• Courtois. Les utilisateurs ne doivent pas être blâmés ou se sentir stupides.
• Rare. Rarement affiché. 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 en dehors 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 grâce à 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 d’en signaler une.

Les messages d’erreur les plus évidents à éviter sont ceux qui ne peuvent pas être actionnables. Si les utilisateurs sont susceptibles d’ignorer le message sans rien 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 ait essayé de supprimer un fichier qui est déjà en cours de suppression. Bien qu’il puisse s’agir d’un cas inattendu du point de vue du code, les utilisateurs ne considèrent pas cela comme une erreur, car le 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 éliminé, 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 plutôt que sur la technologie. Ce faisant, reconsidérer ce qu’est réellement 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 a un sens dans le monde réel, elle doit également avoir un sens dans les logiciels.

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

• Continuez à rechercher les produits qui correspondent le plus à la requête.
• Si la recherche comporte des erreurs évidentes, recommandez automatiquement une requête corrigée.
• Gérer 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 consiste à prévenir les problèmes en premier lieu. Vous pouvez éviter les erreurs en :

• Utilisation de contrôles contraints. Utilisez des contrôles qui sont limités à des valeurs valides. Les contrôles tels que les listes, les curseurs, les zones de case activée, les cases d’option et les sélecteurs de date et d’heure sont limités à des valeurs valides, tandis que les zones de texte ne le sont souvent pas et peuvent nécessiter des messages d’erreur. Toutefois, vous pouvez limiter les zones de texte à n’accepter que 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 de contrôles et d’éléments de menu désactivés. 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 de faire 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 que les choses fonctionnent. 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 des problèmes de mise en forme mineurs.

Fournir les messages d’erreur nécessaires

Parfois, vous devez vraiment fournir un message d’erreur. Les utilisateurs font des erreurs, les réseaux et les appareils cessent de fonctionner, les objets sont introuvables ou modifiés, les tâches ne peuvent pas être effectué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 éviter de nombreux types d’erreurs utilisateur, mais il n’est pas réaliste d’éviter tous ces problèmes. Et quand l’un de ces problèmes se produit, un message d’erreur utile permet aux utilisateurs de se remettre rapidement sur pied.

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

Considérez les contrôles désactivés. La plupart du temps, il est évident qu’un contrôle est désactivé. La désactivation du contrôle est donc 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 évidente ? 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 soit déduire le problème, soit obtenir un support technique. Dans ce cas, il est préférable 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 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 rien faire ou modifier, 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 gestion des erreurs prise en charge par le programme. Considérez ce message d’erreur :

Incorrect :

Il est probable que le problème est vraiment inconnu, car la prise en charge de la gestion des erreurs du programme est insuffisante.

Bien qu’il soit possible qu’il s’agit d’un message d’erreur très mal écrit, il reflète plus probablement l’absence 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 générales spécifiques :

• Un code d’erreur unique doit être affecté à chaque problème.
• 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 bons messages d’erreur ne sont pas seulement un problème d’interface utilisateur, ils sont un problème de conception logicielle. Une bonne expérience de message d’erreur n’est pas quelque chose qui peut être traité ultérieurement.

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

Les résultats de la résolution des problèmes lorsqu’un problème avec plusieurs causes différentes est signalé avec un seul message d’erreur.

Incorrect :

Correct :

Résultats de la résolution des problèmes lorsque plusieurs problèmes sont signalés avec un seul message d’erreur.

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 faire peser le fardeau sur l’utilisateur pour déterminer la cause spécifique ?

Incorrect :

Qu’est-ce que c’est ? L’utilisateur doit maintenant 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 :

Pour une cause spécifique, aucun dépannage 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 seul message d’erreur avec plusieurs causes peut être utilisé ici. Toutefois, il est peu probable que les utilisateurs s’en soucient si, par exemple, ils ne peuvent pas 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 vraiment pas le problème, la cause ou la solution. S’il n’est pas judicieux de supprimer l’erreur, il est préférable d’être à l’avance au sujet du manque d’informations que de présenter des problèmes, des causes ou des solutions qui pourraient 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’avance sur le manque d’informations.

D’autre part, fournissez des informations spécifiques et exploitables si elles sont susceptibles d’être utiles 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 sous la forme d’une erreur, d’un avertissement ou d’une information, en fonction de l’importance et de la formulation. Par exemple, supposons qu’une page Web ne puisse 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é. » (Il s’agit d’un 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é ? » Le fait de le faire à partir de sources non approuvées peut nuire à votre ordinateur. » (Les deux sont formulés comme des conditions susceptibles de provoquer des problèmes futurs.)
• Information. « Vous avez configuré Windows Internet Explorer pour bloquer les contrôles ActiveX non signés. » (Formulé comme une déclaration de fait.)

Pour déterminer le type de message approprié, concentrez-vous sur l’aspect le plus important du problème que les utilisateurs doivent connaître ou sur lequel ils doivent 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, présentez-le sous forme d’avertissement. Créez l’instruction main 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 de l’instruction main doivent toujours correspondre.

Présentation du 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
• Bulles
• Notifications
• Icônes de la zone de notification
• Barres d'état
• Fichiers journaux (pour les erreurs ciblant les professionnels de l’informatique)

Le placement de messages d’erreur dans des boîtes de dialogue modales a l’avantage d’exiger l’attention et l’accusé de réception immédiats de l’utilisateur. Toutefois, c’est également 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 boîtes de dialogue modales sont un excellent choix lorsque l’utilisateur doit reconnaître le problème immédiatement avant de continuer, mais souvent un mauvais choix dans le cas contraire. En règle générale, vous devriez préférer utiliser la présentation la plus légère qui fait bien le travail.

Éviter la surcommunication

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

Il existe de nombreux exemples extrêmes, mais examinons-en un plus typique. 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 pour la lecture.

Incorrect :

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

Qu’est-ce que tout ce texte dit vraiment ? Un peu 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 a un style pyramidal 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 la confusion de l’utilisateur en donnant les messages d’erreur nécessaires.
4. Assurez-vous que le message d’erreur indique un problème, une cause et une solution.
5. Assurez-vous que le message d’erreur est pertinent, exploitable, bref, clair, spécifique, courtois et rare.
6. Concevez les 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, utilisez un message d’erreur différent pour chaque cause détectable.
8. Utilisez la méthode de présentation la plus légère qui fait bien le travail.

Modèles d’usage

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 le reconnectant et en insérant un média. Les problèmes réseau peuvent être résolus en vérifiant la connexion réseau physique et en exécutant le diagnostic et la réparation 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 trouve pas de caméra pour effectuer une tâche utilisateur. Dans cet exemple, une fonctionnalité requise pour effectuer une tâche doit être activée.
Problèmes de fichier Un fichier ou dossier requis pour une tâche lancée par l’utilisateur est introuvable, est déjà en cours d’utilisation 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 un privilège suffisant pour effectuer une tâche lancé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 lancé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.

Consignes

Présentation

• Utilisez des boîtes de dialogue de tâche chaque fois que nécessaire pour obtenir une apparence et une disposition cohérentes. Les boîtes de dialogue de tâches nécessitent Windows Vista ou une version ultérieure. Elles ne conviennent donc pas aux versions antérieures de Windows. Si vous devez utiliser une boîte de message, séparez l’instruction main de l’instruction supplémentaire par deux sauts de ligne.

Erreurs d’entrée utilisateur

• Dans la mesure du possible, évitez ou réduisez les erreurs d’entrée utilisateur en :
  • Utilisation de contrôles qui sont limités à des valeurs valides.
  • La désactivation des contrôles et des éléments de menu lors d’un clic entraînerait une erreur, tant qu’il est évident que la raison pour laquelle le contrôle ou l’élément de menu est désactivé.
  • Fournir de bonnes valeurs par défaut.

Incorrect :

Dans cet exemple, une zone de texte non contrainte est utilisée pour l’entrée contrainte. Utilisez un curseur à la place.

• Utilisez la gestion des erreurs sans mode (erreurs sur place ou bulles) pour les problèmes contextuels d’entrée utilisateur.
• Utilisez des bulles pour les problèmes d’entrée utilisateur monopoint non critiques détectés dans une zone de texte ou immédiatement après qu’une zone de texte a perdu le focus.Les bulles ne nécessitent pas d’espace d’écran disponible ni 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 lorsqu’elles sont cliquées, 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 alors qu’elle est toujours dans le contrôle.

• Utilisez les erreurs sur place pour la détection d’erreurs différées, généralement les erreurs détectées en cliquant sur un bouton de validation. (N’utilisez pas d’erreurs sur place pour les paramètres immédiatement validées.) 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 à côté du problème chaque fois que possible. Les erreurs sur place ne disparaissent 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 commit.

• Utilisez la gestion modale des erreurs (boîtes de dialogue de tâche ou boîtes de message) pour tous les autres problèmes, y compris les erreurs qui impliquent plusieurs contrôles ou qui sont des erreurs non contextuelles ou non d’entrée 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 le contenu entier. Il doit toujours être évident à quoi le message d’erreur fait référence.
• N’effacez pas les entrées incorrectes. Au lieu de cela, laissez-le afin que l’utilisateur puisse voir et corriger le problème sans recommencer.
  • Exception: Effacez les zones de texte mot de passe et code confidentiel incorrects, car les utilisateurs ne peuvent pas corriger efficacement les entrées masquées.

Résolution des problèmes

• É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 dans l’ordre de probabilité 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 modales n’ont pas d’icônes de barre de titre. Les icônes de barre de titre sont utilisées comme une 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 contraire au 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 a besoin d’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’erreur. Dans ce cas, utilisez également le nom de la fonctionnalité comme objet de l’erreur.

  

  Dans cet exemple, l’icône de fonctionnalité comporte une superposition d’erreur 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 sévère. Les erreurs ne sont pas des avertissements.

  Incorrect :

  

  Dans cet exemple, une icône d’avertissement est incorrectement utilisée pour rendre l’erreur moins grave.

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

Affichage progressif

• Utilisez un bouton Afficher/Masquer la divulgation progressive des détails pour masquer des 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 risquent de ne pas les 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 vous contentez pas de reformaté 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 sur l’étiquetage, consultez Contrôles de divulgation progressifs.

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 erreur correcte (pertinente, actionnable et peu fréquente), il ne devrait pas être judicieux pour les utilisateurs de la 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 comme 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

• Concevez des messages d’erreur pour éviter d’avoir besoin d’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’une reformaté détaillée du message d’erreur, mais plutôt d’informations utiles qui dépassent la portée du message d’erreur, telles que les moyens d’éviter le problème à l’avenir. Ne fournissez pas de lien d’aide simplement parce que vous le 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 le contenu de l’aide en ligne. Ce faisant, 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 l’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 permet d’éviter la résolution des problèmes.
• Choisissez des codes d’erreur qui peuvent facilement 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 bénéficier d’informations supplémentaires.

Son

• N’accompagnez pas les messages d’erreur d’un effet sonore ou d’un signal sonore. Il est inutile de le faire.
  • Exception: Exécutez l’effet sonore Arrêt critique si le problème est critique pour le fonctionnement de l’ordinateur et que l’utilisateur doit prendre des mesures immédiates pour éviter de graves conséquences.

Texte

Généralités

• Supprimez le texte redondant. Recherchez-le dans les titres, les instructions main, 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 de l’utilisateur, et non 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, tandis que la version incorrecte est trop technique.

• N’utilisez pas les mots suivants :
  • Erreur, échec (utiliser le problème à la place)
  • Échec (utilisez impossible de le faire à la place)
  • Illégal, non valide, incorrect (utilisez incorrect à la place)
  • Abandonner, tuer, arrêter (utiliser stop à la place)
  • Catastrophique, fatal (utiliser grave à la place)

Ces termes ne sont pas nécessaires et vont à l’encontre du ton encourageant de Windows. Lorsqu’elle est utilisée correctement, l’icône d’erreur indique suffisamment qu’il existe un problème.

Incorrect :

Correct :

Dans l’exemple incorrect, les termes « catastrophique » et « échec » ne sont pas nécessaires.

• N’utilisez pas de formulation qui blâme l’utilisateur ou implique une erreur de l’utilisateur. Évitez d’utiliser vous 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 le sujet et peut se sentir blâmé pour l’erreur si la voix active a été utilisée.

Incorrect :

Correct :

L’exemple incorrect blâme l’utilisateur en utilisant la voix active.

• Être précis. Évitez les formulations vagues, telles que les erreurs de syntaxe et les opérations non conformes. Fournissez des noms, des emplacements et des valeurs spécifiques des objets impliqués.

Incorrect :

Fichier introuvable.

Le disque est saturé.

Valeur hors de la 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 pas de problèmes, de causes ou de solutions potentiellement improbables dans une tentative d’être spécifique. Ne fournissez pas de problème, de cause ou de solution, sauf s’il est probable qu’il soit correct. Par exemple, il est préférable de dire qu’une erreur inconnue s’est produite plutôt qu’une erreur susceptible d’être inexacte.
• Évitez le mot « s’il vous plaît », sauf dans les cas où l’utilisateur est invité à faire quelque chose de gênant (comme attendre) ou où le logiciel est responsable de la situation.

Correct :

Attendez 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, la perte de données ou l’impossibilité 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 :

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 de produits complets ou de symboles de marque. N’incluez pas le nom de l’entreprise, sauf si les utilisateurs associent le nom de l’entreprise au produit. N’incluez pas les numéros de version du programme.

Incorrect :

Correct :

Dans l’exemple incorrect, les noms de produits complets 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 déclarations potentiellement embarrassantes.
  • Exception: Les chemins de fichiers complets, les URL et les noms de domaine n’ont pas besoin d’être entre guillemets doubles.

Correct :

Dans cet exemple, le message d’erreur prêterait à confusion si le nom de l’objet n’était pas entre guillemets.

• Évitez de commencer des phrases avec des noms d’objets. Il est souvent difficile d’analyser cette opération.
• N’utilisez pas de marques d’exclamation ou de mots avec toutes les lettres majuscules. Les points d’exclamation et les majuscules donnent l’impression de crier à l’utilisateur.

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

Titres

• Utilisez le titre pour identifier la commande ou la fonctionnalité d’où provient l’erreur. Exceptions :
  • Si une erreur est affichée par de nombreuses commandes différentes, envisagez plutôt d’utiliser le nom du programme.
  • Si ce titre est redondant ou confus avec l’instruction main, utilisez plutôt le nom du programme.
• N’utilisez pas le titre pour expliquer ou résumer le problème qui est l’objectif de l’instruction main.

Incorrect :

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

• Utilisez une majuscule de style titre, sans mettre fin à la ponctuation.

Instructions principales

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

Incorrect :

Dans cet exemple, le message d’erreur entier est placé dans l’instruction main, ce qui le rend difficile à lire.

• Soyez précis s’il y a des objets impliqués, donnez leur nom.
• Évitez de placer des chemins d’accès de fichiers complets et des URL dans l’instruction main. Utilisez plutôt un nom court (par exemple, le nom du fichier) et placez le nom complet (par exemple, le chemin du fichier) dans l’instruction supplémentaire. Toutefois, vous pouvez placer un seul chemin d’accès ou une URL de fichier complet dans l’instruction main si le message d’erreur n’a pas besoin d’une instruction supplémentaire.

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

• N’indiquez pas le chemin d’accès et l’URL complets du fichier si cela est évident à partir du contexte.

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

• Utilisez le temps présent chaque fois que possible.
• Utilisez les majuscules comme pour les phrases.
• N’incluez pas les derniers points si l’instruction est une instruction. Si l’instruction est une question, incluez un point d’interrogation final.

Principaux modèles d’instructions

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

• [nom de l’objet facultatif] ne peut pas [effectuer l’action]
• [nom de l’objet facultatif] ne peut pas [effectuer l’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 l’action] sur « [nom de l’objet] », car [raison]
• Il n’y a pas assez de [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é de sorte que [résultats indésirables]
• [L’appareil ou le paramètre] n’est pas [disponible | trouvé | activé | activé ]
• « [nom de l’objet] » n’est pas disponible actuellement
• Le nom d'utilisateur ou le mot de passe est incorrect
• Vous n’êtes pas autorisé à accéder à « [nom de l’objet] »
• Vous n’avez pas le privilège de [effectuer une action]
• [nom du programme] a rencontré un problème grave et doit fermer immédiatement

Bien sûr, apportez les modifications nécessaires pour que l’instruction main soit grammaticalement correcte et conforme aux directives d’instruction main.

Instructions supplémentaires

• Utilisez l’instruction supplémentaire pour :
  • Donnez des détails supplémentaires sur le problème.
  • Expliquez la cause du problème.
  • Répertoriez les étapes que l’utilisateur peut suivre pour résoudre le problème.
  • Fournissez des mesures pour éviter que le problème ne se reproduise.
• 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 perdez pas de temps aux utilisateurs en suggérant des solutions possibles, mais improbables.

Incorrect :

Dans cet exemple, bien que le problème et sa solution recommandée soient 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 à partir de l’instruction du problème.

Dans cet exemple, aucune instruction supplémentaire n’est nécessaire ; la solution peut être déduite de manière triviale à partir 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 à plusieurs étapes, car les utilisateurs ont des difficultés à mémoriser plus de deux ou trois étapes simples. Si d’autres étapes sont nécessaires, 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. Viser un maximum de trois phrases de longueur modérée.
• Pour éviter les erreurs pendant que les utilisateurs exécutent 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 si cela est l’une des solutions les plus probables au problème. Réservez ces solutions pour des 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.

• Nous vous déconseillons de contacter le support technique. L’option 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 les problèmes sans contacter le support technique.

Incorrect :

Dans cet exemple, le message d’erreur recommande de contacter le support technique de manière incorrecte.

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

Boutons de validation

• 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 les boîtes de dialogue.
• Si le programme doit se terminer à la suite de l’erreur, indiquez un bouton Quitter le programme. Pour éviter toute confusion, n’utilisez pas Fermer à cet effet.
• Sinon, indiquez un bouton Fermer. N’utilisez pas OK pour les messages d’erreur, car cette formulation implique que les problèmes sont corrects.
  • Exception: Utilisez OK si votre mécanisme de rapport d’erreurs a des étiquettes fixes (comme avec l’API MessageBox).)

Documentation

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

• Reportez-vous aux erreurs par leur instruction de main. Si l’instruction main 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. Faire référence à comme message d’erreur uniquement dans la programmation et d’autres documentations techniques.
• Lorsque cela est possible, mettez le texte en gras. Sinon, placez le texte entre guillemets uniquement si nécessaire pour éviter toute confusion.

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