--- title: "Comment configurer Cache-Control sans casser votre site web" description: "Un guide pratique de Cache-Control avec des modèles sûrs pour les ressources statiques, le HTML, les API, les données privées, les CDN partagés, la revalidation et les réponses obsolètes." canonical_url: https://optimi.com/fr/guides/cache-control md_url: https://optimi.com/fr/guides/cache-control.md last_updated: 2026-07-14 --- */ ({ title: "Comment configurer Cache-Control sans casser votre site web", description: "Un guide pratique de Cache-Control avec des modèles sûrs pour les ressources statiques, le HTML, les API, les données privées, les CDN partagés, la revalidation et les réponses obsolètes.", accent: "performance", parent: { label: "Guides", href: "/fr/guides" }, label: "Guide Cache-Control", icon: "lock", tags: ["cdn-caching", "web-performance"], publishedAt: "2026-07-14", readingTime: "10 min de lecture", }) # Comment configurer Cache-Control sans casser votre site web Choisissez les directives selon l'audience et les exigences de fraîcheur, puis vérifiez la politique effective dans les navigateurs et les caches partagés. Pour configurer `Cache-Control` de manière fiable, déterminez si une réponse est publique ou privée, si elle peut être stockée, combien de temps elle reste fraîche et si un contenu obsolète est acceptable. Émettez ensuite une politique explicite et concise depuis l'origine et vérifiez si votre CDN la préserve ou la remplace. La distinction la plus importante est que `no-cache` autorise le stockage mais impose une revalidation, tandis que `no-store` indique aux caches de ne pas stocker la réponse. `Cache-Control` est un en-tête de réponse HTTP interprété par les navigateurs et les caches partagés tels que les CDN et les proxys. Cloudflare, Fastly et les fournisseurs équivalents peuvent ajouter un TTL edge, une règle de cache ou une politique de surrogate ; l'en-tête à l'origine est donc la politique de départ, pas nécessairement le comportement final. ## Les directives les plus utiles ### `public`, `private` et `no-store` `public` indique qu'une réponse peut être stockée par des caches partagés. `private` limite le stockage à un cache privé, tel que le navigateur de l'utilisateur, et convient aux réponses personnalisées. `no-store` demande à tout type de cache de ne pas stocker la réponse. Utilisez-le pour les données sensibles, les identifiants, les étapes de paiement ou les réponses dont la conservation est inacceptable. ### `max-age` et `s-maxage` `max-age` définit la durée de fraîcheur d'une réponse en secondes. `s-maxage` s'applique aux caches partagés et y remplace `max-age`, tandis que les navigateurs l'ignorent. Ensemble, ils permettent d'attribuer au navigateur et au CDN des fenêtres de fraîcheur différentes : ```http Cache-Control: public, max-age=60, s-maxage=600 ``` Utilisez des secondes entières. Gardez la fenêtre courte lorsque le contenu change fréquemment et utilisez des URL versionnées pour le contenu réellement immuable. ### `no-cache` et les validateurs `no-cache` signifie qu'une réponse stockée doit être validée avant sa réutilisation. Cela ne signifie pas « ne pas mettre en cache ». Associez-le à `ETag` ou `Last-Modified` afin que le validateur puisse produire efficacement une réponse `304 Not Modified` : ```http Cache-Control: public, no-cache ETag: "homepage-release-42" ``` Ce modèle est utile pour du HTML qui doit être vérifié à chaque navigation mais ne nécessite pas un téléchargement complet lorsqu'il n'a pas changé. ### `immutable` `immutable` indique aux clients qu'une réponse fraîche ne changera pas. Utilisez-le uniquement pour les ressources dont l'URL change lorsque leurs octets changent : ```http Cache-Control: public, max-age=31536000, immutable ``` Ne combinez jamais une longue durée de vie immuable avec un nom de fichier mutable tel que `/styles.css`, sauf si vous disposez d'une stratégie fiable de versionnement et de purge qui empêche les anciennes références de rester en circulation. ### `stale-while-revalidate` et `stale-if-error` `stale-while-revalidate` permet à un cache de servir une réponse obsolète pendant une fenêtre limitée tout en la revalidant en arrière-plan. `stale-if-error` autorise le contenu obsolète lorsque l'origine échoue. Ces directives peuvent améliorer la résilience, mais elles prolongent la période pendant laquelle d'anciennes données peuvent être vues. Utilisez-les uniquement pour un contenu dont ce compromis est explicite. > **Le contenu obsolète est une décision produit** > > Servir un ancien article peut être inoffensif ; servir un ancien prix, niveau de stock, une réponse d'autorisations ou un solde de compte peut ne pas l'être. Définissez les fenêtres d'obsolescence par classe de contenu, et non globalement. **Choisissez Cache-Control à partir de l'audience et des exigences de fraîcheur** ![Flux de décision qui sépare d'abord les réponses sensibles ou personnalisées des réponses publiques partageables, puis oriente les ressources versionnées immuables vers une politique immutable de longue durée, le contenu public changeant régulièrement vers une durée de vie partagée bornée avec validateurs, et les réponses nécessitant une validation avant réutilisation vers no-cache avec un ETag.](/diagrams/cache-control/policy-selection.svg) *Une petite politique par classe de réponse est plus sûre qu'un TTL global unique : les données privées ne sont pas stockées dans les caches partagés, tandis que les représentations publiques ne reçoivent que la sémantique de réutilisation qu'elles peuvent supporter.* ## Modèles de politiques sûrs ### Ressources statiques avec empreinte Pour le JavaScript, le CSS, les polices et les médias hachés : ```http Cache-Control: public, max-age=31536000, immutable ``` Le build doit publier une nouvelle URL lorsque le contenu change. Si un déploiement conserve la même URL, choisissez plutôt une durée de vie plus courte et un processus de purge testé. ### HTML public qui change régulièrement Pour du HTML public qui peut rester brièvement frais à l'edge mais doit être mis à jour plus souvent dans les navigateurs : ```http Cache-Control: public, max-age=60, stale-while-revalidate=30 ETag: "page-2026-07-14-8" ``` Cet exemple est un point de départ, pas un TTL universel. Vérifiez la fréquence réelle de publication, les attentes des utilisateurs et la sémantique de contenu obsolète du fournisseur. Si le cache partagé nécessite une durée de fraîcheur différente, utilisez `s-maxage` comme politique distincte et vérifiez son interaction avec les directives de contenu obsolète. Une règle CDN qui force un TTL edge différent peut aller à l'encontre de l'intention de l'origine. ### Données d'API publiques Pour une réponse en lecture seule, identique pour chaque requête anonyme : ```http Cache-Control: public, max-age=30, s-maxage=120 ETag: "products-987" ``` Incluez dans la clé de cache les paramètres qui modifient le résultat. Ne retirez pas un paramètre de requête uniquement parce qu'il semble facultatif. Vérifiez la pagination, les filtres, la locale, la devise et le comportement d'autorisation. ### Réponses personnalisées ou sensibles Pour les données de compte ou de paiement : ```http Cache-Control: private, no-store ``` Si une réponse personnalisée non sensible peut être conservée par le navigateur mais ne doit pas être réutilisée par un CDN partagé, `private, max-age=60` peut convenir après une revue de sécurité. N'utilisez pas une règle de cache publique pour compenser une réponse ambiguë de l'application. ## Les en-têtes qui influencent la justesse `Vary` indique aux caches quels en-têtes de requête sélectionnent une représentation différente. Si une réponse varie selon la langue ou l'encodage, rendez cette variation explicite et confirmez que le CDN la respecte. Faire varier selon un en-tête à forte cardinalité, en particulier la valeur complète de `Cookie`, peut détruire le taux de hit. Omettre une variation requise peut servir la mauvaise langue, le mauvais format ou la mauvaise version pour l'appareil. `Set-Cookie` et `Authorization` demandent une attention particulière. Un cookie de session indique souvent une personnalisation. Une requête avec `Authorization` ne doit pas recevoir une réponse partagée, sauf si vous disposez d'une politique délibérée et sûre et que l'implémentation du cache la respecte. En cas de doute, utilisez `private` ou `no-store` et repensez la frontière entre public et privé. `ETag` et `Last-Modified` prennent en charge les requêtes conditionnelles. Gardez-les stables pour une même représentation et modifiez-les lorsque la représentation change. `Content-Encoding` et la négociation de contenu doivent correspondre à la représentation livrée au client ; testez les chemins compressés et non compressés. ## Configurer l'edge sans perdre le contrat de l'origine Traitez la réponse de l'origine comme la politique source et le CDN comme une couche d'application. Si Cloudflare, Fastly ou un autre fournisseur utilise un TTL de cache edge, une règle de cache, `Surrogate-Control` ou un en-tête propre au fournisseur, documentez leur priorité. Un paramètre qui force la mise en cache peut contourner `private` ou `no-store` ; un paramètre qui force le contournement peut rendre une politique d'origine correcte inefficace. Inspectez à la fois les réponses de l'origine et les réponses publiques. Comparez une requête directe à l'origine avec une requête via le CDN, puis testez un miss, un hit, une revalidation, une purge et une erreur d'origine. Ne vous fiez jamais uniquement à l'étiquette d'un tableau de bord. ## Erreurs qui cassent les sites web N'utilisez pas `no-cache` lorsque le besoin est l'absence de stockage. N'utilisez pas `no-store` partout pour ensuite vous demander pourquoi les navigations répétées et les comportements précédent-suivant du navigateur sont lents. Ne mettez pas le HTML en cache sans vérifier les cookies et l'autorisation. N'ajoutez pas `immutable` à une URL mutable. Ne définissez pas `s-maxage` sans considérer son interaction avec le comportement de contenu obsolète de votre fournisseur. N'oubliez pas qu'une purge ne peut pas atteindre un cache de navigateur qui considère toujours un objet comme frais. ## Checklist de validation Pour chaque classe de réponse, documentez son audience, sa possibilité de mise en cache, son TTL navigateur, son TTL de cache partagé, son validateur, sa clé de cache, sa politique de contenu obsolète et le responsable de la purge. Utilisez `curl -I` et les DevTools du navigateur pour inspecter `Cache-Control`, `Age`, `ETag`, `Last-Modified`, `Vary`, `Set-Cookie`, le statut et l'état du cache. Testez les variantes anonymes, authentifiées, localisées et avec paramètres de requête. Confirmez qu'une réponse modifiée devient visible dans le délai promis et qu'une erreur d'origine ne peut pas exposer de données sensibles ni des données dangereusement obsolètes. Pour la conception globale du cache, consultez [Comprendre le cache CDN](/fr/guides/cdn-caching). Pour réduire le délai à l'origine derrière un miss, consultez [les guides Optimi](/fr/guides), la [diffusion CDN managée](/fr/performance/cdn) et le [DNS managé](/fr/performance/dns). > Il n'existe que deux problèmes difficiles en informatique : l'invalidation du cache et le choix des noms. [Nous contacter](/fr/contact): Passez en revue votre politique de cache avant qu'elle ne devienne un incident — Échangez avec notre équipe pour aligner les en-têtes d'origine, les règles CDN, la fraîcheur et l'invalidation sur le comportement de votre application.