Tous les sites envoient des messages : confirmations de commande, réinitialisations de mot de passe, formulaires de contact ou rappels de réservation. L’e-mail transactionnel est le sujet que personne ne prévoit, mais dont tout le monde dépend. En général, la personne qui a créé le site le configure une fois et plus personne ne s’en occupe.
Jusqu’au jour où les clients cessent de recevoir leurs confirmations de commande et où l’on découvre qu’elles arrivent dans les spams depuis huit mois. Cette page explique pourquoi le problème se produit quelle que soit la plateforme et comment l’éviter.
Pourquoi les e-mails transactionnels échouent sans alerte
Sur la plupart des plateformes, la configuration par défaut envoie les messages directement depuis le serveur web, au moyen de la fonction de messagerie du langage utilisé. Les essais réussissent, car vous consultez votre propre boîte de réception et votre fournisseur vous fait confiance.
En production, l’échec n’a rien à voir avec votre code. Le serveur web ne possède aucune réputation d’expéditeur, son adresse IP est partagée avec les autres services de l’hébergeur et le message prétend venir de votre domaine alors qu’il part d’un serveur que celui-ci n’a jamais autorisé. Les fournisseurs destinataires reconnaissent ce schéma comme une usurpation, car c’en est une dans la plupart des cas. C’est précisément pour cette raison que les consignes de Google destinées aux expéditeurs imposent l’authentification.
De votre côté, l’échec reste invisible. Le site indique que le message a été envoyé, les journaux ne signalent aucune erreur et rien ne vous apprend que le destinataire l’a classé comme indésirable. L’e-mail transactionnel d’un site est particulièrement mauvais pour signaler ses propres problèmes. Ils sont donc souvent découverts plusieurs mois plus tard, à la suite de la plainte d’un client.
Le même problème sur toutes les plateformes
Il ne s’agit pas d’un problème propre à WordPress, même si cette plateforme est souvent mise en cause parce qu’elle est la plus répandue. Le mécanisme est identique partout.
WordPress utilise par défaut la fonction mail de PHP, donc un envoi direct depuis le serveur avec tous les inconvénients décrits plus haut. Une extension SMTP remplace cette fonction et constitue la solution habituelle.
Shopify, Wix et Squarespace envoient leurs propres messages transactionnels depuis une infrastructure généralement bien entretenue. En revanche, sans configuration supplémentaire, ils ne permettent pas toujours d’utiliser votre domaine avec une authentification correcte. Un e-mail qui semble provenir de votre entreprise peut alors ne pas être vérifiable.
Webflow, Ghost et les applications sur mesure fonctionnent de différentes manières, mais le constat reste le même : le mécanisme d’envoi par défaut est rarement authentifié pour votre domaine.
La solution commune à toutes ces plateformes consiste à acheminer les e-mails transactionnels au moyen d’une connexion SMTP authentifiée, sur un domaine dont le DNS autorise explicitement cette connexion à envoyer.
Une solution en trois éléments
Trois éléments sont nécessaires. Avec seulement deux, vos messages peuvent encore finir dans les spams.
Un compte SMTP pour l’envoi. Au lieu d’envoyer directement, le site s’authentifie auprès d’un serveur de messagerie et lui remet le message. Toutes les plateformes le permettent, soit nativement, soit grâce à une extension.
Un DNS qui autorise cet envoi. Il faut un enregistrement SPF qui désigne le serveur expéditeur et une signature DKIM vérifiable jointe au message. Sans eux, même un envoi authentifié semble non autorisé au fournisseur destinataire. Nos guides sur SPF et DKIM détaillent ces deux enregistrements.
Une adresse d’expédition qui existe réellement. Envoyer depuis noreply@votredomaine.fr sans avoir créé cette boîte constitue un signal négatif, certes faible, et fait disparaître les réponses. Ici, la création de la boîte n’entraîne aucun coût supplémentaire puisque la facturation ne dépend pas du nombre d’utilisateurs.
Séparer ces messages de la correspondance
À partir d’un certain volume, il est préférable d’attribuer un circuit distinct aux e-mails transactionnels du site.
Les messages automatiques et les messages rédigés par des personnes n’ont pas le même comportement et ne sont pas évalués de la même façon. Une vague de cinq cents réinitialisations de mot de passe après un incident de sécurité ne ressemble en rien à la correspondance d’une personne. Si les deux catégories empruntent le même circuit, la réputation du trafic automatique devient aussi celle de vos échanges professionnels.
Les profils SMTP par domaine facilitent cette séparation : faites passer le domaine utilisé par l’application sur un circuit et celui de vos collaborateurs sur un autre. Un problème d’un côté reste ainsi limité à ce côté. Notre guide sur le SMTP personnalisé par domaine décrit la configuration.
Certaines entreprises vont plus loin et réservent un sous-domaine à tous leurs messages automatiques. La réputation est alors entièrement isolée, au prix d’une adresse d’expédition un peu moins élégante. L’intérêt dépend du volume envoyé.
Quand choisir un fournisseur transactionnel
Il faut être clair sur la limite : à très grande échelle, les services spécialisés dans l’e-mail transactionnel existent pour de bonnes raisons.
Si vous envoyez des dizaines de milliers de messages par jour, vous avez besoin d’événements de distribution pour chaque message, de rappels webhook en cas de rejet, d’une gestion des modèles et de statistiques détaillées. Ces fonctions constituent la raison d’être de ces services, et aucun hébergeur de messagerie généraliste ne les propose au même niveau.
Nos limites quotidiennes sont conçues pour la correspondance et non pour les campagnes : 1 000 messages par boîte et par jour avec Starter, jusqu’à 2 500 avec Agency. Les e-mails transactionnels d’une petite boutique ou d’un système de réservation respectent facilement ces limites. Une plateforme à fort volume ne le peut pas. Dans ce cas, la bonne architecture consiste à raccorder un fournisseur transactionnel au moyen d’un profil SMTP personnalisé. Vous séparez ainsi l’hébergement du courrier et les envois massifs sans devoir gérer deux fournisseurs de boîtes aux lettres.
Vérifier que tout fonctionne réellement
Comme cette catégorie de messages échoue sans alerte, la meilleure habitude consiste à vérifier la distribution plutôt qu’à la supposer.
Déclenchez un vrai message : passez une commande d’essai ou demandez une réinitialisation de mot de passe. Envoyez-le à des adresses chez deux grands fournisseurs différents. Ouvrez les en-têtes et vérifiez que SPF et DKIM sont validés, et que DMARC confirme l’alignement. Si les trois contrôles réussissent, la configuration est réellement terminée.
Répétez ce test chaque trimestre, ainsi qu’après toute modification du DNS ou tout changement d’hébergeur. Les e-mails transactionnels cessent le plus souvent de fonctionner non pas lors de leur configuration, mais après la modification d’un élément voisin. Personne ne pense à retester les confirmations de commande après avoir déplacé un serveur de noms.
Si les messages arrivent mais sont classés comme indésirables, les statistiques de distribution du domaine et les éventuels rapports DMARC indiquent généralement la cause plus rapidement que des modifications de contenu effectuées au hasard.
