Formulaires et messages d'erreur : les bonnes pratiques

Un formulaire ergonomique demande le moins d'informations possible, dans l'ordre où l'utilisateur les a en tête, avec un libellé visible et une aide pour chaque champ ; il prévient les erreurs plutôt que de les reprocher et, quand une erreur arrive, il dit où elle est et comment la corriger, sans rien effacer. Ce chapitre donne les règles pour structurer un formulaire, choisir les bons champs, valider au bon moment et rédiger des messages d'erreur utiles, puis les applique au formulaire de réservation de Prêt'Matos.

Avant le formulaire : chaque champ doit se justifier

Le formulaire est l'endroit où les utilisateurs abandonnent, se trompent et appellent le support. Chaque champ ajouté coûte du temps et une occasion d'erreur. Pour chacun, pose deux questions : en a-t-on vraiment besoin pour rendre le service ? et le sait-on déjà ?

Dans Prêt'Matos, le salarié est connecté avec son compte de l'entreprise : son nom, son service et son adresse sont connus, il ne faut pas les redemander (critère de concision). Il reste trois informations : le matériel (déjà choisi sur la fiche), la période, et un motif facultatif qui aide la logistique à arbitrer quand deux demandes se chevauchent.

Structurer le formulaire

Une seule colonne. L'œil descend le long des champs sans se demander dans quel ordre les lire. Deux colonnes font sauter des champs et cassent au zoom ou sur téléphone. Seule exception : deux champs courts et indissociables, comme la date de retrait et la date de retour, peuvent tenir côte à côte sur un grand écran.

Les libellés au-dessus des champs. C'est la disposition la plus rapide à parcourir, la seule qui fonctionne sur un téléphone et avec un fort zoom, et celle qui laisse la place aux libellés longs et aux traductions.

Des groupes nommés. Les champs qui vont ensemble forment un groupe avec un titre (en HTML, un fieldset et sa legend) : « Période du prêt » réunit les deux dates. Un long formulaire se découpe en étapes, avec un indicateur « Étape 2 sur 3 » (critère de guidage).

L'ordre de la tâche. Les champs suivent la façon dont l'utilisateur pense sa demande : quoi, puis quand, puis pourquoi. Pas l'ordre des colonnes de la table reservation.

Des boutons qui disent ce qu'ils font. Le bouton principal porte un verbe et son objet (« Confirmer la réservation », « Enregistrer le retour »), pas « OK » ni « Valider ». Il n'y en a qu'un par formulaire, visuellement dominant, placé à la fin des champs, là où l'utilisateur arrive. L'action secondaire (« Annuler ») est visible mais discrète. Le bouton « Réinitialiser » qui efface tout est à bannir : personne n'en a besoin, et tout le monde le clique un jour par erreur.

Choisir le bon type de champ

Le bon champ empêche des erreurs avant même la saisie (critère de protection contre les erreurs) et, sur un téléphone, ouvre le bon clavier.

Libellés, aides et exemples

Un libellé visible pour chaque champ, toujours. Le texte grisé à l'intérieur du champ (l'attribut placeholder) ne remplace pas un libellé : il disparaît dès qu'on tape, si bien qu'on ne sait plus ce qu'on remplissait ; il est souvent trop pâle pour être lu ; et un champ qui contient du texte gris ressemble à un champ déjà rempli.

Une aide sous le libellé quand le champ a une contrainte. « 15 jours au maximum », « Format : JJ/MM/AAAA », « Le numéro est sur l'étiquette collée sous le matériel ». L'aide est écrite avant l'erreur, pas révélée par elle.

Champs obligatoires et facultatifs. Si presque tous les champs sont obligatoires, signale plutôt les facultatifs (« Motif (facultatif) ») et dis-le en tête du formulaire. Sinon, marque les obligatoires d'un astérisque expliqué en tête (« Les champs marqués * sont obligatoires ») et déclare-les comme tels dans le code (required), pour que les lecteurs d'écran l'annoncent.

Accepter les saisies naturelles. Un numéro de téléphone tapé avec des espaces ou des points, une adresse électronique avec une majuscule ou un espace à la fin : nettoie la saisie au lieu de la refuser. Chaque refus d'une saisie compréhensible est une erreur que tu fabriques (critère de compatibilité).

Valider au bon moment

La validation dit à l'utilisateur si sa saisie est acceptable. Trop tôt, elle l'interrompt ; trop tard, elle l'oblige à revenir en arrière.

Trois règles accompagnent ce tableau.

• Pas d'erreur sur un champ qu'on n'a pas fini de remplir : afficher « adresse invalide » après la première lettre agace et inquiète.
• Une erreur disparaît dès qu'elle est corrigée : une fois qu'un message est affiché, revérifie le champ à chaque frappe pour l'effacer aussitôt.
• La validation du navigateur est un confort, celle du serveur est une obligation. N'importe qui peut envoyer une requête à l'API sans passer par le formulaire : le serveur revérifie tout, comme l'explique le cours sécurité applicative.

Rédiger un message d'erreur utile

Un bon message d'erreur a quatre qualités.

1. Visible : placé juste sous le champ concerné, et rappelé en haut du formulaire quand il y a plusieurs erreurs.
2. Explicite : il dit quel champ pose problème et pourquoi, dans les mots de l'utilisateur.
3. Constructif : il dit comment corriger, avec un exemple ou la valeur acceptable.
4. Courtois : il décrit la situation sans accuser l'utilisateur, sans jargon technique, sans majuscules ni points d'exclamation.

