Confirmations

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 conseils de conception actuels.

Une confirmation est une boîte de dialogue modale qui demande si l’utilisateur souhaite poursuivre une action.

Confirmation classique.

Les confirmations présentent les caractéristiques essentielles suivantes :

• Ils s’affichent en tant que résultat direct d’une action lancée par l’utilisateur.
• Ils vérifient que l’utilisateur souhaite poursuivre l’action.
• Ils se composent d’une question simple et de deux réponses ou plus.

Les confirmations sont plus utiles lorsque l’action nécessite que l’utilisateur fasse un choix pertinent et distinct qui ne peut pas être effectué ultérieurement. Ce choix implique souvent un élément de risque qui n’est pas évident pour l’utilisateur, mais le risque n’est pas essentiel aux confirmations. Ces éléments sont nécessaires pour justifier l’interruption de la réponse à une boîte de dialogue modale.

En revanche, les messages d’avertissement présentent une condition qui peut causer un problème à l’avenir. Leur caractéristique fondamentale est qu’ils impliquent des risques :

• Elles impliquent la perte potentielle d’un ou de plusieurs des éléments suivants :
  • Ressource précieuse, telle que la perte de données ou la perte financière.
  • Accès au système ou intégrité.
  • Confidentialité ou contrôle des informations confidentielles.
  • Temps de l’utilisateur (une quantité importante, par exemple 30 secondes ou plus).
• Elles ont des conséquences inattendues ou inattendues.
• Ils nécessitent une gestion correcte maintenant, car les erreurs ne peuvent pas être facilement corrigées et peuvent même être irréversibles.

Si une confirmation comporte un risque, elle peut également être considérée comme un avertissement. Par conséquent, les instructions relatives aux messages d’avertissement s’appliquent également.

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

Est-ce la bonne interface utilisateur ?

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

• Est-ce que l’utilisateur est invité à poser une question pour poursuivre une action qui a deux réponses ou plus ? Si ce n’est pas le cas, le message n’est pas une confirmation.
• L’interface utilisateur présente-t-elle une erreur ou un problème qui s’est produit ? Si c’est le cas, utilisez plutôt un message d’erreur .
• La poursuite de l’action nécessite-t-elle que l’utilisateur fasse un choix qui n’a pas de valeur par défaut appropriée ? Si c’est le cas, une confirmation peut être appropriée.
• Existe-t-il une autre conception qui élimine la nécessité de la confirmation ? La nécessité d’une confirmation indique parfois un défaut de conception. Il existe souvent une meilleure alternative de conception qui n’a pas besoin d’une confirmation.
• L’utilisateur est-il sur le point d’effectuer une action risquée ? Si c’est le cas, une confirmation est appropriée si l’action a des conséquences importantes ou ne peut pas être annulée facilement.
• L’utilisateur est-il sur le point d’abandonner une tâche ? Si c’est le cas, ne confirmez pas. Supposons que les utilisateurs comprennent les conséquences de l’impossibilité d’effectuer une tâche.
• L’action a-t-elle des conséquences que les utilisateurs peuvent ne pas connaître ? Si c’est le cas, une confirmation peut être appropriée.
• Étant donné le contexte actuel, les utilisateurs sont-ils susceptibles d’effectuer une action dans une erreur ? Si c’est le cas, une confirmation peut être appropriée.
• Les utilisateurs effectuent-ils l’action fréquemment ? Si c’est le cas, envisagez une autre conception. Les confirmations fréquentes sont ennuyeuses et ont peu de valeur, car les utilisateurs apprennent à répondre sans réfléchir.
• L’action a-t-elle des implications sur la sécurité ? Si c’est le cas, une confirmation peut être requise même si les tests précédents indiquent le contraire.

Principes de conception

Les confirmations inutiles sont ennuyeuses

La première confirmation Windows jamais créée ressemble sans aucun doute à ceci :

La confirmation originale ennuyeuse.

