« Mon client a acheté un article que je n’avais pas mis dans mon panier. » Ce message, reçu par un support client un lundi matin, signale presque toujours la même cause : un cache Varnish installé devant WooCommerce sans exclusion des pages dynamiques du tunnel d’achat.
Le symptôme est spectaculaire et inquiétant à juste titre : deux visiteurs anonymes qui naviguent au même moment peuvent se retrouver avec un contenu de panier mélangé, voire une page « mon compte » affichant les informations d’un autre client. Sur une boutique en production, ce genre d’incident doit être traité en urgence, car il touche à la confidentialité des données.
Symptôme observé
Le pattern typique remonté par les tickets de support ressemble à ceci : un visiteur ajoute un produit A à son panier, rafraîchit la page quelques minutes plus tard, et découvre un produit B qu’il n’a jamais ajouté. Dans les cas les plus graves, la page /mon-compte/ affiche le nom et l’historique de commandes d’un autre client. Cela n’a rien à voir avec un bug de WooCommerce : c’est Varnish qui sert une réponse HTTP mise en cache à la mauvaise personne.
Varnish, par défaut, met en cache une réponse en fonction de l’URL demandée, sans tenir compte du cookie de session envoyé par le navigateur. Si la configuration VCL ne l’en empêche pas explicitement, une page générée pour le visiteur A avec son panier peut être stockée et resservie telle quelle au visiteur B qui demande la même URL.
Diagnostic : repérer les pages concernées
Le diagnostic commence par l’inspection des en-têtes de réponse HTTP. Une requête sur la page panier qui renvoie X-Varnish-Cache: HIT ou un en-tête équivalent selon la configuration est le signe que la page a bien été servie depuis le cache, alors qu’elle ne devrait jamais l’être.
curl -I https://exemple-boutique.fr/panier/
# Chercher dans la réponse :
# X-Cache: HIT
# Age: 340
Un Age supérieur à zéro sur une page panier confirme le problème : la réponse a été générée il y a plusieurs minutes et n’est donc plus liée au visiteur courant.
Correctif : exclure les pages dynamiques du cache
La règle de fond est simple à énoncer, moins évidente à appliquer correctement : toute page qui dépend de la session (panier, compte, commande, checkout) doit passer directement au backend, sans jamais être mise en cache. Le fichier VCL doit exclure ces URLs et respecter la présence du cookie WooCommerce.
sub vcl_recv {
if (req.url ~ "^/(panier|mon-compte|commande|checkout)") {
return (pass);
}
if (req.http.Cookie ~ "woocommerce_items_in_cart" ||
req.http.Cookie ~ "wp_woocommerce_session_") {
return (pass);
}
}
Le second bloc est essentiel : même en dehors des URLs identifiées, la présence d’un cookie de session WooCommerce doit systématiquement basculer la requête en mode pass, c’est-à-dire sans passage par le cache.
Vérifier aussi le cache de fragments et les widgets panier
Un piège fréquent subsiste même après avoir corrigé la page panier elle-même : le mini-panier affiché en en-tête sur toutes les pages du site, souvent chargé via un fragment AJAX WooCommerce (wc_ajax=get_refreshed_fragments). Si cette route AJAX n’est pas également exclue du cache, le compteur d’articles et le contenu du mini-panier restent incohérents même quand la page panier complète est correctement traitée.
- Exclure toutes les routes contenant
wc-ajaxdu cache Varnish - Vérifier que le plugin de cache côté WordPress (s’il y en a un en plus de Varnish) respecte les mêmes exclusions
- Tester avec deux navigateurs différents en simultané pour confirmer l’absence de fuite
Prévention : séparer clairement cache de page et session
La règle qui évite ce genre d’incident : jamais de cache partagé sur une réponse qui contient un cookie de session utilisateur, point final. Le gain de performance de Varnish doit se limiter aux pages réellement identiques pour tous les visiteurs.
Une fois la configuration VCL corrigée, il reste prudent de purger intégralement le cache Varnish (varnishadm ban req.url ~ .) pour éliminer toute entrée déjà polluée, puis de surveiller les journaux d’accès pendant quelques jours pour confirmer qu’aucune page de panier n’est plus jamais servie en HIT.
Notre verdict
Varnish reste un excellent choix de cache devant WordPress, y compris devant une boutique WooCommerce, à condition de traiter le tunnel d’achat comme un territoire à part entière, jamais mis en cache. Ce type d’incident, bien que rare une fois la configuration correcte en place, illustre pourquoi la mise en cache d’un site marchand exige une vigilance différente de celle d’un simple site vitrine : la moindre erreur de règle VCL touche directement à la confidentialité des visiteurs.
