Un badge « Plus que 2 en stock » affiché alors que l’article venait d’être réapprovisionné le matin même : c’est le signalement reçu d’un client gérant une petite boutique de matériel photo d’occasion, quelques jours après l’activation du module de cache de fragment de W3 Total Cache sur son site en éditeur de site.
Ce billet décrit le symptôme observé, le diagnostic de la règle de cache en cause et le correctif appliqué pour exclure spécifiquement le pattern concerné. Les autres options de configuration de W3 Total Cache et la mise en place d’un CDN ne sont pas traitées dans ce billet.
Symptôme : un contenu qui ne se met pas à jour
Le pattern fiche-produit-stock, utilisé sur le template de fiche produit du thème bloc, affichait un badge de stock calculé par un bloc dynamique interrogeant en temps réel la table de gestion des stocks. Après l’activation du cache de fragment de W3 Total Cache, ce badge continuait d’afficher une valeur ancienne pendant plusieurs heures après chaque mise à jour du stock en base de données, alors que le reste de la fiche produit — description, prix — se mettait à jour normalement.
Le comportement différencié entre le badge et le reste de la page était le premier indice sérieux : seul un élément précis restait figé, ce qui orientait vers un problème de cache localisé plutôt que vers un dysfonctionnement du calcul de stock lui-même.
Diagnostic : le fragment cache englobe trop large
Le module de cache de fragment de W3 Total Cache fonctionne par délimitation manuelle de zones dans le code du thème, via des commentaires spéciaux mfunc et mclude, ou par configuration de zones basées sur des identifiants de bloc. Sur ce thème, la zone de cache de fragment avait été configurée trop largement : elle englobait tout le pattern fiche-produit-stock, y compris le bloc dynamique de stock, avec une durée de vie de quatre heures pensée pour la description produit, rarement modifiée, et non pour le stock, qui change plusieurs fois par jour.
La commande d’inspection du cache de fragment côté serveur a confirmé l’hypothèse : le fichier de cache correspondant à la fiche produit contenait bien le HTML complet du badge de stock, gelé au moment de sa première génération après la dernière purge.
wp w3-total-cache flush fragment --path=fiche-produit-1042
Cette commande a immédiatement rafraîchi l’affichage du badge, confirmant que le problème résidait bien dans le périmètre de la zone de cache, pas dans le calcul du stock.
Correctif : exclure le badge de la zone de cache
La solution retenue a consisté à réduire le périmètre du fragment cache pour qu’il ne couvre que la description produit, stable, en sortant explicitement le bloc de badge de stock de la zone mise en cache via un marqueur de fin de zone repositionné juste avant le bloc concerné.
<!-- mfunc dynamic-cached-content -->
<!-- wp:pattern {"slug":"wpm/description-produit"} /-->
<!-- /mfunc dynamic-cached-content -->
<!-- wp:wpm/badge-stock /-->
Le badge de stock, désormais hors de la zone de cache de fragment, est recalculé à chaque affichage de la page, ce qui reste acceptable en termes de performance puisqu’il s’agit d’une seule requête indexée sur une table de faible volume.
Une alternative envisagée puis écartée
Réduire la durée de vie du cache de fragment à quelques minutes plutôt qu’à quatre heures aurait aussi limité le problème, sans le résoudre complètement : un client consultant une fiche produit dans les minutes suivant une vente aurait pu voir un stock erroné malgré tout. L’exclusion complète du bloc dynamique de la zone de cache a été jugée plus fiable, au prix d’un gain de performance légèrement moindre sur cette portion précise de la page.
Prévention pour les prochains patterns
- Documenter systématiquement, pour chaque pattern du thème, la nature de ses blocs internes : statique, dynamique lié à un contenu rarement modifié, ou dynamique lié à une donnée changeant fréquemment.
- Configurer les zones de cache de fragment au niveau du bloc le plus fin possible, jamais au niveau du pattern entier dès qu’il mélange des natures de contenu différentes.
- Tester la mise à jour d’une donnée dynamique juste après l’activation d’une nouvelle règle de cache, avant de la considérer comme validée en production.
Un cache de fragment mal délimité ne provoque pas d’erreur visible : il produit un mensonge silencieux, souvent plus coûteux à détecter qu’une panne franche.
En résumé
Ce cas rappelle qu’un pattern d’éditeur de site peut mélanger des blocs de natures très différentes en apparence homogènes, et que la configuration d’un cache de fragment doit toujours suivre cette granularité réelle plutôt que la structure visuelle du pattern. Un contrôle de cohérence après chaque changement de règle de cache reste la meilleure prévention contre ce type de régression silencieuse.