C’était un très mauvais début. Si vous voulez que les utilisateurs détestent votre programme, il suffit de saupoudrer des confirmations comme celle-ci. Pour comprendre pourquoi, tenez compte du point de vue de l’utilisateur. L’utilisateur vient de demander d’effectuer une action selon la définition d’une confirmation, donc, sauf si quelque chose a été cliqué ou appuyé accidentellement, bien sûr, l’utilisateur souhaite continuer.

Non seulement les confirmations inutiles sont ennuyeuses, mais elles ne sont pas efficaces pour protéger l’utilisateur contre les erreurs. Les utilisateurs découvrent rapidement quand un programme a des confirmations inutiles et leur réponse naturelle est de les ignorer aussi rapidement que possible, souvent sans lecture. Par conséquent, de telles confirmations ne font guère plus qu’ajouter une étape supplémentaire à ces tâches.

N’utilisez pas les confirmations simplement parce qu’il existe la possibilité que les utilisateurs fassent une erreur. Au lieu de cela, les confirmations sont plus efficaces lorsqu’elles sont utilisées pour confirmer des actions qui ont des conséquences importantes ou involontaires. Les bonnes confirmations n’indiquent jamais l’évidence; ils doivent communiquer quelque chose que les utilisateurs doivent être conscients d’une bonne raison de ne pas continuer. Et ils ne sont utilisés que lorsqu’ils sont vraiment nécessaires par une action, comme demander aux utilisateurs d’enregistrer les modifications uniquement lorsque des modifications méritent d’être enregistrées. Cela nécessite l’attention de l’utilisateur uniquement lorsque cela est vraiment justifié.

Pour d’autres types de confirmations, il existe souvent une meilleure alternative de conception que de forcer les utilisateurs à répondre à une question.

Envisager les alternatives de conception

Voici quelques alternatives de conception qui éliminent la nécessité de confirmations de routine :

• Évitez les erreurs. Concevez des tâches de sorte que des erreurs importantes soient difficiles à faire accidentellement. Par exemple, sépare physiquement les commandes destructrices des autres commandes et nécessite l’exécution de plusieurs actions.
• Indiquez l’annulation. Fournissez la possibilité de rétablir des actions. Par exemple, la suppression d’un fichier dans Microsoft Windows ne nécessite généralement pas de confirmation, car les fichiers supprimés peuvent être récupérés à partir de la Corbeille. Notez que si une action est très facile à effectuer, le simple fait d’avoir des utilisateurs à rétablir l’action peut être suffisant.
• Fournir des commentaires. Rendre les résultats indésirables évidents. Fournir undo seul n’est pas suffisant si les utilisateurs ne se rendent pas compte quand ils font une erreur. Par exemple, l’effet d’une manipulation directe (telle qu’une opération de glisser-déplacer) doit toujours être évident.
• Supposez le résultat probable, mais facilitez la modification. Si vous n’êtes pas sûr de ce que veulent les utilisateurs, mais qu’il existe un choix probable, sûr et sécurisé, supposez ce choix, indiquez clairement ce qui s’est passé et facilitez les modifications à l’aide d’un menu contextuel. Par exemple, Microsoft Word suppose que les utilisateurs souhaitent épeler des mots correctement. S’il reconnaît un mot mal orthographié et qu’il connaît l’orthographe probablement correcte, Word effectue automatiquement la correction, mais permet aux utilisateurs de rétablir.
• Éliminez complètement le choix. Si le choix n’est pas important, les utilisateurs s’en fichent. Il est préférable de simplifier votre programme et d’éliminer le choix.

Faire des confirmations nécessite réflexion

Pour qu’une confirmation ait une valeur, les utilisateurs doivent comprendre la raison de ne pas continuer. Parfois, la raison est évidente, comme lorsque les utilisateurs ferment un document avec des modifications qui n’ont pas été enregistrées :

Dans cet exemple, la raison de la confirmation est évidente.

Dans d’autres situations, la raison n’est peut-être pas si évidente.

