Qu'est-ce que la mise en cache? Guide simple pour les créateurs d'apps

La mise en cache consiste à garder une copie prête de quelque chose qui était lent ou coûteux à obtenir, pour que la requête suivante puisse recevoir une réponse rapide à partir de cette copie. La copie conservée s'appelle un cache. Votre navigateur met en cache les images pour qu'un site se charge plus vite lors de votre deuxième visite; un serveur met en cache le résultat d'une requête de base de données lente pour ne pas devoir l'exécuter pour chaque visiteur.

La mise en cache rend les apps plus rapides et moins coûteuses à faire fonctionner. Son grand compromis est qu'une copie peut devenir désuète.

Pourquoi la mise en cache compte quand vous construisez avec l'IA

Vous rencontrerez la mise en cache dans les apps construites par IA de trois façons :

• « J'ai mis l'app à jour, mais je vois encore l'ancienne version. » C'est le moment de mise en cache le plus courant, et il est habituellement inoffensif — votre navigateur ou un CDN affiche une copie enregistrée.
• La vitesse. Si une page est lente parce qu'elle recalcule les mêmes chiffres pour chaque visiteur, mettre le résultat en cache peut la faire paraître instantanée.
• Le coût. Beaucoup de créateurs d'apps IA et d'hébergeurs facturent le calcul, le temps de base de données et les appels d'API externes. Si mille visiteurs déclenchent la même requête coûteuse, la mise en cache vous permet de ne payer qu'une fois.

Connaître les bases vous permet de demander de la mise en cache là où elle aide, et de la repérer quand elle est la cause d'un comportement étrange.

Une analogie du quotidien

Pensez à la cuisine d'un café achalandé.

Chaque matin, le chef pourrait infuser chaque café à partir de grains fraîchement moulus au moment de la commande. C'est lent. Il garde plutôt une cafetière de café filtre prête sur la plaque chauffante. La plupart des clients reçoivent une tasse en quelques secondes — c'est un succès de cache. Quand la cafetière est vide, quelqu'un en infuse une nouvelle — un échec de cache.

Mais le café qui reste trop longtemps devient amer, alors le café a une règle : jeter toute cafetière de plus de 30 minutes. Cette règle est le délai d'expiration du cache. Personne ne garderait la même cafetière toute la journée, et personne ne préparerait à l'avance la commande personnalisée de quelqu'un avec du lait d'avoine et trois sucres — certaines choses ne devraient jamais être mises en cache.

Où vivent les caches

Un seul chargement de page peut passer par plusieurs caches, du plus proche de l'utilisateur au plus éloigné :

Un CDN (réseau de diffusion de contenu) est essentiellement un réseau mondial de caches pour les fichiers de votre site.

Comment un cache décide quoi garder

Chaque cache doit répondre aux mêmes questions :

• Qu'est-ce qui peut être mis en cache? Les données publiques et partagées (une image de produit, un article de blogue) — oui. Les données privées (la page de compte d'un utilisateur, ses messages) — jamais dans un cache partagé.
• Pour combien de temps? C'est le TTL (time to live, durée de vie). Un logo peut être mis en cache pendant un an; un niveau de stock, pendant 30 secondes.
• Comment est-il mis à jour? Soit la copie expire et est récupérée à nouveau, soit l'app la supprime délibérément quand les données changent — c'est ce qu'on appelle l'invalidation.

Pour les sites web, le serveur indique aux navigateurs et aux CDN comment mettre en cache chaque fichier à l'aide de l'en-tête Cache-Control. Par exemple, Cache-Control: max-age=3600 signifie « vous pouvez réutiliser cette copie pendant une heure ».

Les outils de construction modernes gèrent la partie la plus difficile pour les fichiers statiques grâce à la purge de cache (cache busting) : chaque fois qu'un fichier change, il reçoit un nouveau nom avec une empreinte, comme app.3f9a2c.js. Les navigateurs peuvent garder l'ancien nom longtemps, parce que la nouvelle version porte simplement un nom différent.

Un exemple concret : un catalogue de produits

Vous avez une petite boutique en ligne. La page d'accueil affiche 50 produits avec leurs prix et leur stock tirés de la base de données, ainsi qu'une liste « tendances » qui exige un calcul lent sur toutes les commandes.

1. Les images et les scripts sont mis en cache par le navigateur et par le CDN pendant longtemps. Chaque nouvelle version donne de nouveaux noms aux fichiers modifiés, donc les mises à jour apparaissent quand même.
2. La liste des tendances est calculée une fois toutes les 10 minutes et stockée dans un cache d'application. Chaque visiteur pendant ces 10 minutes reçoit le résultat enregistré instantanément.
3. Les prix sont mis en cache pour une courte durée, et le cache est vidé chaque fois que vous modifiez un produit, pour que les clients ne voient jamais un ancien prix longtemps.
4. Le stock à la caisse n'est jamais mis en cache. Quand quelqu'un clique sur « Acheter », l'app vérifie la vraie base de données, donc elle ne peut pas vendre un article qui vient d'être épuisé.
5. Les pages de panier et de compte ne sont jamais conservées dans des caches partagés, parce qu'elles sont personnelles.

Résultat : la page d'accueil est rapide, la base de données fait beaucoup moins de travail, et rien qui touche à l'argent ou à la vie privée n'est jamais périmé.

Termes clés

Idées fausses courantes

• « La mise en cache est toujours bonne. » Mettre la mauvaise chose en cache cause de vrais bogues : anciens prix, nouveaux articles absents, ou — le pire cas — la page privée d'un utilisateur affichée à un autre. Mettez en cache de façon délibérée.
• « Si je vois l'ancienne version, ma mise à jour a échoué. » Habituellement, non. Essayez un rechargement forcé (Ctrl+Maj+R, ou Cmd+Maj+R sur Mac) ou une fenêtre privée avant de supposer qu'il y a un problème.
• « La mise en cache corrige une app lente. » Elle masque la lenteur pour les requêtes répétées. La première requête reste lente, et si le problème sous-jacent est un index manquant dans la base de données, corrigez-le aussi.
• « Je devrais tout mettre en cache le plus longtemps possible. » Les longues durées conviennent aux fichiers qui reçoivent de nouveaux noms quand ils changent. Pour les pages HTML et les données, des durées plus courtes sont plus sûres.
• « Vider mon cache corrige le problème pour tout le monde. » Cela ne vide que votre navigateur. Les visiteurs et les caches des CDN conservent leurs propres copies.

Quoi demander à votre créateur d'apps IA

• « Quelles parties de cette app sont lentes, et lesquelles pourraient être mises en cache en toute sécurité? »
• « Mets en cache [la liste des tendances / le résultat de l'API] pendant [N] minutes, et vide-le quand les données sous-jacentes changent. »
• « Assure-toi qu'aucune page contenant des données personnelles ou de compte ne peut être mise en cache par un CDN ou un cache partagé. »
• « Définis de longues durées de cache pour les fichiers statiques avec empreinte, et de courtes pour le HTML. »
• « Mets en cache les réponses de [API externe] pour ne pas l'appeler à chaque chargement de page — et dis-moi à quel point ces données pourraient devenir périmées. »
• « Je vois une ancienne version après la publication. Est-ce le cache de mon navigateur, ou quelque chose n'est-il pas déployé? »

La mise en cache dans Mythex

Après avoir publié une mise à jour d'une app Mythex, la documentation indique que les caches CDN peuvent prendre un moment à se mettre à jour, et qu'un rechargement forcé de l'URL publique affiche la nouvelle version — voir Comment publier. La page Limites d'hébergement recommande aussi de mettre en cache les ressources statiques, puisque l'hébergement, le temps de base de données et la bande passante sont payés à partir de votre solde de crédits. Tout ce qui va au-delà — mettre en cache les résultats de requêtes ou les réponses d'API — est quelque chose que vous demandez à l'agent d'intégrer à votre app.

Lectures connexes : qu'est-ce qu'un CDN, comment rendre votre site plus rapide et qu'est-ce que la limitation de débit.

Questions