---

Le vrai problème n’est pas le prix du token, c’est ce qu’on lui envoie

On a longtemps expliqué les factures d’agents par la grille tarifaire des fournisseurs. C’était une erreur de diagnostic. En 2026, les prix par million de tokens ont continué de baisser chez la plupart des acteurs, et pourtant les praticiens continuent de s’arracher les cheveux sur des factures qui explosent. La raison est structurelle : un agent ne paie pas le prix d’une conversation, il paie le prix d’un système qui se répète à lui-même.

Un chatbot classique envoie un prompt système, un historique de conversation et une question. Un agent envoie tout cela plus les définitions de ses outils, plus les résultats des outils déjà appelés, plus les traces de raisonnement intermédiaires, plus — et c’est le plus vicieux — l’intégralité de l’historique à chaque nouveau tour de boucle. Ce que l’on appelle la croissance quadratique du contexte : si votre agent fait N appels d’outils et que chaque appel réinjecte tout l’historique, le volume total de tokens traités croît en O(N²), pas en O(N).

Les chiffres publics disponibles en octobre 2026 donnent la mesure du désastre. Un agent non optimisé tourne autour de 200 dollars par mois. Un agent correctement architecturé se situe entre 29 et 50 dollars par mois. Le facteur entre les deux : 4 à 7. C’est là que se trouve le fameux « diviser par 5 » — pas dans un tour de passe-passe tarifaire, mais dans une discipline d’ingénierie.

Et le pire, c’est que la plupart des équipes ne le savent même pas. Les agents déployés en production affichent un taux d’échec de 88 % à la mise en service selon les données de 2026, et un agent de support client non surveillé rate plus de 30 % de ses tâches après trois semaines d’exploitation. Autrement dit : on paie souvent très cher pour un agent qui ne fonctionne pas. La facture n’est pas seulement un problème de budget, c’est un symptôme de conception.

---

Anatomie d’une trace : où part réellement l’argent

Prenons une trace d’agent typique, celle d’un assistant outillé connecté à une demi-douzaine de serveurs MCP — le cas d’usage le plus courant en 2026, où un agent avec accès à 15 serveurs MCP n’en sollicite en réalité qu’une demi-douzaine par tâche. Voici les postes qui composent la facture.

1. Le prompt système et les schémas d’outils. C’est le coût fixe, celui qu’on oublie parce qu’il est « gratuit » dans la tête du développeur. Chaque outil exposé au modèle transporte sa définition JSON Schema : nom, description, paramètres, types, contraintes. Un serveur MCP un peu riche peut facilement embarquer plusieurs milliers de tokens de définitions. Multipliez par une demi-douzaine de serveurs sollicités et vous avez un plancher de plusieurs milliers de tokens envoyés à chaque tour, même quand l’outil n’est jamais appelé. C’est le premier poste de gaspillage, et le plus facile à corriger.

2. L’historique de conversation. Il croît linéairement avec les échanges, mais il est renvoyé intégralement à chaque tour. Sur une boucle de dix appels d’outils, le même message d’ouverture peut être facturé dix fois. C’est le mécanisme central de l’inflation.

3. Les résultats d’outils réinjectés. Chaque réponse d’API, chaque page web récupérée, chaque ligne de base de données renvoyée au modèle est un token d’entrée au tour suivant. Un outil de recherche web qui retourne 5 000 tokens de contenu brut coûte 5 000 tokens à chaque fois qu’il est rappelé dans le contexte, pas une seule fois.

4. Les tokens de sortie intermédiaires. Les appels de raisonnement — les fameuses chaînes de pensée, les blocs de planification, les JSON de tool calling — sont facturés au tarif de sortie, généralement plus élevé que l’entrée. Un agent qui « réfléchit » beaucoup avant d’agir paie deux fois : en sortie de raisonnement, puis en entrée lorsqu’il réinjecte ce raisonnement dans le tour suivant.

5. Les retries. Chaque échec d’appel d’outil, chaque timeout, chaque réponse mal formée déclenche une nouvelle tentative — et donc une nouvelle facture complète. Les retries sont le poste le plus insidieux : invisibles dans les dashboards naïfs, ils peuvent doubler la note sur un agent fragile.

6. Les embeddings. Si votre agent fait de la recherche sémantique en mémoire, chaque document indexé et chaque requête produisent des tokens d’embedding, facturés séparément.

7. Le cache lecture/écriture. Le prompt caching (cache de préfixe) facture différemment l’écriture en cache et la lecture depuis le cache. Bien utilisé, c’est le levier le plus puissant ; mal utilisé, c’est une ligne de facture supplémentaire qui masque une régression.

