Un client nous a écrit un vendredi soir : « Un visiteur a vu le panier d’un autre client, avec son adresse et ses trois articles. » Panique légitime. En creusant les journaux du cache FastCGI installé quelques semaines plus tôt, la cause est apparue en quelques minutes : la page /panier/ était mise en cache comme n’importe quelle page vitrine, cookie de session ou pas.
Ce genre d’incident n’est pas rare. Dès qu’un site mélange contenu public et zones personnalisées, un cache de page agressif devient une arme à double tranchant : il accélère spectaculairement le site, mais peut aussi servir la page d’un visiteur à un autre si les exclusions ne sont pas posées correctement. Voici les motifs les plus fréquents, pourquoi ils posent problème, et comment les corriger durablement.
Ce qu’on voit sur le terrain
Le scénario le plus classique concerne WooCommerce : le panier, le paiement et la page « mon compte » sont mis en cache exactement comme la page d’accueil. Résultat, un visiteur A ajoute un produit, la page panier est générée et stockée dans le cache pendant, disons, dix minutes. Un visiteur B arrive juste après sur la même URL et reçoit la version en cache, donc le panier de A.
Autre variante plus insidieuse : le cache ignore le cookie wordpress_logged_in_* et sert aux visiteurs connectés la même page statique qu’aux anonymes. La barre d’admin disparaît, les widgets « bonjour Untel » affichent un nom générique, et certains thèmes qui personnalisent le menu selon le rôle utilisateur cassent complètement l’expérience.
Enfin, on rencontre des configurations où seule la home et les articles sont exclus manuellement, en oubliant les pages générées dynamiquement par des extensions tierces : espace membre, tableau de bord d’affiliation, formulaire de réservation avec disponibilités en temps réel.
Pourquoi c’est un problème plus grave qu’il n’y paraît
Le premier réflexe est de minimiser : « ça ne concerne que quelques pages ». Mais l’impact dépasse largement l’inconfort visuel. Sur un site e-commerce, un panier erroné entraîne des commandes ratées, des remboursements et une perte de confiance immédiate. Sur un espace membre, afficher les informations d’un autre utilisateur est une fuite de données personnelles, potentiellement soumise au RGPD si des données identifiantes fuitent réellement.
Le second problème est la difficulté à détecter l’incident. Le cache fonctionne « normalement » du point de vue serveur : pas d’erreur 500, pas de log d’exception. Le bug n’apparaît que côté visiteur, souvent signalé bien après coup par un client mécontent, ce qui complique le diagnostic rétroactif.
Configurer les exclusions correctement
La règle de base : ne jamais faire confiance uniquement à un plugin de cache pour détecter les pages sensibles. Les exclusions doivent être posées à plusieurs niveaux, redondants entre eux.
- Au niveau du serveur web (Nginx, Apache ou Varnish), exclure du cache toute requête portant un cookie
wordpress_logged_in_,wp_woocommerce_session_oucomment_author_. - Exclure explicitement par URL les pages panier, paiement, mon compte, ainsi que toute page marquée dynamique par une extension (réservation, devis, espace client).
- Désactiver le cache dès qu’un en-tête
Set-Cookieest émis par la réponse, ce qui couvre les cas non prévus. - Vérifier que le cache d’objets (s’il y en a un) respecte lui aussi la segmentation par utilisateur, notamment pour les fragments de panier affichés en AJAX.
Voici un exemple de règle côté Nginx qui refuse de servir depuis le cache dès qu’un cookie de session WordPress ou WooCommerce est présent :
set $skip_cache 0;
if ($request_uri ~* "/panier/|/mon-compte/|/paiement/") {
set $skip_cache 1;
}
if ($http_cookie ~* "wordpress_logged_in_|wp_woocommerce_session_") {
set $skip_cache 1;
}
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;Le test qui rassure avant mise en production
Avant de déployer une configuration de cache sur un site avec des zones personnalisées, un test simple et systématique évite bien des mauvaises surprises : ouvrir le site dans deux navigateurs différents (ou une fenêtre normale et une fenêtre privée), se connecter avec deux comptes distincts, et vérifier que chacun voit bien ses propres informations sur le panier, la page de compte et tout formulaire personnalisé.
Il faut répéter ce test après chaque mise à jour majeure du plugin de cache, du thème ou de WooCommerce, car une nouvelle version peut introduire une page ou un fragment qui échappe aux règles existantes. Un test automatisé, même basique, avec deux sessions cURL et comparaison des réponses, permet d’industrialiser ce contrôle dans une intégration continue.
En résumé
Le cache de page est l’un des leviers les plus efficaces pour accélérer WordPress, mais il ne pardonne aucune approximation sur les zones personnalisées. La bonne pratique consiste à exclure par cookie plutôt que par simple liste d’URL, à vérifier les fragments AJAX au même titre que les pages entières, et à tester systématiquement avec deux comptes distincts avant toute mise en production. Un panier vide affiché à tort coûte toujours plus cher que les quelques millisecondes économisées en le mettant en cache.
