FinOps 2026 : réduire sa facture cloud sans dégrader le service

Une facture cloud ne dérape presque jamais à cause d’une décision unique. Elle dérape par accumulation : une instance dimensionnée large « on ajustera plus tard », un environnement de recette monté pour une démonstration et jamais éteint, un bucket qui garde tout parce que personne n’a écrit de règle de rétention. Chaque ligne est défendable isolément. C’est la somme qui ne l’est pas.

Le cloud a inversé la mécanique d’achat : un développeur engage plusieurs milliers d’euros par an en trois lignes de Terraform, sans que personne n’ait à signer. C’est ce qui fait la vitesse du modèle, et ce qui rend le contrôle a posteriori indispensable. Le FinOps remet la facture dans la boucle d’ingénierie : mesurer, attribuer, décider, recommencer. Ce n’est pas une coupe budgétaire pilotée par la direction financière, c’est une contrainte d’architecture au même titre que la latence.

Deux missions structurent ce que nous écrivons ici. Chez Neuflize OBC, le backend de l’application bancaire mobile a été migré vers Azure AKS, puis étendu au Paiement Instantané et à la Vérification du Bénéficiaire. Le sujet réel n’était pas la migration : c’était de tenir le règlement sans doubler la facture. Résultat : −52 % de coûts cloud sur le périmètre bancaire mobile, à service constant. Pour une startup SaaS en série A (sous NDA) — douze personnes, une facture AWS qui doublait tous les six mois et un board qui posait des questions — deux semaines d’audit ont produit −61 % de facture, un runway allongé de cinq mois et un coût par client divisé par 2,6, sans régression fonctionnelle.

À peu près tout ce que nous trouvons en audit entre dans trois catégories, qui ne se traitent ni avec les mêmes outils ni dans les mêmes délais.

1. Ce que vous payez et n’utilisez pas

Ressources allumées sans usage : environnements de test qui tournent la nuit et le week-end, répartiteurs de charge sans backend, adresses IP réservées et non attachées, volumes détachés, snapshots orphelins. C’est le gisement le plus rapide : la suppression ne demande aucun arbitrage technique, seulement de savoir à qui appartient la ressource.

2. Ce que vous utilisez mal

Ressources utiles, mais surdimensionnées ou mal choisies : huit vCPU pour une charge qui en consomme un, une base managée provisionnée pour un pic annuel, des requests Kubernetes fixées « au cas où », des données maintenues en classe chaude depuis trois ans. Ici, il faut mesurer avant de toucher.

3. Ce que vous payez au mauvais tarif

Charge légitime, dimensionnement correct, mais payée au tarif à la demande alors qu’elle tourne en continu depuis deux ans, ou exécutée sur une famille d’instances plus coûteuse que nécessaire. Aucun changement d’architecture n’est requis : c’est un sujet d’achat, pas d’ingénierie.

S’y ajoutent les coûts que personne ne regarde parce qu’ils ne portent pas de nom de serveur : transfert sortant, trafic entre zones de disponibilité facturé dans les deux sens, passerelles NAT facturées à l’heure et au gigaoctet traité, ingestion de logs.

Deux semaines : c’est la durée d’un audit FinOps utile sur un compte ou un petit ensemble de comptes. Au-delà, on ne trouve pas beaucoup plus ; en deçà, on rend des recommandations non chiffrées.

Jours 1 à 3 — établir la vérité de la facture

• Export détaillé de la facturation (Cost and Usage Report sur AWS, Cost Management sur Azure) sur douze mois et non trois : il faut voir la saisonnalité et la date exacte des décrochages.
• Décomposition par service, compte, environnement et équipe. La question qui fait mal : quelle part de la facture n’est rattachée à aucun propriétaire ?
• Reconstruction de la courbe : à quelle mise en production, à quel nouveau client correspond chaque marche d’escalier ?

Jours 4 à 7 — mesurer avant d’optimiser

• Relevé de l’utilisation réelle sur deux semaines : CPU, mémoire, IOPS, débit réseau, lus au percentile 95 et non en moyenne.
• Sur Kubernetes : écart entre requests, limits et consommation observée, par namespace et par déploiement.
• Inventaire des ressources orphelines et des environnements sans trafic applicatif.

Jours 8 à 12 — appliquer, dans cet ordre

1. Supprimer ce qui ne sert pas.
2. Éteindre ce qui n’a pas besoin de tourner en continu.
3. Redimensionner et changer de famille d’instances.
4. Seulement ensuite : acheter des engagements sur la consommation restante.

Cet ordre n’est pas cosmétique : un engagement souscrit avant le right-sizing verrouille le gaspillage pour un à trois ans.

Jours 13 et 14 — rendre la mesure permanente

