Vos demandes de devis n'arrivent jamais : ce qui casse un formulaire de contact

Il y a une phrase qu’on entend au moins une fois par mois : « c’est bizarre, je ne reçois plus rien par le site ». Elle arrive souvent après plusieurs semaines de silence, quand le doute s’installe : est-ce qu’il n’y a vraiment aucune demande, ou est-ce qu’elles se perdent en route ?

Dans la grande majorité des cas que nous ouvrons, le problème n’est pas commercial. Le formulaire fonctionne « visuellement » — le visiteur voit bien un message de confirmation — mais le message ne parvient jamais à destination. Voici les causes réelles, dans l’ordre de fréquence, et comment vérifier chacune sans être technicien.

Le test qui prend deux minutes

Avant toute chose, faites le test vous-même, depuis votre téléphone et en dehors de votre réseau Wi-Fi habituel : remplissez votre propre formulaire avec une vraie adresse à vous, et écrivez quelque chose de reconnaissable (« test du mardi matin »).

Puis vérifiez trois endroits, dans cet ordre :

• La boîte de réception de l’adresse censée recevoir les demandes.
• Le dossier spam / courrier indésirable de cette même adresse.
• Le dossier « Promotions » ou « Autres » si vous utilisez Gmail ou Outlook, qui trient automatiquement.

Le résultat oriente immédiatement le diagnostic. Message reçu en boîte principale : le circuit fonctionne, le problème est ailleurs (visibilité, trafic, positionnement). Message en spam : problème de délivrabilité (la capacité d’un e-mail à atteindre la boîte de réception). Rien du tout, nulle part : le formulaire n’envoie pas, ou envoie vers une adresse erronée.

Cause n°1 : l'e-mail part d'une adresse qui n'a pas le droit d'écrire

C’est, de loin, la cause la plus fréquente — et la plus contre-intuitive.

Quand un visiteur remplit votre formulaire, ce n’est pas lui qui vous écrit : c’est votre site qui envoie un e-mail en son nom. Beaucoup de sites, par défaut, envoient ce message en se faisant passer pour l’adresse du visiteur (jean.dupont@gmail.com, par exemple). Sauf que votre serveur n’a évidemment aucune autorisation pour écrire au nom de Gmail.

Les messageries modernes vérifient cela systématiquement, via des mécanismes d’authentification (SPF, DKIM, DMARC — des enregistrements techniques qui déclarent quels serveurs ont le droit d’envoyer du courrier pour votre domaine). Quand la vérification échoue, le message n’est pas rejeté bruyamment : il est classé en spam, ou silencieusement supprimé. Vous ne voyez rien, le visiteur non plus.

La règle correcte est simple : le formulaire doit envoyer depuis une adresse de votre domaine (contact@votredomaine.fr), avec l’adresse du visiteur placée en « répondre à ». Vous cliquez sur « Répondre », vous répondez bien au client — mais l’e-mail, lui, est parti d’un expéditeur légitime.

Comment savoir si c'est votre cas

Ouvrez une notification de formulaire reçue (même ancienne) et regardez le champ expéditeur. S’il affiche l’adresse du visiteur et non la vôtre, le problème est là. Sur un site hébergé chez un prestataire mutualisé, l’envoi passe souvent par la fonction d’envoi par défaut du serveur, sans aucune authentification : c’est le scénario le plus fragile qui existe.

Cause n°2 : la notification arrive dans une boîte que personne n'ouvre

Le deuxième classique n’a rien de technique. L’adresse de destination configurée dans le formulaire est une adresse créée au lancement du site, jamais consultée depuis : une boîte d’hébergeur, une adresse d’un ancien salarié, ou l’adresse d’une agence qui n’intervient plus.

Le symptôme typique : les demandes existent bien, elles s’empilent quelque part, mais personne ne les lit. Cela se répare en quelques minutes — encore faut-il aller vérifier où part réellement la notification, et pas où l’on croit qu’elle part.

Le bon réflexe : une adresse professionnelle sur votre propre domaine, relevée tous les jours, et si possible une copie envoyée à une seconde adresse. Une demande de devis qui attend trois jours est très souvent une demande perdue.

Cause n°3 : le formulaire noyé sous le spam

Un formulaire sans protection reçoit, très vite, des messages automatisés envoyés par des robots. Ce n’est pas une question de notoriété : les robots parcourent le web et remplissent tout ce qu’ils trouvent.

