Prompt caching

Voici l’une des optimisations les plus rentables de tout l’écosystème Claude — et l’une des moins visibles pour vos utilisateurs, sinon par la vitesse. Le prompt caching accélère les réponses et réduit les coûts en réutilisant le travail computationnel des requêtes précédentes. Pour comprendre où sont les gains, il faut d’abord voir le gaspillage qu’il élimine.

Comment Claude traite normalement les requêtes

Avant de générer une réponse, Claude effectue un travail important sur votre message d’entrée :

1. Tokeniser le prompt
2. Créer des embeddings pour chaque token
3. Ajouter du contexte basé sur le texte environnant
4. Générer le texte de sortie

Les trois premières étapes constituent le prétraitement : elles convertissent votre texte en représentations que le modèle peut manipuler, et leur coût croît avec la taille de l’entrée — un long prompt système, dix schémas d’outils, un rapport joint, tout se paie en calcul et en tokens d’entrée facturés. Tout ce prétraitement se fait avant que Claude ne génère la moindre réponse. Et une fois la réponse envoyée, Claude jette tout ce travail computationnel : l’API ne conserve rien d’une requête à l’autre.

Le problème

Ce fonctionnement sans mémoire devient coûteux dès qu’il y a répétition — et la conversation est répétition par nature. Rappelez-vous la structure multi-tours : chaque tour renvoie l’historique complet. Dans une conversation, votre requête de suivi inclut donc le même message précédent, et Claude doit refaire tout le travail qu’il vient de jeter — retokeniser, recalculer les embeddings, recontextualiser un texte qu’il avait entièrement analysé trente secondes plus tôt. Au dixième tour, l’essentiel de la facture paie du travail déjà fait neuf fois. C’est une inefficacité significative, et elle grandit avec chaque échange.

Comment le prompt caching résout ce problème

L’idée est d’une simplicité désarmante : au lieu de jeter le travail de prétraitement, Claude le stocke dans un cache. Ce cache agit comme une table de correspondance entre des messages d’entrée spécifiques et leurs résultats computationnels — tel préfixe de requête, déjà vu, voici son traitement tout prêt.

Lors d’une requête de suivi contenant le même contenu, Claude consulte son cache et réutilise le travail précédent au lieu de tout recommencer. Seule la partie nouvelle de la requête — le dernier message, typiquement — est traitée à plein tarif. L’image juste est celle du signet : le modèle reprend sa lecture où le cache s’arrête, au lieu de relire le livre depuis la première page à chaque question.

Avantages et limites

Le fonctionnement se résume en un cycle : la première requête écrit le préfixe dans le cache, les requêtes suivantes le lisent — moins cher et plus rapide à chaque lecture — et le cache expire au bout de 5 minutes d’inactivité. La contrepartie est évidente : le mécanisme n’apporte rien si vous n’envoyez jamais deux fois le même contenu.

Mais c’est précisément là que le cache devient précieux : en pratique, la répétition est la norme des applications IA, pas l’exception. Un prompt système identique part avec chaque requête ; un historique de conversation se renvoie intégralement à chaque tour ; un grand document en cours d’analyse accompagne des dizaines de questions successives. Sur ces motifs — qui représentent l’essentiel du trafic d’une application réelle — le cache transforme des tokens facturés plein tarif à chaque appel en lectures rapides et économiques.

Cette leçon pose le concept ; la suivante détaille les règles du jeu — comment marquer ce qui doit être caché, où placer les points de cache, et les seuils à respecter pour que le mécanisme s’active réellement.

Points clés à retenir

• Chaque requête paie un prétraitement complet (tokens, embeddings, contexte), jeté après la réponse
• La conversation renvoie l’historique à chaque tour : sans cache, on refait sans cesse le même travail
• Le cache conserve le traitement du préfixe ; seule la partie nouvelle est traitée à plein tarif
• Écriture à la première requête, lectures rapides et économiques ensuite, expiration après 5 minutes
• Prompt système, historique, gros documents : les motifs répétitifs sont la norme — et le terrain du cache