Sur un formulaire, je rencontre souvent des boutons intitulés « Valider ».
Le mot est court. Il tient partout. Pourtant, il ne dit pas toujours ce qui va réellement se passer.
Est-ce que je vais envoyer ma demande ? Enregistrer un brouillon ? Créer mon compte ? Passer au paiement ?
Le problème paraît minuscule, mais c’est exactement le type d’hésitation que la microcopy peut éviter.
Elle regroupe tous ces textes courts intégrés à l’interface : boutons, labels, indications sous un champ, messages d’erreur, confirmations, textes affichés lorsqu’une liste est vide ou lorsqu’une recherche ne renvoie aucun résultat.
Je les remarque surtout quand ils fonctionnent mal.
Un bon microtexte ne cherche pas forcément à être original. Il donne l’information dont j’ai besoin au moment où j’en ai besoin.
Si un utilisateur doit réfléchir au sens d’un bouton ou deviner comment corriger une erreur, quelques mots de l’interface peuvent probablement être améliorés.
Ce qui entre réellement dans la microcopy
La microcopy désigne les petits textes directement liés à une interaction ou à un état de l’interface.
Un bouton « Ajouter au panier », un label « Adresse e-mail », une indication « 8 caractères minimum », un message « Votre demande a bien été envoyée » ou encore « Aucun projet ne correspond à ces filtres » en font partie.
Je la distingue du contenu éditorial classique.
Le paragraphe qui explique les avantages d’une prestation informe et convainc. Le bouton placé juste après doit surtout indiquer ce que je peux faire.
Les deux textes peuvent partager le même ton de marque. Leur fonction n’est pas la même.
Chaque microtexte doit avoir une fonction
Je trouve utile de pouvoir expliquer en une phrase pourquoi un texte existe.
Prenons un champ « Téléphone » dans un formulaire.
S’il est facultatif et sert uniquement au rappel, j’écrirais :
Téléphone — facultatif
Uniquement si vous souhaitez être rappelé.
La deuxième ligne répond à une question plausible : « Pourquoi me demande-t-on mon numéro ? »
En revanche :
« Votre numéro nous permet de mieux répondre à vos besoins. »
reste vague. L’utilisateur ne sait toujours pas s’il recevra un appel, un SMS ou si le numéro est réellement nécessaire.
La microcopy est plus utile lorsqu’elle réduit une incertitude concrète.
Les boutons doivent annoncer l’action
Le GOV.UK Design System recommande d’utiliser un libellé qui décrit l’action déclenchée par le bouton.
Voir : GOV.UK Design System – Button.
Dans un formulaire de contact, je préfère :
Envoyer ma demande
à :
Valider
Sur une interface de gestion :
Archiver le projet
est plus précis que :
OK
Le bouton n’a pas besoin de raconter toute l’action. Le contexte fait une partie du travail. Mais il doit donner suffisamment d’informations pour éviter une surprise après le clic.
Je fais particulièrement attention aux boutons qui déclenchent un engagement : paiement, publication, suppression, réservation.
Quand « Continuer » fonctionne… et quand il devient trop vague
Je n’ai pas de problème avec « Continuer » dans un parcours linéaire.
Dans un tunnel :
Coordonnées → Livraison → Paiement → Confirmation
le bouton peut être parfaitement compréhensible pendant les premières étapes.
Je le change lorsque l’action devient plus engageante.
Par exemple :
Continuer vers le paiement
puis :
Payer 89 €
Ce dernier libellé indique clairement que le clic déclenche le paiement.
J’éviterais en revanche une succession de trois écrans utilisant tous « Continuer » si l’un crée le compte, le suivant souscrit un abonnement et le dernier déclenche un prélèvement.
Labels, placeholders et textes d’aide dans les formulaires
Un formulaire concentre beaucoup de microcopy. Chaque mot supplémentaire prend de la place, mais chaque information manquante peut bloquer la saisie.
Le label nomme ce qui est demandé
Le W3C recommande qu’un contrôle de formulaire possède un label permettant d’identifier clairement sa fonction.
Voir : W3C – Labeling Controls.
Je reste généralement très directe :
Adresse e-mail
plutôt que :
Comment pouvons-nous vous contacter ?
si le champ attend uniquement une adresse e-mail.
Le placeholder ne remplace pas le label
Un placeholder disparaît dès que l’utilisateur commence à saisir.
Si le nom du champ est uniquement écrit à cet endroit, il devient plus difficile de vérifier ensuite ce qui était demandé.
Le W3C déconseille donc son utilisation en remplacement du label.
Voir : W3C – Form Instructions.
Je peux avoir :
Adresse e-mail
[
Le label reste visible. Le placeholder donne un exemple, si cet exemple apporte réellement quelque chose.
Le texte d’aide doit ajouter une information
Sous « Numéro de commande », une indication comme :
Vous le trouverez dans l’e-mail de confirmation.
peut faire gagner du temps.
Sous « Nom », écrire :
« Saisissez votre nom. »
ne fait que répéter le label.
Je supprime ce type d’aide plutôt que remplir systématiquement l’espace disponible sous chaque champ.
Écrire un message d’erreur qui aide à corriger
« Erreur » ne donne aucune solution.
« Champ invalide » reste à peine plus utile.
Le W3C recommande que l’erreur soit identifiable et que les informations disponibles permettent de comprendre comment la corriger.
Voir : W3C – User Notification.
Pour une adresse e-mail :
Peu utile :
Adresse e-mail invalide.
Plus précis :
Saisissez une adresse e-mail au format
Pour une date :
Peu utile :
Format incorrect.
Plus précis :
Saisissez la date au format JJ/MM/AAAA.
Le GOV.UK Design System recommande lui aussi des messages qui décrivent le problème et orientent vers la correction.
Voir : GOV.UK Design System – Error message.
Je retire également les reproches inutiles.
« Vous avez oublié votre nom »
devient simplement :
Saisissez votre nom.
Le problème est indiqué. Rien n’est gagné à culpabiliser la personne qui remplit le formulaire.
Après l’action, dire clairement ce qui s’est passé
Une absence de retour est particulièrement gênante après une action importante.
L’utilisateur envoie un formulaire. Rien ne change. Il reclique. Peut-être deux fois.
Un message de succès doit au minimum confirmer l’action.
Votre demande a bien été envoyée.
Si l’on connaît réellement la suite, on peut la préciser :
Votre demande a bien été envoyée.
Nous vous répondrons par e-mail sous deux jours ouvrés.
Je n’ajoute pas de délai si l’entreprise n’est pas capable de le tenir.
Le W3C traite également les notifications de succès dans ses recommandations sur les formulaires.
Voir : W3C – User Notification.
Les actions destructives demandent des mots précis
Les fenêtres de confirmation contiennent souvent :
Êtes-vous sûr ?
[ Oui ] [ Non ]
Si l’utilisateur a été interrompu quelques secondes, cette formulation lui demande de se souvenir de ce qu’il était en train de faire.
Je préfère :
Supprimer le projet « Refonte 2026 » ?
Cette suppression est définitive.
[ Annuler ]
[ Supprimer le projet ]
Le GOV.UK Design System réserve ses boutons d’avertissement aux actions ayant des conséquences sérieuses et recommande un contexte explicite.
Voir : GOV.UK Design System – Warning buttons.
« Supprimer » et « Archiver » ne doivent pas non plus être utilisés comme synonymes. Si l’un est réversible et l’autre non, les mots doivent refléter cette différence.
Un état vide n’est pas toujours une erreur
Lors de la première connexion à un outil de gestion de projets, afficher :
Aucune donnée disponible.
donne l’impression qu’un problème technique a peut-être eu lieu.
La situation réelle est différente : l’utilisateur n’a encore rien créé.
Je peux écrire :
Vous n’avez encore aucun projet.
Créez votre premier projet pour commencer à organiser vos tâches.
[ Créer un projet ]
Le même composant ne doit pas forcément être utilisé lorsqu’une liste normalement remplie devient vide après l’application de filtres.
Dans ce cas :
Aucun projet ne correspond à ces filtres.
[ Réinitialiser les filtres ]
Les deux écrans sont visuellement proches. La microcopy doit refléter deux situations différentes.
Que dire lorsqu’une recherche ne renvoie rien ?
« Aucun résultat » constate simplement l’échec.
Je regarde ce qui peut aider à repartir.
Pour :
Aucun résultat pour « wireframme ».
on peut proposer :
Vérifiez l’orthographe ou essayez un terme plus général.
Dans un e-commerce, des catégories proches peuvent éventuellement être affichées. Sur une documentation, des recherches apparentées peuvent être utiles.
Je garde ces suggestions limitées.
Un écran sans résultat n’a pas besoin de devenir une nouvelle page d’accueil avec vingt contenus recommandés.
Connexion et récupération de compte : garder un vocabulaire stable
Une personne crée un compte avec son « adresse e-mail ».
Sur l’écran suivant, le formulaire lui demande son « identifiant ».
Elle peut légitimement se demander s’il s’agit de la même information.
Je garde donc le vocabulaire stable lorsque l’objet reste le même.
Le même principe s’applique à :
Compte / Profil / Espace personnel
ou :
Organisation / Entreprise / Société
dans un logiciel professionnel.
Les synonymes sont utiles dans un article. Dans une interface, ils peuvent créer une ambiguïté inutile.
Expliquer une interface sans multiplier les tooltips
Un tooltip peut être utile pour une fonction inhabituelle.
Il devient suspect lorsque chaque bouton de l’écran en possède un.
Si une icône est incompréhensible sans une phrase d’explication, j’étudie d’abord la possibilité d’ajouter un vrai libellé.
De même :
« Cliquez sur Ajouter pour ajouter un nouveau projet. »
n’apprend pas grand-chose si le bouton s’appelle déjà « Ajouter un projet ».
Je garde l’onboarding pour les choix qui nécessitent réellement un apprentissage : configuration initiale, interaction inhabituelle ou conséquence qui n’est pas immédiatement visible.
Jusqu’où appliquer le ton de marque ?
Une interface bancaire, une plateforme de jeux et une marque de cosmétiques n’ont aucune raison d’employer exactement le même ton.
La personnalité peut donc apparaître dans la microcopy.
Je réduis néanmoins fortement les effets de style lorsque l’utilisateur rencontre un problème.
Une page 404 peut se permettre une touche d’humour si le chemin de retour est évident.
Un paiement refusé mérite davantage de sobriété.
« Oups, votre carte a décidé de prendre des vacances ! »
peut faire sourire le rédacteur. Pour la personne qui essaie de terminer une commande, le message prioritaire est plutôt de savoir ce qui a échoué et ce qu’elle peut essayer ensuite.
Le ton ne doit jamais retarder l’information.
Créer un vocabulaire cohérent dans tout le produit
Sur une interface importante, je trouve utile de tenir un petit lexique.
Par exemple :
- Projet : dossier principal ;
- Tâche : action à réaliser dans un projet ;
- Archiver : retirer de la vue principale sans supprimer ;
- Supprimer : effacer définitivement.
Ce document évite qu’un écran parle de « dossier », un autre de « projet » et un troisième d’« espace » pour désigner exactement la même chose.
La cohérence des libellés est aussi importante dans la navigation. J’aborde ce point dans mon article consacré à la navigation UX et aux menus.
Microcopy et accessibilité
Un bon texte ne suffit pas si l’interface ne permet pas de l’associer correctement au composant concerné.
Un message d’erreur peut être parfaitement rédigé et rester difficile à exploiter s’il est simplement affiché en rouge sous un champ sans relation programmatique avec celui-ci.
Le W3C traite séparément les labels, les instructions, la validation et les notifications dans ses tutoriels sur les formulaires.
Voir : W3C – Forms Tutorial.
Je regarde donc le texte et son intégration.
La couleur ne doit pas être le seul indice d’erreur. Les instructions doivent être disponibles au bon moment. Les messages dynamiques importants doivent pouvoir être annoncés aux technologies d’assistance.
Microcopy et développement se rencontrent directement sur ces sujets.
Ce qui change sur mobile
La place disponible oblige parfois à raccourcir.
Enregistrer les modifications apportées à votre profil
peut devenir :
Enregistrer les modifications
si le contexte montre déjà clairement que l’on édite le profil.
Je ne cherche pas systématiquement le libellé le plus court.
Valider
occupe moins de largeur que :
Envoyer ma demande
mais le second peut éviter une hésitation.
Le bon compromis consiste à retirer les mots dont le contexte permet déjà de se passer, sans supprimer l’information qui décrit l’action.
Ces arbitrages rejoignent ceux de mon article sur l’UX mobile.
Prévoir les traductions avant de figer les composants
Un bouton parfaitement calibré pour « Ajouter » peut accueillir difficilement son équivalent dans une autre langue.
Certaines formulations s’allongent fortement lors de la traduction.
Je préfère donc que le composant puisse absorber une variation raisonnable de longueur.
Les jeux de mots posent un autre problème. Une phrase amusante en français peut devenir incompréhensible ou impossible à traduire correctement.
Sur les actions fonctionnelles, un vocabulaire direct facilite généralement la localisation.
La traduction ne doit pas être traitée comme une simple substitution de mots lorsque le produit est destiné à plusieurs marchés.
Exemple : reprendre un formulaire de contact
Imaginons cette version :
Nom *
Email *
Téléphone *
Objet *
Message *
[ Valider ]
Le formulaire n’est pas incompréhensible. Mais plusieurs éléments restent vagues.
Pourquoi le téléphone est-il obligatoire ? « Objet » attend-il un titre libre ou une catégorie ? Que produit exactement « Valider » ?
Je pourrais obtenir :
Votre demande
Quel est le sujet de votre demande ? *
[ Je souhaite parler d’une refonte de site ]
Vos coordonnées
Nom *
Adresse e-mail *
Téléphone — facultatif
Uniquement si vous souhaitez être rappelé.
Votre message
Parlez-nous de votre projet *
[ Zone de texte ]
[ Envoyer ma demande ]
Puis :
Votre demande a bien été envoyée.
La structure change peu. La principale amélioration vient de la précision apportée autour des champs et de l’action finale.
Pour le travail complet sur les champs, erreurs et parcours, j’ai détaillé le sujet dans mon article consacré à l’UX des formulaires.
Exemple : améliorer un écran vide dans un SaaS
Un utilisateur ouvre pour la première fois l’onglet « Clients » d’un logiciel commercial.
Version initiale :
Aucune donnée disponible.
[ Ajouter ]
Je remplacerais par :
Vous n’avez encore ajouté aucun client.
Ajoutez votre premier client pour centraliser ses coordonnées et vos échanges.
[ Ajouter un client ]
Quelques semaines plus tard, le même utilisateur applique un filtre qui exclut tous ses clients.
Le bon message n’est plus le même :
Aucun client ne correspond à ces filtres.
[ Réinitialiser les filtres ]
Le composant visuel peut rester identique. La situation doit être correctement nommée.
Les erreurs que je rencontre le plus souvent
Utiliser « Valider » pour toutes les actions
Un verbe plus précis indique souvent ce qui va réellement se produire.
Supprimer les labels et tout mettre dans les placeholders
L’information disparaît pendant la saisie.
Afficher des messages techniques
« Erreur 422 » ou « valeur invalide » n’aide pas la majorité des utilisateurs à corriger le problème.
Écrire une aide qui répète le champ
Le texte supplémentaire n’est utile que s’il apporte une information supplémentaire.
Faire de l’humour pendant une situation stressante
Un ton léger peut fonctionner ailleurs dans l’interface. Pas nécessairement lors d’un paiement refusé.
Changer de vocabulaire entre deux écrans
Les synonymes créent parfois de faux concepts.
Expliquer chaque icône avec un tooltip
Si l’interaction est importante et difficile à comprendre, un libellé visible peut être plus efficace.
Oublier les états de succès
L’utilisateur doit savoir si sa sauvegarde, son envoi ou sa modification a été prise en compte.
Utiliser « Aucun résultat » pour toutes les situations
Première utilisation, filtre trop restrictif et panne de chargement ne racontent pas la même chose.
Remplir la maquette avec du faux texte puis écrire la microcopy à la fin
La vraie formulation influence directement la taille et parfois la structure du composant.
Ma méthode pour travailler la microcopy
Je commence par parcourir l’interface comme une succession de décisions.
À quel moment l’utilisateur doit-il choisir ? Quand doit-il fournir une information ? Où peut-il faire une erreur ? Qu’attend-il après son clic ?
Écrire d’abord les actions importantes
Boutons principaux, confirmations et actions destructives sont prioritaires parce qu’ils influencent directement le parcours.
Travailler ensuite les erreurs
Je teste volontairement de mauvaises valeurs, des champs vides et des cas limites. Le parcours idéal ne montre qu’une partie de la microcopy.
Vérifier les états vides
Première utilisation, absence de résultat et absence de données après filtrage doivent être distinguées.
Relire le vocabulaire à l’échelle du produit
Je cherche les synonymes non intentionnels et les actions qui changent de nom entre deux écrans.
Tester les textes dans les composants
La formulation finale doit être visible dans Figma ou dans le prototype. C’est le seul moyen de voir si elle tient correctement sur desktop et mobile.
Retirer ce qui n’aide pas
Si un texte d’aide répète le label ou si un tooltip explique quelque chose déjà évident, je le supprime.
Ce travail appartient pleinement à la conception UX/UI. Le texte est une partie du composant, au même titre que sa taille ou son comportement.
Auditer rapidement les textes d’une interface
Je commence par chercher quelques mots récurrents :
Valider, OK, Erreur, En savoir plus, Aucun résultat.
Ils ne sont pas automatiquement mauvais. Ils méritent simplement une vérification.
Je parcours ensuite les formulaires en provoquant des erreurs. J’ouvre les listes vides. Je lance une recherche improbable. Je vérifie une suppression et une sauvegarde.
Beaucoup de microcopy n’apparaît que dans ces états secondaires.
Je termine par le vocabulaire général : le même objet garde-t-il le même nom ? Les boutons utilisent-ils des verbes cohérents ? Les messages annoncent-ils réellement ce qui vient de se passer ?
Une demi-heure suffit souvent pour identifier plusieurs formulations qui créent des hésitations évitables.
FAQ sur la microcopy UX
Qu’est-ce que la microcopy en UX ?
La microcopy regroupe les textes courts liés aux interactions et aux états d’une interface : boutons, labels, instructions, messages d’erreur, confirmations et états vides.
Quelle différence entre microcopy et UX writing ?
La microcopy désigne plus précisément ces petits textes. L’UX writing couvre plus largement la conception des contenus d’un produit numérique, son vocabulaire, son ton et la cohérence des textes dans l’ensemble du parcours.
Faut-il éviter le mot « Continuer » ?
Non. Il fonctionne bien dans un parcours où l’étape suivante est évidente. Une formulation plus précise devient préférable lorsqu’une action engage l’utilisateur, notamment un paiement ou une publication.
Peut-on utiliser un placeholder comme label ?
Le W3C recommande de conserver un vrai label. Le placeholder disparaît pendant la saisie et ne doit pas remplacer l’intitulé du champ.
Comment rédiger un message d’erreur ?
Le message doit identifier le problème et, lorsque c’est possible, expliquer comment le corriger. « Saisissez la date au format JJ/MM/AAAA » apporte plus d’aide que « Format invalide ».
Peut-on mettre de l’humour dans les messages d’interface ?
Oui lorsque le contexte s’y prête. Dans une situation bloquante ou stressante, la compréhension de l’erreur et de la prochaine action doit rester prioritaire.
Que faut-il écrire dans un état vide ?
Il faut d’abord expliquer pourquoi rien n’est affiché. Si une action pertinente existe, elle peut être proposée directement : créer un premier projet, ajouter un client ou réinitialiser des filtres.
Pourquoi utiliser toujours les mêmes termes ?
Un changement de mot peut faire croire à l’existence d’un autre objet ou d’une autre action. Un vocabulaire stable facilite l’apprentissage de l’interface.
Quand travailler la microcopy ?
Dès les wireframes et les prototypes. Les vrais textes influencent la compréhension du parcours et les dimensions des composants.
Sources et ressources
- W3C – Labeling Controls : labels et identification des champs.
- W3C – Form Instructions : instructions, formats attendus et utilisation du placeholder.
- W3C – Validating Input : validation et identification des erreurs.
- W3C – User Notification : erreurs, succès et notifications.
- GOV.UK Design System – Button : rédaction des boutons et actions destructives.
- GOV.UK Design System – Error message : rédaction des messages d’erreur.
- GOV.UK Design System – Question pages : labels, textes d’aide et formulation des questions dans les formulaires.
À lire également sur TooNetCreation
- UX et UI : quelles différences et pourquoi les deux sont indispensables à un site web ?
- Qu’est-ce qu’un wireframe ? Définition, utilité et méthode pour concevoir un site web
- Hiérarchie visuelle : comment organiser une page web pour guider l’utilisateur ?
- Comment construire un parcours utilisateur efficace sur un site web ?
- UX des formulaires web : comment réduire les frictions et les abandons ?
- UX mobile : pourquoi adapter l’expérience et pas seulement réduire la maquette ?
- Navigation UX : comment concevoir un menu qui aide vraiment l’utilisateur à trouver son chemin ?
- Conception UX/UI et expérience utilisateur
