«Nous avons bien reçu votre demande.» Le site l'affiche sans hésiter. Dans la boîte mail de l'entreprise, pourtant, rien. Avant de remplacer le formulaire, cherchez ce que cette confirmation engage réellement : la demande est-elle enregistrée, une notification a-t-elle été envoyée, quelqu'un peut-il reprendre le dossier ? Une réponse différente à chacune de ces questions change complètement le diagnostic.
Le plus simple est de suivre une demande d'essai identifiable. Écrivez par exemple «ESSAI-FORMULAIRE-25OCT-A», notez l'heure et utilisez des coordonnées fictives avec une adresse que vous contrôlez. Vous pourrez retrouver le même essai dans le stockage du formulaire, les journaux d'envoi et la messagerie. Avec cinq messages intitulés «Bonjour», cette recherche devient inutilement pénible.
Le premier endroit à regarder est le registre des demandes
Ouvrez l'interface qui doit conserver les envois du formulaire. Selon votre installation, ce sera une liste de réponses, un outil de gestion clients ou un autre stockage. Cherchez votre référence. Certains formulaires enregistrent la demande avant de notifier l'équipe. D'autres essaient simplement d'envoyer un courriel. Il faut connaître votre cas, car la possibilité de récupérer une demande en dépend.
Une confirmation dans le navigateur peut apparaître après un enregistrement fiable, après une simple réponse du serveur, voire trop tôt dans une mauvaise réalisation. Demandez à votre prestataire de préciser le moment exact. Vous devez savoir ce qui reste disponible si la notification échoue juste après.
La documentation de WordPress.com sur les notifications distingue les réponses enregistrées des courriels qui les annoncent. L'interface d'un autre service sera différente. Faites-vous montrer les deux preuves dans votre propre système, sans supposer qu'un formulaire visible conserve forcément les messages.
Quatre étapes pour situer la rupture
Pour votre essai, notez séparément : demande enregistrée, notification acceptée par le service d'envoi, message accepté par le serveur destinataire, demande prise en charge dans l'entreprise. La troisième étape ne garantit pas une présence dans la boîte de réception principale. Une quarantaine, un filtre ou une règle de messagerie peut encore intervenir.
Si la demande n'est pas enregistrée, revenez au formulaire. La validation a-t-elle réussi ? La requête a-t-elle atteint la bonne adresse ? Une vérification contre les abus l'a-t-elle bloquée ? Une page copiée d'un environnement de test peut conserver une ancienne destination. Modifier la messagerie ne changera rien à ce problème.
Si l'enregistrement existe, cherchez la tâche de notification : adresse destinataire réelle, dernier essai, erreur éventuelle. Une ancienne adresse d'employé ou une autorisation expirée suffit parfois à expliquer le silence. Avec un identifiant de message fourni par le service d'envoi, poursuivez ensuite jusqu'au serveur destinataire. Relevez le résultat précis : rejet, attente ou acceptation. «Le mail ne fonctionne pas» ne permet pas de décider de la suite.
Une adresse d'expédition à vous, une adresse de réponse au client
Une configuration paraît naturelle : placer l'adresse saisie par le visiteur dans le champ From, afin que le message semble venir directement de lui. Votre site envoie alors une notification en se présentant sous un domaine qu'il ne maîtrise pas. Les contrôles de messagerie peuvent relever cette incohérence.
Utilisez une adresse d'expédition appartenant à un domaine que vous contrôlez et que le service d'envoi a correctement configuré. L'adresse validée du visiteur va dans Reply-To. Le bouton Répondre peut ainsi joindre le client. Contact Form 7 recommande cette séparation dans sa documentation. Le même principe mérite d'être vérifié pour un formulaire développé sur mesure.
Dans un exemple de PME, le nom affiché peut être «Demandes du site», associé à son adresse d'expédition. Ajoutez la référence au sujet et faites apparaître les coordonnées du client dans le contenu. Puis répondez depuis la vraie boîte de réception. Vous vérifiez ainsi aussi le travail quotidien de l'équipe, pas seulement le transport technique du premier message.
Les vérifications utiles derrière SPF, DKIM et DMARC
Demandez à la personne qui gère votre messagerie de contrôler l'authentification d'une notification réellement émise par le formulaire public. La présence d'un enregistrement DNS ne suffit pas : le chemin d'envoi actuel doit l'utiliser correctement. Un changement d'hébergeur ou de service peut rendre une ancienne configuration inadaptée.
Les consignes de Google pour les adresses Gmail personnelles distinguent les expéditeurs ordinaires des gros volumes : SPF ou DKIM s'applique généralement, avec des exigences supplémentaires dont DMARC pour les envois massifs. L'authentification aide la distribution sans garantir l'arrivée en boîte principale. D'autres destinataires peuvent appliquer leurs propres règles.
Évitez donc de remplacer un réglage DNS par un exemple trouvé au hasard. Listez d'abord les services qui expédient pour votre domaine : messagerie habituelle, facturation, newsletter et formulaire. Une correction qui rétablit les demandes mais bloque les factures coûte cher. Conservez l'état précédent et vérifiez les autres circuits importants après toute modification.
Une procédure d'essai que l'équipe peut conserver
Prévoyez si possible deux boîtes destinataires contrôlées. Gardez les protections habituelles actives et utilisez uniquement des coordonnées inventées. Un bouton «Envoyer un mail de test» dans l'administration peut emprunter un autre circuit ; il ne remplace pas une demande déposée sur la page publique.
- Ouvrez la page publiée dans une nouvelle fenêtre. Remplissez les champs obligatoires, notez la référence et recopiez le message de confirmation.
- Retrouvez l'enregistrement et comparez accents, retours à la ligne et numéro de téléphone avec votre saisie.
- Vérifiez la tentative de notification, le destinataire effectif et l'identifiant fourni par le service d'envoi.
- Contrôlez réception, indésirables et éventuelle quarantaine administrative. Répondez au message pour tester la bonne destination.
- Refaites un essai sur téléphone avec une autre référence. Une valeur volontairement invalide doit produire une erreur compréhensible, sans annoncer un succès.
- Dans l'environnement de test, interrompez l'envoi des notifications. Vérifiez que la demande reste récupérable et qu'une reprise ne multiplie pas les tâches.
Si le formulaire est déjà difficile à remplir, consignez-le séparément. Notre article sur les demandes et rendez-vous accessibles couvre le clavier, le zoom et les erreurs lisibles. Un bouton coupé et un message rejeté ont chacun leur cause, même s'ils gênent le même client.
L'entreprise doit pouvoir travailler sans notification
Une petite structure peut souvent s'appuyer sur une liste centrale de demandes, sans lancer un nouveau grand projet informatique. Le courriel attire l'attention ; l'enregistrement conserve le travail à faire. Désignez la personne qui vérifie les demandes ouvertes et celle qui prend le relais pendant ses absences. Une liste que personne ne consulte ne constitue pas une solution de secours.
Les nouvelles tentatives d'envoi doivent être limitées et rattachées à la même référence. Une panne temporaire ne devrait pas créer plusieurs fiches clients ou plusieurs rappels. Renvoyer une notification et créer une nouvelle demande sont deux opérations différentes. Testez précisément ce qui se passe lors d'une reprise automatique.
Si le formulaire alimente aussi un outil clients, ouvrez le dossier obtenu. Nom, langue souhaitée et prestation doivent arriver dans les bons champs. Notre guide sur le rapprochement après une automatisation développe cette vérification. Pour commencer, exigez une fiche retrouvable pour chaque référence d'essai et une explication des cas incomplets.
Attention au renvoi automatique du texte saisi
Certains formulaires envoient immédiatement une copie intégrale à l'adresse renseignée. Un utilisateur malveillant peut saisir l'adresse de quelqu'un d'autre et faire circuler du contenu indésirable par votre service. Préférez un accusé de réception court, au texte fixe, avec une référence. Ne réexpédiez pas sans contrôle tous les liens et les longs textes libres.
Limitez la fréquence d'envoi et définissez le traitement des demandes répétées. Décidez aussi quelles informations peuvent passer par un courriel ordinaire, surtout pour un sujet sensible. Les journaux de diagnostic doivent aider à suivre le problème sans devenir une copie supplémentaire incontrôlée des conversations. Donnez-leur des accès et une durée de conservation adaptés.
Un signalement précis accélère la réparation
Transmettez au prestataire l'URL publique, la référence, l'heure avec fuseau, le navigateur et le texte exact de la confirmation. Ajoutez la dernière étape prouvée et le premier élément manquant. Les mots de passe et les vrais messages de clients n'ont pas leur place dans un ticket ordinaire.
Après la correction, refaites le même parcours, y compris la réponse au client et le cas d'interruption des notifications. Faites-vous montrer comment reconnaître une nouvelle panne. L'essai se termine quand une personne dans l'entreprise retrouve la demande et peut s'en occuper. C'est ce résultat que votre client attend après avoir cliqué sur Envoyer.
FAQ
Une extension SMTP suffit-elle à rétablir les emails du formulaire ?
Elle peut améliorer l'expédition, sans corriger une mauvaise destination du formulaire, un enregistrement absent ou une règle du destinataire. Cherchez d'abord la dernière étape réellement prouvée.
Faut-il afficher l'adresse du client comme expéditeur ?
Utilisez généralement un domaine d'expédition maîtrisé et configuré auprès du service. Placez l'adresse validée du client dans Reply-To, puis essayez le bouton Répondre dans la vraie boîte de l'équipe.
Comment tester sans employer de données clients réelles ?
Prenez des coordonnées fictives, des boîtes contrôlées et une référence unique. Suivez enregistrement, expédition et réception, puis simulez une interruption des notifications dans un environnement de test adapté.