Une mise à jour WordPress tourne, la page se recharge, et pourtant l’ancienne bannière s’affiche encore. Ce scénario, des milliers de webmasters le vivent chaque mois sans comprendre d’où vient le décalage. Le réflexe habituel consiste à accuser le plugin de cache, à le désactiver, parfois à le supprimer. Le problème se situe ailleurs : dans la façon dont ce plugin décide qu’une version de page est morte. Un cache qui gère mal les versions coûte plus cher qu’une absence totale de cache.
Le cache ne sert pas du vieux contenu par hasard
Quand vous publiez un article ou modifiez un titre, WordPress enregistre les changements en base de données. Le cache, lui, stocke une copie statique de la page générée pour éviter de reconstruire la requête à chaque visite. Tant que cette copie existe, le visiteur reçoit l’ancienne mouture, même si la base contient la nouvelle.
Ce n’est donc pas un bug : c’est le principe même du cache. La question n’est pas de savoir s’il garde du contenu, mais comment il apprend qu’il faut le jeter. Sur ce terrain, les stratégies de référencement naturel et les plugins se croisent plus qu’on ne le croit, et les analyses publiées sur mobitex.fr montrent bien que la fraîcheur d’une page pèse sur le classement.
Le mécanisme d’invalidation repose sur des événements. À chaque sauvegarde, WordPress déclenche des hooks, et le plugin écoute ceux qu’il connaît. S’il n’écoute pas le bon, ou s’il écoute un hook qui se déclenche trop tôt, la purge n’a pas lieu au bon moment. Résultat : une page périmée continue de servir, et vous la découvrez en navigation privée, souvent par hasard, parfois rapportée par un client.
Pourquoi le contenu obsolète survit à la mise à jour
Les causes se recoupent presque toujours. Une purge par URL ne fonctionne pas si le thème modifie la structure des permaliens. Une purge globale déclenchée trop souvent annule l’intérêt du cache, mais une purge trop rare laisse passer les vieilles versions.
Entre les deux, il existe un mécanisme plus fin : la purge par version, qui associe à chaque contenu un identifiant de révision. Quand la révision change, l’ancienne copie devient orpheline et le plugin sert la nouvelle.
Ce système a un avantage considérable. Il ne dépend pas d’une correspondance exacte entre l’URL demandée et l’URL purgée, ce qui le rend résistant aux variations de paramètres, aux versions mobile et aux pages de pagination.
Un plugin qui ne raisonne qu’en URL brute se trompe dès qu’un paramètre traîne, et laisse vivre des fichiers périmés pendant des jours. Le symptôme est déroutant : vous videz le cache à la main, tout rentre dans l’ordre, puis le problème revient à la publication suivante. Sur ce point, voir aussi notre article sur hreflang balises 404.
Ce qui distingue un plugin qui purge correctement
Le critère décisif n’est ni le nombre d’options ni la taille de l’interface. C’est la manière dont le plugin relie une mise à jour à la version qu’elle remplace. Voici ce qu’il faut regarder avant d’installer quoi que ce soit.
- Le plugin écoute-t-il les hooks de publication, de mise à jour et de suppression, ou seulement celui de sauvegarde des articles ?
- Une purge par version, qui invalide toutes les copies liées à une révision, plutôt qu’une purge par URL.
- Que se passe-t-il quand vous modifiez un menu ou un widget ? La page d’accueil se rafraîchit ou reste figée ?
- Le nettoyage des anciennes entrées est automatique, ou faut-il vider la table à la main tous les mois ?
WP Fatest Cache coche justement cette case du nettoyage automatique : il supprime les anciennes versions mises en cache dès que du contenu est mis à jour, ce qui évite l’accumulation de copies mortes. LiteSpeed Cache, lui, propose une version gratuite compatible avec WooCommerce et couvre la mise en cache des pages, la minification du CSS et du JavaScript, ainsi que l’usage d’un CDN. Deux approches différentes, mais toutes deux pensées pour que l’invalidation suive la publication au lieu de la subir.
Attention au piège de l’entrée de gamme. WP Fatest Cache ne permet d’activer le lazy loading et la minification qu’en payant, et WP Rocket n’a aucune version gratuite. Ce n’est pas rédhibitoire en soi, mais cela déplace le curseur : un plugin gratuit qui gère mal les versions vous coûtera plus cher en temps perdu qu’un plugin payant correctement conçu. Le prix affiché n’est jamais le vrai coût.
Le vrai coût d’un cache qui se trompe de version
Un visiteur qui tombe sur une page périmée ne se dit pas « leur cache est mal configuré ». Il voit un site abandonné, un prix qui ne correspond plus, une date de rupture de stock dépassée.
Selon la page Hostinger, 40 % des visiteurs quittent un site s’il prend plus de trois secondes à se charger, et cette statistique sert souvent à justifier l’installation d’un cache. On oublie la suite logique : un cache qui sert du contenu obsolète fait fuir autrement plus vite qu’un chargement lent, parce que le visiteur n’a même pas la sensation que quelque chose cloche, il croit simplement que votre information est fausse.
Le calcul est vite fait. Une page produit avec un ancien tarif, c’est un panier abandonné. Un article corrigé qui affiche encore la coquille, c’est un commentaire désagréable et un lien partagé qui pointe vers une version fausse. Le coût ne se lit pas dans la facture du plugin, il se lit dans les conversions perdues et dans le temps passé à chercher pourquoi le site raconte n’importe quoi.
Choisir un cache sur sa logique de purge, pas sur sa popularité
Avant d’installer, testez le comportement réel plutôt que la fiche descriptive. Modifiez un titre, videz le cache du navigateur, rechargez en navigation privée, puis regardez si le changement apparaît immédiatement. Publiez un brouillon, supprimez-le, vérifiez que rien ne reste. Ces trois gestes révèlent en cinq minutes ce qu’aucune page de présentation ne dira jamais. Un plugin qui échoue à ces tests n’a pas sa place sur un site qui publie régulièrement.
Bon, tout cela demande un peu de méthode, et c’est justement là que beaucoup reculent. Franchement, installer un cache sans comprendre sa purge revient à poser une serrure sans vérifier qu’elle se reverrouille. Le plugin n’est jamais le coupable idéal : c’est la stratégie d’invalidation qui décide si votre site montre la bonne version au bon moment. Reste une question qui mérite d’être posée avant la prochaine mise à jour : quand vous publiez, savez-vous vraiment ce que vos visiteurs voient dans la seconde qui suit ?
