« Le panier de mon client affiche des articles qu’il n’a jamais ajoutés. » Ce type de signalement, remonté après l’activation d’un cache de page agressif sur une boutique WooCommerce, cache presque toujours le même mécanisme : un fragment Ajax mis en cache par erreur en même temps que la page HTML statique.
WooCommerce affiche le mini-panier et certains blocs du tunnel via des fragments régénérés en Ajax à chaque chargement, précisément pour éviter ce genre de problème avec les caches de page. Le souci apparaît quand une configuration de cache trop permissive capture aussi ces réponses Ajax comme si elles étaient statiques.
Le mécanisme des fragments WooCommerce
Le filtre woocommerce_add_to_cart_fragments permet à WooCommerce de renvoyer, après chaque action Ajax sur le panier, un fragment HTML à jour pour le mini-panier, sans recharger toute la page. Ce fragment transite par l’endpoint wc-ajax=get_refreshed_fragments, appelé côté client en JavaScript.
Le problème survient lorsque le plugin de cache traite cet endpoint comme une page ordinaire : il enregistre la première réponse générée pour un visiteur donné, puis la sert telle quelle à tous les visiteurs suivants qui partagent la même URL de cache — ce qui inclut le contenu du panier du premier visiteur.
Pourquoi WP Rocket peut être en cause malgré ses réglages par défaut
WP Rocket exclut nativement les pages marquées comme dynamiques par WooCommerce (panier, commande, mon compte) de sa mise en cache. Le problème apparaît généralement quand une règle de cache personnalisée a été ajoutée pour accélérer une page qui embarque elle-même un appel Ajax vers wc-ajax, par exemple une page d’accueil avec un mini-panier sticky, sans que cette règle exclue explicitement les requêtes Ajax.
Corriger l’exclusion du cache
La correction passe par une exclusion explicite des requêtes portant le paramètre wc-ajax dans les réglages avancés de WP Rocket, section « Cache Ajax » ou via le fichier de configuration si la mise en cache est pilotée par un réglage serveur en complément :
// Dans wp-config.php ou un mu-plugin, s'assurer que WooCommerce
// ne sert jamais ces requêtes depuis un cache de page
add_action('init', function () {
if (isset($_GET['wc-ajax'])) {
nocache_headers();
define('DONOTCACHEPAGE', true);
}
});Sur les hébergements avec un cache serveur en plus de WP Rocket (Varnish, cache d’objet géré par l’hébergeur), il faut vérifier que cette même exclusion existe à ce niveau : un cache applicatif bien configuré ne suffit pas si un cache serveur intercepte la requête avant que WordPress ne s’exécute.
Vérifier la correction avec deux navigateurs distincts
- Ajouter un produit A au panier dans un navigateur, ou une fenêtre de navigation privée
- Ajouter un produit B, différent, dans un second navigateur ou une seconde fenêtre privée
- Recharger la page contenant le mini-panier dans les deux fenêtres et vérifier que chacune affiche son propre contenu
- Répéter le test après avoir vidé le cache de page pour confirmer que le comportement tient dans la durée, pas seulement au premier chargement
Il est utile d’automatiser ce contrôle plutôt que de le refaire manuellement à chaque mise à jour de WP Rocket ou de WooCommerce : un petit script de supervision, exécuté depuis un service externe, peut effectuer deux requêtes successives avec des cookies de session différents sur la page contenant le mini-panier et comparer les fragments renvoyés. Un écart entre les deux réponses, alors qu’aucun cookie commun n’est utilisé, doit immédiatement déclencher une alerte, bien avant qu’un client ne s’en aperçoive de son côté.
Le cas particulier des thèmes avec panier persistant en en-tête
Certains thèmes premium affichent un compteur d’articles dans l’en-tête, visible sur absolument toutes les pages du site, y compris la page d’accueil et les fiches produit les plus consultées. Ce compteur repose lui aussi sur un fragment Ajax WooCommerce, ce qui multiplie les points d’exposition au même risque : si l’en-tête entier fait partie d’un cache HTML statique sans exclusion du compteur, l’incident touche alors la quasi-totalité des pages du site plutôt que la seule page panier, ce qui aggrave nettement l’impact visible pour les clients.
Dans ce cas de figure, il vaut mieux extraire le compteur de panier dans un appel Ajax distinct, chargé après le rendu de la page en cache, plutôt que de l’inclure dans le HTML mis en cache lui-même. Cette séparation nette entre contenu statique et contenu dynamique reste la meilleure garantie de robustesse, quel que soit le plugin de cache utilisé par la suite.
En résumé
Un panier qui affiche le contenu d’un autre visiteur n’est presque jamais un bug WooCommerce en tant que tel, mais une exclusion de cache mal posée sur les requêtes wc-ajax. Vérifier systématiquement cette exclusion à chaque niveau de cache actif sur l’hébergement — plugin, serveur, CDN — évite ce type d’incident, aussi rare qu’embarrassant pour la confiance des clients.
