Imaginez que vous consultiez un avocat chaque semaine sur le même dossier. À chaque rendez-vous, il relit l'intégralité du dossier depuis le début, et vous facture ces heures de lecture. C'est absurde, mais c'est exactement ce qui se passe quand vous envoyez le même long contexte à une IA à chaque requête : vous payez la relecture complète, encore et encore. Le prompt caching, c'est dire à l'avocat de garder le dossier ouvert sur son bureau.
C'est probablement le levier d'économie le plus rentable et le moins utilisé de l'IA en entreprise. Avec la hausse des tarifs annoncée pour septembre sur plusieurs modèles, dont Claude Sonnet 5, le moment est bien choisi pour comprendre comment il fonctionne.
Le problème qu'il résout
Une IA n'a pas de mémoire entre deux appels. À chaque requête, vous devez lui renvoyer tout ce dont elle a besoin : le prompt système, les instructions, les documents de référence, l'historique de la conversation. C'est ce qu'on appelle le contexte, expliqué dans notre article dédié.
Or ce contexte est souvent largement identique d'un appel à l'autre. Un agent qui travaille sur une base de code renvoie la même base de code à chaque étape. Un assistant métier renvoie le même prompt système de trois mille mots à chaque question. Un chatbot documentaire renvoie les mêmes documents de référence en permanence.
Et vous payez ces tokens d'entrée au tarif plein, à chaque fois. Sur un agent qui enchaîne cinquante étapes, vous avez facturé cinquante fois la lecture du même document.
Le mécanisme
Le prompt caching permet de marquer une portion de votre contexte comme stable. Le fournisseur conserve alors une représentation traitée de cette portion pendant une durée limitée. Aux appels suivants, si cette portion est identique, elle n'est pas retraitée intégralement : elle est lue depuis le cache, à un tarif très inférieur.
L'économie est substantielle. Sur les modèles Claude par exemple, la lecture en cache est facturée une fraction du tarif d'entrée normal, avec des réductions pouvant atteindre 90 % sur les tokens répétés. Certains fournisseurs vont plus loin : chez Moonshot, la relecture de contenu déjà en cache est même gratuite.
Attention à une subtilité. Mettre quelque chose en cache a un coût initial supérieur au tarif normal : compter environ 1,25 fois le tarif d'entrée pour un cache de courte durée, et jusqu'à 2 fois pour un cache d'une heure. Le calcul devient donc simple : le cache est rentable si vous relisez ce contenu plusieurs fois avant qu'il n'expire. Sur deux appels, ce n'est pas intéressant. Sur cinquante, c'est massif. Sur un contenu que vous n'utilisez qu'une fois, c'est une perte sèche.
Les trois règles pour que ça marche
1. Mettez le stable au début, le variable à la fin. C'est la règle la plus importante et la plus mal comprise. Le cache fonctionne sur un préfixe identique : si vous modifiez un seul caractère au début de votre contexte, tout ce qui suit devient invalide. Structurez donc vos requêtes en plaçant le prompt système et les documents de référence en tête, et la question de l'utilisateur tout à la fin.
2. Surveillez la durée de vie. Un cache expire, généralement après quelques minutes s'il n'est pas réutilisé. Si vos appels sont espacés de vingt minutes, un cache de cinq minutes ne vous servira jamais et vous aurez payé le surcoût d'écriture pour rien.
3. Vérifiez que ça fonctionne réellement. Les réponses de l'API indiquent combien de tokens ont été lus depuis le cache et combien ont été écrits. C'est la seule preuve que votre configuration marche. Beaucoup d'équipes croient avoir activé le cache alors qu'un détail invalide le préfixe à chaque appel, et paient le surcoût d'écriture sans jamais bénéficier de la lecture.
Pourquoi c'est particulièrement pertinent maintenant
Trois évolutions rendent ce levier plus important qu'avant.
Les hausses de tarifs d'abord, avec la fin de plusieurs périodes promotionnelles à la fin de l'été. Un cache bien construit peut compenser une part significative d'une augmentation de 50 %.
Les agents autonomes ensuite. Comme nous l'expliquions dans notre article sur les agents, ces systèmes fonctionnent en boucle : observer, planifier, agir, vérifier. Chaque tour renvoie l'essentiel du contexte précédent. C'est le cas d'usage idéal pour le cache, et aussi celui où l'oublier coûte le plus cher.
Les contextes géants enfin. Quand les modèles acceptent un million de tokens, la tentation est d'y verser des documents entiers. Sans cache, c'est financièrement intenable.
Ce qu'il faut retenir
Le prompt caching est un exemple typique d'optimisation invisible : elle ne change rien à la qualité de vos résultats, elle change seulement le montant de votre facture. C'est aussi pour cette raison qu'elle est souvent négligée, puisque rien ne casse quand on l'oublie.
Le réflexe utile est simple : chaque fois que vous vous apprêtez à renvoyer un contenu identique à une IA pour la deuxième fois, demandez-vous s'il ne devrait pas être en cache. Combiné aux traitements par lots, qui offrent généralement 50 % de réduction sur les tâches non urgentes, vous pouvez souvent réduire une facture de moitié sans toucher à une ligne de votre logique métier. C'est rarement le cas en informatique, autant en profiter.