Dépannage WooCommerce : erreurs fréquentes et solutions (protocole WP Clinique)

Votre boutique WooCommerce ne prend plus les commandes, et chaque heure d’arrêt se compte en ventes perdues. Cette page sert à une chose : identifier votre panne, puis vous envoyer à la procédure qui la traite.

Cinq pannes couvrent la quasi-totalité des incidents WooCommerce : le panier qui se vide, la page de commande qui tourne en boucle, le paiement accepté sans commande créée, les emails de commande qui ne partent pas, et l’erreur critique après une mise à jour.

Si la panne dépasse la boutique, écran blanc, site inaccessible ou erreur serveur, commencez par notre protocole de dépannage WordPress.

Repérez d’abord l’étape exacte où le parcours casse : ajout au panier, page de commande, paiement, création de la commande, ou email de confirmation. Cette localisation élimine à elle seule la moitié des causes possibles.

• Le panier se vide tout seul : cache, sessions ou CDN. Traité plus bas.
• La page de commande tourne en boucle : minification JavaScript, HTTPS, conflit de thème. Traité plus bas.
• Les emails de commande n’arrivent pas : envoi serveur, SMTP absent, actions planifiées. Traité plus bas.
• Le paiement est accepté mais aucune commande n’apparaît : le retour de la passerelle échoue. Voyez le protocole d’urgence des erreurs de paiement.
• Erreur critique juste après une mise à jour : incompatibilité entre extension, thème et version de PHP. Voyez le guide des erreurs de mise à jour.

Notez le message exact et le moment précis où il apparaît. C’est l’information qui fait gagner le plus de temps, que vous corrigiez vous-même ou que vous passiez la main.

Un panier qui se vide vient presque toujours du cache. Les pages panier, commande et compte client portent une session propre à chaque visiteur. Mises en cache ou servies par un CDN, elles renvoient la même page à tout le monde, et le panier disparaît.

• Excluez les pages panier, commande et mon compte du cache, côté extension, côté serveur et côté CDN.
• Vérifiez le domaine des cookies. Un site servi tantôt avec www, tantôt sans, perd la session à chaque bascule.
• Contrôlez la durée de vie des sessions WooCommerce et le cache objet, qui peut resservir un panier périmé.

Une page de commande qui recharge sans fin a trois causes dominantes : une minification JavaScript qui casse les scripts de WooCommerce, une redirection HTTPS mal réglée, ou un conflit entre votre thème et une extension.

• Désactivez la minification et la concaténation JavaScript, puis rechargez la page de commande.
• Vérifiez que le site ne sert qu’une seule version d’URL, en HTTPS, sans boucle de redirection.
• Basculez sur un thème par défaut le temps du test. Si la boucle disparaît, le thème ou ses surcharges WooCommerce sont en cause.

Si la page de commande s’affiche correctement mais que le paiement échoue, la panne est ailleurs : elle est traitée dans le protocole d’urgence des erreurs de paiement.

L’envoi natif de PHP part sans authentification : il finit en indésirable ou disparaît en route. Un service SMTP règle la majorité des cas. Le reste vient des actions planifiées de WooCommerce, qui empilent les envois sans jamais les exécuter.

• Passez l’envoi en SMTP authentifié, ou par un service d’envoi transactionnel.
• Vérifiez SPF et DKIM sur votre domaine. Un email parti n’est pas un email délivré.
• Regardez la file des actions planifiées. Une file bloquée arrête les emails, mais aussi la synchronisation du stock et les relances.

Reproduisez la panne avec une commande test avant de toucher à quoi que ce soit, activez les journaux, puis testez les extensions par lots sur une préproduction. Une modification à la fois, sinon vous ne saurez pas laquelle a corrigé.

• Passez une commande test avec un produit simple et une livraison standard.
• Notez le message exact et l’étape où il survient.
• Activez les journaux WooCommerce et les erreurs PHP de votre hébergeur.
• Désactivez les extensions par lots sur la préproduction, jamais en production.
• Documentez chaque correctif : ce qui a été fait, quand, et pourquoi.

Le rapport d’état du système de WooCommerce donne l’état de la boutique en une page, et la documentation de journalisation indique où sont stockés les journaux.

Activer les journaux sans afficher d’erreur à vos clients

À placer dans wp-config.php, sur la préproduction de préférence. La documentation officielle de WordPress détaille chaque constante.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Une fois le dépannage terminé, désactivez le débogage et supprimez le fichier de journal. Il expose vos chemins serveur à qui sait où regarder.

Si les journaux révèlent une erreur 500, notre guide de l’erreur 500 WordPress donne la marche à suivre complète.

Une erreur qui disparaît ne prouve rien. Repassez le parcours complet, du panier à la page de confirmation, avec un vrai paiement, et vérifiez que la commande, l’email et le stock ont bien suivi.

• Parcours complet : panier, page de commande, paiement, page de confirmation.
• Contrôles : compte client, email reçu, stock décrémenté, taxes, codes promo, livraison.
• Journaux propres pendant un achat test, du début à la fin.

Une panne corrigée peut revenir à la mise à jour suivante. Notre protocole de surveillance après dépannage décrit le suivi qui l’évite.