Un ordre de grandeur utile pour arbitrer : sur un agent tool-calling non optimisé, le poste « entrée » (système + schémas + historique + résultats) domine largement la sortie. C’est une bonne nouvelle, car c’est précisément le poste le plus compressible.

---

Le tableau de bord des tarifs : ce que l’on compare vraiment

Les grilles tarifaires d’octobre 2026 doivent être lues avec précaution : les prix par million de tokens ne disent rien sans le volume réellement consommé. Voici la structure de comparaison qui compte, avec les modèles phares de la période — GPT-6 Astra, Claude Opus 5, Gemini 3.8, Grok 4.6, DeepSeek V4 — dont les prix et benchmarks sont documentés dans les comparatifs de septembre 2026.

Poste	Ce qu’il mesure	Levier principal	Impact typique
Tokens d’entrée (système + schémas)	Définitions d’outils, instructions	Réduction des schémas, outils à la demande	Fort
Tokens d’entrée (historique)	Croissance de la conversation	Compaction, fenêtre glissante	Très fort
Tokens d’entrée (résultats d’outils)	Réinjection des sorties d’API	Troncature, résumé des résultats	Fort
Tokens de sortie	Raisonnement, JSON, réponses	Routage vers modèle plus petit	Moyen
Cache lecture	Réutilisation du préfixe	Stabilité du prompt, ordre des messages	Très fort
Cache écriture	Mise en cache initiale	Regroupement des requêtes	Faible (coût d’entrée)
Retries	Échecs et timeouts	Robustesse, validation des schémas	Variable (jusqu’à ×2)
Embeddings	Indexation et recherche	Batch, dimension réduite	Faible à moyen

La leçon du tableau est simple : les deux premiers postes d’entrée représentent l’essentiel de la facture, et ce sont les deux plus faciles à attaquer. Le cache de lecture, lui, n’est pas un poste de coût mais un multiplicateur d’économie — à condition de comprendre son mécanisme.

---

Le prompt caching : le levier le plus puissant, et le plus piégeux

Le prompt caching (ou cache de préfixe) repose sur une idée simple : si le début de votre prompt est identique d’une requête à l’autre, le fournisseur peut réutiliser le calcul déjà effectué et facturer cette portion à un tarif de lecture réduit plutôt qu’au tarif d’entrée plein. Sur un agent, le préfixe stable est constitué du prompt système et des définitions d’outils — exactement le poste fixe qui nous coûtait cher plus haut.

Les conditions de déclenchement sont strictes et c’est là que tout se joue : le préfixe doit être strictement identique, dans le même ordre, avec le même schéma. Changez un mot dans une description d’outil, réordonnez deux messages, ajoutez un champ à un JSON Schema, et le cache est invalidé. Vous payez alors une écriture en cache — plus chère qu’une entrée normale — pour un bénéfice nul.

C’est le piège numéro un : le cache qui masque une régression. Une équipe modifie son prompt système pour corriger un bug, ne remarque pas que le cache est invalidé, et voit sa facture grimper sans comprendre. Pire : une équipe qui bénéficiait d’un taux de hit élevé peut voir ce taux s’effondrer après un déploiement, sans qu’aucune alerte ne se déclenche, parce que le cache « fonctionne » — il écrit simplement au lieu de lire.

Le second piège est le cache sémantique. Contrairement au cache exact de préfixe, un cache sémantique (côté application, via des embeddings) réutilise une réponse pour une requête similaire. Il peut faire des merveilles sur des questions récurrentes, mais il introduit un risque de dégradation silencieuse : deux requêtes « proches » peuvent appeler des outils différents. Sur un agent, un cache sémantique mal calibré renvoie la réponse d’hier à une question qui a légèrement changé — et l’utilisateur ne le voit pas.

Le taux de hit réaliste en production dépend entièrement de la stabilité de votre prompt. Un agent dont le prompt système et les schémas d’outils sont figés peut atteindre des taux élevés ; un agent qui injecte la date du jour, l’identifiant utilisateur ou un contexte dynamique en tête de prompt casse le cache à chaque requête. Règle d’or : tout ce qui est stable va en tête, tout ce qui est variable va en queue.

---

Les cinq leviers, dans l’ordre où il faut les appliquer

La tentation est de tout optimiser en même temps. C’est une erreur : sans mesure, on ne sait pas ce qui marche. Voici l’ordre recommandé, du plus fondamental au plus fin.

1. Observabilité d’abord : mesurer avant de couper

Impossible de réduire ce qu’on ne mesure pas. La première étape est d’instrumenter chaque trace pour attribuer le coût par étape, par outil et par utilisateur. Les métriques qui comptent ne sont pas les tokens bruts mais le coût par tâche réussie, le coût par session, le taux de retries et les tokens gaspillés par appels d’outils inutiles. Un agent qui coûte 0,50 $ par tâche réussie est meilleur qu’un agent à 0,10 $ qui échoue une fois sur trois — le second coûte en réalité plus cher par résultat.