Lorsque vous choisissez des étiquettes de bouton de validation pour les boîtes de dialogue, les instructions générales sont de choisir des étiquettes qui sont des réponses spécifiques à l’instruction main. Cela permet une prise de décision efficace, car les utilisateurs doivent lire une quantité minimale de texte pour continuer. Toutefois, cet objectif d’efficacité peut être contre-productif pour les confirmations. Examinez cet exemple :

Incorrect :

Dans cet exemple, la réponse correcte nécessite une réflexion.

Si vous présentez cette confirmation immédiatement après que l’utilisateur a donné la commande Désinstaller, la réponse de l’utilisateur est susceptible d’être « Bien sûr que je veux désinstaller ! » L’utilisateur clique sur Désinstaller sans y réfléchir.

Pour les confirmations, nous ne voulons pas que les utilisateurs prennent des décisions hâtives et émotionnelles. Pour encourager les utilisateurs à réfléchir à leur réponse, nous devons fournir un petit coup de vitesse décisionnel. Lorsque cela est pratique, il est généralement préférable de le faire en mettant soigneusement en forme les boutons de validation. Par exemple, nous pouvons utiliser un langage supplémentaire pour indiquer qu’il existe une raison de ne pas continuer.

Mieux :

Dans cet exemple, « anyway » est ajouté à l’étiquette du bouton commit pour indiquer que la confirmation donne une raison de ne pas continuer.

Si cette approche n’est pas pratique, nous pouvons utiliser des boutons de validation Oui/Non.

Mieux vaut également :

Dans cet exemple, l’utilisation des boutons de validation Oui/Non force les utilisateurs à lire au moins l’instruction main.

Fournir toutes les informations

Si vous souhaitez poser une question, vous devez fournir suffisamment d’informations pour permettre aux utilisateurs de répondre intelligemment à cette question. Considérez la boîte de dialogue Confirmer le remplacement de fichier de Windows XP :

Boîte de dialogue Confirmer le remplacement de fichier de Windows XP.

Cette confirmation fournit-elle toutes les informations dont les utilisateurs peuvent avoir besoin pour répondre à la question ? Avant de répondre, considérez les scénarios utilisateur les plus courants :

• Copiez (ou déplacez) l’autre fichier en remplaçant celui existant.
• Conservez le fichier existant, sans copier ni déplacer l’autre fichier.
• Conservez ou copiez le fichier le plus récent (scénario supérieur).
• Conservez le fichier existant ou copiez l’autre fichier, selon des critères tels que le contenu et la taille du fichier.
• Conservez le fichier existant et copiez l’autre fichier sous un autre nom.
• Annulez l’opération en cas de problème ou d’inattendu.

Les utilisateurs peuvent atteindre le scénario 1 en cliquant sur Oui et scénario 2 en cliquant sur Non. Ils peuvent atteindre le scénario 3 en comparant les dates du fichier et en cliquant sur le bouton approprié, mais notez combien de réflexion il faut pour déterminer le fichier plus récent, puis déterminer le bouton approprié, en particulier pour ce qui est probablement le scénario le plus courant.

Les scénarios 4, 5 et 6 sont également étonnamment difficiles. Les tailles de fichier étant arrondies, il est impossible, par exemple, de déterminer si ces fichiers ont la même taille ou même s’il s’agit du même fichier. Les icônes étant destinées à l’application utilisée pour ouvrir le fichier, les utilisateurs doivent ouvrir les fichiers pour inspecter et comparer leur contenu. Avoir des miniatures du contenu du fichier serait beaucoup plus utile pour répondre à la question.

La confirmation de copie de fichier à partir de Windows Vista permet de mieux gérer ces scénarios en fournissant plus d’informations et en ajoutant l’option permettant de conserver les deux fichiers :

Confirmation de la copie du fichier Windows Vista.

Fournir des informations spécifiques et utiles

Si vous souhaitez poser une question, assurez-vous que les utilisateurs comprennent la question et les implications des réponses alternatives. Considérez cette confirmation de sécurité windows Internet Explorer :

Confirmation de sécurité vague.