Un audit qui se termine par un rapport se périme en un trimestre. Il doit se terminer par un tableau de bord ouvert chaque semaine, une politique de tags appliquée dans le code d’infrastructure, des budgets et des alertes. Sur la mission série A, ce tableau de bord a été repris en interne : c’est le critère de fin de mission, pas le pourcentage.

Le right-sizing est le levier le moins spectaculaire et le plus rentable. Trois règles suffisent.

• Mesurer au percentile, pas en moyenne. Une instance à 12 % de CPU moyen est peut-être correctement dimensionnée si elle monte à 80 % pendant la clôture mensuelle.
• Descendre d’un cran, observer, recommencer. Diviser par deux d’un coup produit des incidents et détruit la confiance dans la démarche.
• Changer d’axe quand la charge est déséquilibrée. Beaucoup de services sont limités par la mémoire et surpayés en CPU : une famille optimisée mémoire coûte souvent moins cher qu’une montée en gamme sur une famille généraliste.

Le cas ARM et Graviton

Sur AWS, les instances Graviton (processeurs ARM conçus par AWS) sont proposées à un tarif horaire inférieur à celui de leur équivalent x86 à taille comparable ; des familles ARM existent aussi chez les autres fournisseurs. Le gain de performance, lui, dépend de la charge : il se mesure, il ne se postule pas.

Le passage est indolore pour les langages qui s’exécutent sur une machine virtuelle ou un interpréteur — Java, Go, Node.js, Python — dès lors que vos images de conteneur sont construites en multi-architecture. Il devient coûteux dès qu’une dépendance native ou un agent tiers n’existe qu’en x86. La règle : migrer d’abord un service peu critique, comparer latence et débit à charge identique, puis étendre. Graviton fait partie des leviers appliqués sur la mission série A.

Kubernetes : les requests sont la vraie facture

Sur un cluster, ce n’est pas la consommation qui dimensionne les nœuds, ce sont les requests : un déploiement qui demande deux CPU et en consomme 0,2 réserve pour rien la place de plusieurs autres pods. Alignez-les sur la consommation observée au p95 — le Vertical Pod Autoscaler en mode recommandation produit les chiffres sans rien modifier — puis laissez la mise à l’échelle des nœuds restituer la capacité libérée. Sans cette seconde étape, vous avez optimisé les pods et payé les mêmes nœuds.

Une fois le périmètre nettoyé, il reste une base de consommation stable, qui tourne en permanence. La payer au tarif à la demande est un choix — rarement conscient.

Trois principes d’usage :

• Couvrir le socle, pas le pic. Engagez-vous sur le minimum observé sur douze mois, jamais sur la moyenne. La part variable reste à la demande ou en Spot.
• Commencer par un an sans paiement d’avance. Les remises maximales annoncées supposent trois ans et un paiement intégral en début de période : c’est un arbitrage de trésorerie autant qu’une décision technique. Si votre architecture bougera dans l’année, l’engagement court capture déjà une part importante du gain.
• Suivre deux indicateurs, pas un. Le taux de couverture — quelle part de la consommation est sous engagement — et le taux d’utilisation — quelle part de l’engagement est consommée. Une couverture élevée avec une utilisation faible signifie que vous payez du vide.

Enfin, les engagements expirent : un renouvellement automatique sans revue reconduit l’architecture d’il y a trois ans.

Le stockage objet coûte peu au gigaoctet, ce qui le rend invisible — jusqu’au jour où il pèse une part significative de la facture parce que rien n’a jamais été supprimé.

• Écrire des règles de cycle de vie. Sur S3 : transition vers une classe d’accès peu fréquent après quelques semaines, vers une classe archive au-delà, expiration au terme de la rétention légale ou métier. L’équivalent existe sur Azure Blob Storage et sur Cloud Storage.
• Vérifier ce que vous archivez. Les classes archive facturent la restauration et imposent une durée minimale de stockage : pour des données relues régulièrement, elles reviennent plus cher que la classe standard.
• Nettoyer les versions et les envois incomplets. Le versionnage sans règle d’expiration des versions non courantes conserve indéfiniment chaque écriture, et les envois multipart interrompus restent facturés sans apparaître dans la liste des objets.
• Traiter les snapshots et les logs comme du stockage. Une sauvegarde quotidienne sans rétention finit par coûter plus cher que les volumes qu’elle protège, et une rétention infinie sur une plateforme facturée à l’ingestion est un choix, pas une valeur par défaut.

Le cycle de vie S3 fait partie des cinq leviers appliqués sur la mission série A : il ne demande pas une ligne de code applicatif, seulement une décision de rétention.

Un environnement fantôme est un environnement complet — calcul, base, stockage, réseau — qui tourne, qui coûte, et dont plus personne ne se sert. Sur la mission série A, trois environnements de ce type ont été supprimés pendant l’audit. Ils apparaissent toujours de la même façon : une recette montée pour une démonstration commerciale, une plateforme de tests de charge dont la campagne s’est terminée il y a dix-huit mois, une copie de production créée le temps d’une migration achevée depuis.

