Pourquoi une conversation avec un agent IA coûte de plus en plus cher

J’ai épuisé mon quota deux fois de suite, la même semaine, pour deux raisons différentes. La première fois en moins de cinq minutes. J’ai reconstitué ce qui s’était passé, et ce que j’en ai tiré change concrètement la façon dont je fais travailler un agent IA depuis. J’en avais fait un article en anglais sur Medium au moment des faits ; en voici la version française, à jour de ce que j’applique aujourd’hui.

Deux façons de vider un quota

La première fois, j’avais lancé plusieurs tâches en parallèle sur un même dépôt de code, chacune dans son propre espace de travail isolé. Ce que je n’avais pas mesuré : chaque tâche démarre une session complètement indépendante, qui recharge depuis zéro tout ce qui est configuré globalement — les outils connectés, les instructions, le contexte de démarrage. Trois tâches en parallèle, ce n’est pas trois fois le travail : c’est trois sessions entières, chacune payant seule le prix d’entrée. Quota épuisé en moins de cinq minutes.

La seconde fois, dans une session unique, en plein débogage. À un moment, l’agent a décidé qu’il avait besoin de plus de contexte : il a lu un fichier de journal dans son intégralité, plusieurs dizaines de milliers de lignes. Ce contenu est resté en mémoire de conversation pour tout le reste de la session — chaque message suivant l’a retransmis en entier, retraité, refacturé. Puis j’ai délégué une tâche annexe à un sous-agent, qui a hérité de cette même conversation, journal compris.

Ce qu’un agent IA facture réellement

Un modèle de langage ne traite pas du texte : il traite des nombres. Avant tout calcul, le texte est découpé en unités — mots, fragments de mots, ponctuation — et chaque unité est convertie en nombre dans le vocabulaire du modèle. C’est cette unité, le token, qui sert de base de facturation, en entrée comme en sortie, à des tarifs distincts.

Le point qui coûte cher à comprendre sur le tas : compter les questions ne suffit pas. Il faut mesurer la quantité de contexte traitée à chaque appel, les tokens produits et le tarif applicable. Les instructions, l’historique retenu et les résultats d’outils peuvent peser bien davantage que la nouvelle question.

Le traitement dépend aussi du fournisseur et de l’agent. Le cache de prompts documenté par Anthropic distingue les écritures en cache, les lectures et les tokens non mis en cache. Tout le contexte n’est donc pas nécessairement refacturé au même prix. Une session qui accumule du contenu peut coûter davantage, mais sa longueur seule ne permet pas de calculer la facture.

Chaque modèle a une limite fixée par son fournisseur — 200 000 tokens pour le modèle que j’utilisais alors. Une fenêtre plus large n’est d’ailleurs pas automatiquement un avantage : un modèle a tendance à moins bien exploiter ce qui se trouve au milieu d’un contexte long. Liu et al. l’ont mesuré sur plusieurs modèles : la performance chute quand l’information utile est placée au milieu d’un long contexte. Lost in the Middle, 2023. Ce qui compte n’est pas seulement la taille de la fenêtre, c’est la fiabilité avec laquelle le modèle va y retrouver l’information utile.

Vider la conversation, ou la résumer

Dans Claude Code, l’outil que j’utilisais, deux commandes permettent de reprendre la main sur une conversation qui s’alourdit, et elles ne font pas la même chose. /clear efface tout : l’historique disparaît, on repart d’une base neuve — le bon réflexe en changeant de sujet, ou quand la session est devenue lourde. /compact demande au modèle de résumer la conversation en cours, puis remplace l’historique complet par ce résumé : la fenêtre se libère, l’intention de la session est conservée, au prix des tokens dépensés pour produire le résumé et d’une perte de précision sur les détails. Documentation de Claude Code sur la maîtrise des coûts.

Le réflexe qui change tout : vérifier l’état du contexte au début d’une session, pas quand le problème est déjà là. Ça ne coûte rien, et ça évite de découvrir en pleine tâche que la moitié de la fenêtre est déjà consommée.

Ce qui charge le contexte avant même de commencer

Les descriptions des outils externes connectés, notamment via MCP, peuvent occuper une part importante du contexte. Sur la configuration que j’utilisais alors, elles occupaient de l’ordre de 30 à 40 % de la fenêtre avant que le moindre travail ne commence. C’est un constat sur cette configuration, pas une propriété du protocole : le chargement des descriptions et leur éventuelle mise en cache dépendent du client.

La règle pratique : ne connecter que ce qui sert réellement à la session en cours, et vérifier ce qui est connecté avant de démarrer plutôt qu’en découvrant la facture après coup.

Écrire la règle, parce que le modèle ne la devine pas

Par défaut, un agent tend vers l’exhaustivité : il lit un fichier en entier là où un extrait ciblé aurait suffi, il lance une recherche large avant de formuler une hypothèse, il produit une sortie détaillée qui reste ensuite dans le contexte et se fait retransmettre à chaque appel suivant. Ce comportement ne change pas tout seul — il faut l’écrire.

C’est le rôle d’un fichier d’instructions placé à la racine du projet — CLAUDE.md dans Claude Code, AGENTS.md dans d’autres outils. Son chargement dépend du client et du périmètre de la session. Il expose les règles attendues, sans garantir que le modèle les suivra. Son coût de chargement doit être comparé aux lectures et aux reprises qu’il permet d’éviter.

Ce contrat tient en une question posée avant chaque action : est-ce que cette action justifie son coût ? Et une séquence stricte pour explorer du code, de la moins chère à la plus chère : déduire de ce qui est déjà connu, chercher par nom de fichier si le motif est connu, chercher par contenu avec un filtre précis, lire un extrait ciblé, et seulement en dernier recours une recherche large. Un refactoring mécanique se fait en édition directe, pas via une exploration formelle. Un bug déjà identifié se corrige directement, sans détour par une session de brainstorming. Et toute sortie verbeuse — celle d’un compilateur, d’une suite de tests — se filtre avant d’entrer dans le contexte plutôt que d’y être déversée en entier.

Un outillage local qui couvre l’essentiel des cas

Des outils locaux permettent de cibler la lecture : ripgrep cherche dans le texte, fd retrouve des fichiers par leur nom, jq filtre des données JSON et ast-grep recherche des structures de code. Leur exécution locale ne consomme pas de tokens de modèle ; les instructions d’appel et les résultats transmis au modèle en consomment. L’intérêt est de lui présenter l’extrait utile.

Les installer ne suffit pas : le modèle ne s’en sert pas de lui-même. Il faut l’écrire explicitement dans le contrat — quel outil, pour quel usage, avec quelle contrainte. Sans cette consigne, l’agent revient à son comportement d’exploration par défaut, plus coûteux.

Ce que j’ai retenu

Je surveille désormais le contexte réellement chargé, les lectures volumineuses et les tokens facturés, y compris ceux du cache. Pour une tâche déléguée, je vérifie quel historique elle reçoit et je limite le retour au résultat utile. Je précise les outils et les règles de lecture dans les instructions, puis j’observe si l’agent les suit.

Repartir d’une session courte peut aider à changer de sujet, avec un coût éventuel de relecture des documents et de reconstruction du contexte. Le bon critère reste le coût du résultat accepté, reprises comprises.