Combien coûte vraiment un agent IA en production

La question du coût arrive tard dans les projets d’agents, généralement après la démonstration, et elle reçoit une réponse rassurante fondée sur le prix unitaire affiché par le fournisseur. Quelques fractions de cent par appel : la conclusion s’impose que le sujet est négligeable. Puis le système passe en production, et la facture du premier mois complet arrive avec un ordre de grandeur qui n’avait été anticipé par personne. L’écart ne vient pas d’une erreur d’arithmétique. Il vient de ce que l’estimation portait sur un appel, alors que le système facture des tâches.

Je propose donc de décomposer honnêtement ce qui compose cette facture, dans l’ordre décroissant de contribution. Le prix unitaire du modèle, qui concentre toute l’attention, arrive en dernier.

D’où vient la facture, par ordre de contribution

Poste	Mécanisme	Ordre de grandeur
Tours par tâche	Contexte réinjecté à chaque tour : croissance quadratique	Une tâche à 8 étapes coûte jusqu’à 30 étapes isolées
Reprises silencieuses	Mauvais outil, format illisible, boucle, rejet utilisateur	Jusqu’à 50 % du volume facturé, sans erreur journalisée
Contexte réinjecté	Instructions et passages qui grossissent à chaque correctif	Croît de façon monotone avec la maturité du système
Prix unitaire	Tarif par appel du fournisseur	Le poste le moins déterminant

L’estimation initiale ne se trompe pas de calcul : elle se trompe d’unité. Elle porte sur un appel, la facture porte sur une tâche.

Une tâche n’est pas un appel

C’est le facteur dominant et il est structurel, pas accidentel.

Un agent qui accomplit une tâche réelle ne produit pas une réponse en un tour. Il lit une demande, décide d’une action, appelle un outil, reçoit un résultat, réévalue, appelle un autre outil, et conclut. Chacun de ces tours est un appel facturé. Une tâche modeste en consomme 4 ou 5 ; une tâche qui échoue partiellement et se reprend en consomme 15.

À cela s’ajoute un effet moins intuitif et plus coûteux : à chaque tour, on réinjecte le contexte. Les instructions du système, l’historique de la conversation, les résultats intermédiaires accumulés. Le volume traité au tour 8 inclut donc tout ce qui a été traité aux tours précédents. La croissance n’est pas linéaire en nombre d’étapes ; elle est de l’ordre du carré. Une tâche à 8 étapes ne coûte pas 8 fois une étape isolée — elle peut en coûter 30.

C’est la raison pour laquelle une estimation fondée sur « un appel coûte x, on prévoit n appels par jour » se trompe systématiquement dans le même sens, et d’un facteur qui dépasse souvent 3.

Les reprises que personne ne compte

Le deuxième poste est celui des échecs silencieux, et il est invisible dans les tableaux de bord habituels parce qu’il ne produit aucune erreur.

Un agent se trompe d’outil et doit recommencer. Il produit une réponse dans un format que l’étape suivante ne sait pas lire, et on relance. Il boucle sur une action qui ne converge pas jusqu’à ce qu’un garde-fou l’interrompe. Il aboutit à une réponse que l’utilisateur rejette, ce qui déclenche une reformulation et un cycle complet supplémentaire.

Aucun de ces événements n’est un incident au sens technique. Le système répond, les journaux sont propres, la disponibilité est parfaite. Et pourtant la consommation double. J’ai vu des déploiements où 50 % du volume facturé correspondait à des chemins qui n’avaient produit aucune valeur.

Mesurer ce poste suppose de suivre une métrique que peu d’équipes instrumentent : le nombre d’appels par tâche réussie, et non par tâche entamée. C’est la seule qui rende visible ce que les reprises consomment.

Le coût d’un agent n’est pas le prix d’un appel multiplié par le nombre d’appels. C’est le prix d’une tâche, multiplié par le nombre de fois où il a fallu la recommencer.

Le contexte qu’on réinjecte sans le savoir

Le troisième poste est celui qui grossit tout seul, au rythme des améliorations apportées au système.

