FinOps : reprendre la main sur le coût IA & Cloud sans plomber la perf

Le diagnostic : des coûts qui s’installent “par défaut”

L’infrastructure à la demande a, en dix ans, transformé la capacité d’exécution… et banalisé les dérapages. Dans la plupart des audits, on retrouve la même signature : des ressources orphelines qu’aucune équipe ne revendique, des tags incomplets qui empêchent d’assigner un propriétaire, des environnements de tests qui tournent la nuit « pour demain », et des volumes historiques qui s’accumulent dans des classes de stockage inadaptées. La poussée IA accentue ce biais : quand l’inférence entre en scène, la gravité se déplace vers le GPU. Sans mesures dédiées — taux d’occupation, part du cache, efficacité du batching — la facture croît plus vite que l’usage métier qu’elle est censée servir.

Ce que les organisations qui s’en sortent font différemment

Les entreprises qui reprennent la main traitent le coût comme une donnée produit : observable, attribuable, actionnable. Concrètement, elles verrouillent le langage commun de l’allocation — owner, équipe, produit, environnement, centre de coût — et font appliquer ces balises par des politiques d’organisation. Pas de tag, pas de déploiement. L’objectif de 95 % de couverture n’est pas un totem : c’est la condition pour que les tableaux de bord cessent d’être décoratifs et que le showback — l’exposition des coûts aux équipes — devienne un outil de décision. Le chargeback, lui, relève d’une politique comptable ; mais la transparence est non négociable, car elle change le comportement avant même de changer la facture.

Le deuxième différenciateur est opérationnel : l’optimisation qui bloque. Droitsizing piloté par les percentiles d’usage, arrêts planifiés des environnements non‑prod, et un partage des rôles clair entre engagements et opportunisme : les Savings Plans/RI pour la base stable, les instances Spot/Preemptible pour le burst. Les gains annoncés par les fournisseurs — 65 % sur Azure, 72 % sur AWS pour les Savings Plans — ne deviennent réels que lorsqu’ils sont intégrés dans un cycle CI/CD avec des seuils d’acceptation. À défaut, la discipline s’effrite en quelques sprints.

Le nerf de la guerre en IA : servir plus, payer moins

Avec l’IA, la tentation est de regarder d’abord le tarif GPU. C’est une erreur d’optique. Le coût d’inférence se joue en amont, au choix du modèle et au dessin du chemin critique. Les acteurs économes commencent par la sobriété : distiller ou fine‑tuner un modèle 8–13B pour la majorité des requêtes, et n’escalader vers un géant que lorsque l’incertitude le justifie. Ils travaillent ensuite le service : lecontinuous batching — fourni nativement par vLLM — remplit la carte sans casser les SLA, pendant que la quantification (int8/FP8), les réponses structurées et le partage de KV‑cache réduisent le volume de tokens. Enfin, ils mutualisent intelligemment : activer MIG sur A100/H100 permet de partitionner une carte en tranches isolées, garantissant des SLO par workload au lieu d’un « qui peut le plus peut le moins ».

Le tout n’a de sens qu’avec des compteurs crédibles. Dans les traces OpenTelemetry, on attend, en production, les attributs qui rendent un incident explicable : modèle, fournisseur, tokens en entrée et en sortie, coût par requête, taux de cache, et un témoin d’utilisation GPU. Ce sont ces chiffres, davantage que des captures de facture en fin de mois, qui permettent de relier la technique au ROI.

L’outillage : choisir ce qui prouve, pas ce qui impressionne

Le socle efficace reste sobre. Les explorateurs de coûts natifs donnent la trajectoire et les anomalies. Les « recommenders » guident le droitsizing et les engagements, à condition d’être recadrés par des seuils maison. L’observabilité relie tout le monde : les mêmes attributs de coût remontent jusqu’aux tableaux de bord des équipes, service par service, produit par produit. Côté Kubernetes et multi‑cloud, Kubecost et OpenCost apportent l’allocation et la visibilité GPU. Les prévisions sérieuses s’adossent aux playbooks FinOps — TCO, maturité, KPIs — et à des baselines d’usage, pas à un tableur isolé dont personne ne tient la mémoire.

Trois décisions à prendre cette semaine

Fixez la grammaire d’allocation. Standardisez les tags — owner, produit, centre de coût, environnement — et faites‑les appliquer par des policies. Publiez chaque semaine la couverture de tagging et traitez les écarts comme des incidents de qualité.

Rendez l’optimisation automatique. Activez le droitsizing et les arrêts planifiés dans la CI/CD ; couvrez la base par des engagements et réservez les Spots pour les pics. Mesurez mois par mois l’utilisation et l’adéquation des engagements.

Faites parler vos traces IA. Ajoutez tokens, coût, cache_hit_ratio et gpu_utilization aux spans ; déployez vLLM pour le batching et MIG là où la charge est morcelée. Vous aurez, à la fois, un plan d’optimisation et une défense en cas d’arbitrage budgétaire.

Conclusion

Le FinOps n’est pas l’art de payer moins cher : c’est la capacité à prouver que chaque euro sert une unité de valeur métier. Côté cloud « généraliste », le chantier passe par l’allocation propre et des engagements tenus. Côté IA, par la sobriété d’inférence : modèles adaptés, batching, cache, MIG, et des métriques qui relient GPU et ROI. Bien mené, ce triptyque — visibilité, optimisation, gouvernance — transforme un centre de coût en avantage d’exécution.