Emails WooCommerce : vos clients les reçoivent-ils vraiment ?

Le problème silencieux

Un client passe commande. Il ne reçoit pas de confirmation. Il rappelle. Vous vérifiez : la commande est bien là, le paiement est encaissé, mais l’email n’est jamais parti.

C’est un des problèmes les plus fréquents sur WooCommerce. D’après l’équipe WooCommerce elle-même, plus de 1 % de toutes leurs interactions support concernent le dépannage des emails transactionnels (source : developer.woocommerce.com). Et le pire, c’est que la plupart des marchands ne savent même pas que leurs emails ne partent pas — jusqu’à ce qu’un client se plaigne.

Jusqu’ici, diagnostiquer le problème nécessitait un plugin tiers (WP Mail Log, WP Mail SMTP, etc.) pour capturer les envois et voir ce qui échouait. Avec WooCommerce 10.9, le logging des emails transactionnels devient natif.

Ce que WooCommerce 10.9 change

Une nouvelle classe EmailLogger se branche sur quatre hooks internes de WooCommerce :

woocommerce_email_sent se déclenche après chaque envoi d’email transactionnel, avec un booléen succès/échec. woocommerce_email_disabled se déclenche quand un type d’email est désactivé dans les réglages. woocommerce_email_skipped se déclenche quand WooCommerce n’envoie pas un email pour une raison technique (pas de destinataire, par exemple). Et wp_mail_failed, le hook global de WordPress, capture les erreurs PHPMailer/SMTP réelles (“SMTP connect() failed”, “Could not authenticate”, etc.).

Le tout s’écrit dans le logger standard de WooCommerce (wc_get_logger()) sous une nouvelle source transactional-emails. Ça respecte la configuration existante de votre boutique : handler fichier ou base de données, seuil de log, rétention — tout ce que vous avez déjà paramétré dans WooCommerce > État > Journaux.

Trois niveaux de lecture

Chaque entrée de log utilise un niveau de sévérité qui permet de filtrer rapidement :

INFO — l’email a été envoyé avec succès. En production, vous n’avez probablement pas besoin de voir ceux-là. Si votre boutique est configurée en “erreurs uniquement”, ils n’apparaîtront pas.

NOTICE — l’email n’a pas été envoyé, mais c’est voulu. Soit le type d’email est désactivé dans les réglages WooCommerce, soit il manque un destinataire. Ce n’est pas une erreur, c’est un comportement attendu.

WARNING — l’email a échoué. C’est ce qui vous intéresse en priorité. Le log inclut le message d’erreur SMTP réel, ce qui permet de diagnostiquer directement : mauvais identifiants, serveur SMTP inaccessible, port bloqué, etc.

Chaque entrée contient un contexte structuré :

[
    'source'     => 'transactional-emails',
    'email_type' => 'customer_processing_order',
    'status'     => 'sent', // ou 'failed', 'disabled', 'skipped'
    'recipient'  => 'jdoe',  // username, jamais l'adresse email
    'order'      => 12345,
]

Les emails apparaissent aussi dans les notes de commande

En plus des logs, les emails liés à une commande apparaissent désormais directement dans les notes de commande (WooCommerce > Commandes > sélectionner une commande). Vous voyez quels emails ont été envoyés pour cette commande et s’ils ont réussi ou échoué.

Si vous êtes passé au checkout en blocs WooCommerce, rien ne change de ce côté : les emails post-commande se déclenchent exactement de la même façon, et le logging les capture à l’identique.

Un point de design intéressant : seuls les emails que WooCommerce a tenté d’envoyer apparaissent dans les notes. Les emails désactivés ou ignorés (pas de destinataire) n’y figurent pas, pour ne pas encombrer la vue. Si vous avez besoin de cette information, elle est dans les logs.

Privacy first : pas d’adresse email dans les logs

L’équipe WooCommerce a fait un choix important : aucune adresse email n’est écrite dans les logs. Le champ recipient contient le nom d’utilisateur WordPress correspondant (via get_user_by( 'email' )), ou guest si le client n’a pas de compte.

Les messages d’erreur PHPMailer contiennent parfois l’adresse email en clair (“Could not send to [email protected]”). Ces messages passent par une fonction redact_emails() qui masque les adresses avant l’écriture en log.

C’est un détail qui compte pour la conformité RGPD : vos fichiers de log ne contiennent pas de données personnelles identifiables.

Cas concrets de diagnostic

