Vérifier d’abord quel message manque
La commande est payée, mais le client n’a reçu aucun courriel de la boutique. Ou le marchand attend une alerte alors que le client a bien son récapitulatif. Ces messages ne partagent pas forcément le même déclencheur ni le même destinataire. Le résultat recherché est l’envoi du bon document, à la bonne adresse, sans modifier artificiellement le paiement.
Distinguez la page de confirmation affichée après achat, le reçu éventuel du prestataire et les courriels WooCommerce. L’un peut fonctionner alors que l’autre échoue. Si seule la page finale manque, examinez le retour du paiement et la requête de commande ; changer les réglages de courrier ne réparera pas cette redirection.
Ce guide vise une boutique WordPress utilisant déjà WooCommerce. Il faut un accès autorisé aux commandes, aux réglages de courriels et aux journaux. Un gestionnaire peut examiner la commande, tandis que la configuration globale peut nécessiter l’administrateur. Sur un réseau multisite, vérifiez la boutique sélectionnée. Les droits d’accès au transport de courriel restent propres à l’hébergement ou au prestataire. Sur WordPress.com, ouvrez WP Admin pour retrouver ces écrans si WooCommerce y est installé ; cela ne donne pas accès à la configuration du serveur.
La version examinée est WooCommerce 11.2.1, extension gratuite d’Automattic. Elle déclare WordPress 7.0 et PHP 7.4 au minimum, avec un test jusqu’à WordPress 7.1.4. Ses journaux transactionnels intégrés permettent de commencer sans installer un nouvel outil. Une ancienne version peut présenter moins d’informations : ne cherchez pas un écran nouveau comme s’il avait toujours existé. Ces minima de compatibilité ne recommandent pas une ancienne version PHP.
Relier le courriel attendu au vrai statut de la commande
Dans WooCommerce, Commandes, ouvrez la commande concernée. Vérifiez son statut, son paiement et ses notes. Si un encaissement confirmé laisse encore la commande En attente de paiement, traitez d’abord le rapprochement avec la passerelle. L’événement qui devait annoncer le paiement peut ne pas avoir été exécuté ; il ne s’agit pas forcément d’un défaut de transport du courrier.
Le message Nouvelle commande s’adresse aux destinataires marchands configurés. Le message Commande en cours ou Processing order concerne le client après le passage correspondant à la préparation. Le message Commande terminée ou Completed order accompagne la fin de traitement. Selon les produits, une commande peut atteindre directement l’état terminé ; n’attendez pas nécessairement deux courriels identiques.
Un message de commande en attente, une note au client et un récapitulatif envoyé manuellement ont encore d’autres fonctions. Notez le nom exact attendu avant toute intervention. Le reçu du prestataire ne prouve pas que WooCommerce a généré son propre message, et une notification marchand reçue ne prouve pas que l’adresse du client est correcte.
Ne faites pas passer la commande d’un état payé à En attente, puis de nouveau à En cours, pour provoquer un courrier. Les transitions peuvent déclencher stock, automatisations et messages supplémentaires. Gardez le statut fidèle à la situation commerciale et utilisez les réglages ou actions de courrier adaptés.
- Statut incohérent avec l’encaissement : rapprocher le paiement avant le diagnostic électronique.
- Message désactivé ou adresse incorrecte : appliquer le premier parcours.
- Message attendu mais aucune tentative visible : examiner événement, file et journal.
- Tentative réussie localement mais courrier absent : examiner le transport et le classement dans la boîte.
Parcours 1 : corriger l’activation et la bonne adresse
Ouvrez WooCommerce, Réglages, E-mails, puis Gérer sur le type concerné. Pour une notification automatique, vérifiez Activer cette notification par e-mail et enregistrez si elle avait été désactivée par erreur. Conservez la valeur initiale. L’activation règle les prochains événements ; elle n’envoie pas automatiquement toutes les confirmations manquées dans le passé.
Pour Nouvelle commande ou une autre alerte marchand, contrôlez le champ Destinataire(s). Il peut contenir plusieurs adresses séparées par des virgules. Vérifiez que la boîte surveillée correspond à ce réglage, sans supposer que l’adresse du compte connecté ou l’adresse générale d’administration le remplace toujours. Ne mettez pas tous les clients en copie d’une notification interne.
Pour une confirmation client, ouvrez la commande et examinez l’adresse de facturation enregistrée. Les courriels client usuels utilisent cette adresse, qui peut différer du profil utilisateur actuel. Une commande invitée n’a pas besoin de compte pour posséder son destinataire. Modifier le profil d’un client ne corrige pas nécessairement l’adresse déjà enregistrée sur cette commande.
Si une faute est confirmée par un canal fiable, utilisez le crayon de la zone Facturation pour corriger uniquement le courriel, puis Mettre à jour dans Actions de commande. Ne rechargez pas toute l’adresse depuis le profil pour corriger une seule lettre : d’autres données pourraient être remplacées. Dans Notes de commande, choisissez Note privée, saisissez la raison de la correction, puis Ajouter, sans recopier inutilement de données personnelles.
Le résultat attendu est une notification activée et un destinataire exact pour le document voulu. Pour annuler une correction de réglage inadaptée, remettez sa valeur initiale. Une adresse erronée ne doit pas être rétablie pour le seul confort du retour arrière ; documentez plutôt la valeur confirmée. Avant l’envoi ciblé décrit plus loin, vérifiez qu’aucune tentative différée ne va déjà produire le même message.
Parcours 2 : lire le journal transactionnel intégré
Dans WooCommerce 10.9 et les versions ultérieures examinées, ouvrez WooCommerce > État > Journaux. Dans Browse log files ou Parcourir les fichiers journaux, sélectionnez la source transactional-emails et la date concernée. Ouvrez le fichier et recherchez le numéro de commande ainsi que le type de courriel. Avec un stockage en base, utilisez la vue de journal correspondante. Commencez par les données présentes, sans envoyer plusieurs messages pour remplir le journal. Les notes privées de commande peuvent aussi signaler une tentative réussie ou échouée.
Lisez le résultat exact. Sent indique que le message a été remis au système d’envoi sans erreur locale détectée ; ce n’est pas une preuve d’arrivée en boîte. Failed indique un échec de cette tentative. Disabled signifie que le type était désactivé. Skipped indique qu’une condition manquait, par exemple un destinataire. Ces distinctions évitent de changer l’expéditeur pour un message qui n’a jamais été tenté.
Si les lignes attendues sont absentes, ouvrez l’onglet Settings ou Réglages des journaux. Vérifiez activation, conservation et Level threshold. Pour voir les réussites INFO, les non-envois NOTICE et les échecs WARNING, choisissez temporairement Info si le seuil actuel les masque, puis enregistrez. None signifie tous les niveaux, pas absence de journalisation. Si le champ est imposé par WC_LOG_THRESHOLD, faites vérifier cette configuration par son responsable. Conservez le réglage initial et rétablissez-le après le diagnostic ; ce changement ne recrée pas les anciens événements.
Les destinataires peuvent apparaître sous un nom d’utilisateur ou guest plutôt que sous leur adresse complète. Ce libellé ne démontre pas un destinataire manquant ; vérifiez l’adresse dans la commande. Un message d’erreur lisible peut aussi demander un rapprochement avec le journal du transport pour confirmer sa cause exacte. Dans cette version, Disabled et Skipped sont consignés dans le journal mais ne créent pas les mêmes notes de tentative que Sent ou Failed. L’absence de note ne prouve donc pas que le type était activé.
Le résultat attendu est la localisation du défaut : activation, condition, événement ou envoi. Un journal vide n’autorise pas à déclarer que le message a été reçu, supprimé ou bloqué par le client. Examinez aussi les erreurs fatales au même instant si la génération semble s’arrêter. Aucun outil de journalisation installé après coup ne peut reconstituer un événement qui n’était pas enregistré.
Examiner une file de courriels différés sans tout rejouer
Dans WooCommerce, Réglages, Avancé, Fonctionnalités, vérifiez si Deferred emails ou l’envoi différé des courriels est activé. Cette fonction décale le traitement de certaines notifications vers une file. Son état peut également être influencé par une personnalisation. La désactiver ne constitue pas une méthode générale de récupération des messages déjà en attente.
Ouvrez WooCommerce > État > Actions planifiées. La version examinée utilise le groupe woocommerce-emails et l’action woocommerce_send_queued_transactional_email pour cette file. Utilisez la recherche, puis les vues Pending ou Failed selon l’état recherché. Rapprochez le crochet, le groupe, l’heure et les arguments avec la commande. Une autre action planifiée présente dans la liste peut ne rien avoir à voir avec son courrier.
Consultez l’état et le journal de l’action identifiée. Une action en attente doit encore être exécutée ; une action en échec demande la correction de son erreur avant une nouvelle tentative. Si la file entière ne progresse plus, examinez le fonctionnement des tâches de fond avec le responsable du site. Ne supprimez pas toutes les actions pour faire disparaître les alertes.
Une exécution manuelle peut réellement envoyer des courriels. Sur une copie isolée, avec base distincte et tous les destinataires dirigés vers une boîte de test, ouvrez le détail de l’action identifiée. Après correction, utilisez Run uniquement pour cette action si le lien est disponible et l’essai autorisé, puis consultez son journal. Ne lancez pas Run en bloc. Sur la boutique active, choisissez un seul moyen de récupération : reprise de cette notification ou document ciblé, après contrôle du risque de doublon.
Le résultat attendu est une action qui se termine et une tentative de courrier visible dans le journal. Ne confondez pas une action achevée avec une réception en boîte : le transport reste à vérifier. Le retour arrière vise le réglage de tâche ou le composant corrigé ; il ne retire pas les messages déjà expédiés. Conservez les actions utiles à l’historique au lieu de vider leur liste.
Parcours 3 : tester le transport sans utiliser une commande client
Si le journal indique Sent ou Failed, vérifiez le système qui envoie réellement le courrier. WooCommerce utilise normalement la fonction wp_mail de WordPress ; un outil déjà présent peut la relier à un service SMTP ou à une API. Un résultat local réussi signifie que cette étape a accepté le message, pas que la boîte du destinataire l’a affiché.
Dans WooCommerce > Réglages > E-mails, repérez Email Preview lorsque cette interface est disponible. Sélectionnez le type dans la liste, puis Send a test email. Saisissez une boîte que vous contrôlez et confirmez une seule fois. Ces contrôles existent aussi dans l’écran individuel avec Email improvements activé. Si votre interface ne les propose pas, utilisez le test documenté du transport déjà installé. Ne changez pas de système d’édition de courriels pour ce seul essai. Le courrier de test est réel, mais ne demande ni achat ni changement de statut.
Comparez la tentative avec le journal du prestataire déjà configuré. Recherchez heure, destinataire et identifiant de message lorsque celui-ci est disponible. Distinguez acceptation, mise en file, rejet et retour d’erreur. Si le service refuse l’authentification ou l’expéditeur, corrigez ce paramètre selon le compte utilisé avant une nouvelle tentative limitée ; n’ajoutez pas un second outil concurrent d’envoi.
Le résultat attendu est un test reçu et un chemin d’envoi compris. Un aperçu arrivé démontre ce chemin à cet instant ; il ne prouve pas que l’événement de commande a déclenché son propre courrier. Si l’aperçu fonctionne mais qu’aucune tentative transactionnelle n’apparaît, revenez à la génération et à la file au lieu de recréer la connexion.
Gardez les réglages initiaux avant une correction du transport et rétablissez les paramètres sans rapport avec la panne. Les secrets révoqués ou expirés ne deviennent pas valides par simple retour de valeur. Aucun mot de passe ni jeton ne doit être copié dans la commande, la console ou un rapport public.
Vérifier l’expéditeur et la réception sans refaire toute la configuration
Dans WooCommerce, Réglages, E-mails, examinez le nom et l’adresse d’expédition. Ils doivent correspondre à une identité que votre service d’envoi est autorisé à utiliser. Un outil de transport peut imposer sa propre adresse : comparez le message réellement reçu plutôt que de conclure à partir d’un seul champ de l’administration.
Ne placez pas l’adresse du client dans From pour résoudre un courrier manquant. Le destinataire reçoit le message ; l’expéditeur représente la boutique ou le domaine autorisé. Une adresse de réponse peut être différente, mais elle ne remplace pas l’authentification de l’expéditeur. Corrigez la valeur responsable, enregistrez et refaites seulement le test utile.
Si le prestataire accepte le message mais que la boîte ne le montre pas, vérifiez indésirables, quarantaine et règles de réception. Pour un message reçu en spam, lisez ses en-têtes d’authentification avec le responsable du domaine : SPF, DKIM et DMARC portent sur des identités précises. Un résultat réussi ne garantit pas à lui seul le classement en boîte principale.
Cette étape n’exige pas de remplacer les serveurs DNS, les enregistrements de réception ou toute la messagerie. Utilisez les valeurs demandées par votre prestataire pour le domaine effectivement contrôlé. Si le défaut est limité à la délivrabilité, traitez-le dans le diagnostic correspondant plutôt que de modifier les statuts commerciaux.
Le résultat attendu est un expéditeur autorisé et une réception vérifiable. Conservez la valeur validée et la preuve du message témoin. Le retour arrière d’une mauvaise modification porte sur ce seul réglage ; il n’existe pas de commande permettant de retirer un courrier déjà accepté par une boîte extérieure.
Envoyer un récapitulatif ciblé après la correction
Lorsque le client doit recevoir à nouveau les informations et que l’état de paiement est exact, ouvrez sa commande. Vérifiez l’adresse de facturation, le statut et l’absence d’une notification équivalente encore programmée. L’action manuelle disponible n’est pas nécessairement la reproduction exacte du message automatique Commande en cours.
Dans Actions de commande, choisissez Envoyer les détails de la commande au client, ou Send order details to customer, puis Appliquer une seule fois. Cette action produit le courriel Order Details, historiquement associé au nom technique customer_invoice. Elle envoie le récapitulatif selon l’état actuel de la commande ; ce n’est ni un nouveau paiement ni une preuve d’encaissement.
Si la commande est encore considérée comme impayée, ce document peut contenir une demande ou un lien de paiement. C’est pourquoi le rapprochement précède son envoi dans le cas d’un achat déjà encaissé. Ne l’utilisez pas pour annoncer que tout est payé alors que WooCommerce conserve un état faux. Le modèle personnalisé doit également être contrôlé si son texte affirme un paiement sans condition.
Pour une alerte manquante chez le marchand, l’action Resend new order notification correspond à un autre destinataire et à un autre type de message. Ne choisissez pas cette commande en espérant joindre le client. Vérifiez les destinataires configurés avant de la déclencher et évitez les deux actions si une seule répond au besoin.
Le résultat attendu est une tentative unique du document voulu dans transactional-emails et sa réception vérifiée. Une note disant que les détails ont été envoyés manuellement n’est pas à elle seule une preuve de livraison. Attendez le résultat avant un nouveau clic. Un courrier déjà expédié ne s’annule pas ; si son contenu était incorrect, faites traiter la correction de communication séparément, sans oscillation de statut.
- Ouvrez la seule commande concernée et rapprochez son paiement, son adresse de facturation et les notifications encore en attente.
- Dans Actions de commande, sélectionnez Send order details to customer pour le client, ou Resend new order notification pour le marchand, selon le besoin établi.
- Cliquez Appliquer une fois, puis contrôlez transactional-emails et la boîte autorisée avant toute autre tentative.
Valider les prochains événements sans multiplier les envois
Pour vérifier le déclenchement automatique, utilisez une copie isolée avec base distincte, paiements en mode test et tous les courriels dirigés vers des destinations sûres. Neutralisez les intégrations commerciales réelles, tout en conservant la notification entrante du paiement de test si elle déclenche la transition étudiée. Une commande de test vérifie ce scénario : statut, génération, éventuelle file, journal et réception. Elle ne valide pas tous les types de message ni tous les moyens de paiement.
Un aperçu de modèle ne remplace pas ce contrôle de l’événement. Inversement, il n’est pas nécessaire de créer dix commandes pour tester une simple faute d’adresse déjà identifiée. Choisissez la vérification qui correspond à la couche corrigée et conservez son résultat.
Sur le site actif, suivez ensuite les commandes concernées sans déclencher des renvois collectifs. Une correction d’activation ou de transport peut laisser des dossiers anciens à reprendre individuellement. Vérifiez pour chacun le document encore utile et les tentatives déjà exécutées ; une reprise de file peut produire un message après votre intervention manuelle.
Conservez une note des réglages corrigés, du message attendu et du résultat final. La résolution est complète lorsque l’état commercial reste exact, que le bon événement produit le bon courriel et que son acheminement est vérifié. Les commandes récentes et leur historique doivent être préservés ; une restauration globale de la boutique n’est pas un moyen de renvoyer une confirmation.
