Cache : ce qu'il accélère, ce qu'il rend faux, ce qu'il casse

40 min
Quiz · 6 questions

Par Stéphane Robert mis à jour le 9 octobre 2026

Améliorer cette page

Que voulez-vous signaler ?

L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.

Un cache garde en mémoire une copie de données coûteuses à obtenir, pour les resservir vite sans solliciter la source à chaque fois. C'est souvent la brique qui fait passer une page de 300 à 10 millisecondes, et celle qui, mal comprise, sert des prix périmés ou fait tomber la base le jour où elle se vide. Cette leçon apprend à lire un cache sur un schéma : comment il est rempli, comment il se trompe, ce qui se passe quand il disparaît, et quel état il ne doit jamais porter sans protection.

Ce que vous allez apprendre

Expliquer la lecture en cache-aside et le rôle du TTL
Dire pourquoi l'invalidation est la difficulté centrale d'un cache
Prédire l'effet d'un cache vide ou en panne sur la base
Distinguer un cache jetable d'un cache qui porte un état à protéger

Qu'est-ce qu'un cache ?

Un cache est une copie rapide et partielle d'une donnée dont la source de vérité est ailleurs. Il vit en mémoire, ce qui le rend des dizaines de fois plus rapide qu'une base sur disque, et il ne garde qu'une partie des données : les plus demandées. Redis, son fork communautaire Valkey ou Memcached en sont les exemples les plus courants ; un CDN est un cache placé en bordure.

Sur un schéma, il se reconnaît à sa position entre l'application et la source, et à une flèche de remplissage depuis cette source. Il n'existe jamais seul : un cache sans source de vérité derrière lui n'est plus un cache, c'est une base en mémoire, avec des risques de perte que personne n'a mesurés.

Comment un cache est-il rempli ?

Le mode le plus courant est le cache-aside : l'application cherche d'abord dans le cache, et en cas d'absence lit la base puis remplit le cache pour la fois suivante. Chaque entrée reçoit une durée de vie (TTL, Time To Live) au-delà de laquelle elle est considérée comme périmée et relue. Le schéma suit les deux chemins d'une lecture.

Lecture en cache-aside : le chemin rapide quand la donnée est en cache, le détour par la base sinon. Source · SVG

Le taux de succès, la part des lectures servies par le cache, mesure son utilité : un cache qui répond à 95 % des lectures divise par vingt la charge de lecture sur la base. D'autres modes existent, comme l'écriture simultanée dans le cache et la base (write-through), mais le cache-aside reste le premier à savoir reconnaître.

Pourquoi l'invalidation est-elle si difficile ?

Un cache sert une copie, et une copie peut devenir fausse dès que la source change : décider quand la retirer est le problème central de la famille. Un TTL long rend le cache efficace mais sert plus longtemps une valeur périmée ; un TTL court garde des données fraîches mais renvoie plus souvent vers la base. Supprimer explicitement l'entrée à chaque modification de la source est plus juste, mais oublie facilement un cas.

Dans la boutique, un prix modifié qui reste en cache dix minutes fait payer l'ancien prix, ou en afficher un qui n'est plus pratiqué. Un stock en cache peut annoncer disponible un article épuisé. La question à poser devant chaque donnée mise en cache est donc celle du premier module : une lecture périmée est-elle acceptable pour cette donnée, et pendant combien de temps ?

Que se passe-t-il quand le cache est vide ou tombe ?

Un cache vide ou en panne renvoie toutes les lectures vers la base, qui doit alors absorber une charge pour laquelle elle n'a souvent jamais été dimensionnée. C'est le mode de panne qui transforme une dégradation attendue en panne générale. Après un redémarrage, le cache est froid : il ne contient rien, et chaque requête est un échec qui va lire la base.

Le cas le plus brutal est l'avalanche de requêtes : une entrée très demandée expire, et des centaines de requêtes simultanées constatent son absence et vont toutes la recalculer en base au même instant. Les parades se lisent dans la configuration : un seul recalcul autorisé à la fois, des durées de vie légèrement aléatoires pour que tout n'expire pas ensemble, un réchauffement du cache avant de lui envoyer le trafic.

