Vous venez de mettre à jour un prix, une offre d'emploi ou une page légale — et pourtant, une partie de vos visiteurs voit encore l'ancienne version. Parfois c'est vous, parfois un client à Roubaix ou un collaborateur à Valenciennes. Les problèmes de mise en cache qui affichent du contenu obsolète ne sont pas un bug mystérieux : c'est presque toujours une couche de cache mal configurée qui sert une copie périmée au lieu de recalculer la page.
Chez Apresta, on croise ce cas après chaque refonte, chaque changement tarifaire ou chaque correction RGPD sur les sites de TPE et PME qu'on accompagne dans la MEL et les Hauts-de-France. La bonne nouvelle : une fois le mécanisme compris, le diagnostic prend souvent moins d'une heure. Voici comment identifier quelle couche cache vous ment, la corriger sans sacrifier la vitesse, et éviter que ça se reproduise.
Symptômes : comment reconnaître un cache obsolète
Un problème de cache se manifeste rarement partout en même temps. C'est précisément ce caractère inégal qui permet de remonter la piste. La page est souvent correcte en navigation privée, mais pas en navigation normale — signe que le navigateur ou un cookie de session joue un rôle. Le changement peut apparaître sur desktop mais pas sur mobile, ou l'inverse, selon la façon dont chaque appareil accède au CDN. Certains utilisateurs voient la nouvelle version, d'autres l'ancienne, parfois selon leur ville ou leur FAI, parce que les serveurs edge ne se synchronisent pas au même rythme.
Un hard refresh (Ctrl+F5) affiche la bonne page alors qu'un simple rechargement ne le fait pas : le cache local est en cause. Les modifications backend (WordPress, PrestaShop) restent visibles en admin mais pas en front : le cache applicatif ou serveur sert encore l'ancien HTML. Après une mise en production, le site « revient » à l'ancien design pendant quelques heures : typique d'un CDN ou d'un reverse proxy qui n'a pas été purgé.
Si le problème disparaît en navigation privée, suspectez en priorité le cache navigateur ou un CDN edge. Si personne ne voit la mise à jour, le cache serveur ou un déploiement incomplet est plus probable.
Les quatre couches de cache à connaître
Comprendre où se situe la copie périmée évite de purger au hasard. Chaque couche obéit à ses propres règles ; purger l'une sans toucher aux autres ne résout souvent que la moitié du problème.
Le cache navigateur est le plus proche de l'utilisateur. Le navigateur garde CSS, JS, images et parfois des pages HTML en local selon les en-têtes HTTP (Cache-Control, ETag, Expires). C'est rapide pour l'utilisateur, mais un TTL mal calibré fige des ressources pendant des semaines.
Le cache CDN / reverse proxy — Cloudflare, OVH CDN, Fastly — stocke une copie de vos pages sur des serveurs proches de vos visiteurs. Excellent pour la performance, dangereux si le TTL est trop long ou si les règles d'invalidation manquent. C'est la couche qu'on suspecte en premier sur les sites à fort trafic.
Le cache applicatif / serveur regroupe les plugins WordPress (WP Rocket, W3 Total Cache, LiteSpeed), Varnish, Redis object cache, cache natif PrestaShop ou Symfony. Le HTML est généré une fois puis servi tel quel. Une purge locale sans purge CDN laisse une partie des visiteurs sur l'ancienne version.
Le cache opcode PHP (OPcache) garde le bytecode compilé. Moins fréquent pour du contenu obsolète visible en front, mais il explique parfois pourquoi un correctif de code ne semble pas pris en compte immédiatement après un déploiement.
Causes fréquentes chez les PME
TTL trop agressif
Un TTL de 24 h ou 7 jours sur des pages qui changent chaque semaine garantit des décalages. Les pages statiques (CGV, mentions légales stables) peuvent tolérer des durées longues ; les prix, stocks et bannières promotionnelles, non. Chez nous, on voit régulièrement des PME lilloises configurer un cache « performant » au lancement, puis ne jamais le réviser quand le site bascule vers l'e-commerce.
Purge manuelle oubliée
Après une mise à jour, personne n'a cliqué sur « Vider le cache » dans le plugin ou le panneau Cloudflare. Classique en équipe réduite où le marketing publie et le technique n'est pas prévenu. Le contenu est bien en base, mais personne ne déclenche l'invalidation. C'est un problème de process autant que de technique.
Cache partagé entre environnements
Staging et production pointent vers le même bucket CDN, ou un reverse proxy sert encore l'ancien build. On voit ça après des migrations mal isolées : la purge faite sur staging vide le cache prod, ou l'inverse — les deux environnements se marchent dessus.
Headers HTTP incohérents
Le serveur envoie Cache-Control: max-age=31536000 sur du HTML dynamique. Le CDN et le navigateur obéissent — et figent la page des mois. Un audit des en-têtes HTTP prend vingt minutes et évite des semaines de frustration.
Exclusions mal configurées
Panier, espace client et pages connectées doivent être hors cache. Si une page dynamique est cachée par erreur, les utilisateurs connectés voient parfois le contenu d'un autre visiteur — cas plus grave que du contenu obsolète, avec des implications RGPD.
Service Worker ou PWA mal versionné
Un service worker garde une copie offline. Après une mise à jour, l'ancienne version persiste jusqu'à ce que le SW se mette à jour — souvent au prochain passage complet sur le site. Les applications PWA nécessitent une stratégie de versioning explicite, pas un déploiement « on verra ».
Diagnostic : méthode en 30 minutes
Le diagnostic efficace suit un ordre logique : reproduire, lire les en-têtes, identifier la couche, vérifier le process de publication.
Commencez par reproduire méthodiquement. Testez en navigation privée, puis depuis un autre réseau (4G du téléphone) pour éliminer le cache local et le FAI. Comparez avec un outil externe — WebPageTest ou curl -I https://votresite.fr/page — pour voir ce que reçoit un visiteur sans votre historique de navigation.
Avec curl -I, repérez les en-têtes clés. Cache-Control indique la durée et les directives (no-cache, no-store, max-age). Age montre depuis combien de temps la réponse est en cache CDN. X-Cache, CF-Cache-Status ou X-LiteSpeed-Cache indiquent un hit ou miss selon la stack.
L'interprétation guide l'action. Age: 0 avec contenu obsolète pointe vers le cache serveur ou applicatif. CF-Cache-Status: HIT avec contenu ancien confirme le CDN. Des en-têtes corrects mais un navigateur qui persiste oriente vers le cache local ou un service worker. Du contenu obsolète partout, y compris en privé, évoque un déploiement non propagé ou une mauvaise branche Git.
Terminez en vérifiant le flux de publication. Qui publie ? Y a-t-un hook de purge automatique à la sauvegarde ? Si la réponse est « on purge quand on y pense », vous avez trouvé la cause process — et la correction technique ne suffira pas.
Pour aller plus loin sur l'infrastructure, notre guide CDN, cache et hébergement performances détaille les bonnes pratiques de configuration.
Corrections : par priorité
Urgent — contenu faux ou illégal visible
Quand un prix erroné ou une mention légale obsolète est visible publiquement, agissez dans l'heure. Purgez immédiatement le cache CDN et serveur, corrigez les headers sur les pages concernées (Cache-Control: no-cache temporaire si besoin), puis vérifiez en navigation privée et via un outil externe. Communiquez en interne : ne dites pas « c'est corrigé » tant que la purge n'est pas confirmée.
Ordre de grandeur : 15 à 45 minutes si vous avez accès aux panneaux. Sans accès technique, comptez une demi-journée d'intervention prestataire (150 à 400 € HT selon stack).
Important — stratégie de TTL par type de page
Une stratégie TTL cohérente évite de repurger chaque semaine. Les pages statiques (à propos, contact) tolèrent un TTL long avec purge à la modification. Le catalogue e-commerce demande un TTL court sur les fiches stock (5 à 15 min) ou une invalidation à la mise à jour produit. La homepage et les landing SEA méritent une purge systématique à chaque changement promo. Le HTML dynamique utilisateur doit porter Cache-Control: private, no-store.
Important — automatiser la purge à la publication
Sur WordPress, un hook save_post qui purge URL + homepage + sitemap élimine la dépendance à la mémoire humaine. Sur PrestaShop, vider le cache thème après modification module. Sur stack custom, un webhook vers Cloudflare API ou Varnish ban. L'automatisation coûte une demi-journée de setup et évite des dizaines d'incidents.
Plus tard — versioning des assets
Renommer style.css en style.v2.css ou utiliser un hash (style.a3f9b2.css) force le navigateur à télécharger la nouvelle version sans purger manuellement chaque visiteur. C'est la solution durable pour les CSS et JS, indépendamment du cache HTML.
Plus tard — séparer staging et production
Deux environnements, deux caches, deux CDN. Jamais de purge prod depuis staging. Cette séparation paraît évidente, mais on la retrouve manquante sur une refonte sur trois chez les PME qu'on audite.
Prévention : ne plus revivre ce scénario
La prévention repose sur trois piliers : documentation, routine et revue périodique. Documentez qui purge quoi (CDN, plugin, Redis, Varnish) — un simple tableau partagé suffit. Intégrez le test en navigation privée après chaque publication sensible dans la checklist marketing. Mettez en place des alertes si le déploiement ne se propage pas (monitoring uptime + comparaison checksum HTML).
Revoyez les TTL tous les 6 mois. Un site qui a évolué vers l'e-commerce ne peut pas garder les mêmes règles qu'une vitrine 2020. Formez le marketing au réflexe « publier ≠ visible immédiatement » si un cache est actif — cela évite les appels paniqués le lundi matin.
Pour les sites où la vitesse est critique, le cache reste indispensable — l'enjeu n'est pas de le supprimer mais de le gouverner. Notre article vitesse sous 2 secondes montre comment concilier performance et fraîcheur du contenu.
Cas concrets anonymisés (HDF)
PME e-commerce textile à Lille — soldes lancées un lundi matin, bannière encore « -20 % » le mardi pour 30 % des visiteurs. Cause : Cloudflare en HIT avec TTL 24 h, plugin WordPress en purge locale seulement. Correction : purge CDN + règle « bypass cache on cookie admin » + purge auto au publish. Délai résolution : 2 h.
Artisan BTP à Arras — nouvelle grille tarifaire PDF remplacée, lien page identique. Cause : cache navigateur sur le PDF (max-age d'un an). Correction : renommage fichier + header no-cache sur documents téléchargeables modifiables.
SaaS B2B à Villeneuve-d'Ascq — correctif JS déployé, comportement ancien chez certains clients. Cause : service worker PWA non bumpé. Correction : incrément version SW + notification « nouvelle version disponible ».
FAQ
Pourquoi je vois la bonne page mais pas mes clients ?
Vous êtes probablement connecté en admin (cookie qui bypass le cache) ou votre navigateur a déjà récupéré la nouvelle version. Vos clients passent par le CDN ou un cache partagé encore chaud. Testez en navigation privée sans être connecté, ou via un outil externe.
Dois-je désactiver le cache pour corriger le problème ?
Non, sauf urgence temporaire. Désactiver le cache dégrade la vitesse et peut surcharger le serveur. Mieux vaut ajuster les TTL, purger ciblé et automatiser l'invalidation à la publication.
Combien de temps faut-il pour qu'un cache se vide tout seul ?
Cela dépend du TTL configuré : de quelques minutes à plusieurs jours. Un CDN avec max-age=86400 gardera la page 24 h minimum. Ne comptez pas sur l'expiration naturelle pour une correction urgente — purgez activement.
Cloudflare affiche « HIT » : est-ce forcément la cause ?
Un HIT signifie que Cloudflare sert sa copie. Si le contenu est obsolète et le HIT est présent, oui, le CDN est impliqué. Purgez l'URL ou tout le cache, puis vérifiez que les headers de votre origine autorisent une mise à jour raisonnable.
Le cache peut-il impacter le SEO ?
Indirectement, oui. Googlebot voit généralement la version servie par votre serveur ou CDN. Si des URLs obsolètes ou des redirections en cache incorrectes persistent, l'indexation peut diverger. Pour le SEO technique global, voir Core Web Vitals 2026.
Et maintenant ?
Un cache mal maîtrisé vous fait perdre en crédibilité (prix faux, offres expirées) autant qu'en performance. La correction passe par un diagnostic en couches, une purge ciblée, puis des règles TTL et une purge automatique à la publication.
Si vous hésitez entre « purger tout » et « toucher à rien de peur de casser », faites auditer votre stack par une équipe qui connaît votre CMS et votre CDN — c'est exactement le type d'intervention qu'on mène chez Apresta pour les PME lilloises.