# Les e-mails de commande WooCommerce n’arrivent pas

> Une commande passe, mais ni vous ni le client ne recevez d’e-mail : c’est l’un des cas les plus fréquents que je traite sur WooCommerce, et la cause n’est presque jamais WooCommerce lui-même. Le plugin génère le message correctement dans l’immense majorité des cas ; c’est son transport vers la boîte de réception qui échoue, souvent sans qu’aucune erreur ne remonte dans votre tableau de bord.

- Source canonique : [https://allaux.fr/wordpress-woocommerce/problemes/emails-commande-non-recus](https://allaux.fr/wordpress-woocommerce/problemes/emails-commande-non-recus)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Ouvrez WooCommerce > État > Journaux et cherchez une erreur fatale à l’heure exacte de la commande : si le hook d’envoi plante, aucun message n’est même généré. Sinon le message part mais n’est pas livré. Contrôlez le destinataire dans WooCommerce > Réglages > E-mails, puis remplacez l’envoi par la fonction mail() de PHP par un relais SMTP authentifié.

## Comment je procède

1. **Vérification des réglages WooCommerce** — Je commence par WooCommerce > Réglages > Emails : je vérifie que le type d’e-mail concerné (nouvelle commande, en cours, terminée…) est bien activé et que le champ « destinataire(s) » contient la bonne adresse, sans espace ni typo.
2. **Lecture des journaux WooCommerce** — J’ouvre WooCommerce > Statut > Journaux. Si un plugin provoque une erreur fatale pendant le hook d’envoi, elle y apparaît : c’est la première piste quand aucun e-mail ne part, pas même vers les indésirables.
3. **Envoi d’un test isolé** — J’envoie un e-mail de test pour distinguer un message jamais généré, plus rare, d’un message généré mais jamais livré, de loin le cas le plus fréquent sur les boutiques que je vois.
4. **Vérification du transport** — Par défaut, WordPress envoie via wp_mail(), qui repose sur la fonction mail() de PHP. Beaucoup d’hébergeurs la bloquent ou la limitent, et sans alignement SPF/DKIM pour le domaine d’envoi, le message part en indésirables ou disparaît.
5. **Mise en place d’un relais SMTP authentifié** — La correction durable passe presque toujours par un service d’envoi transactionnel connecté en SMTP authentifié, via un plugin qui s’accroche au hook phpmailer_init au lieu de laisser le serveur envoyer en direct.

## Ce que je traite régulièrement

- Le client affirme n’avoir reçu aucune confirmation, alors que la commande existe bien dans l’administration
- Je ne reçois plus les notifications de « nouvelle commande », même en vérifiant les indésirables
- Tout fonctionnait, puis plus rien du jour au lendemain, sans modification connue de mon côté
- L’e-mail de réinitialisation de mot de passe n’arrive jamais, alors que la confirmation de commande fonctionne
- Les e-mails finissent par arriver, mais avec plusieurs heures de retard

## Deux problèmes très différents derrière un même symptôme

WooCommerce ne gère pas l’envoi lui-même : il construit le contenu de l’e-mail (nouvelle commande, facture, avoir…) puis le confie à wp_mail(), la fonction native de WordPress. Sur la plupart des hébergements mutualisés, wp_mail() retombe sur la fonction mail() de PHP, qui envoie directement depuis le serveur sans authentification. C’est ce cas de figure qui explique la grande majorité des e-mails jamais reçus.

Sans enregistrements SPF et DKIM correctement alignés pour le domaine d’envoi, les grands fournisseurs de messagerie traitent ce trafic comme suspect : le message part en indésirables, ou il est purement et simplement rejeté sans notification côté site. C’est un problème de délivrabilité, pas un bug WooCommerce.

Un second cas, plus rare, est celui d’un message qui n’est même jamais généré : un plugin de cache qui met en cache la page « commande reçue » peut, mal configuré, court-circuiter le hook responsable de l’envoi. Les deux situations se ressemblent pour le client, mais se corrigent très différemment.

## Ce qui relève du réglage, ce qui relève du développement

> Vérifier qu’un type d’e-mail est activé et que le destinataire est correct, c’est à la portée du commerçant ou d’un généraliste, directement dans WooCommerce > Réglages > Emails. Diagnostiquer un conflit de hook, lire une erreur fatale dans les journaux, ou configurer proprement un relais SMTP authentifié avec ses clés d’API, c’est le travail que je fais.

## Pages liées

- **Problème de paiement WooCommerce** — Commande bloquée ou webhook en échec : un autre symptôme qui touche le même tunnel de commande. ([/wordpress-woocommerce/probleme-paiement](/wordpress-woocommerce/probleme-paiement))
- **Maintenance WooCommerce** — Surveillance et interventions régulières pour éviter que ce type de panne ne se reproduise en silence. ([/services/maintenance](/services/maintenance))
- **WordPress & WooCommerce** — La page d’ensemble sur les pannes et évolutions que je traite sur ces plateformes. ([/wordpress-woocommerce](/wordpress-woocommerce))

## FAQ

### Comment savoir si le problème vient de WooCommerce ou de mon hébergeur ?

En envoyant un e-mail de test depuis WooCommerce et en vérifiant les journaux (Statut > Journaux). Si aucune erreur n’apparaît côté WooCommerce, le problème est presque toujours dans le transport de l’e-mail par le serveur.

### Faut-il installer un plugin payant pour régler ça ?

Pas forcément un plugin payant, mais presque toujours un service d’envoi transactionnel tiers connecté en SMTP, dont beaucoup ont une offre gratuite suffisante pour le volume d’une boutique moyenne.

### Pourquoi les e-mails de commande fonctionnent mais pas ceux de mot de passe ?

Ce sont deux hooks WordPress différents. Il arrive qu’un plugin ou une personnalisation interfère avec l’un sans toucher l’autre, ce qui explique ce genre d’écart apparemment illogique.

### Est-ce que je risque de perdre l’historique des commandes pendant la correction ?

Non. Le problème se situe uniquement au niveau de l’envoi des notifications, jamais au niveau des commandes elles-mêmes, qui restent enregistrées normalement dans la base de données.