- Écrire les consignes avant la saisie et rattacher chaque erreur au bon champ.
- Conserver les valeurs utiles et distinguer une erreur de saisie d’une panne.
- Tester la correction jusqu’à la confirmation, avec des données fictives.
Observer un envoi raté du début à la fin
Prenez un formulaire de devis et remplissez-le comme le ferait une personne qui le découvre. Saisissez une adresse incomplète, laissez un champ requis vide et joignez un document trop lourd si cette option existe. Appuyez sur Envoyer. Notez le premier élément que vous voyez, l’endroit où le clavier vous conduit et ce qui reste dans les champs. Une bordure rouge sous le premier écran ne donne guère de piste si le bouton reste tout en bas. Un message général en haut ne suffit pas non plus si le visiteur doit deviner quelle ligne pose problème.
Quand un formulaire refuse une demande, la personne doit savoir ce qui manque, où le corriger et si ce qu’elle a déjà saisi est encore là. Le bon test consiste à provoquer plusieurs erreurs puis à terminer l’envoi sans aide, depuis un téléphone et au clavier. On peut commencer par le formulaire qui reçoit les demandes les plus importantes, sans refaire le reste du site.
Refaites l’exercice avec un collègue à qui vous ne donnez aucune indication. Demandez-lui de verbaliser sa prochaine action. S’il dit « je vais retaper tout le formulaire », regardez si les données ont réellement disparu ou si l’interface le lui laisse croire. Les deux situations méritent une correction différente. Pour choisir les questions utiles avant ce test, partez du guide sur le formulaire de devis qui qualifie la demande sans décourager.
Donner une consigne qu’on peut suivre
Un message comme « format invalide » décrit le problème du point de vue du logiciel. « Saisissez une adresse au format nom@exemple.fr » indique une action. Pour une pièce jointe, annoncez les formats et le poids maximum dès le départ, puis précisez la raison du refus : « Ce fichier dépasse 5 Mo » si c’est la limite réelle du site. Vérifiez que les règles affichées correspondent à celles du serveur. Si les visiteurs peuvent entrer un numéro international, évitez une consigne qui leur impose dix chiffres et les conduit à supprimer l’indicatif.
Gardez des libellés visibles au-dessus des champs. Un exemple inscrit à l’intérieur disparaît dès qu’on commence à écrire et ne remplace pas le nom du champ. Le guide HTML de MDN sur les libellés explique comment associer le texte au contrôle. Le message d’erreur, lui, doit rester proche du champ et lui être associé techniquement. Faites le test au clavier : si vous revenez dans le champ, son nom et la consigne doivent rester compréhensibles, même sans vous fier à la couleur.
Décider où orienter la personne
Sur un formulaire court, signaler l’erreur près du champ peut suffire si elle apparaît dans la zone déjà visible. Sur un parcours plus long, un résumé après la tentative d’envoi peut lister les corrections et proposer un lien vers chacune. Utilisez les mêmes mots dans le résumé et dans le formulaire. Si le résumé dit « Coordonnées invalides » et que le champ s’appelle « Adresse de réponse », la correspondance est floue. Sur mobile, vérifiez que l’en-tête fixe ne recouvre pas le champ quand on suit le lien.
Évitez de déplacer le focus à chaque frappe. Un signalement prématuré peut interrompre quelqu’un qui n’a pas fini de taper son adresse. Après la correction, assurez-vous que le message obsolète disparaît et que l’étape suivante reste accessible. Si la personne revient depuis une autre étape, le récapitulatif doit encore correspondre aux valeurs présentes. Testez ce retour avec les boutons du parcours et avec l’historique du navigateur si le formulaire change de page.
Adapter la réponse au problème réel
| Situation | Réponse à vérifier |
|---|---|
| Champ requis vide | Nommer le champ et indiquer l’action attendue. |
| Pièce refusée | Expliquer la limite et permettre de remplacer seulement le fichier. |
| Connexion interrompue | Signaler que la réception est incertaine et proposer une suite. |
| Demande enregistrée | Confirmer la réception uniquement après confirmation du serveur. |
Un navigateur peut bloquer certaines erreurs de saisie immédiatement, mais le serveur doit aussi contrôler les données reçues. Si un service externe ne répond pas, écrire « corrigez les champs en rouge » envoie la personne dans une impasse. Présentez ce qui est certain et ce qu’elle peut faire : réessayer, ou utiliser un canal de contact alternatif. Ne réaffichez pas un mot de passe, un jeton ou le contenu d’une pièce privée dans le message. Pour le volet technique, consultez le guide sur la sécurisation d’un formulaire de contact.
Une coupure peut arriver après l’enregistrement, mais avant le retour de la confirmation. Un deuxième clic n’est alors pas forcément une deuxième demande intentionnelle. Traitez ce scénario avec l’équipe qui reçoit les messages et avec la personne qui maintient l’intégration. Le guide sur les demandes en double entre WordPress et un CRM détaille ce problème distinct.
Recetter la correction sans toucher aux vraies demandes
Dans un environnement de test, préparez trois cas : un envoi sans erreur, un envoi avec plusieurs champs à corriger et une panne simulée. Pour chacun, notez la réponse affichée, les valeurs conservées et la réception effective. Ajoutez un test au clavier, un test sur petit écran et un essai avec un zoom augmenté. Si un fichier doit être sélectionné à nouveau après une erreur, indiquez-le explicitement. Certains mécanismes de navigation ne peuvent pas rétablir la sélection initiale ; promettre qu’elle est conservée serait trompeur.
Assignez chaque défaut à la bonne personne : les mots et consignes relèvent souvent du contenu ; le focus, la validation et les retours du serveur relèvent de l’intégration. Fixez un critère observable pour fermer chaque correction. Exemple : « après un refus de fichier, je garde mon message et je peux envoyer un document accepté sans revenir au début ». Si plusieurs formulaires partagent le même composant, vérifiez au moins un exemple court et un exemple long avant de généraliser le réglage.
Une fois la recette terminée, vérifiez aussi ce que l’équipe voit après réception. Le suivi des demandes avec Form Monitor relève de cette seconde étape. Commencez par corriger le refus qui oblige aujourd’hui à recommencer : vous aurez un résultat facile à vérifier, sans changer toutes les questions en même temps.
Nicolas Tissot
Gérant de Blue Strat. WordPress, développement web et référencement pour les artisans, TPE et PME.
Découvrir Nicolas Tissot