Prompt caching : réutiliser les calculs

Qu’est-ce que le prompt caching ?

Lorsque vous envoyez le même préfixe de prompt à répétition — un prompt système long, des instructions détaillées, un document de référence — OpenAI peut automatiquement mettre en cache ce préfixe. Les appels suivants qui partagent ce préfixe bénéficient d’un TTFT réduit et d’un coût inférieur sur les tokens en entrée. Autrement dit, le travail d’ingestion du contexte stable n’est plus refait à chaque requête.

Le prompt caching est automatique depuis 2025 : vous n’avez rien à activer. OpenAI détecte les préfixes identiques et les met en cache. Votre marge de manœuvre n’est donc pas de l’allumer ou de l’éteindre, mais d’écrire vos prompts de façon à ce que le mécanisme puisse s’appliquer. C’est un travail de structure, pas de configuration, et c’est là que la plupart des équipes laissent des gains sur la table.

Comment ça fonctionne

Le cache porte sur les préfixes du prompt : les premiers tokens doivent être strictement identiques d’un appel à l’autre, et la correspondance s’arrête au premier caractère divergent. Une taille minimale de 1 024 tokens est requise pour déclencher la mise en cache, ce qui exclut d’emblée les prompts système courts. Le cache est partagé au sein d’une même organisation, ce qui signifie que plusieurs services de votre entreprise appelant le même préfixe s’entraident. Sa durée de vie va de quelques minutes à quelques heures, sans garantie ferme, et la réduction obtenue est d’environ 50 % sur le coût des tokens en entrée mis en cache.

La conséquence pratique de la règle du préfixe est qu’il faut placer les éléments stables en début de prompt et les éléments variables à la fin. Un service qui insère la date du jour où l’identifiant de session en tête de son prompt système invalide son cache à chaque appel sans jamais s’en rendre compte.

import openai

client = openai.OpenAI()

# ✅ Bonne structure : éléments stables en premier
PROMPT_SYSTEME = """Vous êtes un assistant juridique spécialisé en droit
français des contrats. Vous analysez les clauses contractuelles selon le
Code civil et la jurisprudence récente. Vous répondez toujours en
structurant votre analyse : 1) Identification de la clause,
2) Analyse juridique, 3) Risques potentiels, 4) Recommandations.

Voici le contrat de référence à analyser :
[Insérez ici un document de 2000+ tokens qui ne change pas entre les appels]
"""

def analyser_clause(clause: str) -> str:
    """Chaque appel réutilise le cache du prompt système."""
    response = client.responses.create(
        model="gpt-5.6-terra",
        instructions=PROMPT_SYSTEME,  # Préfixe stable = mis en cache
        input=f"Analysez cette clause : {clause}",  # Partie variable
    )
    return response.output_text

Dans cet exemple, le contrat de référence et la grille d’analyse constituent le bloc invariant, tandis que la clause examinée change à chaque appel. Analysez quarante clauses d’un même contrat et vous payez le contexte une fois au tarif plein.

Vérifier le cache

Une optimisation que vous ne mesurez pas est une optimisation que vous croyez avoir. L’API retourne des informations sur l’utilisation du cache dans la réponse :

response = client.responses.create(
    model="gpt-5.6-terra",
    instructions=PROMPT_SYSTEME,
    input="Analysez la clause de non-concurrence.",
)

# Vérifier l'utilisation du cache
usage = response.usage
print(f"Tokens entrée : {usage.input_tokens}")
print(f"Tokens entrée (cache) : {usage.input_tokens_details.cached_tokens}")
print(f"Tokens sortie : {usage.output_tokens}")

# Si cached_tokens > 0 : le cache a été utilisé
ratio_cache = usage.input_tokens_details.cached_tokens / usage.input_tokens
print(f"Ratio de cache : {ratio_cache:.1%}")

Loguez ce ratio en production plutôt que de le regarder une fois en développement. Une chute soudaine du taux de cache est le symptôme le plus fiable d’un changement involontaire dans la construction du prompt, et vous la verrez avant que la facture mensuelle ne vous l’apprenne.

Structurer pour maximiser le cache

La première approche consiste à enrichir volontairement le prompt système. Contre-intuitif quand on cherche à réduire les tokens, mais cohérent avec la règle du seuil : un prompt système de 900 tokens ne sera jamais mis en cache, alors que le même enrichi d’exemples few-shot et d’un document de référence franchit la barre et bascule au tarif réduit sur la partie mise en cache.

# Enrichir le prompt système pour maximiser le cache
PROMPT_ENRICHI = """
[Instructions détaillées - 500+ tokens]
[Exemples few-shot - 500+ tokens]
[Document de référence - 1000+ tokens]
---
Total > 1024 tokens = éligible au cache
"""

Dans une conversation multi-tours, le mécanisme joue en votre faveur sans effort supplémentaire : l’historique accumulé constitue un préfixe naturellement stable, qui grandit à chaque échange. À condition de toujours réinjecter les messages dans le même ordre, le tour numéro dix profite du cache construit par les neuf précédents.

def conversation_avec_cache(historique: list[dict], nouveau_message: str):
    """L'historique croissant maximise le cache automatiquement."""
    historique.append({"role": "user", "content": nouveau_message})

    response = client.responses.create(
        model="gpt-5.6-terra",
        instructions=PROMPT_SYSTEME,
        input=historique,
    )

    historique.append({
        "role": "assistant",
        "content": response.output_text,
    })
    return response.output_text

Enfin, puisque la durée de vie du cache se compte en minutes, le regroupement temporel des requêtes qui partagent un préfixe devient une décision d’ordonnancement. Traiter les quarante clauses d’un contrat d’affilée maintient le cache chaud ; les étaler sur la journée en intercalant d’autres dossiers le laisse expirer entre chaque appel.

import asyncio

async def batch_avec_cache(clauses: list[str]) -> list[str]:
    """Envoie les requêtes rapidement pour profiter du cache."""
    resultats = []
    for clause in clauses:
        resultat = analyser_clause(clause)
        resultats.append(resultat)
    return resultats

Trois erreurs annulent tout ce travail, et elles se ressemblent : modifier le début du prompt, ne serait-ce que d’un caractère, invalide le cache pour la totalité de la requête ; randomiser l’ordre des instructions, par exemple en construisant le prompt à partir d’un dictionnaire non ordonné, produit le même effet de façon intermittente et donc difficile à diagnostiquer ; et espérer un gain sous le seuil de 1 024 tokens revient à optimiser quelque chose qui ne se déclenche jamais.

Points clés à retenir

• Le prompt caching est automatique chez OpenAI — placez les éléments stables en début de prompt
• Seuil minimum : 1 024 tokens identiques en préfixe
• Gain : ~50 % sur les tokens en entrée mis en cache + TTFT réduit
• Vérifiez usage.input_tokens_details.cached_tokens pour confirmer le cache