La facture que personne ne savait expliquer
L'an dernier, j'ai vu une équipe fintech ouvrir sa facture Anthropic du mois et se taire d'un coup. Le montant avait triplé en un trimestre, personne n'avait livré quoi que ce soit qu'on aurait qualifié de coûteux, et aucun d'eux ne savait dire où l'argent était parti. La scène m'a semblé familière, parce que j'avais déjà vécu exactement la même réunion en 2014. La seule différence, c'est qu'à l'époque la ligne qui surprenait tout le monde disait AWS, pas tokens.
La dépense IA en 2026 se comporte comme la dépense cloud d'il y a dix ans. Elle grimpe vite, n'appartient vraiment à personne, et se justifie par le potentiel au lieu de se mesurer au retour. La discipline qui a fini par dompter les factures cloud, le FinOps, est aujourd'hui braquée sur les tokens, les GPU et l'inférence. Et la plupart des entreprises s'y mettent des années trop tard.
Le scénario ne change presque jamais. Une équipe livre une fonctionnalité IA, l'usage grimpe, la facture tombe comme une douche froide, et quelqu'un finit par demander quels workflows méritent vraiment ce qu'ils coûtent. C'est là que commence le FinOps de l'IA.
Pourquoi la facture de tokens dérive si discrètement
Le piège, c'est que chaque appel pris isolément paraît trop dérisoire pour qu'on s'en soucie. Une complétion coûte des fractions de centime, alors personne ne la surveille, jusqu'à ce que des milliers d'appels par minute, des fenêtres de contexte gonflées et des agents bavards finissent par former un chiffre sérieux.
L'enquête annuelle de la FinOps Foundation le confirme : la quasi-totalité de ses praticiens gèrent désormais la dépense IA, contre environ un tiers il y a deux ans. La courbe ressemble furieusement aux débuts du cloud, quand la commodité du à la demande dépassait en silence tous les budgets fixés.
Un coût que vous ne voyez pas par workflow est un coût que vous ne contrôlez pas.
Et le coupable est rarement une requête hors de prix. C'est du volume que personne n'a attribué. Un chatbot qui renvoie tout l'historique de conversation à chaque tour. Un agent qui relit un PDF de politique de cinquante pages à chaque requête. Un batch nocturne qui fait tourner GPT-4o sur des lignes où une expression régulière aurait suffi. Aucun de ces appels n'est faux en soi, mais multipliez-les par le trafic de production et ils deviennent discrètement une ligne à cinq chiffres sans nom attaché. C'est exactement la leçon qui se cache derrière le vrai coût de l'IA au-delà des tokens : le prix du modèle n'est que la partie émergée.
Les leviers qui font vraiment bouger le chiffre
La bonne nouvelle, c'est que réduire la dépense IA n'oblige presque jamais à réduire la qualité. Quatre leviers d'ingénierie font le gros du travail : mettre en cache les réponses qui reviennent, regrouper les requêtes qui ne sont pas urgentes, router les tâches faciles vers de plus petits modèles, et élaguer le contexte qui ajoute des tokens sans ajouter de réponse.
Imaginez un assistant support qui traite les mêmes quarante questions à longueur de journée. Sans cache, il régénère chaque réponse de zéro. Activez le cache de prompt, qu'Anthropic comme OpenAI facturent avec une forte décote, et envoyez les cas simples vers un Claude Haiku ou un GPT-4o-mini. Le même workflow peut coûter une fraction de l'original tout en restant identique pour la personne en face.
Le cadre de la FinOps Foundation(lien externe, nouvel onglet) décrit cela comme crawl, walk, run : d'abord la visibilité, ensuite l'attribution de la responsabilité, enfin l'optimisation continue. L'ordre est tout l'enjeu. Optimiser avant de voir réellement sa dépense, c'est deviner avec des étapes en plus.
L'attribution est plus dure que l'optimisation
La plupart des problèmes de coût IA sont des problèmes de responsabilité déguisés en problèmes techniques. Si aucune équipe ne porte la facture d'une fonctionnalité, aucune équipe n'a de raison de la rendre efficace. L'attribution, c'est-à-dire taguer la dépense à un produit, une équipe ou un workflow, est ce qui transforme un total vague en une pile de décisions que quelqu'un peut assumer.
C'est la même maturité opérationnelle qu'exige déjà l'infrastructure de production, celle que je creuse dans les leçons Kubernetes en production : on ne gère pas ce qu'on ne sait pas attribuer. Des outils comme Datadog LLM Observability ou les tags d'AWS Cost Explorer rendent l'exercice mécanique dès que quelqu'un décide de s'y mettre. Une fois les unit economics en main, comme le coût par requête, par client, par ticket résolu(lien externe, nouvel onglet), l'IA cesse d'être un surcoût mystérieux et devient une entrée pilotée que l'on peut raisonner.
Mettez la dépense dans la conversation produit
Le coût IA appartient à la revue produit, pas seulement à la revue financière. Quand un product owner voit le coût par résultat réussi posé juste à côté de l'adoption et de la qualité, les arbitrages deviennent explicites au lieu d'accidentels.
Ce seul changement rebranche les comportements. Une équipe qui sait qu'une fonctionnalité coûte plus à faire tourner qu'elle ne rapporte va la repenser ou l'arrêter. Une équipe qui pilote à l'aveugle mettra tranquillement la perte à l'échelle. Traiter la dépense comme une métrique de premier rang, c'est ainsi que les fonctionnalités IA gagnent leur empreinte opérationnelle au lieu de grignoter la marge de l'intérieur.
Par où commencer
Cette semaine, choisissez un seul workflow IA et taguez-le avec son vrai coût par résultat réussi. Le chiffre justifiera la fonctionnalité d'emblée, ou lancera une conversation que vous auriez dû avoir il y a des mois. Dans les deux cas, vous aurez fait passer cette dépense d'invisible à pilotée, ce qui, comme pour le cloud, est tout le jeu.
