Le coût d'exécution d'un agent IA : évaluez le coût de la boucle entière, pas des tokens

Le coût d'exécution d'un agent IA est rarement dominé par le modèle. Dans les agents que nous cadrons et construisons, les postes importants sont les appels d'outils qui entourent le modèle (recherche, scraping, enrichissement de données, vérification d'email), les retentatives qui refacturent ces outils, et l'hébergement et le traçage dont vous avez besoin avant de faire confiance au système pour fonctionner sans supervision. Si vous voulez un chiffre que vous pouvez défendre devant un conseil d'administration, chiffrez la boucle entière par tâche accomplie et traitez le prix par million de tokens comme une donnée parmi six.

Ce qu'achète réellement une seule tâche d'agent

Prenons un exemple simple : un agent qui qualifie un lead entrant. Une exécution peut récupérer le site du prospect via une API de scraping, lancer deux ou trois recherches web, extraire des données d'entreprise auprès d'un fournisseur d'enrichissement, vérifier une adresse email, et effectuer trois ou quatre appels au modèle pour planifier, extraire, rédiger et vérifier. Chacun de ces éléments est un événement facturé. Le modèle est probablement le seul que vous avez chiffré.

La nomenclature complète d'une tâche ressemble généralement à ceci :

• Tokens du modèle, répartis entre entrée, sortie et entrée en cache, sur chaque appel de la boucle
• Appels d'outils et d'API, chacun avec son propre prix à la requête ou une licence par poste avec quota
• Retentatives et nouvelles exécutions causées par des timeouts d'outils, une sortie du modèle malformée ou des limites de débit
• Infrastructure : file d'attente, workers, base de données, base vectorielle si vous en utilisez une
• Observabilité : spans de traçage et rétention des logs, souvent facturés à l'événement
• Temps de révision humaine pour la part des tâches signalées

Le piège avec les agents, contrairement à un pipeline fixe, c'est que l'agent décide lui-même du nombre d'appels d'outils à effectuer. Votre coût par tâche est une distribution, pas un chiffre. Deux tâches identiques en apparence peuvent différer de plusieurs multiples en coût, parce que l'une a cherché cinq fois et l'autre une seule fois.

Pourquoi les appels d'outils dépassent les tokens

Les prix des tokens ont baissé de manière constante, et vous pouvez les réduire encore via la mise en cache des prompts et le traitement par lots. Anthropic documente les deux sur sa page de tarification. Les prix à la requête des API de recherche, de scraping et d'enrichissement n'évoluent pas de la même façon. Ils sont facturés à l'appel, tarifés pour une consommation machine, et l'agent les appelle de manière répétée là où un humain aurait survolé une seule page.

Le marché évolue dans le même sens. Brave a récemment annoncé que son Search API accepte les paiements agentiques via le protocole x402, ce qui est un fournisseur d'outils concevant explicitement pour des agents qui paient à l'appel sans humain dans la boucle. Attendez-vous à ce que d'autres fournisseurs de votre agent facturent de cette façon. C'est pratique pour l'agent et dangereux pour le budget, sauf si vous le plafonnez.

La mise en cache n'aide que le côté modèle. Le modèle lit votre prompt système une fois et le cache absorbe les répétitions. Un appel API tiers n'est jamais mis en cache, sauf si vous construisez ce cache vous-même, indexé par domaine, requête ou fiche, avec une expiration raisonnable.

Ce que nous avons appris avec notre propre moteur de prospection

Nous exploitons un outil de prospection interne qui scrape le site de chaque prospect et rédige un email personnalisé par entreprise. La première vraie question de conception a été le coût marginal par prospect, car le prix du scraping par page et le prix du modèle par appel s'échelonnaient tous deux avec la liste. Nous avons fini par auto-héberger Firecrawl et faire tourner un modèle local, de sorte que le coût marginal par prospect est essentiellement du calcul que nous payons déjà. La seconde découverte était moins évidente : un seul appel qui extrait les faits et rédige l'email en une seule passe a surpassé une chaîne à plusieurs étapes, à la fois en coût et en qualité. Moins d'appels signifiait moins d'endroits où échouer, donc moins de retentatives, qui est précisément là où la chaîne dépensait discrètement. Nous avons détaillé ce schéma général dans single call vs agent chains.

Le multiplicateur des retentatives

Les retentatives sont le poste que personne ne budgétise. Une API de scraping expire, le modèle renvoie du JSON avec une virgule de trop, une limite de débit se déclenche à la troisième recherche. Chaque retentative refacture tout ce qui se trouve à l'intérieur de la boucle qu'elle relance. Si votre politique de retentative englobe la tâche entière plutôt que la seule étape en échec, un outil capricieux peut tripler le coût de cette tâche.

Deux métriques permettent de repérer ce problème tôt. La première est le nombre d'appels d'outils par tâche accomplie, suivi comme une distribution avec sa queue, pas seulement une moyenne. La seconde est le nombre de tentatives par tâche accomplie, qui indique à quelle fréquence la boucle a redémarré. Quand la queue de l'une ou l'autre s'allonge, votre facture grossit avant que vos tableaux de bord ne le montrent. Des plafonds stricts sur les deux, imposés dans le code plutôt que dans le prompt, constituent le contrôle le moins coûteux. Rendre les actions payantes idempotentes, pour qu'une nouvelle exécution ne les répète pas, compte tout autant, et nous avons traité ce sujet dans AI agent duplicate actions and idempotency.

