Je gère plusieurs sites WordPress. Sur chacun partent des emails en nombre que personne n’imagine : notifications de contact, réinitialisations de mot de passe, confirmations de commande, alertes aux gestionnaires. Le journal email WordPress de FluentSMTP est l’outil que je consulte dès qu’un client m’écrit « je n’ai rien reçu ». Avant, je regardais les logs du serveur SMTP en ligne de commande. Je devais faire correspondre à la main des grep et des horodatages. Maintenant j’ouvre une page dans le tableau de bord de WordPress et j’ai tout sous les yeux.
Pourquoi je consulte le journal email WordPress avant les logs du serveur
Le cas typique est toujours le même. Un formulaire de contact qui « n’arrive pas ». Un client qui ne reçoit pas l’email de réinitialisation de mot de passe. Une commande qui reste sans confirmation. Sans un journal à portée de main, la première hypothèse est le dossier spam. Puis les logs du serveur SMTP. Puis peut-être le pare-feu. Avec FluentSMTP, je saute ces étapes. Je vois tout de suite si WordPress a vraiment tenté d’envoyer cet email. À qui, quand, avec quelle réponse du serveur d’envoi.
FluentSMTP enregistre chaque appel à wp_mail(). Pas seulement les emails des plugins tiers, aussi ceux générés par le cœur de WordPress : notifications de nouvel utilisateur, rappels de mise à jour, alertes d’erreur. Pour chaque envoi, le journal affiche l’expéditeur, le destinataire, l’objet, les en-têtes complets, le corps du message. Et la réponse du fournisseur SMTP ou de l’API utilisée. Si un email a échoué, cette réponse du serveur est là. Je n’ai pas à la deviner.
Ce que je trouve vraiment dans le registre des envois
Le plugin prend en charge des dizaines de connecteurs : Amazon SES, SendGrid, Mailgun, Brevo, Postmark, SparkPost. Aussi Google Workspace et Microsoft 365 via OAuth, en plus du SMTP générique classique. Sur les sites que je gère, j’utilise presque toujours du SMTP authentifié avec le domaine du client. Parfois une API dédiée, quand le volume d’emails augmente. Dans les deux cas, le journal email WordPress ne change pas. Chaque ligne a un statut, envoyé ou échoué. Il y a un bouton pour revoir le contenu ou renvoyer le message, sans que l’utilisateur doive refaire l’action qui l’a généré.
Le renvoi manuel est la fonction que j’utilise le plus souvent. Un formulaire rempli deux fois parce qu’il « n’arrivait pas » devient un clic sur le journal. Pas un nouveau signalement au client. Pour les échecs répétés, j’ai activé les notifications sur Telegram. Dès qu’une connexion arrête de fonctionner, je le sais avant qu’on me le signale. Plutôt que de le découvrir par un ticket de support.
Le journal ne concerne pas seulement les notifications adressées à moi ou au client qui administre le site. Y finit aussi chaque email sortant généré par le site vers des tiers : la confirmation de commande qu’une boutique en ligne envoie au client final, le reçu d’un paiement, la notification d’expédition. Si cette confirmation n’arrive pas, je la vois dans le journal email WordPress exactement comme une notification interne, avec le même bouton pour la renvoyer au bon destinataire sans lui faire répéter l’achat.
Comment je configure FluentSMTP sur les sites que je gère
Après avoir connecté le bon connecteur, je change la conservation du journal. Par défaut elle reste active longtemps. Moi, je la porte à 30-60 jours, selon le trafic du site. Ça sert à retrouver un problème signalé en retard. Sans remplir la base de données de lignes que je ne consulterai jamais. J’active ensuite au moins un canal de notification pour les échecs, Telegram ou Slack selon le client. Le journal seul n’avertit personne : il faut l’ouvrir pour être lu.
Sur les sites avec formulaire de contact, j’utilise aussi Cisilino Site Defense Network pour bloquer les bots. Moins de spam entrant signifie moins d’emails générés par les formulaires. Le journal reste plus lisible, avec moins de bruit à filtrer quand je cherche le bon message.
Les identifiants SMTP ne restent pas en clair dans la base de données
Un détail que je vérifie toujours avant d’enregistrer une connexion : où finissent les identifiants. FluentSMTP les chiffre par défaut avec les clés SALT de WordPress, celles déjà présentes dans wp-config.php pour la sécurité des sessions. On peut désactiver le chiffrement, mais le plugin lui-même signale que c’est déconseillé. Sur les sites que je gère, je préfère une autre option : enregistrer le mot de passe API ou SMTP directement dans wp-config.php, hors de la base de données. Je définis les constantes avant que le plugin ne les lise. Ainsi, même un dump de la base de données ou un accès non autorisé au tableau de bord n’expose pas la clé du fournisseur d’envoi. C’est le même principe que j’applique ailleurs : moins de secrets dans la base de données, mieux c’est.
Plusieurs connexions en même temps, pas une seule à la fois
FluentSMTP permet de configurer plusieurs connexions en même temps, pas une seule à la fois. Sur un site, je règle celle par défaut et j’en ajoute une seconde comme réserve : si le premier fournisseur ne répond pas, l’envoi passe automatiquement à la connexion de réserve, sans que j’aie besoin d’intervenir. Le choix de la connexion dépend de l’adresse de l’expéditeur : chaque connexion a son « From », le reste passe par celle par défaut. La réserve n’est prête que si la connexion par défaut échoue vraiment (une erreur du fournisseur, pas un email tombé en spam). C’est une des raisons pour lesquelles je le préfère à un simple SMTP sans alternative. Si SendGrid ou Amazon SES ont un problème pendant quelques heures, le site continue quand même à envoyer, et je le vois tout de suite dans le journal email WordPress. Tout est inclus dans la version gratuite, sans version pro payante : on paie seulement le fournisseur d’envoi choisi, pas le plugin.
Un contrôle de santé chaque jour, pas seulement quand quelque chose casse
Au-delà du journal ligne par ligne, FluentSMTP fait un contrôle de santé de la connexion chaque jour, automatiquement. Si le fournisseur arrête de répondre, l’alerte arrive avant qu’un client ne m’écrive « le site n’envoie plus d’emails ». Le même tableau de bord affiche un graphique avec les totaux journaliers d’envois réussis et échoués. Utile pour comprendre en un coup d’œil si une baisse est normale ou le symptôme de quelque chose qui se détériore, sans avoir à ouvrir le journal email WordPress ligne par ligne chaque fois. Il y a aussi un résumé périodique par email, avec les totaux de la semaine : ce n’est pas une alerte d’erreur, c’est un bulletin que je lis en passant pour savoir si le volume d’envois est dans la norme.
Pour qui, comme moi, gère plusieurs sites en ligne de commande, FluentSMTP expose aussi des commandes WP-CLI : un test d’envoi, un contrôle de santé de la connexion, les statistiques et le nettoyage des anciens journaux. Je les utilise dans les mêmes scripts qui tournent déjà sur les serveurs pour d’autres tâches de maintenance, sans avoir à ouvrir le tableau de bord de chaque site un par un.
Les limites honnêtes du journal email WordPress
Ce n’est pas une solution magique. La conservation est basée sur les jours, pas sur un nombre maximal de lignes. Sur un site avec beaucoup de trafic transactionnel, la table du journal peut grossir vite. Il vaut mieux la surveiller, ou fixer une conservation plus courte. Les notifications d’échec n’arrivent que sur les canaux de chat configurés, pas par email. C’est logique : un email qui avertit d’un email en échec risque lui aussi d’échouer. Mais il faut le savoir avant d’y compter.
Enfin, le journal enregistre ce qui s’est passé côté WordPress et côté fournisseur. Il ne garantit pas la livraison dans la boîte du destinataire. Si un email est marqué comme envoyé mais finit en spam, c’est un problème de réputation du domaine ou de configuration SPF/DKIM. Pas quelque chose qu’un journal peut résoudre seul. Il reste malgré tout le premier endroit où je regarde, avant toute autre vérification.
Le plugin est gratuit et open source. Page officielle sur wordpress.org, sans fonctions bloquées derrière une version pro. Pour qui gère même un seul site avec un formulaire de contact, ça vaut le coup de l’installer juste pour le journal email WordPress. La première fois qu’il résout un « je n’ai pas reçu l’email » en une minute plutôt qu’en une demi-heure, il est rentabilisé.
Laisser un commentaire