---
title: "Comprendre le cache CDN : quoi mettre en cache et quoi éviter"
description: "Découvrez le fonctionnement du cache CDN, quelles ressources et réponses peuvent être mises en cache sans risque, comment fonctionnent les clés et les purges, et comment éviter d'exposer publiquement des données privées."
canonical_url: https://optimi.com/fr/guides/cdn-caching
md_url: https://optimi.com/fr/guides/cdn-caching.md
last_updated: 2026-07-14
---

*/ ({
  title: "Comprendre le cache CDN : quoi mettre en cache et quoi éviter",
  description:
    "Découvrez le fonctionnement du cache CDN, quelles ressources et réponses peuvent être mises en cache sans risque, comment fonctionnent les clés et les purges, et comment éviter d'exposer publiquement des données privées.",
  accent: "performance",
  parent: { label: "Guides", href: "/fr/guides" },
  label: "Comprendre le cache CDN",
  icon: "cdn",
  tags: ["cdn-caching", "edge-delivery"],
  publishedAt: "2026-07-14",
  readingTime: "9 min de lecture",
})

# Comprendre le cache CDN : quoi mettre en cache et quoi éviter

Une politique de cache sûre commence par l'audience de la réponse, sa fraîcheur, sa clé de cache et son plan d'invalidation.

Un cache CDN stocke les réponses HTTP éligibles dans des emplacements edge afin que les requêtes ultérieures reçoivent une réponse plus proche des utilisateurs et sans trajet jusqu'à l'origine. Mettez agressivement en cache les ressources statiques lorsque leurs URL sont versionnées, mettez le contenu public en cache pour une durée de fraîcheur délibérément définie et gardez les réponses personnalisées ou sensibles hors des caches partagés. La difficulté n'est pas d'activer le cache : elle consiste à prouver que la même réponse mise en cache est sûre pour chaque requête susceptible de la recevoir.

## Comment un cache CDN décide

Pour une requête, le CDN calcule une clé de cache, recherche une réponse stockée et vérifie si cette réponse est fraîche et valide pour la requête. Un hit peut éviter la latence de l'origine. Un miss récupère la réponse, applique les règles de mise en cache et peut la stocker pour les requêtes suivantes. Une réponse obsolète peut être revalidée auprès de l'origine avec `ETag` ou `Last-Modified`, ou être servie dans le cadre d'une politique d'utilisation de contenu obsolète explicitement autorisée.

L'URL est souvent l'entrée minimale de la clé de cache, mais les systèmes réels peuvent aussi varier selon l'hôte, la chaîne de requête, la méthode, la langue, l'encodage, les indications d'appareil, les cookies, l'autorisation ou certains en-têtes de requête. Chaque dimension supplémentaire peut fragmenter le cache. Chaque dimension omise peut faire servir une représentation incorrecte.

**Un CDN ne réutilise qu'une représentation correspondante, sûre et fraîche**

![Flux de décision depuis une requête entrante jusqu'au calcul de la clé de cache, à la recherche d'une représentation stockée correspondante et aux vérifications de fraîcheur. Une correspondance fraîche est servie depuis l'edge ; une correspondance expirée est revalidée ; un miss récupère la réponse de l'origine, qui n'est stockée que lorsqu'il est sûr de la partager.](/diagrams/cdn-caching/cache-reuse-decision.svg)

*La clé de cache, la politique de partage, la fenêtre de fraîcheur et le validateur déterminent si l'edge peut répondre à une requête sans risquer de servir une réponse incorrecte ou privée.*

> **Mettez en cache la représentation, pas la requête par accident**
>
> Avant de mettre une réponse en cache, notez quels utilisateurs peuvent la recevoir, ce qui différencie deux représentations, combien de temps elle peut rester fraîche et comment une mise à jour atteint chaque edge.

## Que mettre en cache

### Ressources statiques versionnées

