En-têtes de cache HTTP Cache-Control, ETag et max-age sans supposition

Chaque réponse HTTP que vous envoyez est soit mise en cache, soit non — et si vous ne faites pas exprès, le navigateur décide pour vous. Le résultat est généralement un mélange de mise en cache agressive pour les éléments qui changent fréquemment et de non-mise en cache pour les éléments qui changent rarement. Les deux nuisent à vos utilisateurs.

Ce guide vous donne le modèle mental pour définir correctement les en-têtes de cache HTTP la première fois : ce que chaque directive contrôle, comment les ETags déclenchent la revalidation, et comment choisir des durées de vie (TTL) qui survivent aux déploiements sans servir de contenu périmé.

Comment le cache du navigateur fonctionne réellement

Lorsqu'un navigateur demande un ressource, il vérifie d'abord son cache local. Si une copie mise en cache fraîche existe, elle est servie immédiatement — sans requête réseau du tout. Si la copie mise en cache pourrait être périmée, il envoie une requête conditionnelle à l'origine. L'origine confirme soit que la ressource n'a pas changé (304 Not Modified), soit elle envoie la réponse mise à jour complète (200 OK).

Les CDNs se situent au milieu de ce cycle de vie. Ils stockent les réponses plus près des utilisateurs géographiquement, et ils respectent les mêmes en-têtes de cache HTTP — avec quelques extensions spécifiques aux CDNs comme s-maxage.

Trois questions déterminent le comportement de mise en cache :

• Cette réponse est-elle mise en cache du tout ? Contrôlée par Cache-Control: no-store ou private
• Durée de fraîcheur ? Contrôlée par max-age ou s-maxage
• Comment la péremption est-elle validée ? Contrôlée par les ETags ou Last-Modified

les directives de l'en-tête Cache-Control

Le Cache-Control l'en-tête est la méthode principale pour déclarer la politique de mise en cache. Plusieurs directives sont séparées par des virgules. Voici ce que chacune fait réellement :

max-age

max-age=N indique aux caches (navigateur et CDN) combien de secondes la réponse reste fraîche. Une réponse avec max-age=86400 est considérée comme fraîche pendant exactement 24 heures à partir de la réception. Après ce délai, le cache doit effectuer une revalidation avant de la servir à nouveau.

Pour les ressources statiques avec des noms de fichiers versionnés (comme main.abc123.js), une durée de un an est courante : max-age=31536000. Pour les documents HTML, une fenêtre beaucoup plus courte — ou aucune mise en cache — est plus sûre, car les documents HTML font référence à ces fichiers versionnés.

s-maxage

s-maxage remplace max-age pour les caches partagés (CDNs, serveurs proxy) uniquement. Le navigateur l'ignore. Cela permet de servir des réponses longuement mises en cache aux utilisateurs tout en gardant le CDN plus frais. Un modèle typique est Cache-Control: public, max-age=3600, s-maxage=86400 — le navigateur met en cache pendant une heure, le CDN met en cache pendant 24 heures.

no-cache

no-cache ne signifie pas « ne pas mettre en cache ». Il signifie que le cache doit effectuer une revalidation avec l'origine avant de servir la réponse stockée, même si elle est encore fraîche. La réponse est mise en cache, mais chaque utilisation nécessite un tour de communication pour vérifier sa validité. Cela est approprié pour du contenu qui change fréquemment mais bénéficie des économies de bande passante d'une réponse 304.

no-store

no-store est la seule directive qui empêche vraiment le cache. Aucun cache du navigateur, aucun cache CDN, aucune écriture sur disque. L'utilisez pour les réponses contenant des données sensibles — relevés bancaires, dossiers médicaux, tokens. N'utilisez pas cela comme valeur par défaut parce que vous n'avez pas encore réfléchi à la mise en cache.

public et private

public autorise explicitement les caches partagés (CDNs) à mettre en cache la réponse, même si la requête avait un Authorization en-tête. private restreint la mise en cache à l'ordinateur du navigateur uniquement — les CDNs ne doivent pas la mettre en cache. Pour des réponses authentifiées qui sont spécifiques à l'utilisateur, private empêche que la réponse d'un utilisateur ne soit servie à un autre.

must-revalidate

must-revalidate empêche les caches de servir des réponses périmées lorsqu'ils ne peuvent pas atteindre l'origine. Sans cela, un cache pourrait servir une réponse périmée si le réseau est indisponible. Avec cela, la requête échoue avec un code 504 si l'origine est inaccessible. Utilisez-le pour du contenu où servir des données périmées est pire qu'une erreur.

ETags : revalidation précise

Un ETag est un identifiant généré par le serveur pour une version spécifique d'une ressource — pensez-y comme une empreinte de la réponse. Le serveur l'envoie dans la réponse :

ETag: "abc123def456"

Lorsque la copie mise en cache expire, le navigateur envoie une requête conditionnelle avec l'ETag stocké :

If-None-Match: "abc123def456"

Si la ressource n'a pas changé, le serveur répond avec 304 Not Modified et un corps vide — en économisant la bande passante tout en confirmant la fraîcheur. Si elle a changé, le serveur répond avec 200 OK et le nouvel ETag.

ETags forts et faibles

UN ETag fort ("abc123") signifie que la réponse est identique à l'octet par octet. Un ETag faible (W/"abc123") signifie que les réponses sont équivalentes sémantiquement mais peuvent différer de manière mineure comme les espaces en blanc ou l'ordre des en-têtes. Les ETags faibles peuvent être générés plus efficacement mais ne peuvent pas être utilisés dans les requêtes de plage. Sauf si vous avez une raison spécifique pour utiliser des ETags faibles, utilisez des ETags forts.

