Les textes d’interface sont les mots qui accompagnent une action : nom d’un champ, aide à la saisie, bouton, message d’erreur ou confirmation. Ils doivent permettre de comprendre ce qui est demandé et ce qui vient réellement de se passer.
Améliorer ces textes ne consiste pas à ajouter une promesse sur chaque écran. Une formulation chaleureuse reste utile seulement si elle décrit le bon état. Les exemples de ce guide sont illustratifs : ils ne définissent ni un délai de réponse ni les conditions d’AskOptimize.
Partir d’une tâche et des états réellement disponibles
Choisissez un parcours, par exemple envoyer une demande ou choisir une offre. Listez les écrans et les états : avant la saisie, information manquante, envoi en cours, échec et réception confirmée. Associez chaque texte à un événement que le système peut effectivement reconnaître.
Une animation ou une phrase « C’est presque terminé » ne démontre pas l’avancement du traitement. De même, un clic sur « Envoyer » n’est pas une preuve de réception. Un message de confirmation doit correspondre à une réponse technique vérifiée, avec des limites compréhensibles si la suite est encore inconnue.
Un petit tableau de travail peut associer écran, état, texte actuel, texte proposé et contrôle attendu. Il sert à repérer les contradictions sans changer la composition visuelle ni réécrire les textes de présentation de toute la page.
Nommer les champs et expliquer ce qui est attendu
Un champ demande un nom compréhensible et, si nécessaire, une indication sur le format ou l’information attendue. Le W3C présente les labels et instructions de saisie comme une aide pour identifier ce qui doit être renseigné. Une consigne utile doit rester accessible pendant l’utilisation du formulaire.
Exemple illustratif : « Adresse e-mail » identifie le champ ; une aide distincte explique à quoi cette adresse sert. Un exemple peut préciser le format, mais il ne remplace pas le nom du champ. Les informations facultatives doivent être distinguées des informations nécessaires au traitement prévu.
Ne demandez pas une donnée uniquement parce que la maquette prévoit un emplacement. Vérifiez sa nécessité avec le responsable du parcours. Toute affirmation sur l’utilisation ou la confidentialité doit correspondre aux règles réellement validées, pas à une phrase rassurante copiée ailleurs.
Décrire une erreur sans effacer le travail effectué
Une erreur doit permettre d’identifier ce qui bloque. Le W3C explique l’identification textuelle des erreurs de saisie : la personne doit pouvoir comprendre l’élément concerné et la nature du problème. La couleur ou une icône seule ne suffit pas à apporter cette explication.
Distinguez une saisie invalide d’une panne d’envoi. Dans le premier cas, le texte peut préciser le champ à corriger. Dans le second, il ne faut pas demander arbitrairement de remplacer une adresse correcte ni affirmer que l’équipe répare déjà le serveur si cet état n’est pas connu.
Exemple illustratif : « L’envoi n’a pas été confirmé. Votre message est conservé dans le formulaire. » n’est utilisable que si cette conservation est effectivement implémentée et testée. Le texte proposé et le comportement doivent être vérifiés ensemble. Une formulation exacte ne peut pas remplacer une fonction absente.
Différencier attente, réussite et prochaine étape
Pendant une attente, annoncez ce qui est connu sans inventer une progression. Après une réponse positive, expliquez le résultat confirmé. Si l’envoi a été accepté mais que la remise au destinataire n’a pas été vérifiée, ces deux états ne doivent pas être présentés comme équivalents.
Le W3C traite les messages d’état accessibles aux technologies d’assistance, notamment lorsqu’une mise à jour n’entraîne pas de changement de contexte. La réception doit donc porter sur le comportement du message, pas seulement sur sa présence dans une capture.
Une prochaine étape peut être indiquée si elle est réelle : consulter un document, revenir au projet ou attendre un échange selon les modalités convenues. Évitez un délai de réponse inventé ou une affirmation « paiement effectué » fondée uniquement sur l’ouverture d’un écran de succès.
Garder les mêmes mots pour les mêmes actions
Choisissez un vocabulaire partagé entre la page, le formulaire et la confirmation. Si la personne demande une proposition, n’appelez pas ensuite cette demande une inscription validée. Une offre sur mesure ne doit pas sembler achetée lorsque seul le premier contact a été transmis.
Le ton peut rester direct et humain. Il dépend de la marque et des personnes concernées, pas d’une règle universelle sur le tutoiement ou le vouvoiement. Les textes courts gagnent à conserver l’information essentielle plutôt qu’à chercher systématiquement une formule originale.
Sur une page de présentation des prix, les mots doivent distinguer le choix d’une offre, la demande d’un devis et un éventuel paiement. Ici, le sujet est le texte associé aux états et aux actions ; il ne remplace pas la présentation complète du service.
Recevoir les textes dans leur parcours complet
Relisez les formulations sur téléphone et ordinateur, dans les thèmes disponibles et avec des contenus longs. Examinez les accents, retours à la ligne et libellés tronqués. Testez le clavier et les annonces avec les outils prévus, en indiquant ce qui n’a pas été contrôlé.
Un scénario de recette doit préciser l’action, le résultat attendu et la preuve observée. Les états d’erreur et de réussite demandent un environnement et des autorisations adaptés. Sans essai de bout en bout, une lecture du code ou une capture ne démontre pas la livraison d’un message.
Un texte plus compréhensible peut réduire une hésitation sans produire une vente supplémentaire. Distinguez ce qui a été réécrit, ce qui fonctionne et ce qui reste à mesurer. Mon accompagnement en optimisation de conversion permet de cadrer ces corrections ; partagez le parcours et les messages à reprendre pour définir le travail utile, sans imposer de nouvelle collecte ou de refonte visuelle.
