La mise en cache des prompts

Le prompt caching s’attaque à un gaspillage invisible mais massif des applications conversationnelles : le retraitement, requête après requête, d’un contenu que le modèle a déjà analysé. Bien employé, il accélère les réponses de Claude et réduit sensiblement les coûts — sans changer un mot de vos prompts. Cette leçon pose le concept ; les deux suivantes couvriront les règles précises et l’implémentation.

Traitement normal (sans cache)

Pour comprendre ce que le cache économise, il faut voir ce qu’une requête coûte. À chaque appel, Claude effectue un travail de préparation substantiel avant de générer le premier token de réponse : tokenisation du texte, création des représentations internes, mise en relation de chaque élément avec l’ensemble du contexte. Ce preprocessing croît avec la taille de l’entrée — un long prompt système, dix schémas d’outils, un gros document joint, tout cela se paie en temps de calcul et en tokens d’entrée facturés. Et une fois la réponse envoyée, tout ce travail est jeté. L’API ne conserve rien entre deux requêtes : chaque appel repart de zéro.

Le problème du contenu répété

Ce fonctionnement sans mémoire devient coûteux dès qu’on converse. Rappelez-vous la structure d’une conversation par API : à chaque tour, on renvoie l’historique complet. La requête de suivi inclut donc le message original, la réponse de Claude, puis le nouveau message — et Claude retraite intégralement le message original qu’il vient pourtant d’analyser il y a trente secondes. Au tour suivant, il le retraitera une troisième fois, plus les deux tours intermédiaires. Plus la conversation s’allonge, plus la part de contenu déjà vu domine chaque requête : on paie sans cesse pour refaire un travail dont le résultat était connu.

Comment fonctionne le cache

Le prompt caching casse ce cycle en deux temps :

1. Requête initiale : Claude traite le contenu normalement et sauvegarde le travail de préparation dans un cache
2. Requêtes suivantes : quand une requête commence par le même contenu, Claude relit le cache au lieu de tout recalculer, et ne traite à plein tarif que la partie nouvelle

L’image la plus juste est celle d’un signet : le modèle « reprend sa lecture » là où le cache s’arrête, au lieu de relire le livre depuis la première page. La partie cachée est facturée à une fraction du tarif normal, et le temps de première réponse chute d’autant.

Ce qu’il faut savoir avant de l’utiliser

Deux propriétés cadrent l’usage. D’abord, le cache exige une correspondance exacte : la moindre variation dans le contenu mis en cache — un caractère — et la réutilisation échoue. C’est pourquoi on ne cache que les parties stables des requêtes : prompt système, schémas d’outils, documents de référence. Ensuite, le cache est éphémère : sa durée de vie est de 5 minutes, renouvelée à chaque réutilisation — parfait pour une conversation active, inopérant pour un utilisateur qui revient le lendemain.

Dans ce cadre, les gains sont là où le contenu répété est massif : les applications conversationnelles, où l’historique et le prompt système reviennent à chaque tour, et l’analyse de documents, où l’on pose des questions successives sur le même texte volumineux. Une fois les marqueurs de cache posés — c’est l’objet des prochaines leçons —, la réutilisation est automatique : aucune logique applicative à écrire.

Points clés à retenir

• Chaque requête paie un preprocessing 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 sauvegarde ce travail et le réutilise : seule la partie nouvelle est traitée à plein tarif
• Contraintes : correspondance exacte au caractère près, durée de vie de 5 minutes renouvelée à l’usage
• Cas idéaux : conversations (système + historique stables) et questions successives sur un même document