vendredi 25 septembre 2026

À propos

Contact

Hébergement & serveurs

Emails transactionnels WordPress : pourquoi wp_mail() échoue et comment le fiabiliser

Un client se plaint que les e-mails de commande ou de réinitialisation de mot de passe n'arrivent jamais. Le coupable est presque toujours la fonction mail() du serveur, pas WordPress.

Par Clément Hadrot • 13 octobre 2021 • 4 min de lecture • Aucun commentaire
Emails transactionnels WordPress : pourquoi wp_mail() échoue et comment le fiabiliser

« Le client dit qu’il ne reçoit jamais les commandes par e-mail. » Cette phrase revient régulièrement en support, et la première réaction est souvent de chercher un bug dans le code du site, dans le thème ou dans l’extension d’e-commerce. Dans l’immense majorité des cas, le problème est ailleurs : la fonction wp_mail(), qui gère l’envoi de tous les e-mails générés par WordPress, s’appuie par défaut sur la fonction mail() native de PHP, connue pour sa fiabilité limitée.

Comprendre pourquoi cette fonction pose problème, et comment la remplacer par un envoi SMTP authentifié, résout la quasi-totalité des cas de non-réception — qu’il s’agisse d’un e-mail de réinitialisation de mot de passe, d’une confirmation de commande, ou d’une notification de formulaire de contact.

Pourquoi mail() est un mauvais point de départ

La fonction mail() de PHP transmet le message directement à l’agent de transfert de courrier local du serveur (souvent Sendmail ou Postfix en configuration minimale), qui tente ensuite de le livrer directement au serveur de messagerie du destinataire. Ce trajet direct, sans authentification ni réputation d’expéditeur établie, est traité avec une grande méfiance par les grands fournisseurs de messagerie comme Gmail ou Outlook, qui filtrent agressivement ce type d’envoi vers le dossier spam, voire le rejettent silencieusement.

Le symptôme le plus trompeur est que wp_mail() retourne souvent true, laissant croire que l’e-mail est parti avec succès, alors que cette valeur signifie seulement que le message a été transmis à l’agent local — pas qu’il a été livré à son destinataire final.

Basculer vers un envoi SMTP authentifié

La solution consiste à faire transiter les e-mails par un serveur SMTP authentifié, qu’il s’agisse d’un service dédié (comme un fournisseur d’e-mail transactionnel) ou d’une adresse professionnelle classique avec identifiants. Ce mécanisme s’appuie sur le hook phpmailer_init, qui permet de configurer directement l’objet PHPMailer utilisé en interne par WordPress :

add_action( 'phpmailer_init', function( $phpmailer ) {
    $phpmailer->isSMTP();
    $phpmailer->Host       = 'smtp.exemple.fr';
    $phpmailer->SMTPAuth   = true;
    $phpmailer->Port       = 587;
    $phpmailer->Username   = 'envoi@exemple.fr';
    $phpmailer->Password   = getenv( 'SMTP_PASSWORD' );
    $phpmailer->SMTPSecure = 'tls';
    $phpmailer->From       = 'envoi@exemple.fr';
    $phpmailer->FromName   = 'Exemple';
} );
L'essentiel à retenir : wp_mail() repose par défaut sur la fonction mail() de PHP, peu fiable ; Un serveur SMTP authentifié résout la majorité des cas de non-livraison ; phpmailer_init permet de brancher SMTP sans plugin

Le mot de passe ne doit jamais être écrit en dur dans le thème : il doit provenir d’une variable d’environnement ou d’une constante définie dans wp-config.php, en dehors du dossier public du site. C’est un détail de sécurité trop souvent négligé sur ce type de configuration.

Passer par un plugin plutôt qu’un code personnalisé

Pour un client qui doit pouvoir modifier ces réglages sans intervention d’un développeur, un plugin dédié à la configuration SMTP reste préférable à du code personnalisé dans le thème. L’interface graphique de ces extensions inclut généralement un test d’envoi qui confirme immédiatement si la configuration fonctionne, sans attendre qu’un vrai client se plaigne de ne rien recevoir.

Points à vérifier avant de considérer le problème résolu

  • Le nom de domaine d’expédition correspond-il au domaine réellement autorisé à envoyer (voir SPF) ?
  • L’adresse d’expédition existe-t-elle réellement, plutôt qu’un noreply@localhost générique ?
  • Le test d’envoi arrive-t-il en boîte de réception, ou toujours en spam malgré le SMTP ?

Diagnostiquer sans deviner

Un plugin de journalisation des e-mails, ou un simple hook temporaire sur wp_mail_failed, permet de capturer les erreurs réelles plutôt que de supposer :

add_action( 'wp_mail_failed', function( $error ) {
    error_log( 'Échec envoi mail : ' . $error->get_error_message() );
} );

Un e-mail « envoyé » selon WordPress et un e-mail réellement reçu par un destinataire sont deux affirmations très différentes. Ne jamais confondre les deux en support client.

En résumé

La fiabilité des e-mails transactionnels ne se joue pas dans le code métier du site, mais dans la façon dont ils quittent le serveur. Remplacer la fonction mail() native par un envoi SMTP authentifié, avec une adresse d’expédition cohérente avec le domaine, résout la grande majorité des cas de non-réception constatés sur des sites WordPress en production.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi