Un message de confirmation à l'écran ne prouve pas que quoi que ce soit a été envoyé. C'est presque toujours la page qui affiche l'écran suivant, et elle s'affiche que le courriel soit parti du serveur ou qu'il soit mort en silence deux secondes plus tôt.
C'est la panne que personne ne détecte, parce qu'elle est silencieuse des deux côtés. Le visiteur croit vous avoir écrit. Vous croyez que personne ne vous a écrit. Aucun rebond, aucune erreur, aucun signal dans votre journée. Le seul symptôme est une entreprise plus tranquille que le trafic ne le laisse croire.
Où va réellement une demande quand quelqu'un clique sur « envoyer » ?
Cinq choses doivent fonctionner, et chacune échoue à sa manière.
Le formulaire doit se soumettre. Le serveur doit accepter la soumission et la remettre à quelque chose qui envoie du courriel. Ce service d'envoi doit être reconnu par le fournisseur de messagerie du destinataire. Ce fournisseur doit déposer le message dans une boîte de réception plutôt que dans les indésirables. Et un humain doit ouvrir cette boîte.
Brisez un seul maillon et le résultat est identique : rien ne se passe, et personne ne sait pourquoi. La plupart des propriétaires supposent que le problème se trouve au début de la chaîne, dans le formulaire lui-même. Il est presque toujours au milieu.
Pourquoi le courriel se retrouve-t-il dans les indésirables ?
Parce que les fournisseurs de messagerie n'acceptent plus un message simplement parce qu'il prétend venir de vous.
Trois enregistrements DNS décident si votre courriel est cru. Le SPF indique quels serveurs ont le droit d'envoyer du courriel pour votre domaine. Le DKIM ajoute une signature cryptographique qui prouve que le message n'a pas été altéré et qu'il vient bien de là où il le prétend. Le DMARC dit aux fournisseurs quoi faire quand les deux premiers échouent, et peut vous envoyer des rapports à ce sujet.
Si votre site envoie ses notifications depuis un serveur qui n'est couvert par aucun de ces enregistrements, le fournisseur reçoit un message qui prétend venir de votre domaine sans pouvoir le vérifier. Parfois il atterrit dans les indésirables. Parfois il est jeté sans jamais atteindre un dossier.
L'hébergement partagé bon marché aggrave la situation. Vous envoyez depuis une adresse IP partagée avec des centaines d'autres sites, et vous héritez de leur réputation. Quand l'un d'eux sert à envoyer du pourriel, vos demandes de soumission tombent avec lui.
L'erreur que fait presque tous les formulaires bon marché
Voici le bogue précis, et il est partout.
Le formulaire est configuré pour envoyer la notification au nom du visiteur. L'adresse d'expéditeur du courriel est celle du client, disons une adresse Gmail ou Outlook qu'il vient de taper. Ça semble pratique. Vous répondez et vous le rejoignez.
Ça veut aussi dire que votre hébergeur envoie un courriel qui prétend venir d'un grand fournisseur de messagerie pour lequel il n'a aucune autorisation. C'est exactement le comportement que l'authentification a été conçue pour bloquer, et les filtres modernes le traitent en conséquence.
Le correctif est petit, et ce n'est pas une refonte. La notification doit partir d'une adresse de votre propre domaine, du genre formulaire@votreentreprise.ca, via un service correctement authentifié pour ce domaine. L'adresse du visiteur va plutôt dans le champ « Répondre à ». Vous cliquez toujours sur répondre et vous rejoignez toujours le client. Le message passe maintenant les vérifications qu'il échouait.
Pendant que vous y êtes, vérifiez si le site utilise carrément la fonction d'envoi intégrée de votre hébergeur. Sur beaucoup d'hébergements partagés canadiens, cette fonction est soit désactivée, soit non authentifiée, ce qui veut dire que le formulaire échoue depuis le jour du lancement. Un vrai service d'envoi authentifié coûte quelques dollars par mois, parfois rien à faible volume, et c'est la différence entre espérer et savoir.
Le courriel arrive-t-il pour mourir dans une boîte que personne ne lit ?
Celle-là n'est pas technique, et elle est plus fréquente que les pannes techniques.
La notification part vers info@, qui redirige vers l'adresse de quelqu'un parti en 2023. Ou elle va à une seule personne, en vacances. Ou elle va dans une boîte partagée que tout le monde suppose surveillée par quelqu'un d'autre.
Il existe aussi une version plus discrète. Si votre adresse info@ redirige vers un compte Gmail personnel, l'étape de redirection peut à elle seule casser l'authentification que le message venait de passer, parce que le serveur qui redirige n'est pas l'expéditeur d'origine. Du courriel légitime se fait filtrer au deuxième saut. C'est bon à savoir avant de blâmer votre développeur, et c'est une raison de plus de savoir clairement qui contrôle votre domaine, votre DNS et votre courriel.
Envoyez les notifications à au moins deux personnes. Vérifiez le dossier des indésirables de chaque adresse de cette liste, maintenant, avant de lire la section suivante.
Envoyez un accusé de réception, et pensez-le
Une personne qui remplit un formulaire à neuf heures du soir ne sait pas davantage si ça a fonctionné. Si elle n'entend rien, la suite logique est de remplir le formulaire d'un concurrent.
Une réponse automatique règle trois problèmes d'un coup. Elle confirme au client que le message est arrivé. Elle lui donne vos coordonnées, pour qu'il puisse vous joindre autrement si vous restez silencieux. Et elle prouve que l'adresse qu'il a tapée fonctionne, parce qu'un rebond, vous le verrez.
Restez court et humain. Dites que le message est arrivé, dites à peu près quand vous répondez, et signez d'un nom. Un mur de texte promotionnel à neuf heures du soir ne rassure personne.
Le test de dix minutes à faire aujourd'hui
Ne demandez pas à votre développeur si le formulaire fonctionne. Testez-le comme un client le ferait.
Prenez votre téléphone, sur les données mobiles plutôt que sur le wifi du bureau. Ouvrez votre propre site. Remplissez le formulaire de contact avec une adresse personnelle que vous pouvez consulter, et écrivez quelque chose de reconnaissable dans le message, comme l'heure actuelle.
Vérifiez ensuite quatre endroits : la boîte de réception qui devait recevoir la notification, le dossier des indésirables de cette boîte, l'accusé de réception dans l'adresse que vous avez utilisée, et si vous pouvez répondre à la notification et que la réponse vous revient. Refaites l'exercice pour chaque formulaire du site. Le formulaire de soumission, celui de rendez-vous, l'infolettre et le formulaire du pied de page sont quatre tuyaux différents, et ils brisent séparément.
Faites-le aussi après chaque refonte. Un formulaire qui casse discrètement pendant une reconstruction est une des façons classiques dont un nouveau site perd de l'argent tout en étant plus joli, au même titre que les redirections et le référencement qu'on échappe la même semaine.
Cessez de garder votre seule copie dans une boîte de courriel
Le courriel devrait être la notification, pas l'archive.
Chaque soumission devrait aussi être écrite quelque part qui vous appartient : une base de données sur le site, un chiffrier, ou un CRM. Un courriel qui échoue devient alors un désagrément plutôt qu'un client perdu, et vous voyez les soumissions qui n'ont jamais généré la moindre notification. C'est la preuve qui transforme « je pense que le formulaire est brisé » en fait réparable.
Ça vous donne aussi les chiffres que vous n'avez pas en ce moment. Combien de demandes par semaine, depuis quelles pages, à quelle heure. Si votre site attire des visites qui ne deviennent jamais des demandes, c'est ce registre qui dit si le problème est le trafic ou le formulaire.
Les autres portes auxquelles les gens frappent
Le formulaire de contact est une des façons dont un client tente de vous joindre, et les autres brisent tout aussi silencieusement.
Vérifiez que le numéro de téléphone dans votre en-tête se compose d'une touche et sonne sur la ligne que quelqu'un répond. Vérifiez le dossier des demandes de message de Facebook et d'Instagram, qui cache les messages des gens qui ne sont pas connectés à vous et où atterrit justement le message d'un nouveau client. Si vous affichez un numéro WhatsApp, écrivez-lui depuis un téléphone qui ne vous a jamais contacté et voyez si le message arrive.
Chacune de ces vérifications est gratuite, et aucune n'est à l'agenda de qui que ce soit.
Ce que ça coûte à réparer
Réparer un formulaire brisé est habituellement un petit mandat, souvent une heure ou deux de développement plus la configuration d'un service d'envoi authentifié. Ce n'est pas une refonte, et méfiez-vous de quiconque vous le facture comme telle.
Si vous construisez ou reconstruisez de toute façon, ça doit faire partie de la construction elle-même, testé avant le lancement plutôt que découvert en mars. Nos sites web vont de 1 200 $ à 8 000 $ selon la portée, et les fourchettes sont sur la page tarifs. La surveillance continue, pour qu'un formulaire qui cesse d'envoyer soit remarqué par quelqu'un d'autre que le client que vous venez de perdre, c'est le rôle d'un forfait d'entretien, à partir de 129 $ par mois.
Le résumé honnête : c'est le problème le moins cher à régler sur votre site et un des plus coûteux à laisser traîner, parce que le coût est invisible. Vous ne voyez jamais la demande qui n'est pas arrivée.
Faites le test de dix minutes. Si vous préférez qu'on regarde à votre place, envoyez-nous votre site pour une analyse gratuite et on vous dira ce qui est brisé et quoi corriger en premier, que vous travailliez avec nous ou non.