Objectifs
- Comprendre pourquoi un service IA facturé à l'usage se pilote autrement qu'une infrastructure réservée.
- Identifier les décisions de produit qui font varier la dépense sans ajouter d'utilisateurs.
- Poser la définition de la démarche FinOps appliquée à l'IA.
Ce qui change
Sur une application classique, on réserve des machines, de la mémoire, du stockage : la facture suit surtout ce que l'on a provisionné. Avec un service IA facturé à l'usage, la dépense dépend aussi du contenu des échanges et du chemin suivi pour produire une réponse. Le cloud classique peut lui aussi avoir des coûts très variables ; ce qui nous intéresse ici, c'est la part de cette variation qui vient du comportement du produit.
Deux personnes posent une question proche. L'une reçoit une réponse courte. L'autre joint un document, demande plusieurs vérifications et déclenche cinq appels supplémentaires. Le nombre d'utilisateurs est identique, la consommation ne l'est pas.
Exemple fictif
Tous les prix de ce module sont fictifs : ils servent à isoler un mécanisme, jamais à estimer un budget réel.
- 100 000 demandes par jour à 0,006 $ chacune : 600 $ par jour.
- On ajoute une boucle qui exécute 10 appels équivalents par demande : 100 000 × 10 × 0,006 = 6 000 $ par jour.
Le trafic n'a pas bougé, c'est le fonctionnement de la tâche qui a changé. Les dix appels sont une hypothèse pédagogique : une modification de prompt ne multiplie pas systématiquement la facture par dix.
Figure 1 : à trafic identique, le nombre d'appels par demande change la facture (prix fictifs, dix appels par hypothèse pédagogique).*
Le FinOps appliqué à l'IA
Le FinOps est un travail commun entre le produit, la technique et la finance pour relier la consommation à la valeur obtenue. Le chef de produit agit directement sur la dépense : longueur des réponses, quantité de contexte envoyée, nombre de vérifications, nombre d'étapes autorisées à un agent.
Pièges
- Estimer le coût avec le seul trafic, en oubliant que la taille du contexte et les appels supplémentaires comptent autant.
- Déployer une modification de prompt ou de workflow sans mesurer son coût avant et après.
Pour réfléchir
Quelle décision de produit récente de votre équipe a pu augmenter le coût sans ajouter un seul utilisateur ? Exemples à tester : réponses plus longues, plus de documents transmis, vérifications ajoutées, tentatives supplémentaires autorisées.