« Le panier affiche les articles d’un autre client » : ce ticket de support, remonté deux jours après l’activation de Cloudflare Automatic Platform Optimization (APO) sur une boutique WooCommerce construite avec un thème bloc, décrit exactement le symptôme d’un cache de page appliqué là où il ne devrait jamais l’être.
Ce diagnostic couvre spécifiquement l’interaction entre APO et les pages dynamiques d’une boutique WooCommerce ; il ne traite ni l’optimisation d’images proposée par Cloudflare, ni la configuration du cache serveur côté WordPress lui-même, qui restent des sujets distincts.
Ce qu’APO fait par défaut
Cloudflare APO met en cache, au niveau du réseau Cloudflare lui-même, l’intégralité des pages HTML d’un site WordPress, y compris les pages qui ne devraient jamais être partagées entre visiteurs. Sur un thème classique WooCommerce, l’extension pose généralement, dès son activation, des règles d’exclusion automatiques pour les pages de panier, de compte et de commande, en s’appuyant sur les URL standards et des cookies WooCommerce reconnus.
Sur un thème bloc, plusieurs de ces mécanismes de détection automatique échouent silencieusement, car la structure des templates diffère de celle attendue par les règles historiques de l’extension : le template page-cart.html du thème bloc ne porte pas nécessairement les mêmes marqueurs que le fichier cart.php d’un thème classique, sur lesquels certaines heuristiques de détection reposent.
Symptôme précis observé
Le panier, rendu par le bloc natif woocommerce/cart intégré au template de thème bloc, se retrouvait mis en cache par Cloudflare pendant la fenêtre de validité par défaut d’APO. Deux visiteurs consultant la page panier à quelques minutes d’intervalle recevaient alors la même version HTML figée, contenant les articles du premier visiteur ayant déclenché la mise en cache.
Diagnostic : confirmer la source du problème
Avant de conclure à un problème Cloudflare, il faut écarter une cause côté serveur. La commande suivante, exécutée depuis un poste externe, révèle si la réponse provient du cache Cloudflare :
curl -I https://boutique.example.com/panier/ | grep -i cf-cache-statusUn en-tête cf-cache-status: HIT sur la page panier confirme sans ambiguïté que Cloudflare sert une version mise en cache, plutôt que de la laisser transiter jusqu’au serveur d’origine. Sur un site sans problème, cette page doit systématiquement renvoyer DYNAMIC ou BYPASS.
Correctif : poser des règles de bypass explicites
La correction se fait entièrement côté Cloudflare, via une règle de cache dédiée (Cache Rules), sans modification du thème ni de WordPress. La règle cible les chemins critiques et les cookies WooCommerce actifs :
// Règle Cloudflare (Cache Rules), condition d'exclusion :
(http.request.uri.path contains "/panier/")
or (http.request.uri.path contains "/commande/")
or (http.request.uri.path contains "/mon-compte/")
or (http.cookie contains "woocommerce_items_in_cart")
or (http.cookie contains "wp_woocommerce_session_")
// Action : Bypass cacheL’inclusion du cookie wp_woocommerce_session_ dans la condition est ce qui protège réellement contre les cas non couverts par le seul chemin d’URL : un visiteur avec un panier actif consultant n’importe quelle page ne doit jamais recevoir une version mise en cache contenant un fragment panier obsolète, y compris sur des pages qui ne sont pas nommément « panier » mais affichent un mini-panier dans l’en-tête du thème.
Cas du mini-panier dans l’en-tête
De nombreux thèmes blocs affichent un mini-panier (icône avec nombre d’articles) sur toutes les pages du site via un template part partagé. Si ce fragment est intégré directement dans le HTML rendu côté serveur plutôt que chargé en différé par JavaScript après affichage, la mise en cache de n’importe quelle page devient risquée. La solution la plus robuste consiste à extraire ce fragment de panier du rendu serveur en cache et à le charger en asynchrone via wp_localize_script() et un appel fetch() côté client, ce qui rend la page principale entièrement cacheable sans risque d’affichage périmé.
Vérification post-correctif
Après la mise en place des règles, une nouvelle série de tests avec deux sessions de navigateur distinctes (une en navigation privée, une classique) confirme que chaque session reçoit son propre contenu de panier, avec l’en-tête cf-cache-status: DYNAMIC sur toutes les pages sensibles.
Un problème de cache qui mélange les visiteurs se résout toujours à la source : il vaut mieux exclure trop de pages du cache que d’en exclure trop peu sur une boutique en ligne.
En résumé
Cloudflare APO n’est pas responsable en soi de ce type d’incident : le problème vient de règles d’exclusion automatiques mal adaptées à la structure d’un thème bloc. Poser explicitement des règles de bypass basées sur les chemins d’URL critiques et les cookies de session WooCommerce corrige le symptôme en quelques minutes, une fois le diagnostic confirmé par l’en-tête cf-cache-status.
