Comment rédiger les messages d’erreur de validation d’un formulaire

Une personne saisit une adresse e-mail, passe au champ suivant et reçoit une correction utile. Une autre voit presque la même phrase pendant qu’elle écrit encore et se demande ce qu’elle a fait de travers. Les mots peuvent être identiques. L’expérience ne l’est pas.

C’est ce qui rend les messages d’erreur de validation étonnamment difficiles à concevoir. Une phrase plus chaleureuse ne rattrape pas un déclenchement impatient, et une explication précise ne sert à rien si elle désigne la mauvaise réponse. Le vrai travail consiste à déterminer ce que le système sait, quand il doit intervenir et ce que la personne peut faire ensuite.

Il existe des enseignements solides à reprendre, mais ils ne convergent pas tous vers une règle universelle. Les recherches sur le commerce en ligne, les recommandations des services publics et les expériences sur les formulaires d’inscription n’accordent pas le même poids à l’interruption et au retour précoce. Comprendre cette différence est plus utile que collectionner des messages d’erreur supposés parfaits.

Ce que les vrais utilisateurs nous apprennent sur la validation

Dans son rapport de janvier 2024 sur les tests de validation avec messages près des champs menés par Baymard, Edward Scott décrit une participante chez L.L.Bean qui oublie le signe @ dans une adresse e-mail. Le message apparaît après son passage au champ suivant ; elle corrige en quelques secondes. Chez Etsy, un autre participant voit une erreur dès qu’il entre dans un champ d’adresse encore vierge et a l’impression d’être réprimandé avant même d’avoir répondu. REI fournit un autre exemple de correction : l’erreur du cryptogramme de carte disparaît lorsque le participant ajoute le troisième chiffre manquant.

Ces observations historiques montrent pourquoi « affiche les messages de validation près des champs » est une description incomplète. Le moment où le message apparaît et celui où il disparaît peuvent compter autant que sa formulation.

Pour nos propres revues de formulaires, j’en ferais une question : le message répond-il à une action que la personne estime avoir terminée ? Cliquer sur Continuer exprime clairement cette intention. Quitter un champ, parfois. Placer le curseur dans un champ vide, généralement pas. L’interface a besoin d’une raison d’interrompre, pas simplement d’une valeur qui ne respecte pas encore une règle.

Un contrepoint utile vient de l’étude de 2009 sur les formulaires d’inscription menée par Luke Wroblewski et Etre. Vingt-deux participants ont essayé six variantes. Par rapport à la version témoin, la meilleure version affichant les messages de validation près des champs a produit, selon l’étude, une hausse de 22 % du taux de réussite et une baisse de 42 % du temps de réalisation. Un participant expliquait qu’il préférait être informé de ses erreurs au fur et à mesure. Pourtant, les coches vertes à côté de réponses familières ont aussi créé une confusion sur ce que le système avait réellement vérifié.

L’enseignement le plus utile de cette étude concerne l’incertitude : une personne qui choisit un nom d’utilisateur disponible a besoin d’une information détenue par le système ; celle qui saisit son propre nom n’a pas forcément besoin d’être rassurée. Je donnerais la priorité aux retours qui lèvent une inconnue, plutôt que de distribuer uniformément des symboles d’approbation dans tout le formulaire.

Pourquoi GOV.UK choisit un autre moment

Le modèle de validation GOV.UK recommande d’attendre que la personne essaie de continuer ou d’envoyer, plutôt que de valider lorsqu’elle quitte un champ. Il conseille aussi de conserver les réponses saisies, de placer un récapitulatif des erreurs en haut, d’y déplacer le focus et de signaler les erreurs près des champs concernés. Une validation plus précoce doit être étayée par une recherche utilisateur.

La différence avec les exemples du commerce en ligne mérite de rester visible. Une étape courte avec une seule question rend la correction après envoi relativement locale : la réponse est encore sous vos yeux. Dans un long parcours de paiement, le champ incorrect peut être loin derrière au moment d’envoyer.

Si je passais en revue un parcours de réservation d’atelier, je commencerais par la structure de la tâche. Sur une page consacrée à une seule question de date, Continuer est un moment raisonnable pour expliquer qu’un choix n’est pas disponible. Sur une page regroupant coordonnées, besoins d’accessibilité, nombre de places et informations de facturation, attendre le bas peut imposer une longue remontée dans le formulaire. Cela ne justifie pas automatiquement une validation immédiate partout. Cela justifie de tester des retours précoces ciblés.

Il faut aussi distinguer l’aide de l’erreur. Une liste d’exigences de mot de passe peut expliquer les règles pendant la saisie sans traiter chaque condition incomplète comme un échec. Une indication de date peut expliquer la période de réservation avant qu’une valeur soit saisie. Une aide utile n’a pas besoin d’attendre l’envoi, et une aide précoce n’a pas besoin de ressembler à un avertissement rouge.

Consignez le déclencheur utilisé pour chaque champ. Sinon, « nous affichons les messages de validation près des champs » peut cacher trois comportements différents implémentés par trois personnes.

Rédigez la correction que le système peut réellement justifier

