Prompt caching : la technique qui réduit le coût et la latence de vos agents IA

Le 22 juillet 2026, l'équipe d'ingénierie d'Earendil a publié une note technique détaillée sur le fonctionnement du cache de prompt dans les agents IA. Le constat de départ est simple mais rarement pris au sérieux : ce mécanisme discret pèse directement sur votre facture d'API et sur la latence perçue par vos utilisateurs. Pour toute équipe qui fait tourner un agent en production, que ce soit un agent de code, un assistant support ou un bot d'automatisation interne, comprendre le cache de prompt n'est plus un détail d'implémentation.

Un modèle de langage est souvent présenté comme une fonction : on envoie du texte, on reçoit du texte. Cette image est trompeuse pour un agent. À chaque tour, celui-ci renvoie quasiment le même contenu que la fois précédente (prompt système, définitions d'outils, instructions de projet, historique de conversation, résultats d'appels d'outils) plus une petite quantité de nouveauté. Sans mécanisme de cache, le modèle recalcule l'intégralité de ce contexte à chaque appel. Sur une session qui atteint des dizaines ou des centaines de milliers de tokens, cela devient lent et coûteux très vite.

Ce qui se cache vraiment derrière le cache de prompt

Techniquement, un transformeur traite un prompt en deux temps. La phase de prefill lit les tokens d'entrée et calcule, pour chaque couche d'attention, une clé et une valeur par token. La phase de decode génère ensuite les tokens de sortie un par un, en comparant la requête du token courant aux clés déjà calculées pour pondérer les valeurs correspondantes. Ces clés et valeurs forment ce qu'on appelle le cache KV (key-value). Le retenir permet au modèle de ne pas recalculer les tokens déjà traités au tour suivant.

Le point crucial souligné par Earendil : ce cache correspond à un préfixe exact de tokens. Deux prompts qui veulent dire la même chose mais qui ne se tokenisent pas identiquement ne partagent pas de cache. Et si un seul token change au milieu du prompt, tout ce qui suit ce token doit être recalculé. Le cache de prompt étend simplement la durée de vie de cet état au-delà d'une seule génération : quand une nouvelle requête commence par les mêmes tokens que la précédente, l'infrastructure d'inférence réutilise le travail déjà fait sur le préfixe commun et ne calcule que le suffixe nouveau.

Où vit ce cache, et pourquoi ça compte pour vous

Les fournisseurs d'inférence stockent ce cache de deux façons. La première, l'affinité de session, garde le cache près du GPU qui l'a calculé et route les requêtes suivantes vers ce même worker. C'est rapide et simple à opérer, mais fragile : si le routeur équilibre la charge autrement, si le worker redémarre ou si l'entrée est évincée, le cache disparaît. La seconde approche distribue le cache entre plusieurs workers via une couche mémoire additionnelle, ce qui améliore la flexibilité d'ordonnancement au prix d'une complexité d'indexation et d'éviction plus grande. Le choix relève de l'infrastructure du fournisseur, mais il explique pourquoi deux appels a priori identiques peuvent afficher une latence très différente d'une requête à l'autre.

Cache explicite ou automatique : deux philosophies d'API

Les API des fournisseurs exposent le cache selon deux styles. Chez Anthropic, l'approche historique repose sur des points de rupture explicites (cache_control) que vous placez vous-même après les parties stables de la requête : prompt système, définitions d'outils, dernier segment de conversation cachable. Vous savez précisément ce qui est écrit en cache et vous payez pour cette écriture, avec un choix de durée de rétention. D'autres API pratiquent le cache automatique de préfixe : la requête part normalement et le fournisseur détecte lui-même le préfixe réutilisable, sans point de rupture posé par le client. Une clé de cache ou un en-tête de session peut aider au routage, mais ne rend jamais deux préfixes différents équivalents pour autant.

Le piège le plus courant : le catalogue d'outils qui bouge

C'est le passage le plus utile de la note d'Earendil pour quiconque construit un agent. Les définitions d'outils (noms, descriptions, schémas JSON) sont placées avant la conversation et repliées dans le prompt système. Ajouter un outil, en retirer un, modifier un schéma, ou même changer l'ordre de sérialisation des outils peut déplacer le premier token qui diffère tout près du début du prompt. Résultat : toute la conversation qui suit, même si elle n'a pas changé d'un caractère, est recalculée depuis ce point de divergence.

C'est une source d'erreur fréquente avec les systèmes de plugins et les catalogues d'outils façon MCP. Charger un outil seulement quand il devient pertinent semble efficace puisque moins de schémas sont envoyés au départ. Mais sur la plupart des modèles, ce chargement tardif invalide le cache de toute la conversation qui suit. Économiser quelques centaines de tokens de schéma peut ainsi forcer le retraitement de dizaines de milliers de tokens de conversation. Certaines API plus récentes proposent un chargement additif d'outils, où un nouvel outil devient disponible à un point précis de la transcription sans invalider ce qui précède : une piste à surveiller si votre fournisseur la propose.

Ce qu'il faut changer dans la conception de vos agents

Concrètement, pour tirer parti du cache plutôt que de le subir :

• Ordonnez votre prompt du plus stable vers le plus volatile. Prompt système, définitions d'outils, instructions de projet fixes, puis historique de conversation en dernier. Ne réinjectez jamais de contenu variable (horodatage, identifiant de requête, donnée utilisateur changeante) avant la fin de ce préfixe stable.
• Chargez le catalogue d'outils au complet dès le début de la session plutôt que par petits ajouts en cours de route, sauf si votre fournisseur supporte explicitement le chargement additif d'outils.
• Gelez le format de sérialisation de vos définitions d'outils. Un simple changement d'ordre ou de formatage JSON entre deux déploiements suffit à casser le cache de toutes les sessions actives.
• Surveillez les rewinds et les branches de session. Si votre agent permet de revenir en arrière dans la conversation ou de créer une branche, la réutilisation du cache dépend des blocs de préfixe réellement conservés côté fournisseur, pas seulement de l'identifiant de session.
• Choisissez le style d'API adapté à votre besoin. Le cache explicite donne du contrôle fin sur ce qui est mis en cache et pour combien de temps, au prix d'une gestion manuelle des points de rupture. Le cache automatique demande moins d'effort d'intégration mais offre moins de visibilité sur ce qui est effectivement réutilisé.

Notre lecture chez CZSyn

Sur les projets où nous intégrons des agents IA pour des clients (support automatisé, assistants internes, agents de développement), le cache de prompt est souvent le levier le plus sous-exploité. Beaucoup d'équipes optimisent le choix du modèle ou la longueur des réponses, alors que la vraie fuite de budget se cache dans un prompt système qui bouge d'un tour à l'autre ou un catalogue d'outils reconstruit dynamiquement.

Pour une PME qui fait tourner un agent en production avec des sessions longues, discipliner l'ordre et la stabilité du contexte peut réduire la facture API de façon plus nette qu'un changement de modèle, et améliore surtout la latence perçue par l'utilisateur final, ce qui compte tout autant que le coût. C'est un chantier d'architecture à traiter dès la conception de l'agent, pas une option de configuration qu'on ajuste après coup sur la facture du mois suivant.

Sources primaires

• Earendil Engineering, « Prompt Caching In Agents », 22 juillet 2026.
• Documentation officielle Anthropic, « Prompt caching ».
• Documentation officielle OpenAI, « Prompt caching ».