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 : la facture ne dépend pas du nombre de vos questions, mais de la quantité de contexte retransmise à chaque appel. Une conversation avec un agent n’est pas un fil qui se poursuit — c’est un paquet reconstruit et renvoyé en entier à chaque message : instructions de démarrage, tout l’historique, la nouvelle question. Rien n’est conservé d’un appel à l’autre côté serveur ; tout est retransmis, retraité, refacturé. Le coût par message grandit avec la longueur de la conversation, et pas de façon linéaire : une session de cinquante échanges coûte, message pour message, bien plus cher qu’une session qui démarre.

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. 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

Deux commandes existent pour reprendre la main sur une conversation qui s’alourdit, et elles ne font pas la même chose. La première 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. La seconde 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.

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

Chaque outil externe connecté à un agent (au sens MCP — le protocole qui permet à un agent de piloter un outil tiers) injecte la description de ses fonctions dans les instructions de démarrage. Cela se produit avant le premier message, à chaque session. Une configuration chargée en outils externes peut consommer 30 à 40 % de la fenêtre de contexte rien qu’en descriptions d’outils — avant que le moindre travail ne commence. Et chaque message suivant retransmet cette charge en entier.

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, injecté automatiquement dans les instructions de démarrage de chaque session : une sorte de contrat de comportement que le modèle ne peut pas ignorer. Il coûte lui-même des tokens à charger, mais évite suffisamment de comportements coûteux pour être rentable.

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

Une bonne partie des recherches de code qu’un agent traite par une exploration coûteuse se résout en un seul appel avec un outil local rapide. Une recherche plein texte respectueuse du dépôt, une découverte de fichiers par motif de nom, une manipulation de JSON sans faire lire le fichier brut par le modèle, une recherche structurelle dans le code plutôt que du texte brut : ces outils existent, sont rapides, et coûtent zéro token tant que le modèle ne les utilise pas.

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

Le contexte grandit à chaque échange et se retransmet en entier à chaque fois : une session longue coûte cher non pas à cause du dernier message, mais parce que chaque message porte le poids de tous les précédents. Une tâche déléguée hérite du contexte de la conversation qui la lance : mieux vaut la lancer depuis un contexte léger, et n’en récupérer que le résultat. Les outils externes connectés chargent les instructions de démarrage avant que le travail ne commence : n’en connecter que ce qui sert. Tout contenu volumineux lu en cours de route reste dans le contexte pour le reste de la session : un fichier de journal, une capture d’écran, un document entier. Un modèle a besoin d’une contrainte écrite pour se comporter de façon économe — installer les bons outils ne suffit pas, il faut l’expliciter. Et une session courte coûte toujours moins cher qu’une session longue : repartir de zéro ne coûte rien.