94% de tokens en moins : ce que les providers d'IA ne veulent pas que vous sachiez

Vivek Haldar, ex-VP AI Agents chez Emergence AI, a publié début juillet une méthode pour réduire de 94% la consommation de tokens d'un agent récurrent, sans dégrader la qualité. La technique est simple, presque évidente. Ce qui l'est moins, c'est pourquoi personne dans l'industrie n'en parle.

Cinq cents tokens pour faire quoi, exactement ?

Prenez un agent IA classique. Pas le genre qui résout des équations différentielles ou rédige un roman. Non : le genre banal, opérationnel, celui que les entreprises déploient par dizaines pour automatiser des tâches répétitives. Un agent qui scanne des sources, trie des candidats, rédige un brouillon. Chaque jour. La même chose.

Haldar a le sien : un agent LinkedIn qui passe en revue ses 500 articles archivés, choisit le plus pertinent du moment, et rédige un post. Tous les jours.

Avant optimisation, cet agent consommait environ 550 tokens à chaque exécution. 550 tokens, ça paraît rien. Multipliez par 365 jours : 200 000 tokens par an. Pour un workflow dont 80% des étapes sont identiques d'un jour à l'autre.

L'agent allait chercher les mêmes sources. Construisait le même inventaire. Appliquait les mêmes filtres. Tous les matins. Comme si c'était la première fois.

C'est là le problème. Et personne ne le formulait aussi clairement.

Ce que fait réellement votre agent

Il y a une confusion fondamentale dans la façon dont on construit les agents aujourd'hui. On leur confie des tâches récurrentes, puis on les laisse raisonner à chaque exécution sur des étapes qui ne requièrent aucun raisonnement.

Chercher des sources sur un ensemble fixe de flux RSS : c'est du code. Vingt lignes de Python, une boucle, un appel HTTP.

Vérifier si un article a déjà été publié récemment : c'est une requête API. Dix lignes.

Décider quel article a le plus de valeur narrative aujourd'hui, par rapport à l'actualité, au ton du moment, à la cohérence éditoriale : là, oui, il faut un LLM.

Rédiger le post : pareil, LLM.

Le reste ? Du code ordinaire. Gratuit. Rapide. Et pourtant, dans un agent généraliste, tout passe par le modèle. Tout est "raisonné". Tout coûte des tokens.

Haldar appelle ça du "LLM freeloading". Assez juste.

La compilation : coder ce qui ne pense pas

Sa méthode s'appelle "agent skill compilation". En pratique, c'est simple.

Phase 1 : vous laissez tourner votre agent en mode naturel, non-optimisé. Il fait ce qu'il fait. Vous enregistrez tout : les étapes, les décisions, les appels d'outils, les chemins empruntés. Ce sont les traces.

Phase 2 : vous prenez ces traces et vous demandez à un modèle puissant de les analyser. La question posée est précise : "quelles étapes sont déterministes — c'est-à-dire toujours pareilles — et quelles étapes nécessitent vraiment du jugement sémantique ?"

Phase 3 : les étapes déterministes deviennent du code Python. Pas un wrapper LLM. Du code. Gratuit à l'exécution. Les étapes sémantiques gardent leurs appels LLM, mais avec un contexte drastiquement réduit.

Le résultat : un "harness spécialisé". Un bootloader Python d'une centaine de lignes qui exécute tout le déterministe, puis fait deux appels LLM ciblés : un pour sélectionner le candidat, un pour rédiger le brouillon.

Coût après compilation : environ 35 tokens par exécution. Contre 550 avant.

94% de réduction. La latence chute de 87% par la même occasion — moins d'allers-retours réseau, moins de temps d'inférence.

Haldar utilise les brouillons générés. La qualité n'a pas bougé.

OpenAI a un problème avec cette technique

Voici la phrase qui fait mal. Elle est de Haldar lui-même :

"Their business is selling tokens. Preferably lots of tokens from their most powerful and expensive models."

Il parle des providers : OpenAI, Anthropic, Google. Pas des startup. Pas des challengers. Des acteurs dont le modèle économique repose, dans sa version la plus simple, sur le volume de tokens consommés.

Ce n'est pas un scoop. Mais formulé aussi directement, dans un article technique signé d'un ex-VP d'une boîte d'agents IA, c'est un peu gênant.