Les plateformes d’observabilité LLM (LangSmith, Langfuse, Helicone, et l’approche OpenTelemetry GenAI) permettent ce suivi par étape. Le point crucial : journaliser, pour chaque appel d’outil, non seulement le succès mais le coût en tokens et la pertinence de l’appel. Un appel d’outil qui retourne un résultat inutilisé par le modèle est un token gaspillé — et c’est fréquent sur les agents qui exposent trop d’outils.

2. Réduire les schémas d’outils : le gain le plus rapide

C’est le levier le plus sous-estimé. Chaque outil exposé coûte des tokens à chaque tour, qu’il soit appelé ou non. Trois actions concrètes :

• N’exposez que les outils pertinents pour l’étape en cours. Un agent qui expose 15 serveurs MCP alors qu’il n’en utilise qu’une demi-douzaine par tâche paie 15 définitions pour en utiliser 6. La sélection dynamique d’outils (n’exposer que le sous-ensemble utile) réduit mécaniquement le prompt système.
• Compressez les descriptions. Une description d’outil de 200 tokens peut souvent tenir en 50 sans perte de qualité d’appel.
• Préférez les appels déterministes hors LLM. Tout ce qui peut être fait par du code (formater une date, valider un champ, appeler une API fixe) ne doit pas passer par le modèle. Chaque appel d’outil déterministe économise un aller-retour de tokens.

3. Compaction et fenêtre glissante : attaquer la croissance quadratique

L’historique est le poste qui explose. Deux stratégies :

• La fenêtre glissante : ne garder que les N derniers tours. Simple, brutal, efficace — mais risqué sur les tâches longues où le contexte initial compte.
• La compaction : résumer périodiquement l’historique en un résumé compact, en conservant les décisions et les faits clés. Plus fin, mais c’est là que se cache la dégradation silencieuse : un résumé qui perd un détail critique transforme un agent fiable en agent qui rate ses tâches, sans erreur visible.

La compaction doit donc être évaluée, pas seulement déployée. La méthode : constituer un jeu de tâches de référence, mesurer le taux de réussite avant et après compaction, et surveiller le coût par tâche réussie — pas seulement le coût par token. Une compaction qui divise la facture par deux mais fait chuter le taux de réussite de 20 % est une fausse économie.

4. Routage dynamique de modèle : le bon modèle au bon endroit

Tous les tours d’un agent ne méritent pas le modèle le plus puissant. Un routage qui envoie les étapes simples (extraction de champ, classification, formatage) vers un petit modèle et réserve le modèle fort au raisonnement complexe peut réduire significativement la facture. Le comparatif des modèles de septembre 2026 (GPT-6 Astra, Claude Opus 5, Gemini 3.8, Grok 4.6, DeepSeek V4) montre une dispersion de prix et de capacités qui rend ce routage pertinent : tous ne se valent pas, et le plus cher n’est pas toujours nécessaire.

Le piège, encore une fois, est la dégradation silencieuse. Un petit modèle qui « répond » là où le grand modèle « raisonnait » produit des sorties plausibles mais fausses. D’où la nécessité d’une évaluation A/B par étape : on ne route vers un modèle plus petit qu’après avoir vérifié que la qualité de l’étape concernée ne bouge pas.

5. Budgets par étape et alertes : le garde-fou

Enfin, la ceinture de sécurité. Fixer un budget de tokens par étape (recherche, raisonnement, rédaction, validation) et alerter dès qu’il est dépassé permet de détecter les dérives avant qu’elles ne deviennent des factures. Un agent qui consomme soudain trois fois plus de tokens sur l’étape « recherche » a probablement un problème de schéma d’outil ou de boucle. L’alerte ne casse pas la fiabilité ; elle la protège.

---

Les pièges : quand l’économie devient une illusion

L’optimisation de coût a ses zones d’ombre, et elles sont bien documentées en 2026.

La dégradation silencieuse. C’est le risque numéro un. Compaction trop agressive, routage vers un modèle trop faible, réduction de schémas qui prive le modèle d’une information utile : dans tous les cas, l’agent continue de répondre, mais rate plus souvent. Le taux d’échec de 88 % des agents en production et les 30 % de tâches ratées après trois semaines chez un agent de support non surveillé en sont la preuve : sans garde-fou, la dérive est la norme.

