Un client nous a signalé un incident délicat après la mise en place d’un plugin de cache de page sur sa boutique WooCommerce : un utilisateur avait vu, brièvement, le panier d’un autre visiteur en arrivant sur le site. La cause était classique — une exclusion de cache oubliée sur une page qui affichait un contenu personnalisé. Ce type d’incident, rare mais toujours embarrassant, mérite qu’on prenne le temps de comprendre précisément quelles zones d’une boutique WooCommerce sont incompatibles avec le cache de page brut, et pourquoi.
Le cache de page reste l’un des leviers de performance les plus efficaces pour une boutique WordPress, mais WooCommerce introduit des pages fondamentalement dynamiques, propres à chaque visiteur, qui n’ont rien à faire dans un cache partagé entre tous les internautes.
Les trois pages à exclure sans discussion
Trois pages WooCommerce affichent un contenu strictement personnel et ne doivent jamais être servies depuis un cache de page partagé :
- La page panier, qui affiche le contenu du panier de session propre à chaque visiteur ;
- La page de commande (checkout), qui affiche les données de facturation, de livraison, et le récapitulatif de la commande en cours ;
- La page « Mon compte », avec l’historique de commandes, les adresses enregistrées et les informations personnelles du client connecté.
Ces trois pages sont si sensibles que la plupart des extensions de cache sérieuses (WP Rocket, WP Super Cache, W3 Total Cache) les excluent automatiquement dès qu’elles détectent WooCommerce actif. Il est néanmoins indispensable de vérifier cette exclusion manuellement après chaque changement de structure d’URL ou de configuration multilingue, où l’URL de ces pages peut différer de ce que l’extension de cache attend par défaut.
Le cas plus subtil des fiches produit et pages catégorie
Contrairement aux trois pages précédentes, une fiche produit ou une page catégorie peut généralement être mise en cache : son contenu est identique pour tous les visiteurs anonymes. La nuance apparaît dès qu’un élément personnalisé s’y superpose : un prix différencié B2B affiché via un rôle utilisateur, un badge « Déjà dans votre panier », ou un stock affiché en temps réel qui doit rester exact à la minute près pour un produit à faible disponibilité.
Le fragment caching pour concilier cache et personnalisation
Plutôt que d’exclure entièrement une page à cause d’un seul élément dynamique, la technique du fragment caching consiste à mettre en cache la page dans son ensemble tout en excluant précisément le fragment personnalisé, régénéré côté client via une requête AJAX légère après le chargement de la page mise en cache. C’est exactement le principe du mini-panier dans l’en-tête d’un site WooCommerce mis en cache : la page est servie depuis le cache, puis un appel wc-ajax=get_refreshed_fragments vient rafraîchir uniquement le compteur du panier et son contenu :
add_filter( 'woocommerce_add_to_cart_fragments', function ( $fragments ) {
$fragments['.mini-panier-compteur'] = '<span class="mini-panier-compteur">'
. WC()->cart->get_cart_contents_count()
. '</span>';
return $fragments;
} );
Ce mécanisme, natif à WooCommerce, est justement pensé pour cohabiter avec un cache de page agressif : la page HTML statique reste identique pour tous, et seul le fragment JavaScript se met à jour après coup.
Le piège des cookies qui invalident le cache
Certaines extensions de cache basent leur décision de servir une page depuis le cache ou non sur la présence de cookies spécifiques. WooCommerce pose un cookie woocommerce_items_in_cart dès qu’un article est ajouté au panier, ce qui est justement l’un des signaux que les extensions de cache surveillent pour éviter de servir une page en cache à un visiteur qui a un panier actif — un visiteur avec panier non vide ne doit jamais recevoir une page catégorie mise en cache affichant un badge « ajouté au panier » obsolète, par exemple.
Vérifier concrètement ce qui est exclu
Pour auditer une configuration existante, la commande curl reste l’outil le plus fiable pour vérifier les en-têtes de cache retournés par le serveur, page par page :
curl -I https://exemple.fr/panier/
curl -I https://exemple.fr/commande/
curl -I https://exemple.fr/produit/exemple-produit/
Un en-tête Cache-Control: no-store ou no-cache doit apparaître sur les deux premières URL ; la troisième peut légitimement afficher un en-tête de cache actif si aucun contenu personnalisé n’y est injecté.
Sur chaque mise en cache déployée pour la première fois sur une boutique, nous testons systématiquement le scénario « deux navigateurs, deux paniers différents, ouverts en simultané » avant la mise en production. C’est un test simple qui révèle immédiatement une fuite de cache éventuelle.
En résumé
Mettre en cache une boutique WooCommerce n’est pas un choix binaire entre « tout cacher » et « rien cacher » : il s’agit d’exclure strictement les pages réellement personnelles (panier, commande, compte), de traiter les fiches produit au cas par cas selon leur contenu dynamique, et de s’appuyer sur le fragment caching pour concilier performance et personnalisation. Un test croisé avec plusieurs sessions simultanées reste le meilleur garde-fou avant toute mise en production d’une nouvelle configuration de cache.
