En bref
Si un formulaire WordPress affiche « envoyé » et que la boîte de réception reste vide, suivez une demande de test du début à la fin. Relevez son heure, vérifiez si le site l’a conservée, cherchez sa trace chez le service qui envoie les emails, puis dans la boîte du destinataire. Corrigez l’étape où la trace s’arrête. Si la demande est absente dès le site, commencez par le formulaire.
1. Faire un test que votre équipe peut retrouver
Ouvrez la page utilisée par vos visiteurs, par exemple la fiche de demande de devis sur mobile. Remplissez le formulaire avec des données fictives et un objet reconnaissable, comme « Test devis mardi matin ». Notez la page, l’heure et le fuseau, le résultat affiché et la boîte qui devrait recevoir la notification. Si le formulaire sert à déclencher un devis, une réservation ou une relance, prévenez les personnes concernées et utilisez une destination de test lorsque c’est possible. Une notification peut déclencher d’autres actions derrière le site.
Choisissez le parcours qui pose problème. L’envoi d’un message depuis l’extension de messagerie, depuis la page Contact et depuis un formulaire intégré à une page de service sont trois essais différents. Si l’extension propose un bouton d’envoi de test, son résultat permet d’écarter certains problèmes de transport, mais le formulaire peut utiliser un autre destinataire, un autre expéditeur ou un autre connecteur. Après chaque changement, refaites l’essai depuis la page publique.
2. Chercher la demande dans WordPress ou dans le CRM
Consultez les entrées du formulaire, si l’extension les conserve, ou la liste des demandes du CRM. Recherchez le repère choisi. Un message de confirmation dans la page indique que le visiteur a franchi une étape. Il ne renseigne pas toujours sur la suite. Si le formulaire ne conserve aucune entrée par conception, l’absence d’une ligne ne suffit pas à conclure. Utilisez le journal de l’extension ou du connecteur que le site emploie réellement.
Si la demande est présente et contient les champs attendus, votre priorité devient sa transmission à l’équipe. Si elle est absente alors que la conservation est activée, regardez les erreurs côté formulaire, le traitement antispam et les éventuelles actions conditionnelles. Essayez le même type de demande sans pièce jointe, puis avec une pièce jointe de test conforme aux règles affichées. Une différence entre les deux essais permet de concentrer le diagnostic sur le traitement du fichier plutôt que sur l’ensemble du site.
3. Suivre la notification dans le service d’envoi
Vérifiez le destinataire réglé dans le formulaire. Une règle peut envoyer les demandes de devis vers une équipe et les demandes de recrutement vers une autre. Vérifiez aussi l’adresse d’expédition et l’adresse de réponse. Pour qu’un collaborateur puisse répondre au visiteur, son adresse peut être utilisée comme adresse de réponse. L’expédition reste confiée à une adresse autorisée par le service de messagerie. Mélanger ces deux champs peut donner un résultat différent selon le domaine saisi par le visiteur.
Dans la documentation de wp_mail(), WordPress distingue une demande d’envoi traitée sans erreur de la réception effective. Lorsque le site utilise un prestataire SMTP ou un service transactionnel, cherchez l’événement correspondant dans son journal. Relevez le destinataire, l’heure, l’identifiant du message si disponible et l’état exact. Un refus d’authentification, une adresse rejetée et un message accepté par le relais conduisent à des vérifications différentes. N’ajoutez pas une seconde extension d’envoi avant d’avoir identifié celle que le site utilise.
| Dernière trace | À vérifier | Résultat attendu |
|---|---|---|
| Formulaire seul | Entrée sauvegardée, conditions, antispam et pièce jointe. | Une demande identifiable dans le système prévu. |
| Entrée présente | Destinataire effectif, action de notification et journal d’envoi. | Une tentative rattachée à la demande. |
| Envoi accepté | Recherche dans la boîte, règles, indésirables et quarantaine administrateur. | Un message reçu ou une cause de blocage documentée. |
4. Vérifier la boîte que l’équipe utilise vraiment
Une fois l’envoi accepté, cherchez le message dans le dossier des indésirables, les archives, les règles de transfert et les dossiers de la boîte partagée. Si vous êtes sur un domaine d’entreprise, l’administrateur de la messagerie peut avoir accès à une quarantaine ou à un historique plus précis. Fournissez-lui l’heure et le destinataire, puis l’identifiant du message si le prestataire d’envoi l’indique. Il pourra chercher l’événement sans avoir besoin du texte de la demande.
Si un seul destinataire ne reçoit rien, comparez avec une boîte de test autorisée. Si aucune boîte ne reçoit, revenez au journal de transport avant de changer un filtre côté réception. Une panne qui suit une migration d’hébergement peut concerner la messagerie même si les pages s’affichent. Comparez les réglages avec le prestataire concerné et les éléments consignés avant la bascule. Faites un seul changement à la fois pour savoir lequel a eu un effet.
5. Prévoir comment retrouver les demandes pendant l’incident
Quand les demandes sont enregistrées, désignez une personne qui les consulte directement dans l’outil prévu, jusqu’au rétablissement des notifications. Limitez les exports aux informations nécessaires et vérifiez qu’aucune demande n’a déjà été traitée avant de la relancer. Si le site ne conserve pas les envois et que la messagerie ne les a pas reçus, leur récupération n’est pas garantie. La trace disponible dépend de l’extension, du relais et de leur configuration.
Un outil comme Form Monitor peut aider à retrouver les demandes suivies sur le site. Définissez quelles informations l’équipe doit conserver et qui peut y accéder. WordPress indique que les données associées à un échec d’envoi peuvent inclure le destinataire, le contenu et les pièces jointes. Dans votre compte rendu, gardez le résultat du test et la nature de l’erreur sans recopier des messages clients ni afficher ces informations sur une page publique. Relisez au besoin les principes de traitement des demandes.
6. Refermer l’incident avec une réception confirmée
Le test est terminé quand une personne a reçu la demande dans la boîte prévue et sait où retrouver sa trace. Refaites-le sur le parcours initial et sur une variante importante, par exemple un devis avec pièce jointe. Si une demande peut arriver deux fois, vérifiez également comment le formulaire et le CRM identifient les doublons. Notez la date du contrôle et le rôle qui doit refaire l’essai après une mise à jour ou une migration.
Si l’incident revient, ajoutez le formulaire aux fonctions prioritaires de votre test de préparation avant mise à jour. Un suivi dans la durée doit préciser qui vérifie les demandes et qui intervient sur chaque maillon. Ce périmètre peut être cadré lors d’une intervention de maintenance web.