Des coûts fixes qui paraissent minimes jusqu'à ce que vous réduisiez l'échelle

Une file d'attente, deux workers, une instance Postgres et une plateforme de traçage sont peu coûteux en valeur absolue. Répartis sur quelques milliers de tâches par mois, ils sont presque gratuits. Répartis sur deux cents tâches par mois, ils peuvent coûter plus par tâche que l'ensemble des appels API combinés. Les plateformes de traçage facturées par span en sont l'illustration la plus nette : un agent avec douze étapes émet douze spans par tâche, plus les retentatives.

Le régime dans lequel vous vous trouvez détermine la majeure partie de votre architecture. À faible volume, un runtime d'agent géré facturé à l'exécution est souvent moins coûteux que de faire tourner votre propre pile, et les coûts fixes disparaissent dans la marge de quelqu'un d'autre. À fort volume, l'arithmétique s'inverse et l'auto-hébergement des outils lourds devient rentable. Les compromis sont détaillés dans managed vs self-hosted agent runtimes.

Comment estimer avant de construire

Vous pouvez obtenir une fourchette raisonnable avant d'écrire du code, à condition de faire le travail sur papier d'abord :

1. Décrivez la boucle sous forme de liste d'appels. Pour chaque étape, notez le fournisseur et la fourchette attendue d'appels par tâche (minimum, typique, pire cas).
2. Chiffrez chaque étape au prix catalogue. Identifiez celles facturées à l'appel, celles par poste avec quota, et celles en forfait mensuel fixe.
3. Multipliez par le nombre de tentatives attendues. Choisissez une hypothèse de retentative honnête pour le pilote et remplacez-la par des données mesurées dès la première semaine.
4. Répartissez les coûts fixes sur le volume mensuel. Infrastructure, traçage et toute licence, divisés par le nombre de tâches accomplies que vous attendez réellement, pas celui du pitch deck.
5. Comparez avec la valeur d'une tâche accomplie. Si un lead qualifié ou un ticket résolu vaut moins que le coût du pire cas pour le produire, repensez la boucle avant de la construire.

Lancez ensuite un pilote de quelques centaines de tâches avec le suivi des coûts activé par étape dès le premier jour. Le pilote existe pour remplacer vos suppositions des étapes 1 et 3. Si vous ne suivez que les tokens pendant le pilote, vous arriverez en production avec une facture de modèle que vous comprenez et une facture d'outils que vous ne comprenez pas.

Les leviers qui font vraiment bouger la facture

Une fois que vous avez des chiffres mesurés, la plupart des économies viennent d'une courte liste :

• Fusionnez les étapes. Chaque appel au modèle que vous supprimez supprime aussi ses retentatives et ses spans.
• Mettez en cache les résultats des outils. Scrapez un domaine une fois et réutilisez-le pour plusieurs tâches. Donnez aux résultats de recherche une durée de vie de plusieurs jours pour tout ce qui n'est pas de l'actualité.
• Auto-hébergez l'outil lourd quand le volume le justifie. Le scraping et les petits modèles d'extraction sont les candidats habituels, comme dans notre moteur de prospection.
• Traitez par lots tout ce qui n'est pas urgent. L'enrichissement et la classification de nuit peuvent passer par des points d'accès batch à tarif réduit plutôt que par des appels en direct.
• Plafonnez les appels d'outils par tâche dans le code. Une instruction dans le prompt du type « cherchez au maximum trois fois » reste un conseil. Un compteur dans la boucle est un contrôle.
• Routez par étape. Utilisez un petit modèle pour l'extraction et le formatage, et réservez le modèle de pointe aux décisions de jugement, selon le raisonnement développé dans small LLM vs frontier model.

Notez que les conseils centrés sur les tokens que l'on trouve dans la plupart des guides de coûts se retrouvent en bas de cette liste pour les agents. Cela reste utile, et nous tenons un guide séparé sur l'optimisation des coûts LLM, mais il traite la facture la plus petite.

Que demander avant de signer

Si un fournisseur ou une agence vous donne un prix de tokens et un abonnement mensuel à la plateforme, l'estimation est incomplète. Demandez le coût projeté par tâche accomplie et les hypothèses qui le sous-tendent. Demandez combien d'appels d'outils une tâche typique effectue et à quoi ressemble le pire cas. Demandez comment les retentatives sont plafonnées et si les actions payantes sont idempotentes. Demandez quels coûts sont fixes et ce qu'il advient du coût par tâche si votre volume est la moitié de ce que vous aviez prévu.

Une équipe qui a déjà exploité un agent en production répondra à ces questions avec des chiffres issus d'un tableau de bord. Une équipe qui n'a construit que des démonstrations répondra avec des prix de tokens. Si vous êtes en train de chiffrer un agent et souhaitez un second avis sur la boucle avant de vous engager sur une pile technique, parlons-en.