Les signaux qui les trahissent sont cumulatifs : aucun trafic applicatif sur le répartiteur de charge, aucune connexion à la base depuis plusieurs semaines, aucun déploiement depuis le dernier trimestre, aucun tag de propriétaire, aucune réponse quand on pose la question à l’équipe.

La suppression suit une règle simple : éteindre avant de supprimer. On arrête, on attend deux semaines, on prend un snapshot des données, puis on supprime. Ce qui se reconstruit en une heure avec du code d’infrastructure n’a aucune raison de rester allumé.

La prévention vaut mieux que la chasse : date d’expiration obligatoire en tag sur tout environnement hors production, et extinction programmée la nuit et le week-end par défaut.

Un audit produit un décrochage sur la courbe. Sans pratique continue, elle repart avec la même pente un trimestre plus tard, parce que rien n’a changé dans la façon de décider. Le cadre de la FinOps Foundation décrit trois temps qui tournent en boucle : Inform (mesurer et attribuer), Optimize (agir), Operate (ancrer dans le fonctionnement courant). Deux choses font la différence en pratique.

Le coût unitaire plutôt que le montant absolu

Une facture qui augmente n’est pas un problème si le nombre de clients augmente plus vite. Le seul indicateur qui permet un arbitrage est le coût rapporté à une unité métier : coût par client, par transaction, par dossier traité. C’est ce que traduit le « coût par client divisé par 2,6 » de la mission série A : la facture a baissé, mais surtout, servir un client de plus coûte désormais 2,6 fois moins. C’est cette métrique-là qui se défend devant un comité d’investissement.

Showback avant chargeback

Le showback montre à chaque équipe ce qu’elle consomme, sans refacturation ; le chargeback impute la dépense sur son budget. Commencez par le premier : une part importante des économies vient du simple fait qu’une équipe voie son chiffre chaque semaine. Le chargeback n’a de sens qu’une fois l’attribution fiable, sinon vous facturez des erreurs de tags.

Les indicateurs à tenir

• Coût unitaire métier, en tendance mensuelle
• Part de la facture non attribuée à un propriétaire
• Taux de couverture et taux d’utilisation des engagements
• Rapport entre le coût hors production et le coût de production

Enfin, le coût doit entrer dans la décision d’architecture au moment où elle se prend. Une estimation affichée dans la revue de code d’infrastructure change plus de comportements qu’un rapport trimestriel.

La tentation est d’acheter une plateforme avant d’avoir écrit une politique de tags. Branché sur des données non attribuées, un outil produit de beaux graphiques dont personne ne peut rien faire.

Les outils natifs couvrent l’essentiel du besoin pour la grande majorité des organisations. Une plateforme tierce se justifie en contexte réellement multi-cloud, lorsqu’il faut refacturer à des entités juridiques distinctes, ou quand la répartition des coûts d’un cluster partagé devient un sujet politique. Dans tous les cas, le tableau de bord doit vivre là où les équipes regardent déjà.

• Acheter les engagements avant le right-sizing. L’erreur la plus coûteuse, parce qu’elle est irréversible pendant un à trois ans.
• Décréter le tagging sans l’appliquer. Une politique de tags qui n’est contrôlée ni dans le code d’infrastructure ni dans le pipeline reste une intention. Sans attribution, aucune conversation FinOps n’est possible.
• Ne regarder que le montant total. Sans coût unitaire, impossible de distinguer une croissance saine d’une dérive.
• Optimiser à service dégradé. Une baisse obtenue au prix d’incidents sera annulée dès le premier post-mortem.
• Oublier tout ce qui n’est pas du calcul. Transfert de données, passerelles NAT, ingestion de logs, licences facturées à l’instance n’apparaissent pas dans une revue de dimensionnement.
• Faire un audit et refermer le sujet. Sans revue mensuelle ni propriétaire, la courbe reprend sa pente initiale.

Si vous ne devez faire qu’une chose cette semaine : sortez la facture détaillée des douze derniers mois, décomposez-la par environnement et par équipe, et mesurez la part que vous ne savez rattacher à personne. Ce chiffre décide de la suite.

Ensuite, appliquez l’ordre : supprimer, éteindre, redimensionner, puis engager.

Nous menons ces audits en deux semaines, avec des recommandations chiffrées et un tableau de bord repris par vos équipes en fin de mission. Le détail de l’approche est sur la page FinOps, et les deux missions citées ici figurent parmi nos réalisations. Si la trajectoire de votre facture est devenue un sujet de comité, écrivez-nous : quarante-cinq minutes suffisent pour dire si un audit est justifié — ou si le problème est ailleurs.