Cost engineering des agents IA : budgets, caching, routing (2026)

Le vrai coût d’un agent : la facture a plusieurs lignes

Quand un agent coûte trop cher, la réaction réflexe est :

“Il faut un modèle moins cher.”

Parfois oui. Souvent non.

Parce que le coût réel ressemble plutôt à :

Coût par tâche résolue =

• coût LLM (input + output),
• • coût des outils (OCR, STT, DB, search, email, CRM),
• • coût des retries (LLM + outils),
• • coût infra (workers, queues, storage, observabilité),
• • coût humain (HITL, QA, support),
• divisé par “tâches réellement résolues”.

Et la dernière ligne est la plus cruelle : un agent peut “répondre” et ne rien résoudre.

Si vous mesurez seulement “tokens”, vous optimisez la mauvaise chose.

Budgets : sinon l’agent dépense (et vous découvrez après)

Un agent sans budget, c’est un stagiaire avec une carte corporate illimitée :

• il “vérifie”,
• il “re-vérifie”,
• il “double-check”,
• et à la fin il vous rend une réponse parfaite… pour une question qui ne le méritait pas.

Les budgets doivent exister à trois niveaux :

1) Budget tokens (LLM)

• max tokens input (limiter contexte),
• max tokens output (limiter verbiage),
• max tours (stop les boucles).

2) Budget outils (tool calls)

• max tool calls par exécution,
• max coût “outil” (OCR, TTS, etc),
• timeouts stricts.

3) Budget temps (latence)

Un agent qui “réfléchit” 25 secondes sur une tâche simple est un agent qui brûle :

• votre budget infra,
• votre patience utilisateur,
• et souvent votre taux de réussite (timeouts).

Ces budgets doivent être codés, pas suggérés.

Si vous les laissez au prompt, vous faites de la gouvernance “au feeling”.

Routing multi-modèles : une équipe, pas une star

Le pattern le plus rentable (et le plus stable) :

• petits modèles rapides pour router/extract/formatter,
• gros modèles pour les décisions rares, complexes, à fort enjeu.

Pourquoi ?

• le “gros” modèle n’a pas besoin de reformater un JSON,
• le “petit” modèle n’a pas besoin d’arbitrer une décision de conformité.

Le routing n’est pas une optimisation. C’est une architecture.

Routing par risque (la stratégie adulte)

Exemples de règles simples :

• si l’action est irréversible → modèle premium + validation humaine
• si la tâche est extraction → modèle fast/cheap + validation schema
• si le document fait 120 pages → OCR + LLM (pas VLM “au hasard”)

Ce routing par risque est aussi un routing par coût.

Prompt caching : payer une fois les “instructions”, pas à chaque tour

Une grande partie du gaspillage vient d’un phénomène trivial :

vous renvoyez les mêmes instructions, les mêmes politiques, les mêmes exemples… à chaque requête.

OpenAI : prompt caching

OpenAI documente le prompt caching comme un mécanisme où les requêtes réutilisant un même préfixe de prompt peuvent être traitées plus rapidement et à moindre coût (les serveurs routent la requête vers des machines ayant déjà traité ce préfixe).¹

OpenAI explique aussi (dans un article dédié) des détails pratiques :

• les réponses peuvent inclure un champ cached_tokens,
• les caches sont généralement nettoyés après une période d’inactivité (et purgés dans un délai maximal).²

Traduction : si vous placez votre contenu “stable” en préfixe (policies, exemples), vous économisez.

Anthropic : prompt caching

Anthropic documente aussi la mise en cache des prompts, avec une logique de TTL (durée de vie) et des modèles supportés.³

Vous noterez un point intéressant : la doc liste explicitement des modèles supportant le caching (ex. différentes variantes Sonnet/Opus/Haiku), ce qui rappelle une règle d’ingénierie :

• une optimisation n’est utile que si elle est disponible sur le modèle que vous utilisez.

La règle d’or du caching : stable au début, dynamique à la fin

Le Cookbook OpenAI (Prompt Caching 101) donne une recommandation très concrète :

• mettre le contenu statique ou fréquemment réutilisé au début du prompt,
• garder les informations dynamiques (le “cas”) plus tard.⁴

Ce n’est pas un conseil esthétique. C’est une méthode pour que le cache ait une chance d’être réutilisé.

Batch : quand le temps réel est un luxe

Beaucoup de workloads agentiques ne sont pas temps réel :

• traitement back-office,
• enrichissement CRM,
• génération de contenus en lot,
• extraction de documents.

OpenAI documente une Batch API qui permet d’envoyer des requêtes en lot à un endpoint et de récupérer les résultats plus tard.⁵

Le batch vous donne :

• un coût souvent mieux contrôlable,
• une meilleure utilisation des ressources,
• et un moyen de “déporter” des tâches non urgentes hors du chemin critique.

Le piège : traiter en temps réel ce qui pourrait être asynchrone. C’est la façon la plus simple de payer cher… pour rien.

Cache applicatif : le cache qui protège votre ROI (si vous l’encadrez)

Il y a le caching “provider” (prompt caching). Et il y a le caching “produit”.

1) Cache de résultats déterministes (le plus safe)

Exemples :

• lookup CRM (si TTL court et invalidation claire),
• tables de correspondance,
• règles métier versionnées,
• réponses de vérification.

Ici, le cache est “classique”. L’IA n’a rien à faire là.

2) Cache de génération (à manier comme une arme)

Vous pouvez aussi cacher des sorties LLM quand :

• le prompt est stable,
• l’output doit être stable,
• et le risque est faible (ex. reformats, templates).

