# Antipatterns de cache : une configuration identique sur tout un mutualisé

> Un audit révèle la même règle de cache appliquée à des dizaines de sites très différents sur un même mutualisé. Le gain de temps initial se transforme en dette collective.

- Auteur : WordPress Développement
- Publié le : 2024-05-12
- Mis à jour le : 2024-05-12
- Catégorie : Hébergement & serveurs
- URL : https://www.wpmoderne.fr/hebergement/antipatterns-cache-configuration-identique-mutualise/

## L’essentiel

- Une durée de cache unique ignore la nature réelle de chaque site
- Un site e-commerce et un blog n'ont pas les mêmes règles de purge
- La configuration copiée-collée finit par gêner plus qu'elle n'aide

Sur un mutualisé qui héberge quarante-cinq sites WordPress distincts, un audit de performance a révélé un fait simple et révélateur : le même bloc de configuration de cache, avec la même durée d'expiration et les mêmes règles d'exclusion, était appliqué à chacun d'eux, indépendamment de leur nature. Un blog personnel mis à jour une fois par mois partageait exactement la même règle de cache qu'une boutique WooCommerce dont le panier doit rester à jour à la seconde près.

Ce constat n'a rien d'exceptionnel : configurer le cache une fois, au niveau du serveur, et l'appliquer à tous les sites qui y sont hébergés représente un gain de temps réel pour qui gère un parc. Le problème apparaît quand cette configuration unique, pensée pour un cas générique, reste en place des années durant sans être révisée site par site.

## Ce qu'on observe sur ce type de parc

La configuration en question, au niveau du bloc serveur, ressemblait à ceci, appliquée sans distinction :

```
location ~* \.(html|htm)$ {
    expires 30d;
    add_header Cache-Control "public, no-transform";
}
fastcgi_cache_valid 200 30m;
```

Une durée de cache de trente minutes sur les réponses dynamiques convient très bien à un site éditorial classique. Elle devient problématique sur un site qui affiche un compteur de stock en temps réel, ou sur un site associatif dont le formulaire d'inscription à un événement doit refléter immédiatement les places restantes.

## Pourquoi c'est un problème

> L'essentiel à retenir : Une durée de cache unique ignore la nature réelle de chaque site ; Un site e-commerce et un blog n'ont pas les mêmes règles de purge ; La configuration copiée-collée finit par gêner plus qu'elle n'aide

Le symptôme le plus visible remonté par les clients de ce mutualisé n'était pas une lenteur, mais l'inverse : des informations obsolètes affichées malgré une modification récente. Un gérant de boutique en ligne qui met à jour un prix ne le voit répercuté sur le site public que trente minutes plus tard, ce qui, en période de promotion limitée dans le temps, génère de la confusion et parfois des ventes au mauvais prix.

Le deuxième symptôme, moins visible mais tout aussi coûteux, concernait les sites WooCommerce du parc. Une règle de cache pensée pour du contenu éditorial ne prévoyait aucune exclusion automatique des pages de panier et de compte client, ce qui provoquait par intermittence l'affichage du panier d'un visiteur à un autre, un problème de fond largement documenté dans l'écosystème WooCommerce et qui exige des règles de cache spécifiques, jamais une configuration générique de site vitrine.

## Ce qu'il faut faire à la place

La correction ne consiste pas à supprimer le cache, dont le bénéfice reste réel pour la majorité du parc, mais à le segmenter selon la nature réelle de chaque site plutôt que selon la seule commodité de l'hébergeur. Trois profils suffisent généralement à couvrir la quasi-totalité des cas :

- site éditorial statique : cache long, purge uniquement à la publication d'un contenu ;
- site avec formulaires ou comptes utilisateurs : cache court, exclusion systématique des pages de compte et de panier ;
- site e-commerce actif : cache de fragments plutôt que de page complète, avec purge ciblée déclenchée par les hooks WooCommerce comme `woocommerce_product_set_stock`.

Une configuration Nginx qui distingue ces profils par un identifiant de site plutôt qu'une règle globale devient nettement plus maintenable :

```
map $host $cache_profile {
    default        "editorial";
    boutique-a.example.com  "ecommerce";
    boutique-b.example.com  "ecommerce";
}

fastcgi_cache_valid 200 $cache_profile;
```

### Documenter le profil de chaque site, pas seulement sa configuration

Le second manque relevé lors de l'audit était l'absence totale de documentation associant chaque site à son profil de cache attendu. Un nouveau site ajouté au parc héritait par défaut de la configuration générique, sans qu'aucune étape du processus d'onboarding ne pousse à se demander si ce profil convenait réellement.

> Une configuration de cache qui n'a jamais été remise en question depuis sa création n'est pas une configuration stable : c'est une dette qui attend son incident.

## Mettre en place une revue périodique

La correction durable adoptée par cet hébergeur a été d'ajouter une case à cocher explicite dans son processus de provisionnement de site : quel est le profil de cache attendu pour ce site, et pourquoi. Cette question simple, posée systématiquement à la création d'un nouveau site, a suffi à faire remonter plusieurs cas où le profil générique ne convenait manifestement pas, avant même qu'un client ne le signale.

## En résumé

Une configuration de cache identique sur tout un mutualisé n'est pas une erreur en soi au moment de sa mise en place : le problème naît de son immobilisme. Ce qui distingue un parc bien tenu d'un parc fragile n'est pas l'absence de configuration générique de départ, mais la capacité à la faire évoluer site par site à mesure que chacun d'eux change de nature, du simple blog à la boutique active.