Last-Modified : l'ancienne alternative

Avant les ETags, les serveurs utilisaient Last-Modified des timestamps pour la revalidation. Le serveur envoie :

Last-Modified: Thu, 01 May 2026 12:00:00 GMT

Le navigateur effectue la revalidation avec :

If-Modified-Since: Thu, 01 May 2026 12:00:00 GMT

Le serveur retourne 304 si la ressource n'a pas changé depuis ce timestamp.

Le point faible : les timestamps ont une précision de une seconde. Un fichier modifié deux fois dans la même seconde apparaît comme inchangé. Les ETags gèrent cela correctement et sont préférés. La plupart des frameworks modernes envoient les deux — le navigateur utilise celui qui est disponible, avec les ETags en priorité.

Désactiver le cache sans compromettre les déploiements

Un long max-age sur une ressource statique est seulement sûr si l'URL change lorsque le contenu change. Deux stratégies existent :

Fingerprinting de l'URL (recommandé)

Inclure un hachage du contenu du fichier dans le nom du fichier : main.a1b2c3d4.js. Lorsque le fichier change, le hachage change, l'URL change, et le navigateur récupère le nouveau fichier — en évitant complètement le cache. L'ancienne URL reste en cache mais n'est jamais requise à nouveau une fois que l'HTML référence l'URL nouvelle.

Webpack, Vite et la plupart des bundleurs modernes le font automatiquement. Ce modèle permet de définir Cache-Control: public, max-age=31536000, immutable — la immutable directive indique au navigateur de ne pas s'occuper de la revalidation même si l'entrée de cache est techniquement périmée.

Les chaînes de requête (moins fiables)

Ajouter une version à l'URL comme une chaîne de requête (main.js?v=1.2.3) crée techniquement une URL différente, mais certains CDNs et proxies ignorent les chaînes de requête lors de la construction des clés de cache. Le fingerprinting dans le chemin est plus fiable et universellement supporté.

Erreurs courantes qui nuisent au cache

Mettre en cache des réponses d'API qui ne devraient pas être mises en cache

Les API JSON qui retournent des données spécifiques à l'utilisateur ou sensibles au temps doivent utiliser Cache-Control: no-store ou au moins private, no-cache. Une erreur courante est de laisser un CDN mettre en cache une réponse comme /api/user/profile et de servir les données d'un utilisateur à un autre. Si votre API ne définit pas une Cache-Control en-tête, certains CDNs la mettront en cache tout de même en utilisant des heuristiques.

Oublier Vary: Accept-Encoding

Si votre serveur sert des versions compressées et non compressées d'une ressource selon le header Accept-Encoding du client, le cache doit stocker des copies séparées pour chaque variant. Sans Vary: Accept-Encoding, un CDN pourrait mettre en cache la version gzip et la servir à un client qui ne supporte pas la gzip — ou l'inverse. Définissez toujours cette directive lorsque la compression est conditionnelle.

Utiliser no-cache quand on veut vraiment empêcher le cache

Les développeurs écrivent souvent Cache-Control: no-cache quand ils veulent empêcher le cache entièrement, mais no-cache stocke toujours la réponse — elle doit simplement être revalidée avant chaque utilisation. Utilisez no-store lorsque vous ne voulez vraiment pas que la réponse soit persistée n'importe où.

Définir max-age sur des documents HTML sans stratégie de désactivation du cache

Les documents HTML font référence à des ressources versionnées. Si vous mettez en cache vos documents HTML avec un long max-age, les utilisateurs ne prendront pas en compte les nouveaux noms de fichiers après un déploiement — ils continueront à exécuter l'ancien HTML, qui fait référence aux anciens hachages. Définissez une durée de vie courte (ou no-cache) sur les documents HTML, et réservez les durées de vie longues aux ressources immuables que les documents HTML font référence.

Calculez votre fenêtre d'expiration avant de lancer le déploiement

Choisir une max-age valeur est plus facile lorsque vous pouvez visualiser ce qu'elle signifie en temps réel. La Calculateur de TTL / max-age du Cache HTTP sur iotools.cloud vous permet d'entrer une durée de vie en secondes et de voir l'heure exacte d'expiration. Utile pour vérifier des valeurs comme 86400 (24 heures), 2592000 (30 jours) ou 31536000 (1 an) avant de les intégrer dans votre configuration serveur ou vos règles CDN.

Un checklist pratique pour une politique de cache

• Documents HTML : Cache-Control: no-cache — revalider toujours, bénéficier des réponses 304 lorsqu'aucune modification n'a eu lieu
• Ressources statiques versionnées (JS, CSS, images avec hachage dans le nom de fichier) : Cache-Control: public, max-age=31536000, immutable
• Ressources statiques non versionnées (polices, favicon) : Cache-Control: public, max-age=604800 (1 semaine)
• Réponses d'API (publiques, sensibles au temps) : Cache-Control: public, max-age=60, s-maxage=300 — durée de vie courte au navigateur, durée de vie plus longue au CDN
• Réponses d'API (spécifiques à l'utilisateur) : Cache-Control: private, no-cache
• Données sensibles : Cache-Control: no-store
• Toujours définir Vary: Accept-Encoding lorsque vous servez des réponses compressées conditionnellement

Les ETags doivent être activés par défaut pour tout ce que vous mettez en cache — ils sont le mécanisme qui rend la revalidation efficace en termes de bande passante. La plupart des serveurs web (Nginx, Apache, Caddy) génèrent automatiquement des ETags sauf si vous les avez désactivés.

Vous aimerez peut-être aussi