Le cache qui masque les régressions. Un prompt modifié invalide le cache ; la facture monte ; l’équipe ne le voit pas. Ou à l’inverse, un cache sémantique trop permissif renvoie une réponse périmée. Dans les deux cas, le cache « fonctionne » — c’est bien le problème.

Les économies compensées par les retries. Un agent optimisé à l’extrême devient fragile : plus d’échecs, plus de retries, et la facture revient au niveau d’avant, avec une fiabilité en moins. Le taux de retries est donc une métrique de coût à part entière.

Le coût caché de la latence et des évaluations. Un agent qui appelle trois petits modèles en série au lieu d’un gros modèle peut coûter moins cher en tokens mais plus cher en latence perçue — et les évaluations A/B nécessaires pour valider chaque optimisation ont elles-mêmes un coût. L’optimisation doit être rentable nette de son coût de mesure.

La parade est méthodologique : toute optimisation passe par une évaluation A/B sur un jeu de tâches de référence, avec le coût par tâche réussie comme métrique pivot. Pas le coût par token, pas le coût par requête : le coût par résultat.

---

La méthode reproductible : mesurer, attribuer, réduire, vérifier

En synthèse, voici la séquence qui permet de viser le facteur 5 sans sacrifier la fiabilité.

Étape 1 — Instrumenter. Attribuer le coût par trace, par étape, par outil, par utilisateur. Journaliser les tokens d’entrée (système, schémas, historique, résultats), les tokens de sortie, les retries, les embeddings et le cache lecture/écriture.

Étape 2 — Établir la référence. Mesurer le coût par tâche réussie sur un jeu de tâches représentatif. C’est le chiffre de départ, celui contre lequel toute optimisation sera jugée.

Étape 3 — Attaquer les postes fixes. Réduire les schémas d’outils, n’exposer que les outils utiles, compresser les descriptions, déporter le déterministe hors LLM. Gain rapide, risque faible.

Étape 4 — Stabiliser le prompt pour le cache. Placer tout ce qui est stable en tête (système, schémas), tout ce qui est variable en queue. Surveiller le taux de hit et alerter sur toute chute brutale.

Étape 5 — Compacter l’historique. Fenêtre glissante ou résumé, avec évaluation systématique avant/après sur le taux de réussite.

Étape 6 — Router les modèles. Réserver le modèle fort au raisonnement, envoyer les étapes simples vers des modèles plus légers, valider par étape.

Étape 7 — Poser des budgets et des alertes. Par étape, par session, par utilisateur. Détecter les dérives avant la facture.

Étape 8 — Vérifier en continu. Le coût par tâche réussie, le taux de retries et le taux de hit du cache sont des métriques vivantes. Un agent optimisé une fois n’est pas un agent optimisé pour toujours : les prompts évoluent, les outils changent, les modèles sont mis à jour.

---

Perspectives : vers des agents natifs et des prix qui baissent

Deux tendances de fond vont rebattre les cartes. D’abord, l’évolution des prix : la baisse continue des tarifs par token réduit mécaniquement la facture, mais elle ne dispense pas de la discipline — un agent qui consomme cinq fois trop de tokens restera cinq fois trop cher, quel que soit le prix unitaire. Ensuite, l’arrivée d’agents natifs des fournisseurs et de modèles spécialisés : les plateformes intègrent de plus en plus la gestion du contexte, le cache et le routage dans leurs propres infrastructures, ce qui pourrait absorber une partie du travail d’optimisation — au risque d’une moindre visibilité sur les coûts réels.

La leçon de 2026 est claire : le coût d’un agent n’est pas un problème de tarif, c’est un problème d’architecture et de mesure. Les équipes qui gagnent sont celles qui traitent la facture comme une métrique produit, au même titre que la latence ou le taux de réussite. Les autres paient 200 dollars par mois pour un agent qui rate une tâche sur trois.

---

Sources

• Classement des meilleurs LLM en octobre 2026 : le top 15 — Digitiz
• Classement : les 20 meilleurs modèles d’IA (LLM) en octobre 2026 — Le Petit Digital
• LLM Leaderboard: AI Model Rankings & Pricing — llmboard.ai
• Modèles IA 2026 : GPT-6, Claude Opus 5, Gemini, Grok — Studeria
• What Is MCP? The Model Context Protocol Explained (2026) — The AI Rankings
• OpenAI Agents API 2026 : comment un agent IA appelle-t-il des outils ? — jsonsort.com
• Traçage des appels d’outils d’agent IA : que journaliser à chaque requête — apidog.com
• Meilleurs frameworks d’agents open source pour LLM locaux en 2026 — lefilia.fr
• LLM pipelines et MCP : la surface d’attaque que personne ne surveille — ayinedjimi-consultants.fr
• Grand modèle de langage — Wikipédia
• AI agent — Wikipedia