Un client ne reçoit pas sa confirmation et le support cherche immédiatement une nouvelle solution SMTP. Ce changement peut être inutile si WooCommerce n’a jamais généré le message. Pour trouver la cause, reconstruisez la chaîne depuis l’événement de commande jusqu’à la boîte du destinataire.
Vérifier l’événement et le message attendu
Choisissez une commande de test identifiable et relevez son historique. Vérifiez le message qui doit partir pour cet événement, son activation et ses destinataires dans les réglages WooCommerce. Un état de commande inattendu peut expliquer l’absence d’une notification, même lorsque la fonction d’envoi fonctionne.
La documentation officielle rappelle que WooCommerce s’appuie habituellement sur la fonction de messagerie WordPress et distingue les problèmes de génération des problèmes de réception. Selon la version et les outils installés, les journaux disponibles varient. Cherchez une trace exploitable plutôt que de supposer qu’un écran de réglages suffit à confirmer un envoi.
Suivre le transport
Si un message a été généré, recherchez son passage dans le système d’envoi. Relevez l’heure, le résultat et une référence technique, avec des informations personnelles limitées. Un retour favorable de l’application signifie une prise en charge à cette étape ; il ne prouve pas nécessairement l’arrivée dans la boîte de réception.
Exemple fictif : la boutique génère une confirmation, mais le service d’envoi refuse l’expéditeur. Modifier le texte du modèle n’aidera pas. Autre cas : le message est accepté et livré, mais le client le cherche dans une autre boîte. Le même symptôme visible demande alors une réponse différente.
Examiner l’identité de l’expéditeur
Vérifiez l’adresse d’envoi, le domaine utilisé et les mécanismes d’authentification requis par votre service. Contrôlez les enregistrements DNS nécessaires sans supprimer les réglages de la messagerie existante. Le guide DNS Hostiaz explique pourquoi site et e-mails peuvent dépendre de services distincts.
Ne publiez jamais les mots de passe ou clés du service d’envoi dans un ticket. Si un accès doit être renouvelé, identifiez d’abord les autres applications qui l’utilisent. Un changement destiné à réparer la boutique peut interrompre des formulaires ou des notifications qui partageaient le même accès.
Tester la réception dans plusieurs situations
Utilisez des destinataires de test sur différents services et vérifiez le classement du message. Inspectez les refus ou les rebonds disponibles. Essayez également un message de réinitialisation WordPress : il peut emprunter une chaîne proche sans apparaître dans les mêmes journaux WooCommerce.
Si une notification est différée, contrôlez les tâches planifiées. Pour un remboursement, vérifiez le mouvement financier indépendamment du message. Un e-mail est une information sur l’opération, pas sa seule preuve.
Corriger la bonne étape
Appliquez une correction limitée, puis rejouez l’événement de test et suivez chaque étape. Évitez les renvois multiples aux clients pendant le diagnostic. Notez les messages déjà expédiés afin que la remise en service ne crée pas une série de confirmations identiques.
WPASSIST présente ses interventions WordPress pour cadrer ce type d’incident. Fournissez l’événement, l’heure et les états observés, avec un exemple anonymisé. Ce dossier permet d’expliquer précisément où la chaîne s’arrête au lieu de remplacer la messagerie sans diagnostic.
Sources et vérification
Sources primaires consultées le 30 septembre 2026.
