Cost per task, cost per success, cost per verified outcome: les entreprises commencent à changer d’unité pour mesurer le coût réel de l’intelligence artificielle. Mais même un résultat correctement exécuté et vérifié ne dit pas encore si l’organisation a créé — et surtout capturé — de la valeur.
Une entreprise déploie un agent IA. Le modèle coûte moins cher que celui qu’elle utilisait six mois auparavant. Les tokens ont baissé. L’infrastructure a été optimisée. Sur le papier, l’économie est excellente.
Pourtant, la facture augmente. Pourquoi ? La réponse tient en partie à une erreur de mesure. Nous continuons à regarder le prix de l’intelligence consommée alors que l’entreprise achète, en réalité, un résultat. Cette distinction pourrait devenir beaucoup plus importante avec l’arrivée des agents IA. Un agent ne se contente plus de recevoir une question et de produire une réponse. Il peut rechercher une information, consulter une mémoire, appeler plusieurs outils, interroger un système métier, solliciter différents modèles, vérifier un résultat, recommencer lorsqu’il échoue puis transférer le dossier à un humain.
À la fin, le prix du token ne raconte plus qu’une petite partie de l’histoire.
Une entreprise n’achète pas des tokens. Elle achète une capacité à produire un résultat.
C’est en réécoutant mon entretien avec Bertrand Charpentier, cofondateur de Pruna AI, que cette question m’est revenue.
Il présentait un cas dans lequel le temps d’inférence avait été ramené, selon l’entreprise, de 13,5 à 3,6 secondes, tandis que le coût d’un million d’images passait de 10 000 à 2 600 euros. Pruna AI expliquait parallèlement utiliser des benchmarks afin de vérifier que cette compression ne dégradait pas la qualité du modèle.
Les données sont celles communiquées par l’entreprise et ne constituent pas une validation indépendante. Mais elles montrent très bien ce que permet l’optimisation technique : réduire simultanément le temps de calcul et le coût d’inférence tout en cherchant à préserver la qualité.
Une autre question m’intéresse pourtant davantage aujourd’hui : que se passe-t-il après l’inférence ? Car une entreprise ne déploie pas un modèle dans le vide. Il faut connecter les données, intégrer le système aux applications existantes, gérer les droits d’accès, orchestrer les outils, contrôler les résultats, surveiller les erreurs, assurer la sécurité, former les utilisateurs et parfois maintenir une validation humaine.
Avec les agents, cette chaîne s’allonge encore. Un coût d’inférence peut donc diminuer fortement sans que le coût réel du résultat baisse dans les mêmes proportions. Dans certaines situations, il peut même augmenter. C’est en cherchant à comprendre ce paradoxe que j’ai constaté que l’industrie de l’IA était elle-même en train de changer d’unité de mesure.
L’industrie cherche déjà une autre unité de mesure
Ce déplacement est désormais visible dans plusieurs travaux récents.
Anthropic raisonnait dès 2025 sur le coût d’utilisation de Claude à l’échelle des tâches professionnelles. IBM recommande aujourd’hui de regarder le cost per task plutôt que de limiter l’analyse au prix des tokens. DoiT a consacré en août 2026 un framework entier à cette approche sous un titre particulièrement explicite : Cost Per Task, Not Cost Per Token.
NVIDIA introduit de son côté le cost per success dans son cadre d’évaluation des agents. Arize et Fireworks ont poussé le raisonnement vers le cost per successful task dans un benchmark portant sur dix modèles, quarante tâches et 2 400 exécutions agentiques.
Plus récemment encore, le 3 octobre 2026, Ethen Research Lab a publié une note consacrée au Cost Per Verified Outcome. Le principe consiste à rapporter l’ensemble des coûts éligibles nécessaires à la livraison d’un travail au nombre de résultats dont la réussite a effectivement été vérifiée.
Les termes diffèrent et les méthodologies ne sont pas interchangeables. Mais le mouvement est assez clair : l’économie de l’IA commence à quitter le coût de la ressource pour regarder le coût du travail réellement accompli. C’est un changement important pour les entreprises.
Prenons deux modèles. Le premier coûte deux fois moins cher à chaque exécution. Mais il échoue davantage, utilise plus d’outils et nécessite régulièrement une deuxième tentative. Le second est plus cher à l’appel, mais termine correctement la tâche beaucoup plus souvent. Lequel coûte réellement le moins cher ? Impossible de répondre en regardant uniquement son tarif par token.
Le benchmark d’Arize et Fireworks illustre précisément cette difficulté. Une exécution qui échoue a tout de même consommé des ressources. Les tokens ont été facturés, les outils éventuellement sollicités et du compute utilisé. Si l’agent recommence, cette deuxième tentative vient s’ajouter à la première.
Le coût de l’échec fait donc partie du coût du résultat.
Cette évidence prend une importance nouvelle avec les agents parce que leur comportement est moins linéaire qu’un simple appel de modèle. Une tâche peut être résolue immédiatement. Une autre, apparemment comparable, peut déclencher plusieurs recherches, des appels d’outils supplémentaires, davantage de raisonnement ou une intervention humaine.
McKinsey souligne d’ailleurs que les coûts des systèmes agentiques peuvent varier fortement selon la trajectoire suivie pour accomplir une même tâche. Cette variabilité oblige à regarder non seulement le coût moyen, mais aussi les échecs, les exceptions et les situations nécessitant une récupération après erreur. C’est là que la notion de résultat vérifié devient intéressante.
Il ne suffit plus que l’agent affirme avoir terminé sa tâche. Il faut déterminer si le résultat répond réellement aux critères définis par l’organisation.
Dans un service client, la réponse a-t-elle effectivement résolu le problème ? Dans un processus comptable, le rapprochement est-il correct ? Dans un système commercial, les données inscrites dans le CRM sont-elles exactes ? Dans un processus réglementé, les règles applicables ont-elles été respectées ?
On comprend alors pourquoi le prix du token devient une unité économique très partielle. Mais une difficulté subsiste.
Un résultat vérifié n’est pas nécessairement un résultat de valeur
Imaginons un agent commercial. Il identifie correctement un prospect, enrichit sa fiche, prépare une proposition conforme aux règles de l’entreprise et enregistre parfaitement l’ensemble des informations dans le CRM. Le résultat est correct. Il peut même être vérifié. Mais le prospect n’était peut-être pas suffisamment pertinent. Le commercial ne donne peut-être aucune suite à la proposition. Le cycle de vente n’est peut-être pas raccourci. Et le temps gagné n’est peut-être pas réinvesti dans davantage de prospection.
L’agent a réussi. Que vaut cette réussite pour l’entreprise ? C’est ici que je retrouve la question qui m’avait conduite à travailler sur VALEUR : la performance d’un système et la valeur capturée par l’organisation ne sont pas la même chose. Dans le premier article consacré au paradoxe de la productivité de l’IA, j’avais résumé cette distinction ainsi :
Capacité IA ≠ usage IA ≠ productivité ≠ valeur créée ≠ valeur capturée.
L’économie des agents fait apparaître une progression comparable. On peut mesurer le coût de la ressource utilisée. Puis le coût de la tâche. Puis le coût de la tâche réussie. Puis celui du résultat vérifié. Mais à ce stade, nous savons surtout que l’IA a correctement fait son travail. Nous ne savons toujours pas si l’entreprise a amélioré le sien. Cette distinction peut sembler théorique. Elle devient très concrète dès que l’on revient aux indicateurs métier.
Un agent de service client peut augmenter le nombre de dossiers traités et réduire le coût unitaire de chaque résolution. Si la satisfaction baisse ou si les cas complexes sont mal transférés vers les conseillers, l’économie apparente doit être réévaluée.
Une équipe de développement peut produire davantage de code sans réduire le délai entre l’idée et la mise en production. Une direction financière peut automatiser certaines opérations sans accélérer la clôture. Un commercial peut gagner une heure par jour sans vendre davantage.
Dans chacun de ces cas, le système peut parfaitement fonctionner. C’est le lien entre sa performance et le résultat organisationnel qui reste à démontrer.
Ce qui se passe après le résultat
C’est probablement ici que le débat sur le ROI de l’IA doit maintenant se déplacer.
Les nouvelles métriques — cost per task, cost per success, cost per successful task, cost per verified outcome — constituent une avancée importante parce qu’elles rapprochent la dépense technique du travail réellement produit.
Mais elles ne répondent pas encore entièrement à la question d’un dirigeant. Celui-ci ne cherche pas seulement à savoir combien coûte une tâche correctement accomplie. Il veut savoir ce que cette tâche change dans son organisation. Le résultat vérifié doit donc être relié à un résultat organisationnel : chiffre d’affaires, marge, qualité, rapidité, satisfaction client, diminution du risque, innovation ou capacité nouvelle.
Puis vient une dernière question, souvent négligée : que fait l’entreprise de cette amélioration ?
Une automatisation peut libérer du temps. Encore faut-il décider comment ce temps sera utilisé. Une équipe peut devenir plus productive. Encore faut-il que cette productivité rencontre une demande ou permette de supprimer un goulot d’étranglement ailleurs dans le processus. Une IA peut réduire le coût d’une opération. Encore faut-il que cette économie ne soit pas absorbée par de nouveaux coûts d’intégration, de vérification ou de gouvernance.
C’est ce passage du résultat à la valeur capturée qui me paraît aujourd’hui le plus intéressant à observer.
On peut le représenter simplement :
Token → Task → Successful Task → Verified Outcome → Organizational Outcome → Captured Value
Je ne considère pas cette chaîne comme une nouvelle taxonomie scientifique. C’est une grille de lecture issue du croisement entre les travaux récents sur l’économie des agents et les observations menées dans le cadre d’EntrepreneurIA.
Elle permet surtout de poser les bonnes questions au bon niveau. Le token renseigne sur la consommation. La tâche rapproche le coût du travail effectué. La réussite introduit la performance. La vérification introduit la fiabilité. Le résultat organisationnel demande ce que cette performance change réellement dans l’entreprise. La valeur capturée demande enfin ce que l’organisation parvient à conserver, transformer ou réinvestir de cette amélioration.
C’est cette dernière étape qui reste probablement la plus difficile à mesurer.
L’économie des agents sera aussi une question de management
Ce déplacement des métriques n’est pas seulement une affaire de spécialistes de l’infrastructure. Il oblige à rapprocher des fonctions qui disposent chacune d’une partie de l’information.
La DSI connaît la consommation technique et l’infrastructure. Les équipes IA connaissent les performances des modèles. Les métiers savent ce qu’ils attendent du processus. La finance connaît les coûts, les marges et les investissements. Les responsables de la gouvernance connaissent les risques et les contraintes de contrôle.
Aucun ne possède seul l’équation complète. Cela explique probablement pourquoi la question des coûts devient plus difficile lorsque les agents passent en production.
Le choix du modèle lui-même devient un arbitrage économique. Utiliser systématiquement le modèle le plus puissant serait coûteux et souvent inutile. Choisir systématiquement le moins cher peut multiplier les échecs et les reprises. Une architecture efficace peut donc combiner plusieurs niveaux de modèles, des règles déterministes, des outils spécialisés et une intervention humaine réservée aux situations où elle apporte réellement de la valeur.
IBM insiste notamment sur cette logique de model routing : utiliser la capacité adaptée à la tâche plutôt que mobiliser systématiquement le même modèle. Cette approche oblige également à intégrer le coût des erreurs.
Une mauvaise reformulation dans un document interne n’a pas les mêmes conséquences qu’une mauvaise décision financière, juridique ou médicale. Plus le coût potentiel de l’erreur augmente, plus l’entreprise doit investir dans le contexte, la vérification, la traçabilité et la responsabilité humaine.
Le système peut alors sembler plus cher tout en étant économiquement beaucoup plus rationnel.
C’est une raison supplémentaire de se méfier des comparaisons fondées uniquement sur le prix des modèles.
Ce que je demanderais avant de déployer un agent
Je ne commencerais donc plus un business case agentique uniquement par la question : Quel modèle allons-nous utiliser ?
Je chercherais d’abord à comprendre ce que l’entreprise attend réellement du système. Quelle unité de travail voulons-nous produire ? Comment saurons-nous qu’elle a été correctement accomplie ? Quel indicateur de l’organisation doit être modifié si l’agent fonctionne ? Et que ferons-nous concrètement de la capacité ainsi libérée ?
Ces questions paraissent moins technologiques. Elles sont pourtant probablement plus importantes pour déterminer le ROI.
L’IA entre dans une phase où l’optimisation des modèles restera essentielle, mais où elle ne suffira plus à expliquer l’économie d’un système. Le coût devra être regardé jusqu’au résultat, puis le résultat jusqu’à la valeur. C’est aussi ce qui rend les travaux actuels sur le cost per task, le cost per success ou le verified outcome particulièrement intéressants. Ils signalent que l’industrie commence elle-même à chercher de meilleures unités. La prochaine étape sera peut-être de comprendre comment ces unités techniques et opérationnelles peuvent être reliées aux indicateurs économiques de l’entreprise.
Car au bout du compte, un dirigeant ne cherche pas à optimiser un token. Il cherche à améliorer son organisation.
Le prix du token nous dit combien coûte l’intelligence consommée. Il ne nous dit pas ce qu’elle rapporte à l’entreprise.
Note méthodologique
Les notions de cost per task, cost per success, cost per successful task et Cost Per Verified Outcome ne sont pas présentées ici comme des concepts développés par EntrepreneurIA.
Anthropic analysait dès 2025 certains usages de Claude sous l’angle du coût par tâche. DoiT a publié en août 2026 un framework explicitement consacré au Cost Per Task. NVIDIA utilise le cost per success parmi ses métriques d’évaluation des agents. Arize et Fireworks ont mobilisé le cost per successful task dans un benchmark de 2 400 exécutions. Ethen Research Lab a publié le 3 octobre 2026 une définition explicite du Cost Per Verified Outcome.
La chaîne Token → Task → Successful Task → Verified Outcome → Organizational Outcome → Captured Value constitue ici une proposition analytique exploratoire destinée à articuler ces métriques avec les recherches EntrepreneurIA et le cadre VALEUR. Elle ne doit pas être interprétée comme une taxonomie scientifique validée.
Les données relatives à Pruna AI sont issues de l’entretien EntrepreneurIA avec Bertrand Charpentier et sont présentées comme des performances communiquées par l’entreprise.
Sources et références
Anthropic. Economic Index : Uneven geographic and enterprise AI adoption, septembre 2025.
DoiT. Cost Per Task, Not Cost Per Token: A Measurement Framework for the Real Economics of Claude, OpenAI and Grok, août 2026.
Arize AI & Fireworks AI. Cost per successful task: Benchmarking Kimi K3, GPT-5.5, and 8 more AI models, 2026.
Ethen Research Lab/Upcube. Cost Per Verified Outcome: A Better Economic Unit for Agentic AI, 3 octobre 2026.
IBM. Travaux 2026 consacrés à l’économie et à la gestion des coûts des agents IA.
NVIDIA. How to Evaluate AI Agents From Tool Calls to Task Completion, 2026.
McKinsey & Company. Travaux 2026 consacrés à l’économie des systèmes agentiques, au coût par tâche, aux taux de qualité et aux coûts de vérification et de récupération.
EntrepreneurIA — Bertrand Charpentier, Pruna AI. Entretien consacré à l’optimisation et à la compression des modèles, aux coûts d’inférence et aux benchmarks de qualité.




