Maîtriser le coût IA en 5 leviers documentés
Le prompt caching change l'économie de l'IA. Anthropic propose -90 % sur les input tokens cachés (0,1× le prix standard sur cache hit). Sur des conversations longues (RAG, agents, support client), le caching peut diviser la facture par 5 à 10. Coût d'écriture du cache : 1,25× standard pour TTL 5 min.
Workslop = 186 $/employé/mois de coût caché. Étude BetterUp x Stanford septembre 2025 : 40 % des employés ont reçu du « workslop » (contenu IA poli mais inutile/inexact) sur 30 jours. Coût moyen : 1h56 par incident, 9 M$/an pour une entreprise de 10 000 personnes. Argument-massue pour vendre la gouvernance prompts.
Le reasoning des LLM se dégrade au-delà de 3 000 tokens. Sweet spot pratique : 150-300 mots dans le prompt utilisateur. Une JSON schema complexe consomme 500+ tokens. 90 outils disponibles dans un agent = 50 000+ tokens avant la première interaction. La gestion du contexte est devenue un métier.
Le choix de modèle est devenu un arbitrage stratégique. Kimi K2.6 (open-source, chinois) est 8-10x moins cher que Claude Opus 4.7 pour ~75 % de la qualité. Pour 80 % des cas d'usage PME, un modèle moyen suffit largement. Garder Opus pour 20 % de cas réellement complexes.
Le harness engineering est l'évolution naturelle du context engineering. Mai 2026 marque le passage du « comment je formule mon prompt ? » au « quel est le système d'exécution qui rend mon agent fiable, économique et observable sur la durée ? ». 8 leviers opérationnels à arbitrer dès la mise en production (voir section 3bis).
Cette page est utile si…
- Tu as commencé à utiliser l'IA en production et tu vois les premières factures
- Tu veux maîtriser les coûts sans sacrifier la qualité
- Tu cherches un cadre pour gouverner les prompts comme du code
- Tu te demandes si tu peux switcher de modèle pour réduire la facture
Le prompt caching, levier n°1 d'optimisation coût
1.1 Comment ça marche
Le prompt caching permet de réutiliser le calcul d'une portion du contexte qu'on envoie à plusieurs reprises au modèle. Concrètement : si tu as un long système prompt + un long manuel produit que tu envoies à chaque conversation, le modèle peut « mémoriser » cette portion stable et la facturer 0,1× le prix standard (cache hit).
Anthropic a popularisé le pattern. AWS Bedrock l'a adopté. OpenAI propose un équivalent.
1.2 Cas d'usage où le caching divise la facture
- RAG sur corpus stable : système prompt + chunks récupérés similaires entre requêtes
- Agents multi-tour : conversation longue où le contexte initial reste identique
- Support client : FAQ / base de connaissance envoyée à chaque interaction
- Génération de code : codebase ou documentation envoyée en contexte stable
1.3 Coûts du caching à connaître
- Lecture cache (cache hit) : 0,1× prix standard input
- Écriture cache : 1,25× prix standard input pour TTL 5 min, 2× pour TTL 1h
- Pas de cache : prix standard
→ Stratégie type : tout ce qui est stable > 5 min (système prompt, FAQ, manuel produit) → cacher avec TTL 1h. Tout ce qui change vite → ne pas cacher.
1.4 Économie type pour une PME
Pour une PME utilisant Claude pour du support client (1000 conversations/mois × 4000 tokens contexte stable) :
- Sans caching : ~150-200 €/mois
- Avec caching (90 % cache hit) : ~30-50 €/mois
Le workslop, coût caché documenté
2.1 Définition (BetterUp x Stanford 2025)
Le workslop = contenu produit par IA qui a l'air poli et professionnel, mais qui est inutile, inexact, ou pire, qui force des corrections en aval. Exemples :
- Mail commercial parfaitement rédigé mais qui dit n'importe quoi sur le produit
- Compte-rendu de réunion qui invente des engagements
- Code qui appelle une fonction qui n'existe pas
- Synthèse documentaire qui omet l'élément critique
2.2 Les chiffres qui doivent t'arrêter
- 40 % des employés ont reçu du workslop sur les 30 derniers jours (étude BetterUp x Stanford, septembre 2025, n=1100)
- 1h56 : temps moyen perdu par incident workslop (correction, vérification, refonte)
- 186 $/employé/mois de coût caché en moyenne
- 9 M$/an pour une entreprise de 10 000 personnes
2.3 Comment réduire le workslop : la gouvernance prompts comme du code
Cinq pratiques documentées :
- Versionner les prompts dans un repo git (pas dans des chat éphémères)
- Tester les prompts avec un dataset golden (50-100 cas) avant déploiement
- Documenter chaque prompt : objectif, audience, format de sortie attendu, contre-exemples
- Reviewer les prompts comme du code (PR avec relecture par un pair)
- Mesurer les regressions quand on change de modèle ou qu'on optimise
→ Outils : promptlayer, langfuse, helicone (open-source), phoenix arize (open-source)
La gestion du contexte (context engineering)
3.1 Le contexte n'est pas infini, ni cognitivement neutre
Bien que les modèles annoncent des fenêtres de 1M, 2M, 10M tokens, leur reasoning se dégrade dès 3 000 tokens (recherche état de l'art 2026 sur la dégradation de l'attention long-context).
Le contexte qui compte = celui que le modèle utilise effectivement, pas celui qu'on lui envoie.
3.2 Le coût des tools et schemas dans un agent
Quand on construit un agent avec MCP servers (Model Context Protocol) ou tool calling :
- Une JSON schema complexe = 500+ tokens par outil
- 90 outils disponibles = 50 000+ tokens avant la première interaction utilisateur
- Multiplié par chaque appel à l'agent
→ Stratégie : filtrer les outils par contexte (un agent commercial n'a pas besoin des outils techniques). Réduit le contexte initial de 80-90 %.
3.3 Sweet spot pratique en context engineering
Pour un prompt utilisateur :
- 150-300 mots : sweet spot reasoning
- 300-1000 mots : encore acceptable pour tâches structurées
- > 1000 mots : commence à diluer l'attention
Pour le contexte total (système + retrieval + historique) :
- < 8K tokens : excellent
- 8K-32K tokens : acceptable avec discipline
- > 32K tokens : nécessite caching et filtrage
Du context engineering au harness engineering
Le shift conceptuel 2026
Le prompt engineering (2023-2024) a centré l'attention sur la formulation des instructions. Le context engineering (2025-2026, traité dans les sections précédentes) a élargi le périmètre à la gestion du contexte injecté dans le modèle. Mai 2026 marque un nouveau palier : l'émergence du harness engineering comme discipline englobante.
Le harness, c'est tout ce qui entoure l'appel LLM : orchestration, tools, loops, guardrails, observabilité, fallback. Le prompt n'est plus qu'un composant parmi d'autres.
Le terme s'impose dans la communauté builders (concept formalisé notamment par @akshay_pachaar et Anthropic Engineering en mai 2026, publication « Effective harnesses for long-running agents »). Le shift est stratégique : on ne réfléchit plus en termes de « comment je formule mon prompt ? » mais en termes de « quel est le système d'exécution qui rend mon agent fiable, économique et observable sur la durée ? ».
Checklist opérationnelle PME — les 8 leviers du harness
Une PME qui industrialise un agent ou un pipeline IA doit formaliser 8 leviers :
| # | Levier | Question opérationnelle |
|---|---|---|
| 1 | Prompt caching vs semantic caching | Quels prompts ré-utilise-t-on tel quel (caching exact) ? Quels appels acceptent une similarité sémantique (caching approximé) ? |
| 2 | KV cache à l'échelle | Est-ce que la stack supporte le KV cache pour les conversations longues ? Quel impact sur la latence ? |
| 3 | Speculative decoding vs quantization | Pour réduire la latence : un petit modèle qui propose et un gros qui valide (speculative) ? Ou un gros modèle quantifié (8 bits, 4 bits) ? |
| 4 | LLM-as-judge + human evals | Quels critères sont évalués par un LLM juge (cohérence, format, factualité) ? Quels critères restent sur évaluation humaine (jugement métier, ton, conformité) ? |
| 5 | Cost attribution par feature | Combien coûte chaque feature produit par mois ? Par utilisateur ? Par requête ? |
| 6 | Agent guardrails & loop budgets | Combien de tools un agent peut-il appeler avant escalade ? Combien de tokens max par session ? Quels patterns d'output sont interdits ? |
| 7 | Model routing | Quel modèle traite quel type de requête ? Sur quels critères ? (coût, latence, qualité, sensibilité) |
| 8 | Graceful fallback | Que se passe-t-il quand le modèle principal est indisponible ou répond mal ? Y a-t-il un fallback testé ? |
Implication pour la PME : ces 8 leviers ne sont pas à mettre en place tous d'un coup. Mais ils doivent être listés et arbitrés dès que l'agent passe en production. Une PME qui n'a pas tranché sur ces 8 questions opère « au feeling » — ce qui marche en POC, pas en production.
Lien avec le pattern Code Execution with MCP
L'un des patterns les plus efficaces du harness 2026 est le Code Execution with MCP publié par Anthropic Engineering. Il s'agit de transformer l'agent en exécuteur de code Python qui appelle les MCP tools localement, traite les données dans le sandbox, et ne renvoie au modèle que les données strictement nécessaires.
📉 Bénéfice mesuré : réduction de 60-80 % de la consommation de tokens sur les workflows longs (15+ steps), avec amélioration de la latence à la clé.
Pattern documenté en détail dans la fiche Agents en production §8.3 (Code Execution with MCP). À considérer comme brique d'optimisation du levier 6 (loop budgets) et du levier 5 (cost attribution). Cartographie macro complémentaire dans la même fiche Agents en production §8.1 (9-layer architecture).
Le choix de modèle comme arbitrage stratégique
4.1 La règle 80/20 du choix de modèle
Pour la majorité des cas d'usage PME :
- 80 % des requêtes sont gérables par un modèle moyen (Claude Sonnet, GPT-4 mini, Mistral Medium, Kimi K2.6)
- 20 % des requêtes complexes nécessitent un modèle haut de gamme (Claude Opus, GPT-4 Turbo)
Coût typique :
- Modèle moyen : 0,5-3 $/M input tokens, 2-15 $/M output tokens
- Modèle haut de gamme : 5-15 $/M input, 15-75 $/M output
→ Bien dispatcher = diviser la facture par 5 à 10.
4.2 Le cas Kimi K2.6 — la bascule chinoise
Kimi K2.6 (open-source Moonshot AI, sortie 2026) :
- 0,80 $/M input, 3,60 $/M output (vs Claude Opus 4.7 à 5 $/M input et 25 $/M output)
- Performance proche de Claude Opus sur SWE-Bench, Terminal-Bench, agentic coding
- Open-source, self-hostable
- Hébergement EU possible
→ Pour les use cases coding agentique (cf. Faire développer une appli métier), Kimi K2.6 devient un challenger sérieux à Opus.
4.3 Stratégie de routage (LLM gateway)
Outils type LiteLLM (open-source) ou OpenRouter permettent de :
- Router selon complexité de la requête (simple → modèle pas cher, complexe → modèle premium)
- Implémenter un fallback (si Anthropic down → bascule OpenAI)
- Tracker le coût par cas d'usage
- A/B tester deux modèles en parallèle
→ Gain typique : 30-60 % de réduction de facture sur 6 mois après déploiement d'un LLM gateway.
Tableau récapitulatif des leviers
| Levier | Effort initial | Gain typique | Quand y aller |
|---|---|---|---|
| Prompt caching | 1-3 jours dev | -50 à -80 % facture inférence | Dès que contexte stable > 5 min |
| Gouvernance prompts (versioning, tests) | 1-2 semaines setup | -30 à -50 % workslop | Avant la mise en prod |
| Filtrage outils MCP | 1-2 jours | -50 à -90 % contexte initial agent | Dès que > 10 outils |
| LLM gateway + routage modèle | 1-2 semaines | -30 à -60 % facture totale | Dès 500 €/mois de facture |
| Switch modèle premium → moyen | Quelques heures | -50 à -90 % par requête | Audit régulier des cas d'usage |
Plan d'action 30 jours pour maîtriser les coûts IA
Jours 1-7 — Audit
- Extraire la facture détaillée par cas d'usage
- Identifier les 3-5 cas d'usage les plus consommateurs
- Mesurer le contexte moyen et le ratio cache hit actuel
Jours 8-15 — Quick wins
- Activer le prompt caching sur les cas d'usage à contexte stable
- Filtrer les outils MCP des agents (ne garder que les utilisés)
- Switcher les cas d'usage simples vers un modèle moyen
Jours 16-30 — Gouvernance
- Mettre en place le versioning de prompts dans un repo git
- Construire un dataset golden de 50-100 cas (par cas d'usage)
- Déployer un LLM gateway (LiteLLM open-source) pour routage et tracking
Synthèse harness — les 8 leviers à arbitrer
Au-delà des 30 jours, formaliser les 8 leviers du harness engineering (section 3bis) : caching, KV cache, speculative vs quantization, LLM-as-judge, cost attribution, guardrails & loop budgets, model routing, graceful fallback. Une PME qui n'a pas tranché sur ces 8 questions opère « au feeling » : ce qui marche en POC, pas en production.
40 à 70 % de la facture initiale. Ces ordres de grandeur sont reproductibles dès lors que les 3 premières optimisations (caching, filtrage outils, switch modèle) sont rigoureusement appliquées.
Pour aller plus loin
📚 Bibliographie transverse : les ressources de fond (LLM gateway, monitoring, observabilité) sont centralisées sur la page Ressources → Bibliographie. Cette section ne liste que les ressources spécifiques à ce cadrage.