Bonnes pratiques pour un formulaire de contact qui convertit vraiment

La plupart des formulaires de contact sont conçus à l'envers : les champs s'ajoutent parce que quelqu'un en réunion a pensé que ce serait « utile », pas parce que la personne qui recevra le message en a besoin pour agir. Les formulaires qui convertissent vraiment sont construits dans l'autre sens - réduits à l'essentiel, puis testés sur de vrais appareils et par de vraies personnes qui cherchent à les faire échouer.

Rien de ce qui suit n'est exotique. Ce sont surtout des choses qu'une checklist repérerait, si quelqu'un en suivait une.

Demandez moins que ce que vous croyez nécessaire

Chaque champ d'un formulaire est un point de décision, et un point de décision est une occasion de s'arrêter. Un visiteur en train de taper une vraie demande depuis trois phrases fermera quand même l'onglet plutôt que d'aller chercher un numéro de téléphone ou d'expliquer sur-le-champ « comment avez-vous entendu parler de nous ». Pour la plupart des formulaires de contact, nom, e-mail et message suffisent amplement. Tout le reste est optionnel au mieux, reportable au pire - un numéro de téléphone a sa place dans la réponse, pas comme condition d'accès à la demande.

Si un champ mérite vraiment sa place - une fourchette de budget pour une demande commerciale, par exemple - demandez-vous s'il doit être obligatoire. Un champ obligatoire avec un libellé confus ou une validation floue est un champ obligatoire sur lequel les gens abandonnent.

Des libellés et une validation qui ne pénalisent pas

Un texte de type placeholder n'est pas un libellé. Il disparaît dès qu'on clique dans le champ, donc quiconque est interrompu - ce qui arrive à la plupart des gens, la plupart du temps - perd le seul indice sur ce qu'il était en train de remplir. Cela casse aussi l'autofill dans de nombreux navigateurs, et les lecteurs d'écran l'ignorent souvent complètement. Utilisez un véritable élément <label> pour chaque champ, visible au-dessus ou à côté du champ de saisie, toujours. Le texte placeholder, si vous en utilisez, sert à donner un exemple de format (« jane@company.com »), pas des instructions.

Validez au moment du blur - quand quelqu'un quitte le champ - pas à chaque frappe. Signaler une adresse e-mail comme invalide alors que la personne en est encore à trois caractères ne fait qu'entraîner les gens à ignorer vos messages d'erreur. Les erreurs doivent aussi être précises et rattachées au champ qu'elles décrivent, pas condensées dans une seule bannière « veuillez vérifier le formulaire » qui laisse le visiteur chercher.

Réussissez le mobile - c'est l'essentiel de votre trafic

Un formulaire de contact sur téléphone doit afficher le bon clavier sans qu'on ait à le lui demander deux fois. C'est à ça que servent type et inputmode : type="email" fait apparaître la touche @, et inputmode="tel" affiche un pavé numérique pour un numéro de téléphone. Associez chaque champ à une valeur autocomplete correspondante (autocomplete="email", autocomplete="name") pour que le navigateur puisse proposer de le remplir à partir de données qu'il détient déjà - sur mobile en particulier, l'autofill fait souvent la différence entre un formulaire rempli et un formulaire abandonné.

Les zones tactiles comptent autant que les claviers. Un champ confortable à cliquer avec un curseur peut être réellement difficile à toucher avec un pouce - gardez donc les éléments interactifs généreusement dimensionnés et espacés.

Le champ honeypot, sans pénaliser les vrais visiteurs

Un honeypot est un champ de formulaire invisible pour les humains et irrésistible pour les robots : un champ au nom plausible (« website » ou « company ») qu'une soumission automatisée remplit et qu'un vrai visiteur ne voit jamais. Mal fait, un honeypot pénalise justement les personnes qu'il est censé protéger - display: none et type="hidden" sont tous deux filtrés par les robots bien conçus qui lisent le CSS calculé, tandis que certains lecteurs d'écran et extensions de navigateur, eux, révèlent bel et bien les champs cachés, si bien qu'un vrai visiteur utilisant une technologie d'assistance peut finir par le remplir et se voir rejeté silencieusement comme spam.

Cachez-le correctement à la place : positionnez-le hors écran avec du CSS plutôt qu'avec display:none, marquez-le tabindex="-1" pour que la navigation au clavier le saute, et aria-hidden="true" pour que les lecteurs d'écran ne l'annoncent jamais. Un champ ainsi conçu est invisible pour tout vrai visiteur - clavier, souris ou lecteur d'écran - et attrape quand même les robots peu sophistiqués responsables de la majorité du spam. La protection anti-spam de Formhook, honeypot plus limitation de débit, avec Turnstile disponible si vous en avez besoin, est activée par défaut sur chaque formulaire - mais ce schéma de balisage vaut la peine d'être utilisé quel que soit le backend.

Ne laissez pas le formulaire rester silencieux après validation

Le bouton est cliqué, la requête part - et alors, que voit le visiteur ? Un formulaire qui n'affiche rien, ou qui dépose quelqu'un sur une page « Merci » vide et sans contexte, donne l'impression d'être cassé même quand tout a fonctionné - plus d'un visiteur a soumis un formulaire trois fois de suite parce que rien ne lui indiquait que la première tentative avait réussi. Affichez une confirmation en ligne à la place du formulaire, ou renvoyez les gens vers un vrai état de remerciement qui indique la suite (« nous répondrons sous un jour ouvré »). Cette confirmation est aussi la dernière occasion de poursuivre la conversation - un lien vers vos réalisations ou une page de réservation ne coûte rien, et certains visiteurs le suivront.

Rien de tout cela ne nécessite un framework ni une refonte - il s'agit surtout de balisage et d'un quart d'heure d'attention. Si vous préférez ne pas construire vous-même la partie backend - livraison, filtrage anti-spam, tableau de bord, stockage - c'est exactement à ça que sert Formhook ; voyez les tarifs pour ce qu'offre le niveau gratuit. Pour savoir quoi vérifier avant de mettre en ligne, la checklist avant lancement couvre le sujet, et si vous hésitez entre un formulaire et un simple lien mailto:, mailto vs formulaire de contact présente les deux côtés.