Mettez longtemps en cache le JavaScript, le CSS, les polices, les icônes et les médias immuables dont le nom est haché. Une politique générique est :

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

Cette longue durée de vie n'est sûre que si un fichier modifié reçoit une nouvelle URL. N'écrasez pas `/app.js` alors que les navigateurs et les edges sont autorisés à conserver les anciens octets pendant un an. Utilisez un hash de contenu, un numéro de version ou une autre URL versionnée, et supprimez les anciennes versions conformément à votre politique de déploiement.

### Images et médias publics

Les images, segments vidéo, affiches et documents publics téléchargeables constituent souvent de bons candidats pour un CDN. Choisissez une durée de fraîcheur adaptée aux mises à jour éditoriales, prenez en charge les requêtes par plages lorsque nécessaire et faites varier intentionnellement les représentations d'images selon la largeur, le format ou l'appareil. Évitez de créer une clé de cache unique pour chaque en-tête de requête accessoire. La [diffusion d'images adaptatives](/fr/performance/image-adaptative) montre pourquoi des variantes à la bonne taille comptent autant pour le poids que pour la vitesse.

### Réponses HTML et API publiques

Les pages publiques et les réponses d'API en lecture seule peuvent être mises en cache lorsque leur sortie n'est pas personnalisée et que leur fraîcheur est acceptable. Utilisez un TTL court, une revalidation conditionnelle ou `stale-while-revalidate` pour le contenu qui tolère une courte fenêtre de fraîcheur. Un CDN tel que Cloudflare ou Fastly peut proposer des contrôles équivalents de TTL edge et de purge, mais la politique de l'origine et les règles effectivement appliquées par le fournisseur doivent être testées ensemble.

Exemple :

```http
Cache-Control: public, max-age=60, stale-while-revalidate=30
ETag: "article-42-v7"
```

La fenêtre d'obsolescence permet à un cache de servir la réponse précédente pendant sa revalidation lorsque l'implémentation prend ce comportement en charge. Utilisez-la uniquement lorsqu'il est acceptable de servir un contenu légèrement ancien. Si les durées de vie du navigateur et du cache partagé doivent différer, utilisez `s-maxage` comme politique distincte et vérifiez comment le CDN retenu gère son interaction avec les directives de contenu obsolète.

## Ce qu'il ne faut pas mettre en cache dans un CDN partagé

Gardez les pages de compte, l'historique des commandes, les paniers, le paiement, les réponses de paiement, les tableaux de bord privés et les réponses contenant des données personnelles hors des caches partagés. Une base sûre pour les contenus sensibles est :

```http
Cache-Control: private, no-store
```

Utilisez `no-store` lorsqu'une réponse ne doit pas être stockée. Si une réponse peut être stockée dans un cache privé de navigateur mais ne doit pas être réutilisée par un CDN partagé, `private` est la directive importante. `no-cache` a une signification différente : il autorise le stockage mais exige une validation avant réutilisation.

Soyez prudent avec les réponses qui définissent des cookies. Une réponse qui contient un cookie de session ou de personnalisation ne doit pas devenir un objet partagé uniquement parce qu'une règle edge indique « mettre le HTML en cache ». Vérifiez explicitement le comportement de `Authorization`, `Cookie`, `Set-Cookie` et `Vary`. Si vous avez une enveloppe publique et des données privées, mettez ces couches en cache séparément et rendez leur frontière évidente.

Ne mettez pas par défaut en cache les requêtes qui modifient l'état. `POST`, `PUT`, `PATCH` et `DELETE` nécessitent une sémantique et une invalidation spécifiques à l'application. La plupart des caches CDN sont conçus autour de récupérations sûres telles que `GET` et `HEAD`.

## Concevoir soigneusement la clé de cache

Normalisez les paramètres de requête qui ne modifient pas le contenu, tels que les paramètres de suivi, mais ne supprimez pas les paramètres qui sélectionnent un produit, une locale, un filtre ou une représentation. Décidez si l'ordre des paramètres doit avoir une importance. Si la réponse varie selon la langue ou l'encodage, utilisez une politique `Vary` correcte ou une configuration de fournisseur équivalente. Assurez-vous que le CDN respecte réellement les en-têtes que vous envoyez ; certains produits ont des valeurs par défaut propres au fournisseur.

Évitez de faire varier le cache selon l'intégralité de l'en-tête `Cookie`. Cela crée de nombreux objets avec un faible taux de hit et peut mêler l'état de l'application au comportement edge. Extrayez uniquement le signal requis pour une variante publique, ou contournez le cache partagé lorsque la réponse est réellement personnalisée.

Si une réponse est négociée par `Accept`, `Accept-Encoding` ou des client hints, validez le chemin complet de l'origine à l'edge puis au navigateur. Une réponse correcte pour un appareil ou une langue ne l'est pas pour toutes les clés de cache.

## L'invalidation fait partie de la conception

Un TTL n'est pas une stratégie de purge. Décidez comment les corrections urgentes, la disponibilité produit, les changements de sécurité et les versions invalident les objets mis en cache. Utilisez des URL versionnées pour les ressources, des purges ciblées pour le contenu connu et une procédure de purge plus large documentée pour les incidents. Comprenez si une purge est mondiale, asynchrone, souple ou spécifique au fournisseur. Testez ce qu'un utilisateur voit pendant la propagation.

Conservez des validateurs tels que `ETag` ou `Last-Modified` sur les réponses qui peuvent être revalidées. Une réponse `304 Not Modified` peut actualiser les métadonnées du cache sans transférer le corps complet. Surveillez le taux de hit, les requêtes à l'origine, les réponses obsolètes, la fin des purges et les erreurs de cache au lieu de considérer un taux de hit élevé comme le seul indicateur de succès.

## Erreurs courantes

N'assimilez pas un cache hit à une réponse correcte. Ne mettez pas tout le HTML en cache parce que les ressources statiques sont sûres. N'utilisez pas `no-cache` lorsque vous voulez dire `no-store`. N'appliquez pas un TTL d'un an à des URL mutables. N'ignorez pas les chaînes de requête ni les cookies dans la clé de cache. N'appliquez pas `stale-if-error` à un contenu qui devient dangereux ou trompeur lorsqu'il est ancien. Ne supposez pas qu'un paramètre du tableau de bord Cloudflare ou Fastly a la même priorité que les en-têtes d'origine sans vérifier sa documentation et les en-têtes de réponse.

## Checklist de validation

Testez un miss à froid, un hit à chaud, une revalidation d'une réponse obsolète, un objet purgé et une erreur d'origine. Répétez l'opération pour des requêtes anonymes, authentifiées, localisées, mobiles et portant des cookies. Inspectez `Cache-Control`, `Age`, `ETag`, `Last-Modified`, `Vary`, `Set-Cookie`, le statut, l'encodage du contenu, l'état du cache et le corps de la réponse. Confirmez qu'une mise à jour devient visible dans le délai promis et que les données sensibles n'apparaissent jamais dans un objet partagé.

Pour des exemples de politiques directive par directive, consultez [Comment configurer Cache-Control](/fr/guides/cache-control). Pour la couche réseau autour du cache, consultez le [guide CDN managé d'Optimi](/fr/performance/cdn) et le [DNS managé](/fr/performance/dns). Pour une séquence plus large d'amélioration de la vitesse d'un site, consultez [la checklist de performance des sites lents](/fr/guides).

> Il n'existe que deux problèmes difficiles en informatique : l'invalidation du cache et le choix des noms.

[Commencer](/fr/contact): Rendez votre cache CDN sûr et utile — Échangez avec notre équipe sur les clés de cache, la fraîcheur, le comportement des purges et la protection de l'origine pour votre trafic.