Il doit aussi être perceptible sans la couleur : un texte, éventuellement précédé d'une icône, et pas seulement une bordure rouge, que ne distinguent ni une personne daltonienne ni un lecteur d'écran.

Voici des messages relevés dans des applications, et leur réécriture pour Prêt'Matos. L'application vouvoie ses utilisateurs : c'est un choix de l'équipe, appliqué à tous les textes (critère d'homogénéité).

Quand un formulaire long contient plusieurs erreurs après l'envoi, affiche en haut un récapitulatif (« 2 erreurs empêchent l'envoi : »), avec un lien vers chaque champ, et place le focus dessus pour que les utilisateurs de lecteur d'écran l'entendent. Quand l'erreur vient du serveur ou du réseau, affiche un message global, conserve tout ce qui a été saisi et propose de réessayer.

Prévenir plutôt que corriger

Le meilleur message d'erreur est celui qu'on n'a pas besoin d'afficher (heuristique 5 de Nielsen).

• Contraindre la saisie : le calendrier n'autorise pas une date passée ; la date de retour ne peut pas précéder la date de retrait ni la dépasser de plus de 15 jours ; les jours où le matériel est déjà réservé sont grisés, avec la raison au survol ou au focus.
• Proposer de bonnes valeurs par défaut : le matériel de la fiche consultée, la date du jour pour un retour.
• Doser les confirmations : une confirmation (« Supprimer définitivement PC-07 du catalogue ? ») se justifie pour une action rare et irréversible. Pour une action fréquente, une confirmation systématique finit par être cliquée sans être lue ; mieux vaut permettre de défaire pendant quelques secondes (« Retour de PC-07 enregistré. Annuler »).
• Empêcher le double envoi : pendant l'envoi, le bouton affiche « Envoi en cours… » et ne réagit plus ; le serveur, de son côté, refuse proprement une deuxième réservation identique.
• Ne jamais perdre la saisie : après une erreur, un rechargement de page ou une déconnexion, l'utilisateur retrouve ce qu'il avait tapé.

Après l'envoi : confirmer et dire la suite

Le succès mérite autant de soin que l'erreur. Le message de confirmation récapitule ce qui a été enregistré et dit ce qui se passe ensuite :

Réservation confirmée : vidéoprojecteur VP-01, du mercredi 24/03 au vendredi 26/03/2027. À retirer au stock, bâtiment B, de 8 h à 17 h. Vous recevrez un rappel la veille du retour.

Pour Mathis, cette seule phrase aurait évité le point le plus bas de son parcours (chapitre 4).

Des formulaires honnêtes

Certaines interfaces sont conçues pour pousser l'utilisateur à faire ce qu'il ne veut pas : on les appelle interfaces trompeuses (dark patterns). Case d'inscription à la lettre d'information cochée d'avance, bouton « Refuser » minuscule et grisé à côté d'un grand « Accepter », formule culpabilisante (« Non merci, je préfère payer plus cher »), abonnement en un clic mais résiliation en dix écrans.

Ce n'est pas seulement contraire à l'ergonomie (contrôle explicite, compatibilité avec les intentions de l'utilisateur), c'est souvent illégal. Un consentement au sens du RGPD doit résulter d'un acte positif : une case cochée d'avance ne vaut pas consentement, comme l'a jugé la Cour de justice de l'Union européenne en 2019. La CNIL exige que refuser les cookies soit aussi simple que les accepter (cookies et traceurs). Et le règlement européen sur les services numériques (DSA) interdit aux plateformes en ligne de concevoir leurs interfaces de façon à tromper ou manipuler leurs utilisateurs (LCEN et DSA).

Le formulaire de réservation de Prêt'Matos en HTML

Voici l'écran ECR3 « Réserver » écrit en HTML. Il applique les règles du chapitre ; le chapitre 10 en fait un composant React avec la validation et les messages.

<main>
  <h1>Réserver le vidéoprojecteur VP-01</h1>
  <p>Tous les champs sont obligatoires, sauf le motif.</p>

  <form action="/reservations" method="post">
    <input type="hidden" name="materiel" value="VP-01">

    <fieldset>
      <legend>Période du prêt</legend>
      <p id="aide-periode">
        15 jours au maximum, premier et dernier jour compris.
        Retrait et retour au stock, bâtiment B, de 8 h à 17 h.
      </p>

      <label for="debut">Date de retrait</label>
      <input type="date" id="debut" name="debut" required
             min="2027-03-08" aria-describedby="aide-periode">

      <label for="fin">Date de retour</label>
      <input type="date" id="fin" name="fin" required
             min="2027-03-08" aria-describedby="aide-periode">
    </fieldset>

    <label for="motif">Motif (facultatif)</label>
    <p id="aide-motif">Par exemple : présentation chez un client. 100 caractères au maximum.</p>
    <input type="text" id="motif" name="motif" maxlength="100"
           aria-describedby="aide-motif">

    <button type="submit">Confirmer la réservation</button>
    <a href="/catalogue/VP-01">Annuler</a>
  </form>
</main>

Sans JavaScript, ce formulaire fonctionne déjà : le navigateur vérifie les champs obligatoires et les dates, puis le serveur revérifie tout. Le script du chapitre 10 remplace les bulles natives du navigateur par les messages rédigés plus haut.

Exercices