Comment deux agents LangChain ont discuté pour 47 000 $

Onze jours pendant lesquels deux robots se sont mis d'accord pour ne pas être d'accord

Imaginez le dashboard que personne ne regardait. Deux agents, au cœur d'un pipeline de recherche de marché, en train d'avoir la conversation la plus polie de l'histoire du logiciel. L'un dit : voici mon analyse. L'autre répond : ça semble bien, mais vérifie cette partie s'il te plaît. Le premier vérifie, développe, et demande confirmation. Le second redemande des modifications. On recommence. Pendant onze jours. C'est, presque mot pour mot, ce que l'ingénieur Teja Kusireddy a décrit dans un post sur Medium et ce que TechStartups a relaté en novembre 2025. Un outil de recherche multi-agents, bâti sur une stack open-source parfaitement ordinaire, a glissé dans une boucle récursive et a tourné pendant presque deux semaines avant que quiconque s'en aperçoive. Quand ils ont enfin vérifié, la facture était de 47 000 $. Je trouve ce cas plus instructif que les histoires spectaculaires d'explosion en une nuit, précisément parce que rien de spectaculaire ne s'est produit. Pas de bug, pas de crash, pas de prompt incontrôlé. Deux agents ont fait exactement ce qu'on leur avait demandé. C'est ce qui justifie d'y consacrer onze minutes de votre temps.

Quatre agents, un panneau stop manquant

Le montage était sensé sur le papier. Quatre agents de type LangChain, chacun avec une tâche bien délimitée : Recherche, Analyse, Vérification, Synthèse. Ils se coordonnaient via une messagerie agent-to-agent (A2A) — le pattern qui enthousiasme tout le monde, où les agents délèguent, se contrôlent mutuellement et négocient entre eux au lieu d'attendre un humain. C'est réellement puissant. C'est aussi une toute nouvelle catégorie de mode de défaillance, et cette équipe l'a trouvée. Les agents Analyse et Vérification sont tombés dans une boucle de rétroaction qui était, selon les mots de l'auteur, techniquement correcte mais logiquement infinie. Vérification demandait sans cesse à Analyse une passe de plus. Analyse, en petite machine consciencieuse, s'exécutait toujours. Voici la partie qui devrait rendre légèrement mal à l'aise tout ingénieur ayant déjà mis un agent en production. D'après le post-mortem, le système n'avait aucune limite d'étapes, aucune condition d'arrêt, aucun plafond de coût, aucune mémoire partagée, aucun monitoring temps réel, aucune alerte et aucun orchestrateur. La boucle ne s'est jamais brisée parce que rien n'avait été construit pour la briser. Les agents ne dysfonctionnaient pas. C'est la gouvernance qui manquait — une chose bien plus difficile à repérer dans une revue de code qu'un null-pointer.

Pourquoi une boucle « inoffensive » devient une facture à cinq chiffres

Alors pourquoi deux agents qui discutent coûtent-ils le prix d'une voiture d'occasion ? Le mécanisme est la raison silencieuse et structurelle pour laquelle les factures d'agentic coding explosent, et il n'a rien à voir avec le fait que la boucle soit fausse. Chaque tour d'un échange A2A est un nouvel appel d'API, stateless. Quand Vérification renvoie sa critique à Analyse, cette critique n'arrive pas seule — elle arrive accompagnée du contexte accumulé : la recherche initiale, l'analyse précédente, le tour de feedback précédent, les instructions. Le modèle n'a aucune mémoire entre les appels, donc la totalité du context window est ré-envoyée à chaque fois. Chaque poli « vérifie ça s'il te plaît » réexpédie tout ce qui l'a précédé. Maintenant, faites tourner ça des milliers de fois. Une boucle qui déclenche quelques appels par minute sur 264 heures exécute un nombre colossal de requêtes, et chacune est un peu plus grasse que la précédente parce que l'historique de la conversation ne cesse de grossir. C'est exactement la même dynamique que je signale sans relâche dans les sessions de vibe coding en mono-agent, sauf qu'ici deux agents se nourrissent mutuellement au lieu d'un développeur qui martèle la touche entrée. Ce sont les input tokens, pas les output, qui dévorent le budget — les données sur le coût en tokens des agents de coding IA situent l'input à 80–90 % de la facture, et une boucle auto-référentielle est, par essence, une imprimante à input tokens. L'arithmétique cruelle : le coût unitaire qui paraissait négligeable en test — quelques centimes par appel — est catastrophique à l'échelle de la boucle. Personne ne teste pendant 264 heures d'affilée. On teste cinq minutes, on voit un chiffre raisonnable, et on met en production.

La courbe de coûts que personne ne surveillait

Ce que je trouve réellement glaçant, c'est la forme de l'escalade. Ce n'était pas une falaise. C'était une rampe, et le détail semaine par semaine rapporté par l'équipe se lit comme une courbe de capitalisation de manuel :

Semaine	Coût d'API rapporté
Semaine 1	$127
Semaine 2	$891
Semaine 3	$6,240
Semaine 4	$18,400