Cette confirmation pose une question que les utilisateurs ne peuvent pas répondre intelligemment. L’utilisateur a demandé que Windows Internet Explorer afficher une page, et ce message déconseille implicitement par le libellé du texte et en mettant en surbrillance Non comme choix par défaut.

Le problème de sécurité spécifique que pose la page n’est pas suffisamment expliqué, de sorte que le risque de continuer n’est pas clair. Quelles informations contenues dans la confirmation amèneraient l’utilisateur à cliquer sur Non ? En raison de l’imprécision du message, la confirmation n’est pas susceptible de décourager les utilisateurs de continuer, mais les fera se sentir mal à l’idée de le faire.

Pour que cette confirmation soit utile, elle doit fournir des informations spécifiques supplémentaires qui peuvent amener l’utilisateur à décider de ne pas continuer. En général, pour chaque réponse dans une confirmation, tenez compte des scénarios qui l’exigent et assurez-vous que les informations fournies sont suffisantes pour que les utilisateurs souhaitent la choisir. Offrir des choix, pas des dilemmes.

Comment déterminer si une confirmation est nécessaire

La réflexion sur les scénarios et la probabilité de choisir chaque réponse suggère un moyen systématique de déterminer si une confirmation est nécessaire. Si les utilisateurs sont susceptibles de sélectionner toutes les réponses, la confirmation est nécessaire et utile. Toutefois, si une seule réponse est probable (disons 98 % du temps), la confirmation est manifestement inutile et doit être supprimée. Notez que les confirmations liées à des problèmes de sécurité, juridiques et de sécurité sont des exceptions possibles.

Cette confirmation est-elle nécessaire ? Les utilisateurs sélectionneront-ils jamais Non ? C’est possible mais très improbable. Cette confirmation doit être supprimée.

Si vous ne faites que trois choses...

1. Assurez-vous que votre confirmation est vraiment nécessaire. Il doit y avoir une raison légitime et claire de ne pas continuer, et une chance que parfois les utilisateurs ne le fassent pas.

2. Si la raison de la confirmation n’est pas immédiatement évidente, choisissez des boutons de validation qui encouragent les utilisateurs à réfléchir à leur réponse. En règle générale, cela se fait en définissant la confirmation comme une question oui ou non et en fournissant des réponses explicites ou oui/non.

3. Considérez tous les scénarios et fournissez les informations nécessaires pour répondre intelligemment à la question.

Modèles d’usage

Les confirmations ont plusieurs modèles d’utilisation :

Usage	Exemple
Confirmations de routine confirmer que l’utilisateur souhaite effectuer une action de routine à faible risque.	Ces confirmations sont généralement énoncées « êtes-vous sûr...? » et ont souvent une zone ne pas afficher ce message à nouveau case activée zone pour réduire leur gêne. Exemples de confirmations de routine. Note: Ce modèle est généralement inutile et doit être évité.
Confirmations des actions à risque confirmez que l’utilisateur souhaite poursuivre une action qui présente un certain risque et qui ne peut pas être facilement annulée.	Étant donné qu’elles présentent un risque, ces confirmations ont généralement une icône d’avertissement. Exemples de confirmations d’action à risque.
Confirmations de conséquences inattendues confirmer que l’utilisateur souhaite poursuivre une action qui a des conséquences inattendues ou inattendues.	En plus de poser une question, ces confirmations indiquent les conséquences inattendues. parce qu’elles ont des conséquences inattendues, ces confirmations ont généralement une icône d’avertissement. exemples de confirmations de conséquences involontaires. toutefois, ce modèle exige que les conséquences soient vraiment inattendues. Incorrect: Les conséquences sont prévues ici, donc c’est une confirmation de routine.
Précisions clarifier la façon dont l’utilisateur souhaite procéder avec une action qui a des conséquences potentiellement ambiguës ou inattendues.	Les opérations glisser-déplacer peuvent entraîner des clarifications si l’effet de l’opération peut être mal interprété. Exemples de clarifications. Note: Ce modèle doit être évité, car il est préférable de concevoir des actions sans conséquences ambiguës et de supposer le résultat le plus probable souhaité.
Confirmations de sécurité confirmez que l’utilisateur souhaite poursuivre une action avec des conséquences sur la sécurité.	Exemples de confirmations de sécurité.
Confirmations de motifs antérieurs fournissez des informations sur une action, mais présentez-la sous forme de confirmation.	Bien que ces boîtes de dialogue soient présentées sous forme de confirmations, leur objectif réel est l’éducation des utilisateurs ou la publicité des fonctionnalités. Exemple de confirmation d’arrière-pensée. Note: Ce modèle n’est pas recommandé, car il existe généralement une alternative meilleure et plus directe. Par exemple, les animations sont un meilleur moyen de montrer la relation entre la cause et l’effet.

