Tester son formulaire de contact : la checklist de pré-lancement

Un formulaire de contact cassé est le pire genre de bug : il ne déclenche aucune alerte, ne casse aucune mise en page, et ne se manifeste que par le silence - qui ressemble exactement à « personne ne nous contacte ». Des sites ont tourné des semaines avec un formulaire mort pendant que tout le monde pensait que l'activité ralentissait. Quinze minutes avant le lancement évitent tout cela.

1. Le chemin nominal - depuis le vrai site

Envoyez un test authentique depuis l'URL de production déployée, pas depuis localhost. Ce seul test exerce ce que les tests en local ne peuvent pas : DNS, TLS, et surtout CORS - si votre backend de formulaire utilise une liste d'origines autorisées (ce qui devrait être le cas), la production est le seul endroit où vous découvrirez que le domaine n'y figure pas. Testez à la fois www et le domaine apex si vous servez les deux.

Vérifiez les trois bouts de la chaîne : l'état de succès s'affiche dans le navigateur, la soumission apparaît dans le tableau de bord, et la notification (push ou e-mail) arrive bien sur l'appareil que vous aurez réellement sur vous.

2. La validation - essayez de la casser

• Soumettez le formulaire vide. Chaque champ required doit se plaindre, au bon endroit, dans une langue cohérente avec le site (un site serbe avec les messages par défaut du navigateur en anglais est un raté classique - définissez des messages personnalisés si cela compte).
• Soumettez not-an-email dans le champ e-mail.
• Collez un message vraiment long - 5 000 caractères - et vérifiez qu'il est accepté, ou qu'il échoue proprement avec une limite claire, pas une troncature silencieuse.
• Si vous avez un champ fichier : bon type, mauvais type, et un fichier trop volumineux. Ce dernier doit échouer avec un message, idéalement avant la fin d'un envoi lent.

3. Le chemin d'échec - le test que tout le monde saute

Pointez temporairement le formulaire vers un endpoint absurde (ou bloquez la requête dans les devtools) et soumettez. Que voit le visiteur ? La réponse inacceptable est « rien » - un bouton qui ne fait rien, ou un spinner infini. Il doit y avoir un état d'erreur avec un repli (« ou écrivez-nous à … »). C'est l'état que vos vrais utilisateurs rencontrent lors d'une panne ou d'un déploiement raté, et c'est la différence entre un lead perdu et un lead récupéré. Consultez les réponses d'erreur de votre backend pour que votre gestion corresponde à ce qu'il renvoie réellement.

4. Les défenses anti-spam - vérifiez qu'elles sont actives, et pas trop

• Honeypot : remplissez le champ caché via les devtools et soumettez - il doit être avalé silencieusement, sans jamais apparaître dans le tableau de bord.
• Limite de débit : soumettez plusieurs fois rapidement ; vérifiez que la limitation se déclenche et qu'elle est assez généreuse pour une correction-et-renvoi légitime.
• Turnstile (si activé) : testez dans une fenêtre normale et une fenêtre privée ; vérifiez que l'échec du jeton affiche un message compréhensible pour un humain.

(Comment chaque couche fonctionne : protection anti-spam pour formulaire de contact.)

5. Mobile, clavier, et le reste peu glamour

• Soumission complète depuis un vrai téléphone : bons claviers (type="email" fait apparaître le clavier avec @), bouton facile à toucher, état de succès visible sans avoir à chercher en défilant.
• Passage au clavier uniquement : ordre de tabulation sensé, Entrée soumet, états de focus visibles - et Tab doit sauter le honeypot (s'il s'y arrête, ajoutez tabindex="-1").
• Remplissage automatique : laissez le navigateur remplir le formulaire ; vérifiez que les champs sont mappés correctement.
• La redirection de remerciement, s'il y en a une, aboutit et n'est pas bloquée par la validation des redirections du backend.

6. Laissez un canari

Après le lancement, envoyez-vous une vraie soumission par mois - rappel dans l'agenda, trente secondes. Déploiements, changements DNS et clés expirées arrivent tous ; le canari détecte la panne silencieuse avant que quinze jours d'« activité au ralenti » ne le fassent.

Temps total : environ quinze minutes au lancement, trente secondes par mois ensuite. L'assurance la moins chère du développement web.