Un panier WooCommerce vidé au checkout n'est pas un problème de confort. Le client a choisi un produit, il arrive à l'étape de commande, puis le tunnel perd l'état du panier. La boutique peut toujours répondre en HTTP 200, mais la vente est déjà cassée.
La priorité consiste à vérifier si le panier disparaît pour un parcours contrôlé, à quel moment il disparaît, et si le signal est reproductible. La preuve utile ne contient pas le détail du panier d'un vrai client : elle montre seulement l'étape, le résultat attendu, le résultat observé et l'horodatage.
Reconnaître le symptôme sans le confondre
Un panier vidé peut prendre plusieurs formes. Le client peut être renvoyé vers une page panier vide, rester sur le checkout avec un message générique, perdre les frais de livraison, ou voir les moyens de paiement disparaître parce que WooCommerce ne voit plus de contenu à payer.
Ce n'est pas la même chose qu'un checkout WooCommerce bloqué, où le panier existe mais la commande ne termine pas. Ce n'est pas non plus forcément un paiement refusé WooCommerce, car le paiement peut ne jamais être atteint.
Vérifier dans le bon ordre
Le premier contrôle consiste à partir d'un panier synthétique connu. Ajoutez un produit simple, évitez les coupons, les comptes clients et les variations complexes pour isoler la persistance du panier. Le résultat attendu est stable : l'article ajouté doit apparaître au panier, puis au checkout, avec un total calculé.
Ensuite, comparez un parcours avec cache actif et un parcours après purge. Si le panier réapparaît après purge, la piste cache devient prioritaire. Si le problème reste identique, contrôlez les cookies de session et les règles de domaine : passage `www` vers domaine nu, HTTP vers HTTPS, sous-domaine, langue ou devise peuvent casser la continuité.
Contrôlez aussi la Store API. Un checkout moderne peut afficher une page correcte alors que `/wc/store/v1/cart` ou les endpoints de blocs renvoient un état vide, une erreur JSON ou un statut inattendu. Le résultat attendu n'est pas seulement une réponse 200 : il faut que le panier synthétique soit encore représenté dans l'état fonctionnel.
Interpréter les résultats
Si le HTML du checkout est servi depuis un cache public, la page peut ignorer le panier réel. Dans ce cas, la correction attendue est une exclusion stricte des pages panier, checkout et compte client, plus une vérification du cache CDN, serveur et plugin.
Si le cookie change ou disparaît pendant la navigation, la piste devient session, domaine, HTTPS ou consentement cookies. Un bandeau cookies mal configuré peut aussi bloquer des cookies nécessaires au fonctionnement WooCommerce.
Si la Store API devient vide alors que les cookies restent présents, regardez les plugins qui modifient panier, frais de livraison, devises, taxes, coupons ou Checkout Blocks. La bonne étape suivante n'est pas de tout désactiver en production, mais de reproduire en préproduction avec le même thème, les mêmes plugins et le même type de produit.
| Ce que vous observez | Où regarder | Piste privilégiée |
|---|---|---|
| Le panier réapparaît après purge du cache | Cache CDN, cache serveur, cache plugin, exclusion des pages panier, checkout et compte | La page était servie depuis un cache public qui ignorait le panier réel |
| Le cookie de session change ou disparaît en cours de navigation | Passage `www` vers domaine nu, HTTP vers HTTPS, sous-domaine, langue, devise, bandeau de consentement | La continuité de session est rompue avant le paiement |
| `/wc/store/v1/cart` renvoie un panier vide alors que les cookies sont présents | Plugins panier, livraison, devises, taxes, coupons, Checkout Blocks | Un statut 200 ne suffit pas : l'état fonctionnel est vide |
Exemple documenté de laboratoire
Point de départ : boutique de test, un nouveau plugin de cache page activé avec une règle couvrant tout le site. Panne reproduite : le produit synthétique s'ajoute correctement, le panier affiche bien une ligne, puis le checkout redirige vers panier vide. Le ping HTTP reste vert sur la home, le panier et le checkout, mais le signal métier échoue : le panier attendu n'est plus présent à l'étape de paiement.
Les hypothèses écartées : ce n'est pas un cookie de session bloqué (le panier existait avant le checkout), pas une panne Store API (elle répond, mais avec un panier vide servi depuis le cache), pas un problème de domaine (une seule origine dans le parcours). La preuve conservée indique alors le parcours, l'heure, l'étape en échec, le statut HTTP, le type de signal manquant et la récupération après exclusion du checkout de la règle de cache. Elle ne conserve pas de contenu panier client, pas d'identité acheteur et pas de donnée de paiement.
Confirmer le rétablissement
Ne déclarez pas l'incident résolu dès qu'un seul chargement semble correct. Rejouez le même parcours au moins deux fois, avec une session propre, puis vérifiez que le panier survit jusqu'au checkout et que les moyens de paiement attendus restent visibles.
Le rapport doit montrer la fenêtre d'incident, le premier run cassé, le dernier run cassé, le premier run revenu au vert et la piste la plus probable. Un exemple de structure est visible dans l'exemple d'incident.
Prévenir la récidive
La prévention passe par des règles simples : ne jamais cacher publiquement panier, checkout et compte client ; vérifier les cookies après changement de domaine ou de consentement ; tester Store API après mise à jour WooCommerce ; surveiller séparément produit, panier, checkout et confirmation.
Pour cadrer le niveau de surveillance, commencez par Mon Audit Gratuit. Les tarifs permettent ensuite de choisir la cadence et l'historique utiles selon le risque réel du checkout.