Consignes

Général

• Utilisez les confirmations « Enregistrer les modifications » uniquement en cas de modifications importantes. Ne confirmez pas les modifications qui n’ont pas été effectuées directement par l’utilisateur, telles que le reformatage automatique des documents.

Incorrect :

Cet exemple est incorrect lorsqu’il est utilisé pour un courrier électronique ou un document vide qui n’a pas été modifié par l’utilisateur.

Icônes

• Les confirmations n’utilisent pas d’icônes de barre de titre.

• L’icône de zone de contenu d’une confirmation est basée sur son modèle de conception :

  Modèle	Icône
  Confirmations de routine	Pas d'icône.
  Confirmations des actions à risque	Icône d’avertissement.
  Confirmations des conséquences inattendues	Utilisez une icône d’avertissement en cas de risque, l’icône de fonctionnalité si disponible ; sinon, pas d’icône.
  Précisions	Si la confirmation implique un document, utilisez la miniature du document ; sinon, utilisez l’icône de fonctionnalité si disponible, ou aucune icône.
  Confirmations de sécurité	Icône d’avertissement.
  Confirmations de motifs antérieurs	Pas d'icône.

• N’utilisez pas d’icônes d’avertissement pour les questions de routine. Cela va à l’inverse du ton encourageant de Windows et rend l’utilisation de votre programme comme une activité dangereuse. Supposons que les utilisateurs comprennent les conséquences de l’annulation d’une tâche avant qu’elle ne soit terminée.

Incorrect :

Dans cet exemple, une icône d’avertissement est utilisée pour poser une question de routine.

Boutons de validation

• Utilisez des réponses spécifiques à l’instruction main si la raison de la confirmation est évidente ou peut être explicite.

Dans cet exemple, la raison de la confirmation est évidente. Ainsi, Enregistrer et Ne pas enregistrer fonctionnent bien.

• Sinon, utilisez les boutons Oui et Non pour les réponses de confirmation. Cela incite les utilisateurs à réfléchir à la confirmation avant de répondre. N’utilisez jamais OK et Annuler pour les confirmations.

Correct :

Dans cet exemple, l’utilisation des boutons de validation Oui/Non force les utilisateurs à lire au moins l’instruction main.

Incorrect :

Dans cet exemple, l’utilisation d’OK/Cancel est source de confusion.

• Pour fermer un programme ou redémarrer Windows, utilisez des réponses spécifiques à l’instruction main. Pour éviter tout malentendu, n’utilisez pas Close ou Oui/Non à cet effet.

Correct :

Incorrect :

Dans l’exemple incorrect, Oui est utilisé pour redémarrer Windows.

Liens de commande

• Pour le modèle de clarifications, envisagez d’utiliser des liens de commande pour clarifier les alternatives.

Acceptable:

Mieux :

Dans le meilleur exemple, les liens de commande rendent les alternatives claires.

• Présentez d’abord les liens de commande les plus couramment utilisés. L’ordre résultant doit suivre approximativement la probabilité d’utilisation, mais également avoir un flux logique.
• Si un lien de commande nécessite une explication supplémentaire, fournissez une explication supplémentaire. Des explications supplémentaires décrivent pourquoi les utilisateurs peuvent vouloir choisir l’option ou ce qui se passe si l’option est choisie.