Question de la grille	Ce qu'il faut regarder
État porté	une copie jetable, sauf si on y met des sessions ou des verrous
À sauvegarder	rien pour un cache pur ; les sessions si elles y vivent
S'il tombe	la base reçoit toute la charge de lecture
Réplication	utile pour la disponibilité ; inutile pour la donnée elle-même
Mémoire pleine	éviction des entrées les moins utilisées (politique LRU)
Signal à surveiller	taux de succès, mémoire utilisée, évictions, latence

Quel état ne faut-il pas confier à un cache ?

Un cache pur ne porte que des copies ; dès qu'on y met une donnée sans autre copie, il devient une source de vérité, et sa perte n'est plus une dégradation. C'est le cas des sessions : stockées seulement dans Redis, elles disparaissent avec lui, et tous les clients sont déconnectés. C'est aussi le cas des verrous, des compteurs de limitation de débit ou des files bricolées dans le cache.

Ces usages sont légitimes, mais ils changent la lecture de la brique. Il faut alors décider si elle doit écrire sur disque, être répliquée, ou si la perte est acceptée en connaissance de cause. Sur un schéma, la question est simple : cette brique porte-t-elle une donnée qu'on ne trouve nulle part ailleurs ?

Ce que le cache change dans la boutique

Dans la boutique, le cache sert le catalogue sans solliciter la base et porte les sessions des clients, ce qui permet aux copies de l'application de rester sans état. C'est la version 2 du fil rouge : le cache apparaît en cylindre, parce qu'il porte les sessions, une forme d'état vue dans le premier module.

Version 2 du fil rouge : le cache sert le catalogue et garde les sessions. Source · SVG

Ce double rôle est le point d'attention de la boutique. Le catalogue en cache est jetable : sa perte ralentit les pages. Les sessions, elles, ne le sont pas : leur perte déconnecte tout le monde. Il faut donc soit les placer dans un cache répliqué et persistant, soit accepter explicitement cette déconnexion.

Un cache : ce qu'il apporte, ce qu'il coûte

Un cache achète de la latence et du soulagement pour la base avec de la cohérence et de la complexité. C'est le compromis type de toute brique ajoutée : elle résout un problème et en crée d'autres. Le tableau le pose pour la boutique.

Ce qu'on gagne	Ce qu'on paie
des pages servies en quelques millisecondes	des données potentiellement périmées
une base soulagée de la majorité des lectures	une invalidation à concevoir pour chaque donnée
une capacité de lecture qui monte vite	une base exposée à toute la charge si le cache se vide
des sessions partagées entre les copies	une brique de plus, et un état à protéger si elle porte les sessions

Qui prend le relais pour installer et exploiter un cache ?

Cette leçon décrit le rôle architectural du cache ; son installation et son réglage relèvent des guides spécialisés, sur le site et dans la documentation des produits. Le guide Données managées compare les caches managés des fournisseurs cloud et leur place à côté des bases et des files ; le pilier Performance Efficiency sur OUTSCALE traite la conception des clés, des durées de vie et de l'invalidation.

Pièges de lecture courants

Ces erreurs reviennent devant un cache, et elles viennent presque toutes d'une copie prise pour une source, ou d'une source prise pour une copie :

Considérer tout cache comme jetable alors qu'il porte des sessions ou des verrous.
Oublier l'invalidation : un prix ou un stock périmé est servi sans erreur.
Dimensionner la base pour le trafic filtré par le cache : elle tombe le jour où il se vide.
Faire expirer toutes les entrées en même temps et provoquer une avalanche.
Ajouter un cache pour masquer une requête lente qu'un index aurait corrigée.

À retenir

Un cache est une copie rapide et partielle ; la source de vérité est ailleurs.
En cache-aside, l'application lit le cache, puis la base en cas d'absence, et remplit le cache avec un TTL.
L'invalidation est la difficulté centrale : un cache peut servir des données périmées.
Un cache vide ou en panne renvoie toute la charge vers la base.
Un cache qui porte des sessions ou des verrous devient un état à protéger.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin