Qu'est-ce que le cache ? Guide simple pour les créateurs d'applis

Le cache consiste à garder une copie prête de quelque chose qui était lent ou coûteux à obtenir, afin que la requête suivante puisse recevoir une réponse rapide à partir de cette copie. La copie enregistré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.

Le cache rend les applis plus rapides et moins coûteuses à faire tourner. Son grand compromis est qu'une copie peut devenir obsolète.

Pourquoi le cache compte quand on construit avec l'IA

Vous rencontrerez le cache dans les applis créées par IA de trois façons :

• « J'ai mis à jour l'appli mais je vois encore l'ancienne version. » C'est le moment de cache le plus courant, et il est en général sans gravité : 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 rendre instantanée.
• Le coût. Beaucoup de créateurs d'applis 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, le cache vous permet de ne payer qu'une fois.

Connaître les bases vous permet de demander du cache là où il aide, et de le repérer quand il est la cause d'un comportement bizarre.

Une analogie du quotidien

Pensez à la cuisine d'un café très fréquenté.

Chaque matin, le chef pourrait préparer chaque café à partir de grains fraîchement moulus au moment de la commande. Ce serait lent. Il garde donc une cafetière de café filtre prête sur la plaque chauffante. La plupart des clients reçoivent leur tasse en quelques secondes — c'est un cache hit (succès de cache). Quand la cafetière est vide, quelqu'un en prépare une nouvelle — un cache miss (échec de cache).

Mais un café trop longtemps gardé devient fade, alors le café applique une règle : jeter toute cafetière de plus de 30 minutes. Cette règle est la durée de validité 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 d'un client avec lait d'avoine et trois sucres — certaines choses ne doivent pas être mises en cache du tout.

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 distribution de contenu) est essentiellement un réseau mondial de caches pour les fichiers de votre site.

Comment un cache décide ce qu'il garde

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 blog) — 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'appli la supprime délibérément quand la donnée change — c'est l'invalidation.

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

Les outils de build modernes gèrent la partie la plus difficile pour les fichiers statiques grâce au cache busting (renouvellement du cache) : à chaque modification d'un fichier, il reçoit un nouveau nom avec une empreinte, comme app.3f9a2c.js. Les navigateurs peuvent conserver l'ancien nom longtemps, car 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 niveaux de stock depuis la base de données, plus une liste « tendances » qui exige un calcul lent sur toutes les commandes.

1. Images et scripts sont mis en cache par le navigateur et le CDN pendant longtemps. Chaque nouveau build donne de nouveaux noms aux fichiers modifiés, les mises à jour apparaissent donc toujours.
2. La liste des tendances est calculée toutes les 10 minutes et stockée dans un cache applicatif. Chaque visiteur pendant ces 10 minutes reçoit instantanément le résultat enregistré.
3. Les prix sont mis en cache pour une courte durée, et le cache est vidé dès que vous modifiez un produit, pour que les clients ne voient jamais un ancien prix longtemps.
4. Le stock au moment du paiement n'est jamais mis en cache. Quand quelqu'un clique sur « Acheter », l'appli vérifie la vraie base de données, pour ne pas vendre un article qui vient d'être épuisé.
5. Les pages panier et compte ne sont jamais stockées dans des caches partagés, car 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 reçues

• « Le cache est toujours bénéfique. » Mettre en cache la mauvaise chose provoque de vrais bugs : anciens prix, nouveaux articles absents, ou — le pire cas — la page privée d'un utilisateur montrée à un autre. Mettez en cache avec discernement.
• « Si je vois l'ancienne version, ma mise à jour a échoué. » En général, non. Essayez un rechargement forcé (Ctrl+Maj+R, ou Cmd+Maj+R sur Mac) ou une fenêtre de navigation privée avant de supposer que quelque chose est cassé.
• « Le cache règle une appli lente. » Il masque la lenteur pour les requêtes répétées. La première requête reste lente, et si le problème de fond est un index de base de données manquant, corrigez aussi cela.
• « Il faut tout mettre en cache aussi longtemps que possible. » Les longues durées conviennent aux fichiers qui reçoivent un nouveau nom quand ils changent. Pour les pages HTML et les données, des durées plus courtes sont plus sûres.
• « Vider mon cache règle le problème pour tout le monde. » Cela ne vide que votre navigateur. Les visiteurs et les caches CDN gardent leurs propres copies.

Quoi demander à votre créateur d'applis par IA

• « Quelles parties de cette appli sont lentes, et lesquelles pourraient être mises en cache sans risque ? »
• « 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é. »
• « Fixe de longues durées de cache pour les fichiers statiques à 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 peuvent devenir obsolètes. »
• « Je vois une ancienne version après la publication. Est-ce le cache de mon navigateur, ou quelque chose n'a-t-il pas été déployé ? »

Le cache dans Mythex

Après la publication d'une mise à jour d'une appli Mythex, la documentation indique que les caches CDN peuvent prendre un peu de retard, 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 sur 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 appli.

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

Questions