Quand on creuse vraiment le code d’un site, on voit rarement une stratégie de cache cohérente de bout en bout. C’est exactement ce que j’ai trouvé chez un client dont le temps de chargement variait du simple au triple selon l’heure de la journée, sans qu’aucune équipe interne ne comprenne pourquoi. La réponse tenait en un mot : cache, ou plutôt l’absence de coordination entre ses différentes couches.
Les différents niveaux de cache, et pourquoi les confondre coûte cher
Le mot « cache » recouvre en réalité plusieurs mécanismes distincts, qui interagissent parfois mal entre eux :
- Cache navigateur : stocke localement, chez le visiteur, des ressources statiques (images, CSS, JS) pour éviter de les retélécharger à chaque visite. Contrôlé par les en-têtes HTTP
Cache-ControletExpires - Cache serveur / FastCGI : stocke côté serveur une version déjà générée d’une page dynamique (WordPress, par exemple), pour éviter de solliciter PHP et la base de données à chaque visite
- Cache CDN / edge : stocke une copie du contenu sur des serveurs répartis géographiquement (Cloudflare, par exemple), pour servir les visiteurs depuis le nœud le plus proche
- Cache d’objets applicatif : stocke en mémoire (Redis, Memcached) des résultats de requêtes coûteuses pour éviter de les recalculer à chaque appel
Le piège le plus fréquent : ces couches ne sont pas toujours purgées en même temps lors d’une mise à jour de contenu, ce qui explique des symptômes en apparence aléatoires — une page qui affiche une ancienne version pour certains visiteurs et la bonne pour d’autres, selon la couche de cache qu’ils ont touchée.
Ce que l’audit a révélé chez ce client
Chez ce client, trois couches de cache coexistaient sans documentation : un cache FastCGI côté serveur, un CDN devant le site, et un plugin de cache WordPress installé par une agence précédente, qui dupliquait une partie du travail du cache serveur tout en générant ses propres règles de purge, incompatibles avec celles du CDN. Résultat : lors d’une mise à jour de prix sur une page produit, le CDN purgeait sa copie, mais le plugin WordPress recréait immédiatement une page mise en cache basée sur une requête de base de données elle-même mise en cache par un cache d’objet non purgé — un ancien prix pouvait ainsi rester visible plusieurs heures après la correction.
Guide d’optimisation, couche par couche
- Cartographier l’existant en premier : avant toute optimisation, lister précisément quelles couches de cache sont actives, dans quel ordre elles interviennent, et qui a la main sur chacune
- Une seule couche de cache serveur : ne jamais superposer un cache FastCGI natif et un plugin de cache applicatif qui refait le même travail — choisir l’un ou l’autre, jamais les deux
- Aligner les durées de vie (TTL) : un TTL cache navigateur de 30 jours sur une image qui change rarement, un TTL cache serveur de quelques minutes à une heure sur une page produit dont le prix peut évoluer
- Automatiser la purge en cascade : toute mise à jour de contenu doit déclencher une purge dans l’ordre suivant — cache d’objet, puis cache serveur, puis CDN — jamais l’inverse, sous peine de recréer une page en cache avec des données elles-mêmes obsolètes
- Versionner les ressources statiques : ajouter un identifiant de version dans le nom de fichier ou en paramètre d’URL pour les CSS et JS, permettant un TTL très long sans jamais servir une version périmée après déploiement
Le lien direct avec le SEO
Un cache mal coordonné n’affecte pas que l’expérience utilisateur — il affecte directement le Largest Contentful Paint et le Time to First Byte, deux métriques que Google utilise dans son évaluation de l’expérience de page. Pire : si Googlebot crawle une version en cache obsolète pendant que les visiteurs humains voient une version à jour (ou l’inverse), l’incohérence peut ralentir la prise en compte d’une mise à jour de contenu dans l’index.
Comment je teste une chaîne de cache en pratique
Pour diagnostiquer une incohérence de cache, je ne me fie jamais à un simple rechargement de page dans le navigateur — le cache navigateur lui-même fausserait l’observation. Ma méthode consiste à interroger le site directement avec curl -I en ajoutant un paramètre de requête unique à chaque appel, pour forcer le contournement du cache CDN, puis à observer l’en-tête X-Cache ou son équivalent (souvent HIT, MISS ou BYPASS selon la configuration) renvoyé par chaque couche. En comparant cet en-tête avant et après une purge déclenchée manuellement, je peux confirmer précisément quelle couche a été effectivement vidée et laquelle a été oubliée.
Chez le client mentionné plus haut, ce test simple a suffi à démontrer, en moins de dix minutes, que la purge du CDN fonctionnait parfaitement alors que le cache d’objet applicatif ne recevait jamais l’ordre de purge — la preuve technique concrète qui a permis de convaincre l’équipe de développement de revoir leur script de déploiement, plutôt que de se contenter d’une impression partagée que « le cache est capricieux ».
Le mythe qu’il faut arrêter de répéter
On entend souvent que « plus de cache, c’est toujours plus rapide ». C’est faux dès que les couches ne sont pas coordonnées : un cache mal purgé ne ralentit pas le site, il sert carrément un contenu incorrect, ce qui est pire qu’une lenteur ponctuelle. La rapidité n’est une qualité que si le contenu servi est le bon.
Pour aller plus loin : consultez l’analyse de logs via une stack ELK et l’audit des ports ouverts sur l’infrastructure.
Avez-vous déjà cartographié toutes les couches de cache actives sur votre propre infrastructure, et vérifié dans quel ordre elles se purgent réellement ?