Les providers publient des guides d'optimisation. Ils donnent des conseils sur le caching, le batching, le prompt engineering. Ce qu'ils ne font pas, c'est vous expliquer que 80% de votre workflow ne devrait pas passer par eux du tout.

Il y a là un conflit d'intérêts parfaitement rationnel. Pas de complot, pas de malveillance. Juste des incitations qui pointent dans la mauvaise direction pour vous.

La documentation officielle d'Anthropic pour les agents ? Elle parle de "constitutional AI", de "tool use patterns", de "multi-agent orchestration". Elle ne dit pas : "Une fois que votre workflow est stable, transformez-le en code Python et arrêtez de nous payer pour les étapes déterministes."

Ce serait un peu se tirer une balle dans le pied.

Le vrai coût caché

La méthode de Haldar est honnête sur ses limites. Il le dit lui-même : la compilation a un coût initial.

Analyser les traces, générer le harness, vérifier que la qualité est conservée : ça demande un modèle capable, du contexte, et une intervention humaine pour valider. Il estime que ce coût initial s'amortit en 10 à 20 exécutions. Pour un workflow quotidien, c'est deux à trois semaines.

Ensuite, la maintenance. Si le workflow évolue, si les sources changent, si les critères de sélection se modifient : il faut recompiler. Ce n'est pas automatique.

Autre limite : la méthode ne s'applique qu'aux workflows récurrents et stables. Un agent qui gère des bugs imprévisibles, qui explore des données non-structurées, qui doit s'adapter à chaque instance : la compilation n'est pas pertinente. Le raisonnement généraliste du LLM a sa place.

Mais pour les automatisations industrielles, les agents opérationnels déployés à échelle dans les entreprises, c'est une autre histoire.

Le marché qui va naître de tout ça

Haldar ne se contente pas d'exposer le problème. Il identifie une opportunité.

"There's a large open space for founders building specialized harnesses, compilers, and tools that examine recurring agent workflows and move the deterministic parts into code."

Traduction : quelqu'un va construire un outil qui analyse automatiquement vos agents, identifie les parties compilables, génère le harness, et vous économise 90% de vos coûts d'inférence. Ce quelqu'un n'existe pas encore, ou pas à grande échelle.

Les candidates naturelles à combler ce vide : les boîtes de "Agent Ops" comme LangSmith, les orchestrateurs comme LangChain ou Dust, les consultants IA qui cherchent de nouveaux angles de différenciation. En France, des acteurs comme Gorgias, Mistral, ou les cabinets comme Wavestone pourraient lancer des prestations d'"audit de compilation d'agents" dans les 12 prochains mois.

Pour les grandes entreprises françaises qui déploient des agents récurrents (planification logistique, qualification de leads, automatisation RH), le calcul est vite fait. À 1000 exécutions par jour sur des workflows stables, les économies se comptent en dizaines de milliers d'euros annuels.

Ce n'est pas une révolution. C'est de l'ingénierie sérieuse appliquée à un problème réel. Ce qui est, d'ailleurs, plus rare qu'on ne le croit dans l'IA actuelle.

Pourquoi personne ne faisait ça avant ?

Bonne question. La réponse honnête : parce qu'on est encore dans la phase "tout au LLM, on verra après".

L'industrie a passé deux ans à vendre la promesse que les agents IA allaient tout gérer, tout comprendre, tout orchestrer. Les frameworks ont suivi cette logique : LangChain, CrewAI, AutoGen. Tout passe par des LLM. C'est plus simple à construire, plus spectaculaire à démo, et plus facile à vendre à des décideurs qui ne veulent pas entendre parler de Python.

Le problème, c'est que cette approche ne scale pas économiquement. Déployer un agent à 10 exécutions par jour dans une startup, ça coûte rien. Déployer 50 agents à 500 exécutions par jour dans une grande entreprise, ça devient une ligne budgétaire non négligeable.

La compilation d'agents est, dans le fond, une application du principe qu'on connaît depuis les débuts de l'informatique : les abstractions génériques coûtent cher, les implémentations spécialisées sont efficaces. Un compilateur C++ ne fait pas tourner un interpréteur Python pour chaque instruction. Il génère du code machine.

Appliquer ce principe aux agents LLM n'est pas sorcier. Il fallait juste quelqu'un pour le dire clairement.