Guide du cache HTTP : Accélérez votre site sans infrastructure supplémentaire

Baies de serveurs dans un centre de données

La mise en cache est l'optimisation des performances offrant le meilleur rapport effort/résultat qui soit. Une réponse mise en cache est servie en microsecondes, ne coûte rien et ne nécessite aucun traitement côté serveur. Pourtant, la plupart des applications mettent en cache de manière trop agressive (en servant du contenu périmé) ou pas du tout (en gaspillant bande passante et ressources de calcul). Comprendre le cache HTTP le transforme d'une source de bugs en véritable atout.

Comment fonctionne le cache HTTP

Lorsqu'un navigateur ou un CDN reçoit une réponse, il examine les en-têtes pour décider s'il doit la mettre en cache et pendant combien de temps. Lors de la prochaine requête pour la même ressource, il peut servir la copie mise en cache — sans jamais contacter votre serveur.

Le cycle de vie du cache comporte deux phases :

Fraîcheur — La copie en cache est-elle encore valide ? Déterminée par Cache-Control: max-age ou Expires.
Validation — Si elle est périmée, peut-on confirmer auprès du serveur que le contenu n'a pas changé ? Déterminée par ETag ou Last-Modified.

Cache-Control : la directive de mise en cache principale

Cache-Control est l'en-tête de cache le plus puissant. Il s'agit d'une liste de directives séparées par des virgules :

Cache-Control: public, max-age=31536000, immutable

Directives clés

Directive	Signification
`public`	N'importe quel cache (navigateur, CDN, proxy) peut stocker ceci
`private`	Seul le navigateur de l'utilisateur final peut mettre en cache (pas les CDN)
`no-cache`	Doit revalider avec le serveur avant chaque utilisation (ne signifie pas « ne pas mettre en cache »)
`no-store`	Ne jamais mettre en cache — pour les données sensibles
`max-age=N`	Mettre en cache pendant N secondes
`s-maxage=N`	Durée maximale spécifique aux CDN (remplace `max-age` pour les caches partagés)
`immutable`	Le contenu ne changera jamais — ignorer complètement la revalidation
`must-revalidate`	Lorsque périmé, doit revalider avant de servir
`stale-while-revalidate=N`	Servir le contenu périmé pendant N secondes tout en récupérant une version fraîche en arrière-plan

⚠️ no-cache ne signifie PAS « ne pas mettre en cache ». Cela signifie « mettre en cache, mais toujours vérifier si c'est encore valide ». Utilisez no-store si vous ne souhaitez vraiment jamais qu'une ressource soit mise en cache.

Stratégie de mise en cache par type de ressource

Les différentes ressources nécessitent des stratégies différentes :

Assets statiques avec hachage de contenu (CSS, JS, images)

Cache-Control: public, max-age=31536000, immutable

Si votre outil de build ajoute un hash aux noms de fichiers (main.a3f9b2c.js), l'URL change lorsque le contenu change. Mettez en cache indéfiniment — toute nouvelle version obtient une nouvelle URL.

Pages HTML

Cache-Control: no-cache

Ou avec une courte durée de vie :

Cache-Control: public, max-age=60, stale-while-revalidate=3600

Le HTML change fréquemment et pointe vers les assets hachés. Mettez en cache brièvement ou forcez la revalidation.

Réponses API

# Données publiques (ex. : catalogue produits)
Cache-Control: public, max-age=300, stale-while-revalidate=600

# Données spécifiques à l'utilisateur
Cache-Control: private, max-age=60

# Données en temps réel (cours de bourse, scores en direct)
Cache-Control: no-store

Données sensibles (authentification, paiement)

Cache-Control: no-store

Ne jamais mettre en cache. Un point c'est tout.

ETags et requêtes conditionnelles

Lorsqu'une réponse mise en cache expire, le navigateur ne la supprime pas simplement — il demande au serveur si elle est encore valide. C'est la revalidation.

ETags

Un ETag est une empreinte du contenu de la réponse :

# Le serveur envoie :
ETag: "a3f9b2c8d4e1"

# La prochaine requête du navigateur :
If-None-Match: "a3f9b2c8d4e1"

# Si inchangé, le serveur répond :
HTTP/1.1 304 Not Modified
(pas de corps — économie de bande passante)

# Si modifié, le serveur répond :
HTTP/1.1 200 OK
ETag: "b7c2d4e9a1f3"
(nouvelle réponse complète)

