Le coût par tâche réussie : la métrique FinOps qui manque aux agents IA

Deux agents peuvent consommer le même nombre de jetons et produire une valeur très différente. L’un termine la tâche au premier essai ; l’autre multiplie les reprises, appelle trois outils, déclenche un fallback puis abandonne. Une métrique limitée au coût du modèle ne révèle pas cette différence.

Passer du coût technique au coût de l’issue

Le coût par tâche réussie agrège les dépenses nécessaires pour obtenir un résultat défini : jetons d’entrée et de sortie, embeddings, recherche, appels d’outils, compute, observabilité et reprises. Il divise ensuite ce coût par le nombre de tâches réellement terminées selon un critère métier.

Cette définition exige de nommer les tâches et leurs issues. « Conversation terminée » est trop vague. « Dossier qualifié et enregistré », « réponse approuvée » ou « contrôle exécuté avec preuve » sont des résultats mesurables.

Les dimensions minimales

• produit, équipe ou centre de coûts ;
• consommateur, agent et version ;
• modèle principal et éventuel fallback ;
• outil appelé et nombre d’actions ;
• jetons, latence, reprises et erreurs ;
• statut final de la tâche.

Ces dimensions doivent être propagées sans exposer de données personnelles inutiles. Elles peuvent alimenter Application Insights, Log Analytics ou un pipeline de coûts dédié.

Contrôler avant d’optimiser

La première mesure FinOps est un garde-fou : plafond par consommateur, limite d’actions, nombre maximal de reprises et seuil de budget. L’optimisation vient ensuite : cache adapté, routage vers un modèle moins coûteux, réduction du contexte, ajustement des outils ou suppression des boucles inefficaces.

Un cache n’est toutefois pas automatiquement bénéfique. Il doit respecter l’identité, le contexte et la fraîcheur attendue. Servir une réponse d’un autre utilisateur pour réduire les coûts serait un échec de sécurité majeur.

Intégrer la métrique à la décision de production

Un système peut être fonctionnel et sûr tout en restant économiquement incontrôlable. La décision doit donc préciser si le coût est attribuable, si les plafonds sont testés et si une dérive déclenche une alerte. Une absence de données ne doit pas être interprétée comme un coût acceptable.

Actifs de méthode associés : Gateway Validation Kit, Fitness Board et Agent Runtime Golden Path. Ils relient test du plafond, baseline des budgets et tags, télémétrie runtime et attribution du coût au consommateur ou à la tâche.

La question à poser au prochain comité

Ne demandez pas seulement « combien avons-nous dépensé en modèles ce mois-ci ? ». Demandez : combien coûte chaque résultat utile, combien de tâches échouent après consommation et quelle équipe peut expliquer l’écart ?

Vérifier ce point dans votre environnement

Ce que cela change à l’échelle d’un grand compte

• Le budget se pilote par issue, pas par consommation. Un plafond de jetons contient la facture ; un coût par tâche réussie arbitre les investissements. Ce sont deux instruments différents, et le second manque presque partout.
• La métrique révèle les échecs silencieux. Un agent qui abandonne après trois reprises coûte plein tarif pour zéro valeur. Invisible en coût par appel, éclatant en coût par issue.
• Les dimensions sont un contrat transverse. Produit, équipe, agent, version, modèle, outil, statut final : propagées dès la conception, elles servent à la fois le FinOps, l’observabilité et la conformité — trois budgets pour un seul effort.

Frontière de preuveNote de méthode. Ce texte définit une métrique et sa méthode de calcul ; il ne rapporte aucun chiffre observé sur un système client. Les ordres de grandeur d’écart entre agents sont illustratifs et dépendent entièrement du cas d’usage.