Votre prospect voit « Votre demande a bien été envoyée ». Pourtant, personne ne retrouve son message. Refaire le bouton ou changer de boîte mail au hasard ne résout pas le problème : il faut savoir jusqu’où la demande est réellement arrivée.
Un formulaire met en jeu plusieurs étapes. Le navigateur transmet des données au site, le site les traite, un service de messagerie prend éventuellement en charge une notification, puis la messagerie destinataire décide de son classement. Une confirmation à la première étape ne prouve pas les suivantes.
Voici une méthode pour faire vérifier ce parcours par votre prestataire, sans envoyer de fausses demandes à vos clients ni modifier vos réglages de domaine à l’aveugle.
Commencez par une demande identifiable, pas par dix essais identiques
Choisissez un créneau avec la personne qui gère le site et celle qui reçoit les demandes. Utilisez une adresse de test que vous contrôlez et un message fictif, sans données de client. Donnez à l’essai une référence unique, par exemple « TEST-SITE-A », et notez l’heure avec son fuseau.
Dans notre exemple fictif, une entreprise de maintenance reçoit ses demandes sur une boîte partagée. Le formulaire affiche sa confirmation, mais l’équipe ne voit rien. Le but du test n’est pas de démontrer que le formulaire fonctionne parfois : c’est de retrouver cette même référence à chaque étape.
Convenez aussi de ce qui devra être nettoyé après le contrôle : demande fictive dans l’outil métier, notification et éventuel accusé de réception. Ne lancez pas un essai susceptible de déclencher une facturation, une intervention ou une relance réelle. Si le parcours entraîne ces actions, demandez un environnement de test ou une procédure explicitement neutralisée.
Pour chaque étape, retenez un résultat simple : preuve trouvée, échec identifié ou résultat inconnu. « Inconnu » vaut mieux qu’un succès supposé.
Quatre preuves à distinguer
1. Le site a reçu et traité la demande
Le message affiché dans le navigateur doit correspondre à ce que le serveur a réellement accepté. Demandez au prestataire de retrouver la référence de test dans les traces applicatives ou dans le registre des demandes, s’il en existe un.
Un simple retour HTTP favorable ne démontre pas, à lui seul, que toutes les actions attendues ont abouti. L’application peut avoir enregistré la demande et échoué ensuite à envoyer sa notification. À l’inverse, une confirmation peut être affichée trop tôt.
Ne demandez pas d’ajouter toutes les données personnelles aux journaux pour faciliter le diagnostic. Une référence technique, un horaire et un statut peuvent suffire à relier les étapes ; le contenu et la durée de conservation doivent rester proportionnés au besoin.
2. Le service d’envoi a accepté le message
Une notification peut partir par SMTP ou par l’API d’un prestataire. Il faut retrouver son identifiant et le résultat de la soumission. Le mot « envoyé » dans un module peut seulement signifier que le message a été confié au service suivant.
Le protocole SMTP distingue précisément cette prise de responsabilité : une réponse positive après transmission des données signifie que le serveur accepte la responsabilité de livrer le message ou de signaler son échec. Ce n’est pas une preuve de lecture par votre équipe.
Si le prestataire ne retrouve aucune soumission, cherchez d’abord du côté du site, de sa file d’attente ou de sa configuration d’envoi. Changer les filtres de la boîte de réception n’aidera pas un message qui n’a jamais quitté l’application.
3. La messagerie destinataire a accepté ou refusé la livraison
Demandez ensuite les événements disponibles chez le service d’envoi : attente, tentative différée, rejet ou acceptation par le serveur destinataire. Un statut nommé « delivered » doit être interprété selon la documentation du fournisseur : il ne signifie pas nécessairement « visible dans la boîte principale ».
Conservez le code et la raison d’un refus, en masquant les informations personnelles inutiles. Un problème d’adresse, une restriction du destinataire et un défaut d’authentification ne se corrigent pas de la même façon. Un délai temporaire ne justifie pas de renvoyer immédiatement le même message à répétition.
4. La demande est visible au bon endroit
Dans la boîte de test ou la boîte interne prévue, cherchez la référence exacte. Vérifiez les indésirables, les règles de classement, les transferts et, avec l’administrateur, une éventuelle quarantaine. Une boîte partagée peut également avoir ses propres règles ou droits d’accès.
La preuve utile est alors concrète : le message correspondant au test est présent à tel endroit, à telle heure. Elle ne prouve toujours pas qu’un collaborateur l’a lu ou traité. La responsabilité commerciale doit donc être définie séparément : qui consulte les demandes, qui prend le relais et comment repère-t-on celles restées sans réponse ?
Le piège classique : envoyer au nom du visiteur
Le formulaire demande l’adresse email du prospect. Cette adresse est utile pour lui répondre ; elle ne devrait pas pour autant devenir automatiquement l’expéditeur technique de la notification.
Imaginez un visiteur qui saisit une adresse Gmail. Si votre serveur envoie un message en affichant cette adresse dans le champ « De », il prétend envoyer au nom d’un domaine qu’il ne contrôle pas. Les consignes Gmail demandent notamment aux expéditeurs de ne pas usurper cet en-tête.
Une configuration courante consiste à envoyer depuis une adresse du domaine de l’entreprise, autorisée chez le service d’envoi, et à placer l’adresse validée du visiteur dans « Répondre à » — le champ Reply-To. Ainsi, la notification possède une identité d’envoi maîtrisée, tandis que le bouton « Répondre » peut viser le prospect. Le prestataire doit vérifier cette destination, pas seulement l’apparence du nom affiché.
Cette séparation n’authentifie pas à elle seule l’adresse fournie par le visiteur. Une adresse saisie peut être erronée ou appartenir à quelqu’un d’autre. Évitez notamment de renvoyer automatiquement tout le texte libre du formulaire vers une adresse non vérifiée : votre accusé de réception ne doit pas devenir un moyen d’envoyer du contenu abusif à un tiers.
SPF, DKIM, DMARC : demandez une preuve sur le message réel
Ces mécanismes sont complémentaires, mais ils ne constituent pas une garantie d’arrivée en boîte principale.
- SPF permet de vérifier si le serveur qui envoie est autorisé pour le domaine utilisé dans l’identité d’enveloppe. Ce domaine n’est pas forcément celui que le lecteur voit dans « De ».
- DKIM ajoute une signature cryptographique associée à un domaine. La messagerie de réception peut vérifier cette signature avec la clé publique publiée dans le DNS.
- DMARC vérifie le lien entre le domaine visible dans « De » et une authentification SPF ou DKIM réussie et alignée. Il permet aussi au propriétaire du domaine de publier une politique pour les messages qui échouent.
La spécification DMARC explique cet alignement. Pour votre formulaire, la bonne question n’est donc pas seulement « Avons-nous un enregistrement DNS ? », mais « Que montrent les résultats d’authentification du message de test réellement reçu ? »
Un domaine peut être correctement configuré pour les emails des salariés et pas pour le service utilisé par le site. Demandez un inventaire des expéditeurs légitimes : messagerie habituelle, formulaire, outil de devis, newsletter si elle existe. Ne copiez pas un enregistrement SPF trouvé dans un tutoriel et ne passez pas brutalement une politique DMARC en rejet sans avoir vérifié ces usages. Une correction mal préparée peut perturber des envois qui fonctionnaient.
Le reçu de contrôle à demander
Pour éviter un compte rendu limité à « test OK », demandez une courte fiche contenant :
- La page testée, la date, le fuseau et la référence fictive.
- La preuve de réception par le site et, si prévu, d’enregistrement de la demande.
- L’identifiant du message chez le service d’envoi et la signification exacte de son statut.
- Le résultat de livraison, ou la raison précise de son échec.
- La présence du message dans la boîte destinataire et son dossier réel.
- Les domaines utilisés pour l’envoi, les résultats SPF/DKIM/DMARC observés et la bonne destination du bouton « Répondre ».
- Le responsable du suivi et les éléments de test à supprimer ou à conserver selon la procédure convenue.
Un premier essai réussi ne prouve pas que tous les destinataires recevront toujours les messages. Si le site envoie aussi un accusé de réception, testez ce second trajet séparément, uniquement vers des boîtes contrôlées et avec l’accord de leurs responsables. La notification interne et l’email au visiteur peuvent utiliser des modèles ou des réglages différents.
Faut-il conserver les demandes ailleurs que dans les emails ?
Pour une activité qui dépend des devis entrants, un registre sécurisé peut permettre de retrouver une demande même si sa notification échoue. Ce n’est pas une invitation à dupliquer indéfiniment les données : il faut définir les accès, les informations utiles, la durée de conservation et le traitement des suppressions.
L’email devient alors une alerte, pas l’unique exemplaire de la demande. Si aucun registre n’est prévu, dites-le explicitement dans le diagnostic : une perte de notification peut être plus difficile à reconstituer. L’architecture appropriée dépend du volume, de la sensibilité des messages et de l’organisation de l’entreprise.
Corriger la bonne étape, puis refaire le même parcours
Si le site ne reçoit rien, examinez d’abord le formulaire et son traitement. S’il reçoit la demande mais ne soumet aucun email, vérifiez le mécanisme d’envoi. Si le serveur destinataire refuse le message, utilisez son motif de rejet. Si le message est classé ailleurs, contrôlez les règles et l’authentification avant de conclure à une panne du site.
Après correction, refaites un essai avec une nouvelle référence, puis comparez les mêmes preuves. Ne vous contentez pas de changer le texte de confirmation : celui-ci doit décrire une réalité vérifiée.
L’étape précédente du parcours reste importante : un visiteur doit aussi pouvoir corriger une erreur dans le formulaire et terminer sa demande. Mais une saisie réussie et une notification reçue sont deux contrôles différents.
Vous avez une confirmation à l’écran mais des demandes introuvables ? Présentez le parcours à 1Design, avec la page concernée, l’heure d’un essai et ce que votre équipe observe. Le premier objectif est de localiser la rupture et de définir une vérification reproductible, pas de promettre une délivrabilité parfaite.
Vous voulez un site plus clair, plus crédible ou mieux pensé pour convertir ?