Une réponse 304 Not Modified n'a pas de corps — uniquement des en-têtes. Cela économise toute la bande passante liée au re-téléchargement du contenu.

Last-Modified

Similaire, mais utilise un horodatage plutôt qu'un hash :

Last-Modified: Tue, 01 Apr 2026 10:00:00 GMT

# Le navigateur envoie :
If-Modified-Since: Tue, 01 Apr 2026 10:00:00 GMT

Les ETags sont plus fiables (les horodatages peuvent manquer de précision avec des serveurs à charge équilibrée).

En-tête Vary : cache par variante de requête

L'en-tête Vary indique aux caches quels en-têtes de requête influencent la réponse :

Vary: Accept-Encoding

Ceci met en cache une copie distincte pour les réponses gzip et br. Utilisations courantes :

Vary: Accept-Encoding          # Caches distincts pour compressé/non compressé
Vary: Accept-Language          # Caches distincts par langue
Vary: Accept                   # Caches distincts pour les réponses JSON vs HTML

⚠️ Vary: Cookie ou Vary: Authorization désactive effectivement la mise en cache CDN — les CDN ne peuvent pas mettre en cache des réponses spécifiques à un utilisateur.

stale-while-revalidate : actualisation en arrière-plan

L'un des schémas de mise en cache modernes les plus utiles :

Cache-Control: max-age=60, stale-while-revalidate=600

Servir instantanément depuis le cache pendant les 60 premières secondes (frais)
Pour les requêtes entre 60 et 660 secondes : servir immédiatement la copie périmée, tout en récupérant une version fraîche en arrière-plan
Après 660 secondes : doit revalider avant de servir

Les utilisateurs obtiennent toujours une réponse rapide. Le cache reste à jour sans forcer personne à attendre un aller-retour réseau.

Considérations sur la mise en cache CDN

Les CDN (Cloudflare, CloudFront, Fastly) respectent les en-têtes Cache-Control mais ajoutent leur propre niveau de complexité :

s-maxage vous permet de définir des durées de vie différentes pour le CDN et le navigateur :
```
Cache-Control: public, max-age=60, s-maxage=86400
```
Le navigateur met en cache pendant 1 minute ; le CDN met en cache pendant 24 heures.
Purge du cache — lors d'un déploiement, purgez le cache CDN pour les assets mis à jour. La plupart des CDN proposent une purge via API.
Clés de cache — les CDN mettent en cache sur la base de l'URL et des en-têtes Vary. Les chaînes de requête sont généralement incluses dans la clé de cache.

Tester le comportement du cache

Utilisez notre API Request Builder pour inspecter les en-têtes de réponse et vérifier que votre configuration de cache fonctionne correctement :

Effectuez une requête et vérifiez les en-têtes Cache-Control, ETag et Last-Modified
Refaites la même requête — vérifiez la présence de l'en-tête Age (secondes depuis la mise en cache) et de X-Cache: HIT
Vérifiez CF-Cache-Status (Cloudflare) ou X-Cache (CloudFront) pour confirmer la mise en cache CDN

Dans Chrome DevTools → onglet Network → cliquez sur une ressource → onglet Headers — recherchez from disk cache ou from memory cache dans la réponse.

Configuration du cache Nginx

Configurez les en-têtes de cache au niveau de Nginx pour un comportement cohérent :

# Assets statiques — mise en cache permanente
location ~* \.(js|css|woff2|png|jpg|webp|svg)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

# HTML — toujours revalider
location ~* \.html$ {
    add_header Cache-Control "no-cache";
}

# API — cache court avec stale-while-revalidate
location /api/ {
    add_header Cache-Control "public, max-age=60, stale-while-revalidate=600";
}

Utilisez notre Nginx Config Generator pour générer une configuration Nginx complète et optimisée selon votre cas d'usage.

Liste de contrôle de la mise en cache

Les assets statiques (CSS/JS) utilisent des noms de fichiers avec hash de contenu + max-age=31536000, immutable
Le HTML est servi avec no-cache ou un max-age très court
Les réponses API sont mises en cache en fonction de la fréquence de mise à jour
Les données sensibles utilisent no-store
Les ETags ou Last-Modified sont activés pour les requêtes conditionnelles
stale-while-revalidate est appliqué aux endpoints API appropriés
Les en-têtes de cache CDN sont vérifiés et testés

Une mise en cache HTTP correcte donne à votre site une impression d'instantanéité pour les visiteurs réguliers, réduit vos coûts de bande passante et allège la charge serveur — sans aucune infrastructure supplémentaire.