Pour plus d’instructions et d’exemples, consultez Liens de commande.

Valeurs par défaut

• La réponse par défaut pour une confirmation est basée sur son modèle de conception :

  Modèle	Réponse par défaut
  Confirmations de routine	Procéder.
  Confirmations des actions à risque	Ne continuez pas (ou le choix sûr).
  Confirmations des conséquences inattendues	Si les conséquences sont importantes, ne poursuivez pas; sinon, continuez.
  Précisions	Réponse la plus probable.
  Confirmations de sécurité	Ne continuez pas.
  Confirmations de motifs antérieurs	Procéder.

Ne plus afficher ce message

• Utilisez cette option uniquement pour les modèles de confirmation de routine et de motifs antérieurs. Pour les autres modèles, si les informations sont nécessaires, elles doivent toujours être affichées.
• Ne fournissez pas cette option pour justifier l’affichage d’une confirmation inutile. Il suffit de se débarrasser de la confirmation à la place.

Incorrect :

Toujours incorrect :

Dans ces exemples, l’ajout d’une option Ne plus afficher ce message ne résout pas une confirmation inutile.

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

Opérations en bloc

• Pour les confirmations qui s’appliquent aux opérations en bloc, fournissez une option permettant d’appliquer la confirmation à l’ensemble de l’opération.

Cet exemple propose une option pour les opérations en bloc.

• Éliminez ou reportez les confirmations dans une opération en bloc.

Incorrect :

Dans cet exemple, Windows Explorer dans Windows XP confirme chaque fichier en lecture seule lors d’un déplacement de fichier en bloc. Il est préférable de copier les fichiers en lecture seule sans demander, ou de reporter la gestion de ces fichiers et de présenter la confirmation à la fin de la tâche.

Affichage progressif

• Si vous devez inclure des informations avancées dans un message de confirmation, indiquez-les à l’aide de boutons de divulgation progressive (par exemple, « Afficher les détails »). Cela simplifie la confirmation de l’utilisation classique. Ne masquez pas les informations nécessaires, car les utilisateurs risquent de ne pas les trouver.
• N’utilisez pas « Afficher les détails », sauf s’il y a vraiment plus de détails. Ne vous contentez pas de reformatér les informations existantes dans un autre format.

Pour obtenir des instructions en matière d’étiquetage, consultez Divulgation progressive.

Contrôle de compte d'utilisateur

• N’utilisez pas l’interface utilisateur d’élévation du contrôle de compte d’utilisateur (UAC) pour remplacer une confirmation. Si une action a besoin d’une confirmation, utilisez une boîte de dialogue distincte. Pendant l’interface utilisateur d’élévation, les utilisateurs doivent se concentrer sur leur démarrage et sur la fiabilité du programme.
• Affichez la confirmation avant l’interface utilisateur d’élévation. Cela élimine les élévations inutiles.

Texte

Général

• Supprimez le texte redondant. Recherchez du texte redondant dans les titres, les instructions main, les instructions supplémentaires, les zones de contenu, 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.
• N’utilisez pas « avertissement » ou « attention » dans le texte. Si les utilisateurs doivent continuer avec prudence, indiquez-le à l’aide d’une icône d’avertissement à la place.

Incorrect :

Dans cet exemple, le terme « avertissement » n’est pas nécessaire.

Titres

• Utilisez le titre pour identifier la commande ou la fonctionnalité d’où provient la confirmation. Exceptions :
  • Si une confirmation 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.

Toutefois, si la confirmation provient d’une tâche de longue durée et peut s’afficher bien après le début de la tâche, utilisez toujours la commande ou la fonctionnalité pour identifier clairement le contexte.

• N’utilisez pas le titre pour expliquer ce qu’il faut faire dans la boîte de dialogue qui est l’objectif de l’instruction main.
• S’il ajoute de la clarté, commencez le titre par le mot Confirmer.
• Pour les confirmations d’actions à risque, vous pouvez ajouter le nom de l’objet impliqué pour plus d’accentuation.