”Mon client n’a pas reçu sa confirmation de commande”

Allez dans WooCommerce > État > Journaux, filtrez par source transactional-emails et cherchez le numéro de commande. Vous verrez immédiatement si l’email a été envoyé (INFO), échoué (WARNING) avec le message d’erreur, ou s’il était désactivé (NOTICE).

”Les emails partaient, puis ils se sont arrêtés”

Cherchez les WARNING dans les logs. Si vous voyez une série de “SMTP connect() failed” à partir d’une certaine date, c’est probablement un changement côté hébergeur ou une expiration de mot de passe SMTP. Le message d’erreur vous dira exactement ce qui a changé.

”Je ne sais pas quels emails sont actifs”

Les entrées avec le statut disabled vous montrent les types d’email que vous avez désactivés dans WooCommerce > Réglages > Emails. C’est utile quand on reprend une boutique existante et qu’on veut comprendre la configuration en place.

Personnaliser le comportement

Désactiver le logging des emails

Si vous utilisez déjà un plugin de logging dédié ou si vous voulez réduire le volume de logs :

add_filter( 'woocommerce_email_log_enabled', '__return_false' );

Désactiver pour un type d’email spécifique

add_filter( 'woocommerce_email_log_enabled', function( $enabled, $email_id ) {
    // Ne pas logger les emails de nouvelle commande (admin)
    if ( $email_id === 'new_order' ) {
        return false;
    }
    return $enabled;
}, 10, 2 );

Ajouter des informations au log

Le filtre woocommerce_email_log_context vous permet de modifier le tableau de contexte avant l’écriture. Si vous voulez ajouter un champ custom (l’ID du produit principal de la commande, par exemple), c’est là que ça se passe :

add_filter( 'woocommerce_email_log_context', function( $context ) {
    if ( isset( $context['order'] ) ) {
        $order = wc_get_order( $context['order'] );
        if ( $order ) {
            $items = $order->get_items();
            $first_item = reset( $items );
            if ( $first_item ) {
                $context['main_product'] = $first_item->get_product_id();
            }
        }
    }
    return $context;
} );

Ce que ça ne résout pas

Le logging vous dit ce qui s’est passé, pas ce qui va se passer. Si votre serveur SMTP est mal configuré, le log vous montrera les erreurs — mais c’est à vous de les corriger.

Les causes les plus fréquentes d’échec d’envoi restent les mêmes :

L’hébergeur mutualisé qui bloque wp_mail() ou limite le nombre d’envois par heure. Le serveur SMTP externe (SendGrid, Mailgun, Amazon SES) dont les identifiants ont expiré. Le plugin SMTP qui entre en conflit avec un autre plugin — et chaque extension ajoutée a un coût, comme je l’explique dans mon article sur l’impact des scripts et plugins tiers sur WooCommerce. Le DNS mal configuré (enregistrements SPF, DKIM, DMARC manquants) qui fait atterrir les emails en spam.

Le logging natif vous permet de détecter le problème rapidement. Pour le résoudre, il faudra souvent passer par un service SMTP externe fiable et vérifier votre configuration DNS. Plus largement, des emails qui partent de façon fiable font partie d’une boutique WooCommerce correctement optimisée, au même titre que la vitesse et la stabilité.

Limitation connue

wp_mail_failed est un hook global WordPress. Il se déclenche pour tout échec de wp_mail(), pas seulement ceux de WooCommerce. Si un autre plugin envoie un email qui échoue entre le début et la fin d’un envoi WooCommerce, l’erreur capturée pourrait être attribuée au mauvais email.

En pratique, c’est rare. Et ça ne concerne que le message d’erreur humain — le email_type et le status sont toujours exacts. L’équipe WooCommerce a documenté cette limitation dans le code.

En résumé

WooCommerce 10.9 ajoute un outil de diagnostic qui aurait dû exister depuis longtemps. Plus besoin d’installer un plugin tiers pour savoir si vos emails partent. Les logs sont structurés, respectent la vie privée, et s’intègrent dans le système de logging existant.

Si vous gérez une boutique WooCommerce, la première chose à faire après la mise à jour vers 10.9 : vérifier vos logs sur quelques jours. Vous pourriez découvrir des échecs d’envoi silencieux qui durent depuis des mois.

Vous avez des emails WooCommerce qui ne partent pas et vous ne savez pas pourquoi ? Demandez un audit gratuit — je diagnostique le problème et vous recommande la solution adaptée à votre configuration.