Ton IA te coûte trop cher parce qu'elle lit des logs

Le modèle le plus cher que tu paies passe le plus clair de son temps à faire du travail de fourmi : ouvrir vingt fichiers pour en retenir deux lignes, dérouler un journal d'erreurs, compter des occurrences. Ce travail-là n'a besoin d'aucun jugement. Il a besoin de patience.

Et il y a pire que le prix du travail lui-même — c'est ce qu'il laisse derrière.

C'est le point que presque personne ne voit. Quand ton modèle premium déroule un gros résultat de recherche dans la conversation, ce texte ne coûte pas une fois. Il reste dans le fil, et il est refacturé à chaque tour suivant. Une seule commande bavarde en début de session se paie encore trente échanges plus tard.

Déléguer ne sert donc pas seulement à payer un tarif plus bas sur la tâche. Ça sert à ce que le bruit n'entre jamais dans le contexte cher. L'agent secondaire absorbe les quatre cents lignes de sortie et ne remonte que la conclusion. C'est structurel, et c'est là qu'est le gros de l'économie.

Le critère tient en une phrase : si la tâche produit beaucoup de texte dont tu ne garderas qu'une conclusion, elle se délègue.

• Toute recherche qui ratisse. Un grep sur tout un dépôt, un historique de versions sur cent commits, la fin d'un gros journal. Tu veux la réponse, pas les quatre cents lignes qui y mènent.
• Se repérer dans du code qu'on ne connaît pas. Ouvrir cinq ou six fichiers pour comprendre comment un module est branché. La lecture est volumineuse, le résultat tient en un paragraphe.
• Les vérifications après coup. Est-ce que la page répond ? Est-ce que le rendu est correct ? Est-ce que le déploiement est passé ? Réponses courtes, chemin long.
• Explorer une API ou un outil pour trouver quelque chose, par opposition à faire un appel précis dont tu connais déjà la cible.
• Toute modification qui demande de beaucoup lire avant de peu écrire.

Le point commun : le rapport entre le volume traversé et le volume utile est très défavorable. C'est exactement ce qu'il ne faut pas laisser s'accumuler dans un contexte cher.

La symétrie est aussi importante que la règle. Déléguer ces tâches-là dégrade le résultat et coûte plus cher, parce qu'il faut ensuite tout reprendre.

• Les décisions d'architecture. Quoi construire, dans quel ordre, avec quel compromis. Ça ne se sous-traite pas à un modèle qui n'a pas le contexte du métier.
• Le diagnostic d'un échec. Quand quelque chose casse sans raison apparente, c'est précisément le moment où le raisonnement coûteux est rentable. Un agent léger va proposer la cause la plus probable ; or les vraies pannes sont rarement les plus probables.
• La synthèse finale et l'appréciation du risque, sur les éléments que l'agent secondaire a rapportés. Il collecte, tu tranches.
• Une modification d'une ligne dans un fichier déjà ouvert. Monter une délégation coûte plus que la tâche elle-même. Le bon sens reste la règle supérieure.
• Tout ce qui sort vers l'extérieur — publier, envoyer, facturer, supprimer. Pas pour une raison de coût : pour une raison de responsabilité.

C'est ici que la plupart des délégations échouent, et l'erreur est toujours la même.

Un agent lancé démarre à froid. Il n'a pas lu la conversation, il ne sait pas ce que tu viens d'écarter, il ne connaît pas le nom du fichier dont vous parlez depuis dix minutes. Écrire « à partir de ce qui précède, corrige le problème » garantit un résultat inutilisable — et tu paieras deux fois : la délégation ratée, puis le travail refait.

Un paquet correct contient quatre choses, et pas une de moins :

1. Où chercher. Les chemins exacts, pas « dans le projet ».
2. Ce qui est déjà écarté. Les pistes explorées et abandonnées, sinon l'agent les refera toutes.
3. À quoi ressemble « terminé ». Le critère de réussite, formulé de façon vérifiable.
4. Ce qu'il doit rapporter. La conclusion attendue — sinon il te renvoie les quatre cents lignes que tu voulais justement éviter, et toute l'économie est perdue.

Le quatrième point est le plus oublié, et c'est celui qui annule le bénéfice quand il manque.

Sur l'écart de tarif : il dépend entièrement des deux modèles que tu associes. Un modèle léger coûte couramment plusieurs fois moins qu'un modèle de raisonnement — l'ordre de grandeur annoncé est réaliste, mais vérifie-le sur la grille de ton fournisseur plutôt que de me croire. Le chiffre bouge à chaque nouvelle version.

L'économie structurelle, elle, ne dépend d'aucune grille tarifaire : c'est le contexte qui ne gonfle pas. Sur l'audit cité plus haut, la relecture pesait ~59 % du coût. C'est cette part-là qu'on attaque en empêchant le bruit d'entrer, et elle est indépendante du prix affiché des modèles.

Et une chose que cette méthode ne fait pas : elle ne rend pas un mauvais découpage rentable. Si tu délègues une tâche mal définie, tu paies un agent léger pour produire quelque chose d'inutilisable, puis le modèle cher pour tout reprendre. La règle ne remplace pas le fait de savoir ce que tu veux.