Diagnostic de délivrabilité
E-mail de test non reçu : cherchez les preuves avant de renvoyer
« Je n’ai rien reçu » décrit le résultat, mais n’identifie pas la couche en cause. Un diagnostic efficace commence par vérifier l’adresse, puis remonte la chaîne : tâche d’envoi, réponse du fournisseur, relève de la boîte et rendu du message.
Figez d’abord la situation, sans cliquer plusieurs fois sur Envoyer
Les renvois successifs créent plusieurs tâches et identifiants de message, ce qui rend floue la correspondance entre chaque e-mail et chaque action. Notez d’abord l’adresse de réception actuelle, l’heure du déclenchement, l’environnement de test, la version du modèle et l’ID de tâche présent dans les journaux de l’application.
Il est également essentiel d’utiliser une référence temporelle unique. Le navigateur, la file d’attente et le tableau de bord du fournisseur peuvent utiliser des fuseaux horaires différents : convertissez de préférence les heures en UTC et conservez les valeurs d’origine.
Première couche : vérifiez que l’adresse est complète et toujours valide
Recopiez l’adresse depuis la page de réception au lieu de la saisir d’après votre historique. Vérifiez les caractères avant et après @, les espaces invisibles et le fait que votre script de test ne réutilise pas une adresse remplacée lors du cycle précédent.
Une adresse e-mail temporaire a une durée de validité limitée. Si elle a expiré ou si la boîte a été remplacée, l’ancien jeton ne peut pas prouver qu’un nouveau message devrait apparaître sur la page actuelle. Créez d’abord une nouvelle adresse et envoyez un e-mail minimal : c’est plus fiable.
Deuxième couche : distinguez le déclenchement métier de l’exécution de l’e-mail
Un message de réussite sur la page ne signifie pas que la tâche d’e-mail a été exécutée. Vérifiez que l’application a bien créé la tâche, que le consommateur est en ligne, que les tentatives n’ont pas été épuisées et que la variable du destinataire n’a pas été écrasée avant le rendu du modèle.
Si la tâche reste dans la file d’attente, le système de réception ne peut rien observer. Corrigez alors le consommateur ou la configuration au lieu d’actualiser sans cesse la page de réception.
Troisième couche : lisez la réponse du fournisseur ou du SMTP
Recherchez l’ID du message, la réponse d’acceptation, le code de rejet ou l’événement de retour. « Accepté » signifie généralement que le saut suivant a reçu la demande, pas que le message est arrivé dans la boîte de réception cible.
En cas d’erreur temporaire 4xx, attendez selon la stratégie de temporisation. En cas d’erreur permanente 5xx, corrigez d’abord le domaine, l’adresse du destinataire, l’authentification ou les règles de contenu. Conservez la réponse originale au lieu d’écrire simplement « échec de l’envoi ».
Quatrième couche : la relève, la liste et le contenu sont trois problèmes distincts
Attendez un cycle de relève, puis actualisez manuellement et observez les requêtes réseau du navigateur. Si la liste affiche l’objet et l’expéditeur, le message est arrivé ; si le détail est vide, vérifiez les données du contenu plutôt que le DNS.
Le détail d’un e-mail peut fournir html_body ou text_body. Un modèle HTML isolé, des images distantes bloquées ou un script supprimé ne signifient pas que le message n’est pas arrivé : comparez le texte de secours et les champs d’origine.
Cinquième couche : créez un groupe témoin avec un e-mail minimal
Créez une nouvelle adresse temporaire et envoyez un objet fixe, un identifiant d’événement unique et une seule phrase en texte brut, sans image, pièce jointe ni variable complexe. Si l’e-mail minimal arrive, ajoutez progressivement le HTML, les ressources de marque et les données métier.
Le groupe témoin permet de distinguer rapidement un problème de délivrabilité de base d’un problème lié aux règles de contenu. Ne modifiez qu’une variable à la fois ; sinon, même après le rétablissement, vous ne saurez pas quelle était la véritable cause.
Formulez une conclusion réutilisable la prochaine fois
La conclusion doit au minimum préciser la couche en cause, les preuves directes, l’action corrective, l’échantillon de retest et les limites encore inexpliquées. Ne laissez pas seulement « ça a fonctionné après un nouvel essai » : cela n’empêche pas le problème de se reproduire.
Si vous traitez une panne en cours, utilisez le laboratoire de diagnostic de délivrabilité pour obtenir des pistes de vérification prioritaires à partir de quatre faits.