Concevoir un formulaire de contact qui aide vraiment

Partir des demandes reçues et de leur traitement

Regroupez les demandes habituelles : question, devis, assistance ou proposition. Demandez-vous quelles informations sont indispensables pour orienter chacune et lesquelles peuvent être recueillies dans la réponse. Un champ « budget » obligatoire, par exemple, écarte les personnes qui veulent d’abord comprendre le périmètre ; il faut pouvoir justifier son utilité réelle.

Indiquez clairement le destinataire de la demande et ce que la personne peut attendre ensuite. Ne promettez un délai de réponse que si l’équipe peut le tenir. Si plusieurs services reçoivent les messages, définissez une règle d’orientation interne plutôt que de demander au visiteur de connaître votre organisation.

• Objet de chaque type de demande.
• Champs indispensables et raison de leur collecte.
• Responsable de lecture et de réponse.

Rendre la saisie compréhensible et récupérable

Associez chaque contrôle à un libellé visible, signalez les champs obligatoires et donnez des exemples seulement lorsqu’ils aident à répondre. Une indication placée uniquement dans un placeholder disparaît pendant la saisie. Les explications MDN sur la structure des formulaires montrent le rôle des libellés et des groupes de champs.

Testez au clavier, sur téléphone et avec des textes longs. En cas d’erreur, expliquez le problème près du champ concerné, conservez les valeurs déjà saisies et donnez un chemin clair pour corriger. Vérifiez aussi ce qui arrive si la connexion se coupe ou si l’envoi est répété. Le message de succès doit confirmer l’action sans exposer les données personnelles.

Limiter les données et expliquer leur usage

Collectez les informations utiles au traitement de la demande et expliquez la finalité, les personnes concernées et la manière d’obtenir plus d’informations sur le traitement. La CNIL recommande une information au moment de la collecte, éventuellement avec un premier niveau près du formulaire et un lien vers la politique de confidentialité. Adaptez ces mentions au traitement réellement effectué.

Évitez de demander par défaut des documents sensibles ou un compte pour poser une simple question. Si des pièces jointes sont nécessaires, précisez les formats, la taille et la conservation prévus. Les dispositifs antispam doivent être testés pour ne pas empêcher une personne légitime d’envoyer sa demande.

• Information de collecte à jour.
• Données et pièces jointes nécessaires seulement.
• Alternative de contact accessible.

Recetter le parcours jusqu’à la réponse

Envoyez des demandes d’essai avec un champ vide, une adresse mal formée, un texte long et une saisie correcte. Vérifiez le message affiché, la réception au bon endroit, la lisibilité du contenu reçu et la capacité de l’équipe à répondre. Une page de confirmation seule ne prouve pas que le message est arrivé.

Après mise en ligne, contrôlez périodiquement le trajet complet, notamment après un changement d’hébergement, de messagerie ou de protection antispam. Le guide de recette avant publication aide à placer ce test dans l’ensemble des vérifications.

Préparez une petite matrice de recette avec cinq situations : envoi correct, champ obligatoire absent, adresse invalide, interruption réseau et nouvel envoi après attente. Pour chacune, notez l’appareil, l’action, le message affiché, les valeurs conservées et l’état reçu par l’équipe. Utilisez un identifiant de test et des données fictives pour suivre le trajet sans copier de coordonnées personnelles dans le compte rendu.

Le message d’erreur doit expliquer quoi corriger et permettre de reprendre la tâche. Une couleur seule ne donne pas cette instruction. Le tutoriel W3C WAI sur les notifications de formulaire décrit comment associer les erreurs aux champs et rendre les retours compréhensibles. Vérifiez aussi le double clic : il ne doit pas conduire l’équipe à traiter deux fois une même demande.

Distinguer saisie, sélection et envoi confirmé

Dans un formulaire avec suggestions, vérifiez la valeur visible et l’identifiant transmis après sélection puis correction du texte. Une commune affichée ne doit pas conserver par erreur la référence de la proposition précédente. Les commandes secondaires, comme ajouter un document, doivent rester distinctes de l’envoi.

Suivez ensuite attente, échec et réussite. Un message « reçu » exige une confirmation réelle du service. En cas d’échec, les champs doivent pouvoir être repris ; si le résultat est incertain, expliquez comment vérifier plutôt que d’inciter à répéter aveuglément la demande.

Choisir les liens, boutons et actions d’une interface · Concevoir une autocomplétion pour choisir une valeur · Rédiger et annoncer les messages d’état d’une interface

Réduire la ressaisie tout en conservant des libellés et une validation compréhensibles.

Cas fictif : un formulaire de contact distingue nom, adresse électronique et téléphone. Utilisez les jetons adaptés, puis essayez un profil de test enregistré et une saisie manuelle. L’autoremplissage peut produire des valeurs inattendues : contrôlez encore les champs côté serveur. Ne détournez pas autocomplete pour désactiver arbitrairement une aide utile aux personnes.

Exemple fictif : une inscription comporte un contact principal et un autre participant. Deux champs email ne demandent pas forcément la même valeur. Les groupes section-contact email et section-participant email indiquent deux ensembles distincts ; le jeton section- est placé en premier. Cette indication aide l’autoremplissage, sans garantir le comportement de chaque navigateur.

Choisissez aussi le sens du champ : name désigne un nom complet, organization une organisation. Gardez les libellés visibles et acceptez les noms selon les besoins réels, sans imposer arbitrairement un découpage prénom/nom. Testez remplissage automatique, correction manuelle et contrôle serveur : un champ prérempli ne devient ni une coordonnée vérifiée ni une autorisation d’envoyer à une autre personne.

• Les valeurs sont placées dans les bons champs ; les erreurs permettent une correction sans perdre les autres réponses.

Faites défiler le tableau horizontalement pour lire toutes les colonnes. Au clavier, placez le focus sur le tableau puis utilisez les flèches.

• MDN HTML Autocomplete

  Attribut HTML indiquant au navigateur la nature des informations attendues et des indications de remplissage automatique.

Vérifier la demande reçue

Cas proposé : le formulaire affiche un succès alors que son destinataire n’a reçu aucun message. La confirmation à l’écran ne clôt pas le parcours de traitement.

Testez avec des données fictives dans un environnement autorisé. Reliez action, réponse, réception et responsable du suivi ; distinguez échec d’envoi, classement du message et absence de traitement.

• Utiliser une demande fictive identifiable
• Confirmer la réception attendue
• Identifier le responsable du suivi

• Préserver la saisie après erreur

  Rédiger des erreurs de formulaire qui aident à corriger

Ne pas confondre envoi et réception

Une confirmation à l’écran prouve seulement l’état que le serveur a pu confirmer. Testez la réception dans la boîte métier, la possibilité de répondre et les doublons après nouvelle tentative. En cas d’erreur, indiquez une suite utilisable et conservez les champs non sensibles lorsque le contexte le permet.

Écrire quatre messages selon le résultat de l’envoi

Exemple fictif : une demande de maintenance passe par les états ci-dessous. Le message doit dire ce qui est établi et quelle action est possible. Une référence de demande peut aider au suivi ; elle ne constitue pas une preuve de lecture par l’équipe.

Faites défiler le tableau horizontalement pour lire toutes les colonnes. Au clavier, placez le focus sur le tableau puis utilisez les flèches.

• W3C WAI · User Notification

  Ces formulations sont des exemples éditoriaux. Le tutoriel WAI précise les retours de formulaire et l’association des erreurs aux contrôles ; adaptez les termes au traitement réellement assuré.