« Saisissez une adresse e-mail valide » clôt souvent la discussion alors qu’il devrait l’ouvrir. Que signifie valide ici ? Manquant, mal formé, indisponible et non vérifié sont des états différents. Les traiter comme des synonymes produit des messages assurés qui n’expliquent pas l’action suivante.

Pour un formulaire d’atelier fictif, un champ de contact vide pourrait indiquer : « Saisissez une adresse e-mail pour recevoir la confirmation de réservation. » Si le texte saisi ne contient pas de signe @, « Saisissez une adresse e-mail contenant un signe @ » décrit un problème observable. Aucune de ces phrases ne prouve que la boîte existe ou appartient à la personne. Cela exigerait une vérification distincte.

On pourrait être tenté d’écrire un message extrêmement précis pour chaque faute possible. Je l’éviterais, sauf si la logique de validation permet de les distinguer de manière fiable. Affirmer que le domaine est mal orthographié n’aide pas une personne qui utilise un domaine inhabituel mais légitime. Lorsque le système doute, une suggestion facultative peut être préférable à un refus catégorique. L’équipe doit s’accorder sur cette distinction avant de valider le texte.

Voici un petit inventaire de messages pour cet exemple d’atelier. Chaque ligne commence par une condition, car un même champ peut nécessiter plusieurs messages.

La dernière ligne demande délibérément plus au produit qu’une phrase. Une consigne de vérification du statut n’est pertinente que si le service offre un moyen utilisable de le faire. Sinon, le design a besoin d’une autre issue définie avec l’ingénierie et l’assistance. Le texte doit révéler cette décision manquante plutôt que la masquer par « Veuillez réessayer ».

Rendez un formulaire long navigable après un échec

Imaginez appuyer sur Continuer près du bas d’une page de réservation. Deux champs près du haut ont maintenant des erreurs, mais la fenêtre montre toujours le bouton. Une bordure rouge quelque part hors écran ne suffit pas. La personne doit découvrir que l’action a échoué et revenir aux réponses qui demandent son attention.

Dans notre exemple d’atelier, un récapitulatif peut nommer les problèmes de nombre de places et de date, chaque entrée renvoyant vers son champ. Le texte local reste ensuite près de la réponse pendant la correction. Cette répétition a un rôle : le récapitulatif aide à se déplacer ; le message local aide à modifier. Donner des formulations différentes aux deux endroits ajoute un travail d’interprétation inutile.

Le récapitulatif doit aussi rester sélectif. Une adresse de contact qui a passé les vérifications pertinentes n’appartient pas à la liste d’erreurs. Il ne faut pas non plus vider tout le formulaire pour obtenir un état de réinitialisation propre. Voir la réponse précédente aide à comprendre ce qui s’est passé et à ne changer que le nécessaire. Pour les informations sensibles, la conservation exige une décision produit et de sécurité propre ; ne promettez pas que chaque champ sera toujours mémorisé.

C’est là que la revue statique doit devenir une revue d’interaction. Suivez un lien du récapitulatif au clavier. Vérifiez où arrive le focus, si le libellé du champ reste visible sous un en-tête fixe et si son explication est accessible une fois le champ atteint. Faites ensuite la correction et envoyez de nouveau. Une capture peut montrer un encadré rouge ; elle ne prouve pas que ce parcours fonctionne.

Sur mobile, examinez la même séquence avec le clavier ouvert. Un message peut très bien tenir dans un cadre de bureau et se retrouver sous le clavier sur téléphone. Les erreurs longues doivent passer à la ligne, pas se réduire en caractères illisibles. Je préfère consacrer une ligne de plus à la correction plutôt que demander à la personne de zoomer sur l’instruction dont elle a besoin pour finir.

Le message doit changer lorsque les faits changent

Une erreur de revue courante consiste à n’approuver que deux vues : normale et en erreur. La difficulté se situe souvent entre les deux. La personne modifie sa réponse, le problème initial disparaît, mais le message rouge reste. De son point de vue, la correction a peut-être échoué.

Dans le formulaire d’atelier, supposons que quatre places ont été demandées alors qu’il n’en reste que deux. Passer la quantité à deux devrait déclencher une nouvelle vérification de la règle applicable. Modifier la date est différent : cela change le stock dont dépend la règle. Un avertissement sur la séance précédente ne peut pas simplement rester rattaché à la nouvelle. Cette relation compte davantage que l’apparence de la bordure rouge.

Je demanderais trois états supplémentaires dans la transmission : vérification en cours, accepté pour cette étape et vérification impossible. « Vérification de la disponibilité… » ne signifie pas « Deux places disponibles », et aucun des deux ne confirme une réservation. Ces distinctions maintiennent une interface honnête lorsqu’une requête dure plus longtemps que prévu ou qu’une séance se remplit entre deux vérifications.

Il existe aussi un cas limite moins visible. Une personne change deux fois la date, et la première demande de disponibilité se termine après la seconde. Si l’ancienne réponse écrase la nouvelle, l’interface peut afficher une réponse parfaitement lisible à la mauvaise question. Les notes de design doivent exiger que les résultats correspondent à la sélection actuelle ; l’ingénierie choisira comment le garantir.

