Diviser par dix le coût d'entrée de votre chatbot Claude
Votre chatbot appelle l'API Claude, et la facture d'entrée grimpe plus vite que votre trafic. La raison est mécanique : à chaque message, vous renvoyez la même partie stable (instruction de base, ton, règles, documents de contexte) que Claude doit relire et que l'API refacture intégralement à chaque appel. Vous payez plusieurs fois pour le même texte.
Cette masterclass vous donne la méthode du prompt caching : inventorier ce que vous envoyez à Claude, séparer le stable du variable, poser le marqueur de cache sur les bons blocs, et prouver sur les compteurs de l'API que la partie stable n'est plus refacturée à chaque appel.
Ce que cet exercice ne peut pas casser
L'essentiel de l'exercice se fait sur une feuille : l'inventaire et le tri ne touchent pas à votre code. La modification elle-même tient en quelques lignes, que vous pouvez retirer aussi facilement que vous les avez posées. Et la vérification se lit dans la réponse de l'API, sans rien casser : au pire, le cache ne se lit pas et vous payez comme avant.
Ce que vous saurez faire à la fin
- Inventorier tous les blocs envoyés à Claude à chaque appel et dire lesquels sont stables, lesquels sont variables.
- Poser le marqueur de cache sur les bons blocs stables, sans toucher aux blocs variables, et regrouper les blocs trop courts.
- Prouver sur les compteurs de l'API que le cache fonctionne : écriture au premier appel, lecture aux suivants.
- Niveau membre· le prompt prêt à coller qui lit le code de votre route d'appel, sépare le stable du variable et vous écrit la modification exacte à appliquer.
Chaque bloc envoyé à Claude va dans une des deux maisons. Seule la maison stable se met en cache.
Six gestes pour cacher le stable sans casser le variable
Le prompt caching repose sur une idée simple : si une partie de votre requête est identique d'un appel à l'autre, l'API peut la mémoriser au lieu de la relire et de la refacturer en entier. Tout le travail consiste à savoir ce qui est réellement stable, à le cacher proprement, et à le vérifier sur des chiffres. La méthode tient en six gestes, faisables à la main sur votre propre code, sans dépendre d'un outil particulier.
1Inventaire : listez tout ce que vous envoyezdoute : « qu'est-ce que j'envoie, au juste ? »
Listez tous les blocs de contenu qui partent vers Claude à chaque appel : instruction de base, ton, règles, documents de contexte, historique, message du client. Pour chacun, notez s'il est identique d'un message à l'autre dans une conversation, ou s'il change. Si vous n'êtes pas sûr qu'un bloc est réellement stable, ne l'affirmez pas : marquez-le « à vérifier ».
2Tri : le stable d'un côté, le variable de l'autredoute : « et si je me trompe de côté ? »
Séparez clairement les blocs stables (à cacher) des blocs variables (à ne jamais cacher), et justifiez chaque classement en une phrase. Cette phrase vous oblige à vérifier au lieu de supposer : un bloc « presque stable » est un bloc variable.
3Seuil : vérifiez que le bloc vaut le coupdoute : « mon bloc est-il assez gros ? »
Estimez la taille en tokens de chaque bloc stable. Un bloc trop court n'est pas éligible au cache à lui seul : plutôt que de le cacher isolément, regroupez-le avec un autre bloc stable pour passer le seuil.
4Modification : posez le marqueur de cachedoute : « où exactement, dans mon code ? »
Écrivez la version exacte du code à coller : le marqueur de cache posé sur les bons blocs stables, les blocs variables laissés intacts. Commentez chaque ligne modifiée, pour pouvoir relire votre changement et revenir en arrière sans chercher.
5Vérification : lisez les compteursdoute : « comment savoir que ça marche ? »
Après modification, lisez les compteurs de cache dans la réponse de l'API. La preuve tient en deux valeurs : une écriture positive au premier appel, une lecture positive aux appels suivants. Pas d'impression, pas de chiffre d'économie promis à l'avance : des compteurs que vous lisez vous-même.
6Pièges : sortez les données dynamiquesdoute : « pourquoi mon cache ne prend pas ? »
Une date, une heure ou un identifiant de session injectés dans un bloc stable cassent le cache silencieusement : le bloc change à chaque appel sans que vous le voyiez, et la lecture reste à zéro. Repérez ces données dynamiques et sortez-les du bloc caché, côté variable.
À vous de jouer : votre premier cache
Ouvrez le code de votre route d'appel à Claude, ou décrivez-la sur une feuille si vous ne l'avez pas sous la main. Cochez à mesure.
Le résultat, en 30 secondes
À partir de votre seule matière (le code de votre route d'appel, votre instruction de base, la structure de vos messages), le prompt rend quatre livrables : le tableau stable / variable, le code modifié commenté, la checklist de vérification et la liste de vos pièges.
Stable (à cacher) : instruction de base, règles de ton, document de contexte. Variable (à ne jamais cacher) : message du client, historique récent. Code modifié : le marqueur de cache posé sur les blocs stables, chaque ligne commentée. Checklist : écriture positive au premier appel, lecture positive aux suivants. Piège repéré : la date du jour injectée dans l'instruction de base, à sortir du bloc caché.
Le prompt prêt à coller
# RÔLE Tu es un ingénieur spécialisé dans l'optimisation des coûts d'API de modèles de langage, et en particulier du prompt caching de l'API Claude. Tu es précis, pédagogue, et tu vouvoies. Tu ne t'appuies QUE sur ce que je te donne. Ce qui manque, tu me le demandes, tu ne l'inventes jamais. Si tu n'es pas sûr qu'un bloc est réellement stable d'un appel à l'autre, tu le signales au lieu de l'affirmer. # CONTEXTE Je gère un agent conversationnel qui appelle l'API Claude. Je paie trop cher sur les tokens d'entrée parce que je renvoie, à chaque message, la même partie stable (instruction de base, ton, règles, documents de contexte) que Claude doit relire et refacturer à chaque fois. Je veux mettre en cache cette partie stable pour ne plus la payer à chaque appel. Ma matière (si j'en ai) : [collez ici le code de votre route d'appel à Claude, votre instruction de base, et la structure de vos messages. Si vous n'avez rien, laissez vide et suivez le mode interview.]
Le prompt lit le code de votre route d'appel à Claude, sépare le stable du variable, et vous rend la modification exacte à coller : tableau de tri avec tailles estimées, code modifié commenté, checklist des compteurs à lire et liste de vos pièges. Pas de code sous la main ? Il passe en mode interview et vous questionne point par point. Laissez votre email, je vous l'envoie.
Vérifiez que c'est à vous
Vous posez le marqueur de cache sur votre instruction de base. Dix messages plus tard, le compteur de lecture du cache est toujours à zéro. Quelle est la cause la plus probable ?
D'abord avec vos mots, sans regarder les options :
Expliquez-le pour l'ancrer
En une phrase, à un confrère qui paie l'API Claude : pourquoi mettre en cache la partie stable de ses appels, et qu'est-ce qui casse un cache sans prévenir ? Si vous savez le dire simplement, c'est à vous.
Ce que vous savez faire maintenant
- Inventorier et trier le stable et le variable dans n'importe quel appel à l'API Claude.
- Poser un marqueur de cache au bon endroit, regrouper les blocs trop courts, et laisser le variable hors du cache.
- Lire les compteurs de l'API pour prouver que le cache fonctionne, sans promettre un chiffre d'économie inventé.