Mais attention :

• le contexte change,
• les politiques changent,
• le ton change.

Donc vous cachez avec :

• version de prompt,
• version de règles,
• et TTL court.

3) Cache sémantique (le plus rentable, le plus dangereux)

Le cache sémantique dit :

“Si une question ressemble à une autre, on réutilise la réponse.”

Rentable, oui. Mais vous devez accepter une vérité :

• deux questions “similaires” peuvent exiger deux réponses différentes (contexte, client, date).

Donc : cache sémantique seulement si vous avez un garde-fou métier.

Réduire le contexte : ne pas repayer l’histoire à chaque tour

Un gaspillage massif vient d’une habitude “chat” :

• on renvoie toute la conversation,
• on renvoie toute la mémoire,
• on renvoie toutes les sources,
• et on espère que le modèle fera le tri.

Ce n’est pas de l’ingénierie. C’est du tourisme.

En agentic, vous devez séparer :

• state d’exécution (où on en est, résultats validés),
• mémoire long terme (sources, historiques, profils),
• contexte immédiat (ce tour).

Sinon, vous payez deux fois :

1. en tokens,
2. en instabilité (le modèle se perd dans une bouillie de contexte).

Le pattern robuste est simple :

• vous gardez un state minimal,
• vous récupérez juste les sources nécessaires (RAG),
• et vous résumez le reste.

Ce choix est autant financier que qualitatif.

Sorties courtes : le régime de tokens le plus rentable (et le plus oublié)

Les modèles sont polis. Ils aiment expliquer. Ils adorent écrire des paragraphes entiers “pour être sûrs”.

Mais en prod :

• une réponse longue augmente le coût,
• augmente la latence,
• et parfois augmente le risque (plus d’affirmations = plus d’erreurs possibles).

Deux pratiques simples :

1. Répondre court par défaut
   “Voilà la décision + voilà l’action + voilà la prochaine question.”

2. Monter en détail uniquement sur demande
   “Si vous voulez la justification complète, dites ‘détails’.”

Ce n’est pas “radin”. C’est une UX.

Et ça a un effet immédiat sur votre facture.

Exemple : un prompt “cachable” (et maintenable)

Le piège, c’est de faire du caching “à la fin”.

Le bon design ressemble à ça :

1. Préfixe stable (cachable) :

• rôle,
• politiques,
• style,
• schéma de sortie,
• outils autorisés,
• exemples.

2. Partie dynamique :

• le cas utilisateur,
• les sources récupérées,
• l’état minimal.

Le Cookbook OpenAI recommande explicitement de placer le contenu stable/fréquemment réutilisé au début du prompt pour maximiser les bénéfices du caching.⁴

Exemple (très simplifié) :

# Préfixe stable (cachable)
Vous êtes un agent "claims-triage".
Contraintes: ne jamais inventer, citer les sources, escalader si risque élevé.
Outils: search_policy, create_ticket, send_email.
Sortie: JSON strict { intent, missing_docs[], action, rationale_short }.
 
# Partie dynamique (cas)
Email: ...
Sources: ...
State: ...

Ce n’est pas seulement pour le coût. C’est aussi pour la maintenabilité : vous versionnez le préfixe.

Les coûts invisibles : outils, retries, observabilité

Outils : le coût peut être ailleurs que le LLM

Sur un agent documents :

• OCR peut coûter plus cher que la génération.

Sur un voice agent :

• STT + TTS + streaming + téléphonie peut dominer.

Sur un agent CRM :

• l’enrichissement (scraping, data providers) peut coûter plus que le texte.

Donc votre optimisation doit instrumenter :

• coût LLM,
• coût outil,
• coût retry,
• coût stockage/traces.

Retries : la ligne cachée de la facture

Chaque retry est un multiplicateur.

Si votre outil renvoie 429, et que vous retry sans backoff/jitter, vous :

• augmentez le coût,
• augmentez la latence,
• et augmentez l’incident.

Voir : /blog/agents-ia/production/agents-en-production-retries-idempotence-queues.

Observabilité : “c’est cher” jusqu’au jour où ça sauve la prod

Tracer coûte (stockage, pipeline, dashboards). Mais ne pas tracer coûte plus :

• debugging lent,
• incidents longs,
• régressions invisibles,
• et itérations dangereuses.

L’observabilité est une assurance. Vous ne la trouvez “trop chère” que tant que vous n’avez pas eu d’accident.

Anti-patterns qui explosent la facture (et comment les éviter)

1. Tout premium, tout le temps
   Le modèle le plus cher pour router, reformater, extraire un champ. C’est comme utiliser une Ferrari pour livrer des pizzas : ça marche, mais vous n’allez pas aimer la compta.

2. Contexte illimité
   Vous collez 40 pages de contexte “au cas où”. Résultat : tokens + instabilité + latence.

3. Sorties longues par défaut
   L’agent écrit des essais. Le métier voulait une décision et un ticket.

4. Retries sans stratégie
   Un incident devient une multiplication de coûts. (Et parfois une panne plus longue.)

5. Pas de batching
   Vous payez du “temps réel” sur du back-office.

La morale : les coûts ne se contrôlent pas après coup. Ils se contrôlent dans le design.

Dernier rappel (et promis j’arrête) : l’optimisation la plus rentable n’est pas toujours technique. Parfois, c’est de simplifier le workflow, de mieux cadrer la demande, ou de demander une information manquante plutôt que de “tenter un coup”.

Méthode 10 jours : réduire le coût sans casser la qualité

FAQ