Lorsque vous examinez les animations ou les traitements de chargement, gardez cette distinction d’états à l’esprit. Le but n’est pas de donner de l’activité à la transition. Il est d’éviter qu’une personne interprète un ancien résultat comme un nouveau. Si le système ne peut pas vérifier maintenant, une explication neutre est plus exacte que de marquer sa réponse comme invalide.

Une panne du service n’est pas une mauvaise réponse

Dans un parcours de réservation, l’erreur rédactionnelle la plus coûteuse consiste peut-être à demander de corriger une réponse qui n’a jamais été fausse. Une requête échouée peut signifier que l’entrée a été rejetée, que le serveur était indisponible ou que l’issue reste inconnue. Ces possibilités demandent des suites différentes.

Prenez un délai d’attente dépassé après avoir appuyé sur Réserver. La demande n’a peut-être pas atteint le service. Elle a peut-être aussi abouti alors que la réponse s’est perdue. Sans savoir lequel s’est produit, « Votre réservation a échoué » est trop affirmatif. Un second envoi immédiat peut être sans conséquence ou créer un doublon. Le produit a besoin d’une décision explicite sur cette incertitude.

Pour notre exemple, j’examinerais le parcours de reprise avec un ingénieur avant de polir le message. Le service peut-il retrouver l’issue à partir d’une référence de demande ? Une demande répétée renvoie-t-elle sans risque le résultat initial ? L’assistance peut-elle retrouver la tentative ? Quelles réponses restent sur la page ? Ces questions déterminent si la bonne action est de vérifier le statut, de réessayer sans risque ou de contacter l’assistance avec une référence.

Cela ne justifie pas d’insérer les détails techniques internes dans le message d’erreur. Le lecteur n’a pas besoin d’un cours sur les défaillances réseau. Il a besoin d’une explication honnête de ce qui est connu et d’une suite qui fonctionne. Une référence de demande peut être utile si l’assistance sait l’exploiter ; un code d’erreur inexpliqué n’est qu’un problème de plus à interpréter.

Les bonnes pratiques de validation comprennent le parcours de reprise

Dans OpenDesign, un aperçu HTML pris en charge peut aider l’équipe à comparer le champ normal, l’erreur et l’état corrigé. Utilisez des valeurs réalistes et un message long, examinez une fenêtre étroite et commentez l’élément précis à modifier. Testez ensuite la même séquence avec le service backend fonctionnel, le parcours clavier et les annonces du lecteur d’écran.

Une petite séance de revue peut en apprendre davantage qu’un nouveau cycle d’adjectifs. Donnez une tâche concrète, comme réserver quatre places d’atelier, et laissez la personne rencontrer le conflit de capacité. Demandez-lui ce qu’elle pense qu’il s’est passé et ce qu’elle ferait ensuite. Évitez d’expliquer d’abord le sens voulu : vous supprimeriez l’ambiguïté même que vous cherchez à découvrir.

Observez aussi attentivement ce qu’elle fait après la correction que ce qu’elle dit du message. Si elle relit sans cesse l’avertissement, il n’a peut-être pas disparu. Si elle modifie un e-mail valide après un délai d’attente du service, l’interface attribue peut-être le problème au mauvais endroit. Si elle recommence tout le formulaire, le parcours de reprise est peut-être plus difficile à trouver que la tâche initiale.

Dans un service en production, les envois répétés et les boucles de correction peuvent indiquer où enquêter. Ils n’expliquent pas automatiquement la cause. Un nombre élevé d’erreurs peut venir de consignes confuses, d’une règle trop restrictive, d’un stock indisponible ou d’un défaut d’implémentation. Rapprochez la séquence d’événements des comportements observés et évitez de collecter les réponses personnelles brutes uniquement pour diagnostiquer le formulaire.

Avant de valider l’exemple, je suivrais cette courte séquence :

1. Saisir une réponse incomplète et observer quand le retour apparaît.
2. Envoyer avec deux erreurs et atteindre les deux champs depuis le récapitulatif.
3. Corriger une réponse et confirmer que les valeurs sans rapport restent présentes.
4. Modifier une réponse dont d’autres dépendent, comme la date de l’atelier, et examiner le nouveau résultat.
5. Rencontrer un service indisponible et suivre son parcours de reprise.

La dernière vérification porte sur le résultat réussi. La confirmation affiche-t-elle la date et la quantité corrigées ? La personne peut-elle savoir si une réservation existe ? Un formulaire n’a pas retrouvé un fonctionnement correct simplement parce que le texte rouge a disparu.

De bons messages d’erreur de validation laissent moins de choses à interpréter. Les exemples du secteur sont utiles parce qu’ils révèlent où cette interprétation se dégrade : avant qu’une réponse soit terminée, après une correction ou lorsque l’interface prétend savoir plus qu’elle ne sait. Reprenez le raisonnement, testez-le dans votre propre tâche et faites découler la phrase du comportement que vous pouvez réellement fournir.