Mise en cache des prompts
La mise en cache des prompts est la fonctionnalité par laquelle un fournisseur de LLM stocke et réutilise le préfixe récurrent d'un prompt (system prompt, historique de conversation, long document) sur plusieurs requêtes. Au lieu de retraiter les mêmes tokens à chaque fois, le modèle les charge depuis le cache, réduisant considérablement le coût et la latence. Anthropic l'a introduite dans Claude en 2024, suivie par OpenAI et Google, et elle est devenue une fonctionnalité standard des API LLM en 2026.
La mise en cache des prompts est la fonctionnalité par laquelle un fournisseur de LLM stocke et réutilise le préfixe récurrent d'un prompt (system prompt, historique de conversation, long document) sur plusieurs requêtes. Au lieu de retraiter les mêmes tokens à chaque fois, le modèle les charge depuis le cache, réduisant considérablement le coût et la latence. Anthropic l'a introduite dans Claude en 2024, suivie par OpenAI et Google, et elle est devenue une fonctionnalité standard des API LLM en 2026.
Pourquoi c'est important
Les pipelines RAG et les agents injectent de longs system prompts, des historiques de conversation et des documents récupérés dans chaque requête. Dix répétitions signifient dix calculs au prix fort. La documentation d'Anthropic rapporte jusqu'à 90 % de réduction des coûts et 85 % de réduction de la latence sur la portion mise en cache. Les applications d'IA en production ont fondamentalement restructuré leur modèle économique autour de la mise en cache des prompts.
Comment cela fonctionne
- Marquez les sections pouvant être mises en cache : le développeur indique explicitement quelles parties du prompt peuvent être mises en cache en toute sécurité (Anthropic utilise des blocs
cache_control; OpenAI met en cache automatiquement). - Première requête (écriture du cache) : le modèle traite le prompt complet et stocke la section marquée dans le cache. Cette requête coûte en réalité légèrement plus cher en raison du surcoût d'écriture du cache.
- Requêtes suivantes (lecture du cache) : lorsqu'une requête avec le même préfixe arrive, le modèle charge l'état interne depuis le cache. Ces tokens sont facturés à environ 10 % du prix d'entrée.
- Durée de vie du cache (TTL) : les caches vivent généralement environ 5 minutes (Anthropic) ou plus et sont évincés automatiquement en l'absence d'utilisation.
Quand l'utiliser
System prompts de chatbot : mettre en cache des milliers de tokens de rôle, de contraintes et d'exemples au lieu de les retraiter à chaque tour.
Questions-réponses sur de longs documents : insérer un livre, un PDF ou un manuel dans le contexte et poser de nombreuses questions. Le document est mis en cache ; seule la question change.
Définitions d'outils d'agent : mettre en cache des milliers de tokens de schémas d'outils pour que chaque appel d'outil ait une latence plus faible.
Assistants de code : charger l'intégralité du code d'un projet dans le contexte pour de nombreuses questions de suivi.
Pipelines RAG : mettre en cache les documents fixes fréquemment récupérés pour économiser sur le coût des requêtes répétées.
Mises en garde
Correspondance exacte : le préfixe mis en cache doit correspondre token par token. Injecter des données variables comme des dates ou des identifiants d'utilisateur dans le system prompt casse le cache. Déplacez les parties variables après la région mise en cache.
Taille minimale du cache : Anthropic exige au moins 1 024 tokens (Sonnet/Opus) pour la mise en cache. Les prompts courts n'y gagnent rien.
Gestion du TTL : une requête doit arriver dans la fenêtre du TTL pour qu'il y ait un hit de cache. Les services à faible trafic doivent « maintenir le cache au chaud » via des requêtes de heartbeat périodiques.
Surcoût d'écriture : la première requête coûte légèrement plus cher. Sans réutilisation, vous perdez de l'argent.
Évolution en 2026
Caches plus longs : certains fournisseurs proposent désormais des TTL de plusieurs heures à plusieurs jours, utiles pour les agents d'entreprise et les chatbots toujours actifs.
Mise en cache par utilisateur : system prompts personnalisés mis en cache par utilisateur.
RAG hybride : mise en cache des segments fréquemment récupérés pour éviter la recherche vectorielle sur les requêtes répétées.
Implications pour le GEO
Pour qu'un moteur de recherche IA réutilise le contenu d'un blog sur de nombreuses requêtes, le contenu doit être sous une « forme stable et adaptée au cache ». Des changements fréquents d'URL ou une personnalisation dynamique au sein de la page cassent le cache. Les blogs qui servent un Markdown structuré, des URL stables et une génération statique sont plus susceptibles d'être réutilisés comme sources économiques par l'infrastructure de recherche IA.
Sources :