Combien coûte réellement un agent IA en production ?

Le coût d’inférence

Le coût que tout le monde sait nommer est celui des appels. Tokens d’entrée, tokens de sortie, éventuellement un prix à la requête pour un modèle hébergé, un coût GPU pour un modèle interne. Les factures des fournisseurs rendent ce poste lisible. Les directions financières savent le rapprocher d’un volume. Les équipes projet savent l’optimiser : raccourcir les contextes, mettre en cache, router vers un modèle moins cher lorsque la tâche le permet.

Ce poste est réel. Il n’est pas le sujet. Dans un rituel métier : classification de catalogue, scoring, rédaction d’un commentaire de gestion : l’inférence représente souvent la part minoritaire du coût total d’une exécution une fois le système en production. Elle est minoritaire parce qu’elle est automatisée, mesurable, et déjà l’objet d’une attention commerciale. Les autres postes n’apparaissent pas sur la facture du modèle. Ils apparaissent dans les calendriers, les allers-retours, les incidents d’intégration.

Il est néanmoins utile de le mesurer par exécution, pas par mois. Un coût mensuel agrégé mélange les runs utiles, les runs de test, les reprises, les timeouts. Le coût par run, même imparfait, permet de comparer un rituel à un autre, et une semaine à la suivante. Sans cette unité, on discute de « la facture IA » comme on discutait autrefois de « la facture cloud » : un agrégat qui n’aide pas à décider.

L’inférence a aussi une volatilité propre. Un changement de modèle, une hausse de tarif, un allongement de contexte multiplient le poste sans que le rituel ait changé. Si c’est le seul indicateur suivi, l’organisation croit piloter un coût de production. Elle pilote un tarif de fournisseur. Ce n’est pas la même chose.

Le coût de correction

Dès que la sortie n’est pas acceptée telle quelle, un humain corrige. Cette correction a un coût salarial, un coût de délai, et un coût de qualité : chaque reprise introduit une variante que le système n’apprend pas nécessairement.

Le taux d’acceptation en première proposition est l’indicateur qui rend ce poste visible. À 82 % d’acceptation, 18 % des exécutions entrent en correction. À 50 %, la moitié du flux est du rework. Le coût d’inférence de ces runs n’est pas perdu au sens comptable : l’appel a bien eu lieu : mais il est économiquement stérile : on paie le modèle, puis on paie la personne qui défait le résultat.

La correction a une autre caractéristique : elle croît avec l’ambition du livrable. Un libellé court se corrige vite. Un rapport de vingt pages, un graphe d’entités, un dossier d’exigences se corrige lentement, et souvent par plusieurs personnes. Le coût n’est plus linéaire au nombre de tokens. Il est linéaire au nombre de jugements humains nécessaires pour rendre le livrable admissible en comité.

Les organisations qui ne mesurent pas ce taux traitent la correction comme du « métier ». Elle l’est. Elle est aussi un coût de production de l’agent. Tant qu’elle n’est pas rattachée au run, elle disparaît dans la masse salariale et revient, dans les arbitrages, sous la forme d’un sentiment : « l’IA ne nous fait pas gagner autant qu’on le disait ». Le sentiment est souvent juste. La mesure manque.

Le coût de vérification

Même lorsque la sortie est correcte, quelqu’un doit le constater. La vérification n’est pas la correction. C’est le temps passé à s’assurer que l’on peut signer.

Dans un environnement peu gouverné, ce temps est diffus : ouvrir les sources, chercher le fichier, demander à un collègue si le chiffre est le bon, relire « au cas où ». Il n’apparaît dans aucun timesheet d’un projet IA. Il apparaît dans le cycle time du rituel. Un rapport qui « sort en une heure » mais se vérifie pendant deux jours n’a pas un cycle time d’une heure.

La vérification est aussi le poste que l’AI Act et l’audit rendent non compressibles. On peut réduire l’inférence. On ne peut pas supprimer la supervision humaine sur un système à enjeu. On peut, en revanche, réduire le coût unitaire de cette supervision en présentant le dossier au moment de la revue, au lieu de le faire chercher. Un validateur qui ouvre un Evidence Panel vérifie. Un validateur qui reconstitue enquête. L’enquête est plus chère, et plus lente.

Il faut donc séparer, dans le pilotage, trois durées : temps machine, temps de correction, temps de vérification. Les confondre produit des business cases d’heures gagnées que la direction financière ne retrouve pas. Les distinguer permet de voir où le coût se situe réellement, et s’il baisse d’une vague à l’autre.

Le coût de reconstitution

Le quatrième poste n’apparaît pas tous les jours. Il apparaît le jour où l’on demande le dossier. Audit, régulateur, comité des risques, litige, simple question interne six mois plus tard : « pourquoi avons-nous classé ainsi, scoré ainsi, écrit cela ».

Si le run n’a pas produit ses artefacts, la reconstitution mobilise des profils chers, pendant des jours. On relit des mails, on interroge des logs, on retrouve une version de prompt dans un dépôt. Parfois on n’y parvient pas. Le coût n’est alors plus un coût de personnel. C’est un coût d’exposition : décision indéfendable, report d’un comité, provision, ou simplement incapacité à réutiliser le travail déjà payé.

Ce poste a la particularité d’être hors budget projet. Personne ne le provisionne dans le TCO de l’agent. Il est pourtant lié, run après run, à l’absence de preuve native. Une organisation qui déploie sans dossier accumule une option de coût futur. L’option s’exerce le jour de la demande. Le jour de la demande n’est pas choisi par l’équipe produit.

Mesurer le coût par exécution

Le coût réel d’un agent en production est la somme, par run, de l’inférence, de la correction, de la vérification, et d’une quote-part du risque de reconstitution. On ne mesure pas cette quote-part au centime. On la rend visible en mesurant le délai de production d’un dossier de preuve. Si ce délai est de cinq minutes, la quote-part est négligeable. Si elle est de cinq jours, elle domine dès qu’un audit survient.

Le Cockpit utile n’affiche donc pas seulement le prix des tokens. Il affiche le coût par run, le taux d’acceptation, le volume envoyé en revue, le temps de cycle jusqu’à signature. Ces grandeurs sont dans le système. Elles ne demandent pas une enquête déclarative auprès des utilisateurs.

Une fois ces grandeurs disponibles, les arbitrages changent. On peut décider qu’un modèle plus cher, s’il lève le taux d’acceptation, abaisse le coût total. On peut décider qu’un rituel trop coûteux à vérifier n’est pas encore industrialisable, même si l’inférence est bon marché. On peut comparer deux rituels sur une base commune, au lieu de les juger à l’aune de démonstrations.

Le modèle économique au run, côté plateforme, n’est pas un argument tarifaire isolé. Il est aligné sur cette unité de coût. On paie l’exécution que l’on peut gouverner, pas le siège d’un utilisateur qui n’exécute pas. Encore faut-il que l’exécution soit l’unité de pilotage interne. Sinon l’organisation achète au run et manage au ressenti. Les deux ne se rencontrent pas dans un comité d’investissement.

Une fois l’unité posée, les conversations budgétaires changent de vocabulaire. On ne demande plus « combien coûte l’IA cette année ». On demande « quel rituel, à quel coût par run, à quel taux d’acceptation, et que se passe-t-il si le volume double ». Ces questions ont des réponses dans un Cockpit. Elles n’en ont pas dans une facture de tokens. C’est tout l’écart entre un poste de dépense et un coût de production.