Dans cet exemple, le lecteur à mettre en forme est inclus dans le titre.

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

Instructions principales

• L’instruction main pour une confirmation est basée sur son modèle de conception :

  Modèle	Instruction principale
  Confirmations des conséquences inattendues	indiquent la conséquence inattendue. exception : si une question demandant si l’utilisateur souhaite poursuivre implique clairement la conséquence involontaire, posez la question à la place. Dans cet exemple, demander à l’utilisateur de procéder suffisamment indique les conséquences de l’action.
  Tous les autres	Posez une seule question pour déterminer si l’utilisateur souhaite continuer.

• Soyez concis n’utilisez qu’une seule phrase complète. Supprimez l’instruction main jusqu’aux informations essentielles. Si vous devez expliquer quelque chose de plus, utilisez une instruction supplémentaire.

• Soyez précis s’il y a des objets impliqués, donnez leur nom complet.

• Utilisez un phrasé positif. La formulation positive est plus facile à comprendre pour les utilisateurs.

Correct :

Voulez-vous activer le partage de fichiers et d’imprimantes ?

Incorrect :

Voulez-vous désactiver le partage de fichiers et d’imprimantes ?

Toutefois, la formulation doit correspondre à la commande associée, même si la commande est formulée de manière négative ; ainsi, par exemple, utilisez désactiver pour confirmer une commande Désactiver.

• Bien qu’il n’existe pas de règles strictes pour la formulation des formulations, ces expressions de confirmation courantes ont la connotation indiquée :

  Expression	Connotation
  Êtes-vous sûr de vouloir [effectuer une action] ?	Confirmation du résultat direct d’une requête utilisateur.
  Voulez-vous [effectuer une action] ?	Confirmation d’un effet secondaire d’une demande utilisateur.
  Voulez-vous [sélectionner un résultat] ?	Besoin d’une clarification.
  [Effectuer une action] ?	Aucune connotation.

• Pour les confirmations d’action à risque, utilisez le terme définitivement pour indiquer qu’une action ne peut pas être annulée.

Dans cet exemple, « permanently » indique que l’action ne peut pas être annulée.

• Utilisez la majuscule de style phrase.

Instructions supplémentaires

• L’instruction supplémentaire pour une confirmation est basée sur son modèle de conception :

Étiquette	Valeur
Modèle	Instruction supplémentaire
Confirmations des conséquences inattendues	Posez une seule question pour déterminer si l’utilisateur souhaite continuer.
Tous les autres	Expliquer les raisons non évidentes pour lesquelles l’utilisateur peut ne pas vouloir continuer. Ces raisons sont les suivantes : Perte potentielle d’un ou de plusieurs des éléments suivants : Ressource précieuse, telle que la perte de données ou la perte financière. Accès au système ou intégrité. Confidentialité ou contrôle des informations confidentielles. Actions irréversibles.

• Ne répétez pas l’instruction main avec un libellé légèrement différent. Au lieu de cela, omettez l’instruction supplémentaire s’il n’y a pas plus à ajouter.
• Pour les confirmations de conséquences involontaires, envisagez d’utiliser le terme de toute façon pour indiquer de manière concise qu’il y a une raison de ne pas continuer au cas où l’utilisateur aurait négligé l’instruction main. Pour plus d’informations, consultez Concepts de conception.
• Utilisez des phrases complètes, une mise en majuscule de style phrase et une ponctuation de fin.

Documentation

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

• Reportez-vous à une confirmation par son titre si le titre est spécifique à la confirmation (autrement dit, pas le nom du programme) ; sinon, reportez-vous à cette instruction main.
• Si nécessaire, vous pouvez faire référence à une boîte de dialogue de confirmation en tant que message.
• Utilisez le texte exact, y compris sa majuscule.
• Lorsque cela est possible, mettez le texte en gras. Sinon, placez le texte entre guillemets uniquement si nécessaire pour éviter toute confusion.

Exemple : dans le message Copier le fichier , cliquez sur le fichier plus récent.