Quand le volume devient important, deux choses se produisent. Vous cessez de lire les notifications une par une, et une vraie demande finit noyée au milieu. Et votre adresse, qui reçoit soudain beaucoup de messages douteux, se dégrade aux yeux des filtres.

La protection efficace ne passe pas forcément par ces images de code à recopier, qui font fuir les vrais visiteurs. Deux mécanismes discrets suffisent dans la plupart des cas :

• Le champ piège (« honeypot ») : un champ invisible pour l’humain, que seuls les robots remplissent. Rempli = message écarté, sans jamais gêner un visiteur légitime.
• La validation côté serveur : on vérifie la cohérence des données à l’arrivée (format de l’e-mail, longueur du message, champs obligatoires) plutôt que de faire confiance à ce que le navigateur envoie.

Cause n°4 : le visiteur croit avoir envoyé, mais rien n'est parti

Le cas le plus coûteux, parce qu’il est totalement invisible des deux côtés. Le formulaire affiche « Merci, votre message a bien été envoyé », mais l’envoi a échoué en arrière-plan : service d’envoi mal configuré, clé expirée, mise à jour qui a cassé le branchement, ou simple erreur de champ.

Aucun signal d’alerte n’existe par défaut. Le visiteur est satisfait, vous ne savez rien, et personne ne rappelle personne.

C’est précisément pour ça qu’un formulaire doit être testé après chaque intervention sur le site, et pas seulement le jour de la mise en ligne. Une refonte de page, un changement d’hébergement, une mise à jour de sécurité : chacun de ces événements peut interrompre la chaîne d’envoi.

On s'est appliqué l'exercice à nous-mêmes

Un article de conseils est facile à écrire. Le passer sur ses propres sites l’est moins. Nous avons donc fait exactement ce qui est décrit plus haut, sur les domaines que nous exploitons — et ce n’était pas parfait.

Trois choses en sont ressorties :

• L’adresse de réception était une adresse gratuite, du type monentreprise@gmail.com. Elle fonctionnait, mais elle était en plus affichée en clair à plusieurs endroits publics du site. Une adresse visible en clair sur une page web est collectée par des robots en quelques jours : c’est une invitation au spam, et c’est aussi un signal d’amateurisme pour un visiteur professionnel.
• Certains domaines n’avaient tout simplement aucun serveur de messagerie déclaré. Autrement dit, on aurait pu écrire contact@ sur toutes les pages, aucune lettre ne serait jamais arrivée. Personne ne s’en aperçoit tant que personne n’essaie.
• La chaîne d’autorisation d’envoi n’était pas complète partout. Les trois enregistrements évoqués plus haut (SPF, DKIM, DMARC) doivent être posés et cohérents entre eux. Un seul de travers, et les messages partent en spam sans le moindre avertissement.

La correction n’a rien de spectaculaire : basculer sur une adresse du domaine, poser les enregistrements manquants, retirer l’adresse affichée en clair, puis vérifier que la boîte accepte réellement du courrier — pas supposer, vérifier.

C’est ce dernier point qui compte le plus. Sur un sujet aussi silencieux, la seule preuve valable est un test réel de bout en bout. Tant qu’on n’a pas vu le message arriver, on ne sait rien.

Ce qu'on met en place pour que ça ne se reproduise pas

Sur les sites que nous concevons, le formulaire n’est pas traité comme un élément de décoration en bas de page. C’est le point de contact principal, donc il est construit et vérifié comme tel :

• Envoi depuis une adresse du domaine, avec authentification correcte, et adresse du visiteur en « répondre à ».
• Champ piège invisible + validation à l’arrivée, pour écarter les envois automatisés sans imposer d’épreuve au visiteur.
• Notification vers une adresse réellement consultée, avec possibilité de copie.
• Confirmation honnête : le message de succès ne s’affiche que si l’envoi a effectivement abouti.
• Mention de traitement des données conforme au RGPD, avec la finalité et la durée de conservation.
• Test de bout en bout après chaque intervention, depuis un appareil externe.

Aucun de ces points n’est spectaculaire. Mis bout à bout, ils font la différence entre un site qui semble marcher et un site qui vous amène réellement des demandes.

---

Un doute sur votre propre formulaire ? Faites le test des deux minutes décrit plus haut. Si le message n’arrive pas, ou s’il arrive en spam, écrivez-nous : on vous dit ce qui bloque, sans jargon. Voir aussi notre article sur les trois éléments qui comptent vraiment pour la vitesse d’un site sur mobile et l’étude de cas du site J.E.L Nettoyage.