Source: https://aiprimetech.io/fr/blog/agent-cost-control/ Juin 25, 2026 · 6 min · Agents # Éviter que les boucles d’agents n’épuisent votre budget API A Par [AI Prime Tech](https://aiprimetech.io/fr/) · Avec l’aide de l’IA Je vais rédiger directement l’article, avec des tactiques d’ingénierie concrètes, un tableau comparatif et des exemples pratiques. Je m’appuierai sur le comportement réel des boucles et les mécanismes de maîtrise des coûts, et je veillerai à terminer par des enseignements applicables.## Le moyen le plus rapide de faire fondre un budget API J’ai un jour vu un agent de programmation « simple » transformer une demande utilisateur de 400 tokens en une ligne de facture de 28,000 tokens en moins de deux minutes. Le schéma était terriblement familier : l’agent appelait un outil de recherche, résumait les résultats, relisait son propre résumé, interrogeait à nouveau le même outil avec une formulation légèrement différente, puis élargissait le contexte jusqu’à ce que chaque tour embarque toute la conversation, la moitié du dépôt et une succession de plans ayant échoué. Le modèle n’avait aucun problème. C’était la conception de la boucle qui posait problème. C’est le problème fondamental des systèmes agentiques : le coût n’augmente pas en fonction des prompts utilisateur, mais en fonction du comportement des boucles. Une seule boucle mal conçue peut multiplier : - les tokens d’entrée à cause d’un contexte toujours plus volumineux, - les tokens de sortie à cause d’une « réflexion » prolixe, - les dépenses liées aux outils à cause d’appels répétés, - et la latence à cause de nouvelles tentatives en série. Si vous développez des agents en production, le véritable objectif n’est pas de « rendre le modèle plus intelligent ». C’est de « rendre la boucle moins coûteuse, plus courte et moins susceptible de s’emballer ». ## Pourquoi les boucles d’agents font exploser les coûts Un tour de conversation classique comporte une entrée et une sortie. Une boucle d’agent suit une séquence comme celle-ci : - l’utilisateur pose une question, - le modèle élabore un plan, - le modèle appelle un outil, - l’outil renvoie des données, - le modèle lit les données, - le modèle décide de l’étape suivante, - et le cycle recommence. Chaque itération ajoute de nouveaux tokens au prompt de l’itération suivante. Si vous continuez à y ajouter les sorties complètes des outils et les réflexions précédentes, le prompt grossit à peu près par paliers. En pratique, cela produit trois facteurs multiplicateurs de coûts : - Accumulation du contexte : chaque étape embarque les étapes précédentes. - Bavardage avec les outils : le même outil est appelé avec des arguments légèrement différents. - Nouvelles tentatives incontrôlées : le modèle continue d’« essayer encore une chose » alors qu’il en a déjà fait assez. Un piège fréquent : le gaspillage de tokens reste généralement invisible tant que vous n’examinez pas les traces de chaque exécution. La réponse finale peut être concise, mais la chaîne cachée peut être 10x plus volumineuse que la sortie visible par l’utilisateur. ### Un modèle de coût simple Si une boucle exécute N étapes, chacune comprenant : - C tokens de contexte conservé, - I tokens de sortie d’outil réinjectés, - O tokens de sortie du modèle, alors le total approximatif est : ``` total_tokens ≈ N * (C + I + O) ``` Cette estimation est optimiste, car C augmente généralement à mesure que la boucle se poursuit. Dans un agent réel, les derniers tours sont souvent les plus coûteux. ## Les leviers de contrôle qui comptent vraiment Vous pouvez agir à plusieurs endroits. L’astuce consiste à combiner ces leviers. | Levier de contrôle | Ce qu’il réduit | Cas d’usage idéal | Compromis | Plafonnement des étapes | Boucles incontrôlées | Tout agent doté d’outils | Peut provoquer un arrêt prématuré sur les tâches difficiles | Réduction du contexte | Tokens d’entrée | Tâches de longue durée | Risque de perdre un historique utile | Sous-agents moins coûteux | Dépenses liées aux tâches courantes | Recherche, extraction, classification | Coût supplémentaire de coordination | Mise en cache des résultats d’outils | Dépenses liées aux appels répétés d’outils | Sources stables, requêtes répétées | Obsolescence et invalidation | Observabilité des dépenses | Factures inattendues | Systèmes en production | Nécessite un travail d’instrumentation | Conditions d’arrêt des boucles | Boucles infinies ou quasi infinies | Agents peu fiables | Nécessite de définir ce qui est « suffisamment bon » Les configurations de production les plus efficaces les utilisent tous. ## 1) Plafonnez strictement le nombre d’étapes C’est la correction la plus simple et la plus sous-estimée : si vous ne fixez pas de maximum strict, vous faites confiance au modèle pour s’arrêter de lui-même. Je commence généralement par : - 3–5 étapes pour les tâches ciblées, - 6–8 étapes pour les tâches de complexité moyenne, - davantage uniquement si une raison solide le justifie. Un bon plafond n’est pas seulement une soupape de sécurité. Il impose une meilleure décomposition. Si l’agent ne dispose que de quatre actions, il tend à : - demander le bon outil plus tôt, - éviter les détours exploratoires, - et converger plus vite vers une réponse exploitable. ### Exemple de contrôleur de boucle ``` MAX_STEPS = 5 for step in range(MAX_STEPS): action = model.next_action(state) if action.type == "final": return action.final_answer observation = run_tool(action.tool_name, action.arguments) state = update_state(state, action, observation) raise RuntimeError("Agent stopped after step cap") ``` Un piège fréquent : le plafond d’étapes doit s’appliquer à l’ensemble du plan, et non à chaque sous-routine indépendamment. Sinon, vous déplacez l’explosion des coûts de l’agent principal vers les fonctions auxiliaires imbriquées. ## 2) Réduisez le contexte à chaque tour La plupart des agents conservent trop d’historique. Ils n’ont pas besoin de toutes les réponses précédentes des outils, surtout lorsqu’une réponse était volumineuse et qu’un seul détail comptait. En pratique, j’ai obtenu les meilleurs résultats avec une politique de mémoire à plusieurs niveaux : - Conserver tel quel : demande utilisateur, objectif actuel, décisions finales, contraintes non résolues. - Résumer : raisonnements précédents, pistes explorées, longues sorties d’outils. - Supprimer : hypothèses sans issue, résultats d’outils en double, anciens brouillons intermédiaires. ### Que conserver Un objet d’état compact fonctionne mieux que la réinjection de la transcription brute : ``` { "goal": "Find the failing endpoint and propose a fix", "constraints": [ "No schema changes", "Must preserve backward compatibility" ], "known_facts": [ "500s started after deploy 1842", "Only /v1/search is affected" ], "open_questions": [ "Is the new cache layer returning stale payloads?" ], "step": 3 } ``` Cela coûte bien moins cher que de fournir au modèle 20 tours de « réflexion à voix haute ». ### Méthode pratique de réduction du contexte Utilisez trois tampons : - working_set: tour actuel, résultats des outils, plan en cours. - summary_memory: historique compressé. - archive: tout ce dont vous pourriez avoir besoin pour les audits, mais pas pour le contexte du prompt. L’agent ne voit que working_set + summary_memory. Lorsque working_set devient trop volumineux, résumez-le dans summary_memory. Le piège ici est la dérive des résumés. Si votre outil de résumé perd des informations, il peut effacer des contraintes et pousser l’agent à répéter ses erreurs. Je préfère conserver les faits structurés séparément des résumés libres, afin que le modèle n’ait pas à les déduire du texte. ## 3) Utilisez des sous-agents moins chers pour les tâches simples Toutes les étapes ne nécessitent pas votre meilleur modèle. Si la tâche consiste à : - extraire des champs de JSON, - classer un ticket, - vérifier si un fichier a changé, - ou générer une courte requête de recherche, alors un modèle plus petit et moins cher suffit souvent. Réservez le modèle coûteux à la planification, à la synthèse et aux situations ambiguës. ### Répartition courante - Agent principal: raisonne sur la tâche et décide quand s’arrêter. - Sous-agent: effectue des tâches ciblées comme la recherche, l’extraction ou la normalisation. - Vérificateur: contrôle le format, l’exhaustivité et les erreurs manifestes des résultats. Une architecture pratique : ``` User -> Orchestrator (strong model) -> Search agent (cheap model) -> Extract agent (cheap model) -> Final synthesis (strong model) ``` ### Pourquoi cela fonctionne Le modèle principal reste concentré sur le flux de contrôle au lieu de tout faire lui-même. Le sous-agent peut être encadré par un prompt et soumis à une limite stricte de tokens. Exemple de prompt pour un sous-agent de recherche : ``` Return only: 1. the best search query, 2. 3 likely source categories, 3. no explanation. ``` Ce type de contrat ciblé permet de garder des résultats courts et prévisibles. Si votre plateforme vous donne accès à plusieurs modèles à un prix abordable, c’est ici que cet accès devient rentable : un modèle puissant pour l’orchestration, un modèle moins cher pour les sous-tâches répétitives, et aucune raison de gaspiller des tokens coûteux sur de l’analyse syntaxique courante. ## 4) Prenez la mise en cache des résultats des outils au sérieux Les boucles d’agents paient souvent plusieurs fois pour les mêmes informations : - lectures répétées de fichiers, - consultations répétées de bases de données, - recherches web répétées, - appels répétés de génération d’embeddings ou de récupération d’informations. La mise en cache des résultats des outils est l’un des changements les plus rentables que vous puissiez apporter. ### Utilisez une clé sémantique pour le cache, pas le texte brut Un cache fondé sur le prompt brut ne trouve plus de correspondance si la formulation change légèrement. Les meilleures clés reposent sur une intention normalisée : ``` def cache_key(tool_name, args): normalized = normalize_args(args) return f"{tool_name}:{hash(normalized)}" ``` Exemple d’entrée de cache : ``` { "tool": "repo_search", "query": "auth middleware rate limit bug", "result": { "files": ["src/middleware/auth.py", "src/api/routes.py"], "ts": 1710001123 } } ``` ### Quand la mise en cache est la plus utile - Agents d’inspection de dépôts, - recherche documentaire, - bases de connaissances stables, - transformations déterministes, - récupération répétée d’informations dans des workflows à plusieurs tours. ### Quand la mise en cache peut poser problème - données qui changent rapidement, - résultats propres à chaque utilisateur, - tout élément dont la fraîcheur est soumise à des exigences temporelles strictes. Le piège courant consiste à mettre en cache les résultats des outils sans indiquer leur fraîcheur à l’agent. Si le modèle pense avoir reçu des données en temps réel alors qu’elles proviennent du cache, il risque de prendre de mauvaises décisions. Incluez des horodatages ou des périodes de validité dans les métadonnées des outils. ## 5) Affichez les dépenses dans le tableau de bord Si vous ne suivez que la latence et le taux de réussite, vous passerez à côté du véritable mode d’échec : une réussite coûteuse. Pour chaque exécution, vous devez pouvoir observer : - les tokens d’entrée, - les tokens de sortie, - les appels d’outils, - la latence des outils, - la dépense totale, - le nombre d’étapes, - le motif d’arrêt. ### Schéma d’événement minimal ``` { "run_id": "r_8f2c", "step": 4, "model": "gpt-5.5", "input_tokens": 1842, "output_tokens": 221, "tool_name": "repo_search", "tool_latency_ms": 312, "estimated_cost_usd": 0.087, "stop_reason": "step_cap" } ``` ### Ce qu’il faut surveiller en pratique - Tokens par tâche réussie: l’indicateur de coût le plus clair. - Tokens par étape: permet de détecter les prompts trop volumineux. - Appels d’outils répétés: généralement un défaut de planification. - Répartition des motifs d’arrêt: si de nombreuses exécutions se terminent parce qu’une limite est atteinte, votre agent ne planifie pas suffisamment. L’un des graphiques les plus utiles présente le coût par type de tâche. Certaines catégories seront naturellement coûteuses. C’est normal. Ce que vous devez repérer, c’est la tâche qui devrait être peu coûteuse, mais ne l’est pas. ## 6) Arrêtez les boucles incontrôlées au plus tôt Une boucle doit pouvoir s’arrêter pour d’autres raisons que « J’ai atteint la limite d’étapes ». Voici des conditions d’arrêt utiles : - le modèle a produit une réponse finale, - le même appel d’outil se répète sans apporter de nouvelles informations, - la variation du niveau de confiance ou de l’utilité est inférieure au seuil, - la tâche est résolue selon un vérificateur, - le plan stagne. ### Exemple de mécanisme d’arrêt de boucle ``` seen_calls = set() for step in range(MAX_STEPS): action = model.next_action(state) signature = (action.tool_name, canonicalize(action.arguments)) if signature in seen_calls: return fail("repeated tool call with no new information") seen_calls.add(signature) observation = run_tool(action.tool_name, action.arguments) state = update_state(state, action, observation) if verifier_says_done(state): return finalize(state) ``` Cela permet de détecter un mode d’échec très courant : le modèle « veut se rendre utile » et se contente de reformuler la même requête. ### Autre garde-fou utile : conditionner la poursuite à l’utilité Si une étape ne modifie pas suffisamment l’état, ne poursuivez pas. Les critères peuvent être aussi simples que : - aucun nouveau fichier trouvé, - aucune nouvelle entité extraite, - aucune amélioration du niveau de confiance dans la réponse, - aucun nouvel élément probant ajouté. La mesure exacte dépend de la tâche, mais une notion de gain marginal est essentielle. ## Ce qui se passe réellement lorsque vous réglez bien ces mécanismes Une fois la boucle mieux encadrée, l’agent s’améliore généralement sur des points qui peuvent passer inaperçus au début : - Il devient moins bavard et plus décisif. - Il demande plus tôt le bon outil. - Il produit moins de cycles du type « Je poursuis mes recherches ». - Il devient moins coûteux et plus rapide, car moins de tours signifie moins de contexte et moins de latence. Le compromis important est que des limites strictes et une réduction agressive du contexte peuvent fragiliser le système face à des tâches réellement difficiles. Ne prétendez donc pas que l’agent « résout » des problèmes alors qu’il atteint simplement le délai limite. Indiquez-le honnêtement dans les journaux et dans les messages destinés aux utilisateurs. Ma règle générale : privilégier une compétence aux limites définies plutôt qu’une exploration sans fin. ## Une configuration pratique pour la production Si je devais mettre un agent en production demain, je commencerais par : - MAX_STEPS = 5 - un état structuré, plutôt que la relecture de tout l’historique - une mémoire résumée après chaque tour - des sous-agents peu coûteux pour la recherche et l’extraction - un cache des résultats d’outils avec des métadonnées de fraîcheur - la journalisation des tokens et du coût pour chaque exécution - un détecteur d’appels répétés - des motifs d’arrêt explicites Cette configuration n’a rien de spectaculaire, mais c’est elle qui empêche la facture de croître plus vite que le produit. ## Conseils pratiques - Commencez par limiter le nombre d’étapes ; c’est la protection la moins coûteuse contre les boucles incontrôlées. - Réduisez fortement le contexte et conservez l’état structuré séparément des résumés. - Utilisez des sous-agents moins coûteux pour les tâches ciblées, au lieu de dépenser partout des tokens au tarif premium. - Mettez en cache les résultats d’outils réutilisables, mais indiquez leur fraîcheur pour que le modèle ne se fie pas aveuglément à des données obsolètes. - Journalisez les dépenses par exécution, par étape et par appel d’outil afin que toute dérive des coûts soit immédiatement visible. - Arrêtez les boucles en cas de répétition, de stagnation ou d’achèvement vérifié, et pas seulement lorsque les ressources sont épuisées. - Concevez pour une compétence aux limites définies : une solution suffisamment bonne, rapide et prévisible vaut toujours mieux qu’une solution ingénieuse mais coûteuse. [Agents](/fr/blog/tag/agents/)[Ingénierie](/fr/blog/tag/engineering/)[API](/fr/blog/tag/api/) A [AI Prime Tech](https://aiprimetech.io/fr/) Ce blog est publié par AI Prime Tech. Les articles sont rédigés avec l’aide de l’IA ; vérifiez les détails propres à chaque version, tels que les identifiants de modèles, les prix et les limites, dans la documentation officielle avant de vous y fier. Accédez à l’API Claude à moindre coût Une seule clé API pour Claude Opus 5.5, Sonnet 5, Haiku 4.5 et Fable 5.1, ainsi que GPT-6 modèles. Paiement à l’usage, sans abonnement. [Obtenir votre clé API →](/register) AI Prime Tech est une passerelle API tierce indépendante. Claude™ et Anthropic® sont des marques d’Anthropic, PBC. Aucune affiliation ni approbation n’est sous-entendue.