Pourquoi mon formulaire Webflow ne s'envoie-t-il pas ?

Chaque article sur le sujet énumère les mêmes douze causes possibles et vous laisse les parcourir, ce qui est la voie lente. Presque toutes ces pannes appartiennent à trois groupes, et deux vérifications dans le navigateur vous disent lequel avant de rien changer. Faites le diagnostic d'abord. Cela prend une minute et vous évite de désactiver des scripts et de reconstruire le formulaire pour corriger ce qui s'avérait être un réglage.

Comment savoir quel problème vous avez ?

Ouvrez les outils de développement du navigateur et envoyez le formulaire deux fois, en surveillant un panneau différent à chaque fois. Au premier envoi, surveillez la console : une erreur au moment du clic signifie que du JavaScript interrompt la soumission. Au second, surveillez le panneau réseau : si aucune requête n'apparaît, le formulaire n'est pas câblé pour envoyer quoi que ce soit ; si une requête apparaît mais revient en erreur, le formulaire fonctionne et c'est le point de terminaison qui ne fonctionne pas. Ces trois issues désignent trois familles de causes totalement différentes, et savoir laquelle vous concerne élimine aussitôt l'essentiel de la checklist.

Le formulaire ne tente pas de s'envoyer, ce qui relève presque toujours d'un problème de structure dans le Designer plutôt que d'un bug. La cause la plus fréquente est que le bouton à l'intérieur du formulaire est un simple élément bouton et non un bouton d'envoi : il paraît identique et ne fait rien au clic. Vient ensuite un champ obligatoire masqué, peut-être dans une étape non visible, car le navigateur refuse d'envoyer tant qu'un champ requis qu'il ne peut afficher est vide. Ensuite, vérifiez que les champs sont bien à l'intérieur de l'élément formulaire et non à côté, ce qui arrive facilement quand une mise en page est réorganisée.

La console affiche une erreur. Quelle en est la cause ?

En général du code personnalisé, le vôtre ou celui injecté par un outil, qui interfère avec le script gérant l'envoi. Tout ce qui attache son propre gestionnaire au formulaire, empêche le comportement par défaut ou lève une erreur avant l'exécution du code de Webflow arrêtera l'envoi, silencieusement du point de vue du visiteur. Testez en retirant temporairement le code personnalisé de la page et en réessayant, puis réintroduisez-le pièce par pièce. Les widgets tiers méritent d'être suspectés tôt, en particulier ceux qui manipulent la page après chargement, car ce sont ceux les plus susceptibles d'être présents sans que personne se souvienne de les avoir ajoutés.

La requête part mais revient en erreur. Pourquoi ?

Le formulaire va bien et quelque chose à l'endroit où il envoie ne va pas. Une action de formulaire personnalisée est la première chose à vérifier : en définir une indique à Webflow que la soumission part ailleurs, il cesse donc de la traiter et d'envoyer les notifications. Ensuite, vérifiez si le site a dépassé le quota de soumissions de son offre pour le mois, ce qui produit un rejet plutôt qu'un avertissement sur la page. Regardez enfin ce qui se trouve entre le navigateur et le point de terminaison : un certificat expiré, ou une politique de sécurité du contenu assez stricte pour bloquer la requête, produisent tous deux ce type d'échec alors que la page paraît normale.

Il s'envoie, mais l'e-mail de notification n'arrive jamais. Où est-il passé ?

C'est un problème distinct d'un formulaire qui ne s'envoie pas, et il vaut la peine de les séparer car les correctifs n'ont rien en commun. Vérifiez d'abord la liste des soumissions dans les paramètres du site : si l'entrée y figure, le formulaire a fonctionné et seule la notification a échoué, ce qui désigne le chemin e-mail et non le formulaire. Les causes habituelles sont ensuite une adresse de notification jamais définie ou définie sur un autre formulaire, un filtrage côté réception, ou un domaine d'envoi non vérifié. La liste des soumissions est le fait ; l'e-mail est un confort posé par-dessus.

Cela marche pour moi mais pas pour un visiteur. Quelle différence ?

Généralement le filtrage anti-spam, ou le fait que vous testiez là où le visiteur n'est pas. La protection automatisée bloque les soumissions qui semblent générées par une machine, et un vrai visiteur écrivant de façon inhabituelle, ou envoyant depuis un réseau à mauvaise réputation, peut être pris dedans. Testez avec un contenu ordinaire avant de conclure que le formulaire est cassé. L'autre écart courant est de tester sur un domaine de préproduction alors que les visiteurs sont sur le domaine live, ou de tester en étant connecté au site. Reproduisez exactement les conditions du visiteur, en fenêtre privée, sur le vrai domaine, avant de déboguer autre chose.

Pourquoi le formulaire a-t-il cessé de marcher après l'export du site ?

Parce que la gestion des formulaires est un service d'hébergement et non une partie du code exporté : le formulaire envoie désormais dans le vide. Le balisage vous suit et semble complet, ce qui rend la chose déroutante : le formulaire s'affiche, accepte la saisie et paraît s'envoyer. Ce qui manque, c'est ce qui le recevait, et cela est resté derrière. Tout site exporté a besoin de sa propre gestion de formulaires, qu'il s'agisse d'un petit point de terminaison que vous écrivez, d'un service hébergé ou du gestionnaire de votre framework. Vérifiez-le avant de déplacer un site plutôt qu'après, car la panne reste invisible jusqu'à ce que quelqu'un signale n'avoir jamais eu de réponse.