Les cas ci-dessous sont réels. Nous les avons anonymisés : ni client, ni secteur, ni date.
Cas 1 : une application livrée sans scoring session
Quelques semaines après la mise en production, le responsable de l'application découvre sa facture. Deux constats : les environnements sandbox, développement et test consomment autant que la production, et une base SQL représente à elle seule 80 % du coût.
Ce qui a été fait : suppression de la sandbox, base réduite ou désactivée dans chaque environnement hors prod. Résultat : −62 % sur la facture de l'application, avec des actions simples.
Cas 2 : une nouvelle fonctionnalité, pas de réestimation
Une équipe applicative contacte l'équipe FinOps : elle pense à une erreur de facturation. Ses coûts ont doublé en six mois. Il n'y a pas d'erreur : une nouvelle fonctionnalité a fait grimper la consommation, et personne n'a réestimé le coût après sa mise en place.
Cas 3 : une migration de data lake, et aucune alerte
L'équipe FinOps appelle en urgence le responsable d'une application : ses coûts ont été multipliés par 40. Il n'était pas au courant. En cause, une migration vers une nouvelle génération de data lake, mal configurée, et aucune budget alert sur le périmètre.
Cas 4 : des logs activés en non-prod
L'équipe de maintenance active des logs détaillés sur les environnements de test et de préproduction. En deux semaines, les coûts sont multipliés par 6. L'équipe qui exploite l'application ne s'en aperçoit qu'à la deuxième alerte.
Ce qui a été fait : désactivation des logs inutiles, règle de validation des changements de configuration. Environ 240 k€ par an évités.
Cas 5 : des pipelines de données bloqués
Un bug dans une fonction de traitement bloque des pipelines Data Factory, qui tournent en boucle. Le coût journalier grimpe jour après jour. Sur une autre application, des déclenchements beaucoup trop fréquents ont imposé de revoir la conception avant la mise en production.
Ce que ces cas ont en commun
| Cause | Parade |
|---|---|
| Pas de revue avant la mise en production | Scoring session au passage en run |
| Un changement non réestimé | Réestimation à chaque évolution importante, contrôle quelques jours après |
| Personne n'est prévenu | Budget alert par périmètre, envoyée au responsable de l'application |
| Une alerte mensuelle, trop tardive | Monitoring quotidien des anomalies et du forecast |
| La non-prod n'est pas surveillée | Mêmes alertes qu'en prod, validation des changements de configuration |
Un dernier point, souvent mal compris : une budget alert prévient mais ne coupe rien. Elle ne sert que si quelqu'un la reçoit, sait quoi regarder et peut agir dans la journée. C'est pourquoi nous l'associons toujours à un circuit de réaction : détection, alerte, analyse, correction, puis suivi en SteerCo.