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 ?