Les instructions du système partent à chaque appel. Elles sont modestes au départ, puis on ajoute une consigne pour corriger un comportement, une autre pour un cas particulier, 5 exemples pour améliorer un format de sortie, une liste de règles métier. Chacun de ces ajouts est justifié individuellement, et le résultat cumulé est un préambule volumineux, transmis à chaque tour de chaque tâche.

Le même mécanisme joue sur les documents récupérés. Un système de recherche documentaire configuré pour ramener les 10 passages les plus proches, alors que 2 suffisaient, quintuple le volume d’entrée sur toutes les requêtes.

Ce poste a une propriété désagréable : il croît de manière monotone avec la maturité du système, à mesure que l’équipe corrige des comportements en ajoutant du contexte. Sans revue périodique explicite, il ne diminue jamais.

Pourquoi le modèle le moins cher n’est pas le moins coûteux

Le prix affiché par appel est ce qu’on regarde en premier, et c’est le paramètre le moins déterminant — mais il mérite une remarque, parce que le réflexe qu’il déclenche est souvent contre-productif.

Choisir systématiquement le modèle le moins cher est un mauvais calcul quand ce modèle échoue plus souvent. Chaque échec produit une reprise, donc des tours supplémentaires, donc parfois une escalade vers un humain dont le coût dépasse de plusieurs ordres de grandeur celui d’un appel. L’arbitrage pertinent porte sur le coût par tâche réussie, qui intègre le taux d’échec.

En pratique, la structure la plus économique est presque toujours hybride. Un modèle rapide et bon marché traite les étapes de tri, de classification et d’extraction, qui représentent l’essentiel du volume. Un modèle plus capable est réservé aux étapes qui engagent une décision. Cette répartition demande un travail d’architecture, et elle produit des économies bien supérieures à celles d’une négociation tarifaire.

Comment estimer le coût avant d’avoir construit

La méthode qui fonctionne tient en une contrainte : mesurer sur des cas réels plutôt que calculer sur un cas idéal.

On construit un prototype minimal du parcours d’agent, on l’instrumente pour compter les appels et le volume traité par tâche complète, et on lui fait traiter 30 cas issus de la production réelle — en incluant délibérément les cas tordus, ceux qui échouent, ceux où l’utilisateur reformule.

On retient ensuite le 95e centile plutôt que la moyenne. La distribution des coûts par tâche est fortement asymétrique : quelques tâches longues consomment une part disproportionnée du total. Piloter sur la moyenne conduit à sous-estimer d’un facteur 2 à 4, systématiquement.

Ce travail prend 2 à 3 jours et il transforme la conversation budgétaire : on ne discute plus d’une intuition, on discute d’une mesure assortie d’un intervalle.

Les trois leviers, par ordre d’efficacité

Le premier levier, et de loin le plus puissant, est de ne pas appeler le modèle. Une proportion importante des demandes reçues par un système en production sont répétitives, triviales, ou identiques à des demandes déjà traitées. Une correspondance exacte, un cache de réponses, une règle déterministe traitent ces cas pour un coût nul et une latence négligeable. Router ces demandes hors du modèle réduit la facture davantage que n’importe quelle optimisation de formulation — et améliore au passage la prévisibilité du système.

Le deuxième est de borner les boucles. Un plafond strict sur le nombre de tours par tâche, avec escalade au-delà, transforme un coût potentiellement illimité en coût maximal connu. C’est une décision d’architecture triviale à implémenter et qu’on omet régulièrement.

Le troisième est de tailler le contexte, par une revue périodique de ce qui est réinjecté à chaque tour : instructions devenues obsolètes, exemples redondants, passages documentaires inutiles. Cette revue trimestrielle est ingrate et ne produit rien de visible ; elle est aussi l’une des rares tâches de maintenance dont le rendement se lit directement sur une facture.

Ces trois leviers relèvent tous du cadrage plutôt que de la technologie, ce qui est cohérent avec ce que j’observe partout ailleurs sur ce sujet : la maîtrise d’un système d’IA se joue sur son périmètre bien avant de se jouer sur son modèle¹.

---

Footnotes

1. Sur les conditions de cadrage qui déterminent le succès d’un déploiement — propriétaire du résultat, mesure de référence, seuil d’erreur accepté, recours utilisateur — voir Un projet d’IA ne meurt pas d’un mauvais modèle, il meurt d’un mauvais périmètre. ↩