Mise en cache des prompts : accélérer et réduire les coûts

Le prompt caching (mise en cache des prompts) est une fonctionnalité qui accélère les réponses de Claude et réduit les coûts de génération en réutilisant le travail de calcul des requêtes précédentes. Au lieu de tout recalculer à chaque fois, Claude peut sauvegarder et réutiliser son travail quand vous envoyez un contenu identique — et dans les applications réelles, le contenu répété est la norme, pas l’exception.

Comment Claude traite normalement une requête

Pour bien comprendre le caching, voyons d’abord ce qui se passe lors d’une requête classique sans cache.

Quand vous envoyez un message à Claude, il ne génère pas immédiatement sa réponse. Il effectue d’abord un travail de prétraitement considérable sur votre input :

1. Tokenisation du prompt en petits morceaux
2. Création d’embeddings pour chaque token
3. Ajout de contexte basé sur le texte environnant
4. Et seulement ensuite, génération du texte de sortie

Ce prétraitement croît avec la taille de l’entrée — un long prompt système, dix schémas d’outils, un document joint, tout se paie en calcul et en tokens d’entrée facturés. Et après vous avoir envoyé la réponse, Claude jette tout ce travail : tokenisation, embeddings, analyse contextuelle… tout est perdu. L’API ne conserve rien entre deux requêtes.

Le problème : recalculer sans cesse

Cette approche devient inefficace quand vous faites des requêtes successives qui contiennent le même contenu. Par exemple, dans une conversation où vous demandez à Claude d’affiner un résumé d’un même long texte : à chaque échange, Claude doit répéter intégralement le même prétraitement sur un contenu qu’il vient d’analyser quelques instants plus tôt. Rappelez-vous la structure des conversations : l’historique complet repart à chaque tour — plus l’échange s’allonge, plus la part de déjà-vu domine chaque requête. C’est du gaspillage de calcul pur, et il grandit à chaque tour.

La solution : le prompt caching

Le prompt caching modifie ce workflow en sauvegardant le travail de prétraitement au lieu de le jeter. Lors de la première requête, Claude effectue tout le prétraitement habituel mais stocke les résultats dans un cache au lieu de les supprimer. Ce cache fonctionne comme une table de correspondance : « Si je revois ce message, je réutilise le travail déjà fait. » Les requêtes suivantes qui commencent par le même contenu relisent le cache et ne traitent à plein tarif que la partie nouvelle — l’image juste est celle du signet : reprendre la lecture où l’on s’était arrêté, au lieu de relire le livre.

Avantages et limites

Avantages

• Réponses plus rapides : les requêtes utilisant du contenu en cache s’exécutent plus vite
• Coûts réduits : vous payez moins pour les portions en cache
• Réutilisation automatique : la première requête écrit dans le cache, les suivantes le lisent — sans logique applicative

Limites importantes

• Durée du cache : la durée de vie de base est de 5 minutes, rafraîchie à chaque réutilisation ; une option de cache étendu à 1 heure existe pour les contenus consultés moins fréquemment
• Correspondance exacte requise : seul un contenu strictement identique est réutilisé
• Cas d’usage restreints : utile uniquement quand le même contenu revient réellement dans vos requêtes

La durée rafraîchie mérite l’explication : chaque réutilisation repousse l’expiration — une conversation active garde donc son cache chaud en permanence, tandis qu’un utilisateur qui revient après une longue pause repart de zéro. C’est exactement le profil des applications conversationnelles.

Cas d’usage idéaux

Le prompt caching est particulièrement adapté pour :

• L’analyse de documents : poser plusieurs questions sur un même long document
• L’édition itérative : raffiner des aspects spécifiques d’un contenu de base qui reste constant
• Les assistants spécialisés : même prompt système et mêmes outils envoyés à chaque requête

Trois scénarios, une même signature : un gros bloc stable (document, contenu de base, système + outils) et une petite partie variable (la question du moment). C’est ce profil qu’il faut apprendre à reconnaître dans vos propres applications — la prochaine leçon montre comment marquer précisément ce bloc stable avec les cache breakpoints.

Points clés à retenir

• Chaque requête paie un prétraitement complet de son entrée, jeté après la réponse
• En conversation, l’historique renvoyé à chaque tour fait retraiter sans cesse le même contenu
• Le cache conserve ce travail : seule la partie nouvelle se paie à plein tarif
• Durée de vie 5 minutes rafraîchie à l’usage (option étendue 1 heure) ; identité stricte exigée
• Profil idéal : gros bloc stable + petite partie variable — documents, assistants, édition itérative