La première semaine, c'était 127 $. Si vous aviez vu cette ligne sur un dashboard, vous auriez haussé les épaules. La deuxième semaine, c'était 891 $ — agaçant, pas alarmant. À la troisième semaine, c'était 6 240 $, et la dernière ligne droite a atteint 18 400 $. Les dégâts totaux se sont élevés à 47 000 $ avant qu'ils ne débranchent. L'équipe avait des angles morts de visibilité, pas un refus de voir — il n'y avait aucune alerte d'anomalie de coût, aucune timeline inter-agents, aucun monitoring de l'usage des tokens. Du coup, la seule chose qui ait jamais dit « quelque chose ne va pas », c'était la facture. Comme l'a formulé Kusireddy, il y a « une leçon à 47 000 $ dont personne ne parle : la couche d'infrastructure n'existe pas encore, et elle coûte une fortune à tout le monde. » Pour donner une idée de l'échelle en tokens : au tarif Claude Sonnet de 3 $/MTok en input et 15 $/MTok en output, 47 000 $ correspondent à quelque chose de l'ordre de 13 à 15 milliards d'input tokens — pour une tâche qui aurait dû produire un seul rapport de recherche de marché. C'est l'intégralité de la littérature anglaise, relue des milliers de fois, pour que deux agents puissent continuer à se mettre d'accord pour la regarder une nouvelle fois.

Ce qu'une couche d'efficacité en tokens aurait changé (ESTIMATION)

Soyons précis sur ce que l'optimisation corrige ici, parce que ce n'est pas tout — et je préfère être honnête que survendre. Une couche d'efficacité en tokens n'invente pas de condition d'arrêt. Si deux agents sont déterminés à boucler indéfiniment, il vous faut toujours un plafond d'itérations strict ou un plafond de budget pour mettre fin à la conversation. C'est un correctif de gouvernance, et le post-mortem a raison de dire que c'était la défaillance principale. Ce qu'une couche de tokens change, c'est la pente de la courbe — et c'est là qu'est l'argent. Le coût de la boucle a augmenté parce que chaque tour réexpédiait le contexte intégral et accumulé. Le prompt caching sur le préfixe stable, la compression du contexte sur l'historique de conversation, et le filtrage des sorties d'outils verbeuses au lieu de les replier en bloc dans le prompt suivant — voilà les leviers couverts dans le guide de réduction des tokens, et ils s'attaquent exactement aux input tokens qui ont enflé ici. Une estimation conservatrice : appliquez une réduction de 40–50 % des input tokens à la même boucle, et la facture baisse proportionnellement, parce que l'input en constituait l'écrasante majorité.

Scénario	Total rapporté / estimé
Référence (telle que rapportée)	$47,000
Réduction de 40 % de l'input	≈ $28,000
Réduction de 50 % de l'input	≈ $24,000

Cette fourchette de 40–50 % est celle que citent les benchmarks indépendants pour le caching plus la compression de contexte sur les sessions longues et répétitives — et une boucle A2A auto-référentielle est la session la plus répétitive qu'on puisse imaginer. Économie estimée sur cet incident : environ 19 000 à 23 000 $, avec l'hypothèse énoncée clairement : même boucle, mêmes onze jours, simplement des tokens plus légers par tour. Mais voici le meilleur point, et c'est celui que je mettrais réellement sur la slide. Une boucle qui tourne à moitié prix atteint aussi un plafond de budget deux fois moins vite en dollars et deux fois plus lentement dans le temps — ce qui vous achète plus de jours pour vous en apercevoir avant que le chiffre ne devienne effrayant. L'efficacité et la gouvernance ne sont pas des correctifs concurrents. Ils se cumulent. Le tarif des tokens d'API LLM ne se plafonne pas tout seul ; il faut amener à la fois le frein et le moteur plus petit.

La leçon : une alerte n'est pas un frein

Ce que je veux que vous reteniez, ce n'est pas « les systèmes multi-agents sont dangereux ». Ils ne le sont pas. C'est qu'un dashboard qu'il faut aller regarder n'est pas un contrôle, et qu'un coût unitaire mesuré pendant cinq minutes n'est pas le coût que vous paierez pendant onze jours. Les 47 000 $ ont été le prix de la supposition « ça marche » parce que rien ne disait le contraire. Deux correctifs, et il vous faut les deux. Posez un plafond strict sur les itérations et la dépense pour que la boucle se termine. Et placez une couche d'efficacité en tokens devant l'API pour que chaque tour coûte moins cher — ce qui ralentit la courbe et élargit la fenêtre où un humain peut encore intervenir. Tokenade est la seconde moitié de cette équation. Elle s'intercale entre vos agents et l'API — caching du contexte stable, compression de l'historique de conversation, filtrage des sorties d'outils — pour qu'une boucle de longue durée ne réexpédie pas tout votre historique à chaque tour. Vous pouvez faire vos propres calculs sur le calculateur de coût en tokens : ce que coûte aujourd'hui une charge de travail d'agent multi-tours, et ce à quoi ressemble en argent une réduction de 40–50 % de l'input. Gratuit jusqu'à environ 10 millions de tokens économisés. Commencez gratuitement — sans carte bancaire.

Profiles are sourced from public statements, podcast interviews, Twitter/X posts, and Indie Hackers / Reddit threads cited inline. No private claims; if you spot a factual error, contact [email protected].