FinOps pour l’IA : comment maîtriser une facture que personne n’a vu venir
Uber a épuisé son budget annuel IA en 4 mois. Un développeur chez Priceline a généré une facture de 7 000 dollars à lui seul. Ces cas ne sont pas des accidents ils sont le symptôme d’un problème structurel. Lors du Salon de la Data IA de Nantes, Treez a présenté une approche concrète pour reprendre le contrôle des coûts liés à l’IA générative.
Pourquoi la facture IA est imprévisible par nature
Comprendre le problème FinOps de l’IA, c’est d’abord comprendre ce qu’est un LLM sous le capot. Un grand modèle de langage n’est pas une base de données. C’est une machine probabiliste et non déterministe à chaque appel, c’est un nouveau tirage au sort. Le modèle ne « sait » pas que le ciel est bleu : il sait que statistiquement, après la séquence « le ciel est », le mot « bleu » arrive en tête de probabilité.
Conséquence directe sur la facturation : vous êtes facturé au token, et surtout au token de sortie le seul que vous ne pouvez pas contrôler. C’est comme un taxi où vous connaissez le prix au kilomètre, mais où c’est le chauffeur qui choisit le chemin.
Et dans un contexte agentique, ce caractère imprévisible se propage. Un agent qui enchaîne les tâches pour atteindre un objectif peut multiplier les appels au LLM, chaque appel renvoyant l’intégralité du contexte initial. Trois invocations aujourd’hui, six demain sans aucune visibilité.
L’euphorie précède toujours la facture
Le phénomène est bien documenté. Les fournisseurs IA ont longtemps absorbé les coûts pour capter les utilisateurs et créer de la dépendance. Ils commencent maintenant à monétiser. Et pendant ce temps, l’effet rebond joue à plein : plus c’est abordable, plus on crée d’agents, plus on consomme.
Résultat : même si le coût par token baisse avec les nouvelles architectures et les nouveaux GPU, la facture globale augmente dans les entreprises. Microsoft a mis fin à certaines licences Cloud Code. Amazon a tenté de noter ses développeurs sur leur consommation avant de découvrir que certains optimisaient simplement à l’envers, gaspillant des tokens ou créant des agents sans valeur réelle.
La rentabilité des grands fournisseurs IA reste par ailleurs une question ouverte. Environ 1 900 milliards de dollars investis pour 970 milliards de revenus estimés il y a un trillion de dollars « dans la nature ». Les prix peuvent monter comme ils peuvent être restructurés du jour au lendemain. Baser des pans critiques de son modèle business sur des solutions dont vous ne maîtrisez pas les variables de coût, c’est un risque réel.
Les trois leviers pour reprendre le contrôle
Treez propose une approche en entonnoir : pour chaque use case, on descend les niveaux jusqu’à trouver la solution la plus maîtrisée possible.
Levier 1 Sortir le LLM du chemin critique
Le premier réflexe à avoir en phase d’engineering : est-ce que le LLM doit absolument faire partie du run ? Autrement dit, peut-on utiliser un modèle puissant une seule fois pour construire une solution qui fonctionne ensuite sans lui ?
Treez l’a fait concrètement pour un client retail qui avait besoin de migrer 13 000 rapports Google Data Studio vers Power BI en un trimestre. Passer chaque rapport dans un frontier model ? Mort au berceau 300 appels suffisent à épuiser le budget. La solution retenue : utiliser Claude 3.5 (alors en preview) pour construire un programme Python capable de traduire les rapports de façon déterministe, sans appel au modèle en production. La phase d’engineering a coûté plus cher. Le run, lui, ne consomme plus aucun token. Le projet a pu aboutir. Sans cette approche, il n’aurait pas existé.
Levier 2 Passer sur un modèle local
Si le LLM doit rester dans le run, la deuxième question est : doit-il forcément être un service externe ? Des modèles open weight Gemma, DeepSeek, Mistral peuvent être déployés sur une infrastructure locale via des runtimes comme Ollama ou LM Studio. On paie l’électricité et le matériel, plus les appels. Le coût devient fixe, indépendant des fluctuations tarifaires des fournisseurs.
Open weight ne signifie pas modèle dégradé certains sont proches des frontier models en performance. Le point critique : le hardware. Il faut soit investir, soit trouver un partenaire qui fournit l’infrastructure.
Levier 3 Bien choisir son modèle as a service
Si le déploiement local n’est pas envisageable, il reste une marge de manœuvre importante : ne pas partir par défaut sur le dernier frontier model disponible. Les small models spécialisés peuvent être 20 à 50 fois moins chers par token. Sur un volume d’un million de conversations par mois, on peut passer d’une facture entre 15 000 et 75 000 dollars à 150 à 800 dollars. La méthode : définir précisément le périmètre, benchmarker, spécialiser si nécessaire et ne jamais sacrifier la qualité. Une mauvaise réponse bon marché coûte toujours trop cher.
Le routing : arbitrer dynamiquement en production
Ces leviers ne sont pas mutuellement exclusifs. Il est possible d’implémenter du routing en production c’est-à-dire orienter chaque prompt vers le modèle le plus adapté en temps réel selon sa complexité. Des solutions comme OpenRouter ou LiteLLM, ou les services natifs de Microsoft Foundry et Databricks Bedrock, permettent de mettre en place ce type d’architecture.
C’est la solution qu’Uber a finalement adoptée pour stabiliser sa facture après le dépassement de budget : les prompts complexes vont vers le frontier model, les cas simples sont routés vers des modèles open weight locaux ou des petits modèles spécialisés, nettement moins coûteux.
La gouvernance : le point de départ de toute stratégie FinOps
Tous ces leviers techniques ne servent à rien sans une couche de gouvernance. La règle d’or : tout fournisseur qui ne permet pas de mesurer précisément la consommation de tokens est à éviter c’est lui confier les clés du compte en banque.
La gouvernance, c’est aussi la capacité à mettre en face de la dépense la valeur produite. Dépenser 5 millions d’euros par mois en IA peut être parfaitement justifié si ça génère 100 millions d’économies. Ce qui ne l’est jamais, c’est de dépenser sans savoir pourquoi ni combien.
L’erreur classique : laisser tout le monde accéder à toutes les solutions disponibles. C’est là que les coûts explosent. La centralisation des appels via une gateway IA, la mise en place d’observabilité dès le départ, et la qualification sérieuse des use cases avant de scaler voilà le socle d’une stratégie FinOps IA qui tient dans la durée.
Si vous souhaitez parler FinOps IA & Data, contactez nous