Catégorie : FinOps

FOCUS 1.4 est sorti le 4 juin 2026, à la conférence FinOps X. Jusqu’ici, rien d’alarmant : la spec passe en revue mineure tous les six mois environ depuis 2023. Sauf que cette fois, une colonne change de format au point de casser les requêtes qui la consomment. Si ton pipeline FinOps s’appuie sur ContractApplied, ça vaut le coup de vérifier avant de mettre à jour ton connecteur.

Ce que FOCUS ajoute avec la 1.4

FOCUS (FinOps Open Cost and Usage Specification) normalise la façon dont les fournisseurs cloud décrivent une ligne de facturation : même structure de colonnes chez AWS, Azure, GCP ou OCI, pour que tes tableaux de bord FinOps n’aient pas à gérer un mapping différent par fournisseur. Les deux précédentes versions avaient chacune résolu un problème précis : la 1.2 a normalisé l’intégration dans Azure Cost Management (on en parlait ici), la 1.3 a réglé le casse-tête de la répartition des coûts partagés entre équipes (voir cet article). La 1.4, elle, s’attaque à un problème différent : faire coller les données d’usage avec la facture réellement reçue.

Au total, le changelog liste 47 nouvelles colonnes. La plupart arrivent avec deux datasets inédits : BillingPeriod et InvoiceDetail.

InvoiceDetail et BillingPeriod : combler le trou entre usage et facture

Avant la 1.4, FOCUS décrivait bien l’usage (CostAndUsage) mais ne modélisait pas la facture elle-même — numéro de facture, date d’émission, date d’échéance, numéro de bon de commande. InvoiceDetail ajoute une vingtaine de colonnes pour ça : InvoiceId, InvoiceIssueDate, PaymentDueDate, PurchaseOrderNumber, ReferenceInvoiceId, entre autres. BillingPeriod complète avec le cycle de facturation (BillingPeriodStart, BillingPeriodEnd, BillingPeriodStatus).

Concrètement, ça permet enfin de faire le lien entre « ce que dit l’usage mesuré » et « ce qui apparaît réellement sur la facture payable » — la fameuse réconciliation facture, jusque-là bricolée à la main ou absente des exports FinOps. La colonne InvoiceId, qui était seulement recommandée en 1.3, devient d’ailleurs MUST (obligatoire) dès que l’émetteur de facture supporte les factures payables.

ContractCommitment s’enrichit pour les programmes d’engagement

Une quinzaine de colonnes s’ajoutent à ContractCommitment, dont ContractCommitmentApplicability, ContractCommitmentModel et ContractCommitmentPaymentModel. C’est la fonctionnalité Commitment Program Eligibility Details : tu peux désormais savoir si une charge est éligible à un programme de remise par engagement (Reserved Instances, Savings Plans, CUD…) sans deviner à partir du type de ressource.

Le breaking change : ContractApplied passe en objet JSON structuré

C’est le point qui mérite une vraie attention avant de migrer. La colonne ContractApplied, qui relie une charge à un ou plusieurs engagements contractuels, voit son format JSON révisé en 1.4. Le format actuel impose une clé racine Elements (un tableau), avec des champs typés strictement :

{
  "Elements": [
    {
      "ContractId": "12345",
      "ContractCommitmentId": "23456",
      "ContractCommitmentAppliedCost": 500000.00
    },
    {
      "ContractId": "12345",
      "ContractCommitmentId": "34567",
      "ContractCommitmentAppliedQuantity": 10000.00,
      "ContractCommitmentAppliedUnit": "compute_hours"
    }
  ]
}

ContractCommitmentAppliedCost est conditionnelle (requise si quantité et unité ne sont pas fournies), et doit être exprimée dans la devise de facturation. Les clés personnalisées restent possibles, mais doivent être préfixées x_ en PascalCase (x_MyCustomKey) — sinon un parseur strict les rejettera.

Si tes requêtes (dbt, SQL, Python) parsent cette colonne en s’attendant à l’ancienne structure, elles vont silencieusement renvoyer des valeurs vides ou lever une exception selon ton parseur JSON. Teste sur un échantillon de factures avant de basculer ton pipeline de prod, pas après.

BilledCost et EffectiveCost : des règles nettement plus strictes

Le changelog qualifie la révision d’EffectiveCost de « Heavily revised » : les règles sur les covering charges (quand un engagement couvre une charge) et les validations croisées entre lignes sont désormais détaillées, là où la 1.3 restait plus vague. BilledCost gagne lui aussi des exigences élargies — ajustements de prix, charges couvertes, entités non facturantes — et une tolérance d’écart d’arrondi est introduite spécifiquement pour la réconciliation de facture (deux systèmes qui arrondissent différemment ne doivent plus produire un écart bloquant).

Autre durcissement notable : le format des devises doit désormais respecter strictement ISO 4217:2015 (codes à trois lettres), l’exception qui tolérait les devises virtuelles (tokens, crédits propriétaires) a été retirée. Si un de tes fournisseurs facture en « crédits » plutôt qu’en devise réelle, ça ne passera plus la validation telle quelle.

Colonnes dépréciées : adieu ProviderName et PublisherName

ProviderName et PublisherName, déjà dépréciées en 1.3, sont officiellement supprimées en 1.4. Le changelog renvoie vers la section Participating Entity Identification pour choisir la colonne de remplacement adaptée à ton cas (il y en a plusieurs selon qu’il s’agit du fournisseur direct, d’un revendeur ou d’une marketplace). Si un tableau de bord chez toi filtre encore sur ProviderName, c’est le moment de migrer avant que le champ ne disparaisse purement et simplement de tes exports.

Faut-il migrer tout de suite ?

Ça dépend de où tu en es. Si tu n’as pas encore adopté FOCUS du tout, pars directement sur la 1.4 — aucune raison de passer par la 1.2 ou la 1.3 pour un déploiement neuf, la compatibilité ascendante existe pour la lecture mais pas l’inverse. Si tu es déjà sur la 1.3 avec un pipeline de réconciliation construit à la main (exports Cost Management + factures PDF parsées à côté), la 1.4 remplace une bonne partie de ce bricolage par des colonnes natives — ça vaut l’effort de migration. Si ton usage de FOCUS se limite à des dashboards de répartition de coûts sans lien avec la facturation, l’urgence est moindre : les nouvelles colonnes ne te concernent pas directement, seul le changement de ContractApplied (si tu l’utilises) demande une revue.

Côté adoption par les fournisseurs : Azure Cost Management exportait déjà en 1.2 lors de notre article d’octobre, OCI a annoncé son support FOCUS cette année également. Vérifie la version exacte supportée par export avant de brancher ton nouveau parseur — rien n’empêche qu’un export te livre encore du 1.2 ou du 1.3 pendant une période de transition.

FAQ

FOCUS 1.4 est-il rétrocompatible avec la 1.3 ?

Pour la lecture des colonnes inchangées, oui. Mais ContractApplied change de format et ProviderName/PublisherName disparaissent : un parseur strict écrit pour la 1.3 ne lira pas correctement un export 1.4 sur ces points précis.

Qu’est-ce qui remplace ProviderName et PublisherName ?

La section Participating Entity Identification de la spec propose plusieurs colonnes selon le rôle de l’entité dans la chaîne de facturation (fournisseur direct, revendeur, marketplace) — il n’y a pas un remplaçant unique, le bon choix dépend de ton modèle de facturation.

Mon fournisseur cloud supporte-t-il déjà FOCUS 1.4 ?

Ça varie. Vérifie la documentation d’export de ton fournisseur (Cost Management pour Azure, CUR pour AWS, Billing Export pour GCP) avant de supposer que tu reçois déjà du 1.4 — beaucoup de fournisseurs annoncent le support FOCUS en général sans préciser la version exacte livrée par défaut.

Et FOCUS 1.5, prévue pour quand ?

Aucune date n’est annoncée publiquement à ce stade. La FinOps Foundation évoque des pistes — prix catalogue (list pricing) des fournisseurs et suivi natif de la consommation de tokens IA — mais rien n’est figé ni daté.

Pour la suite

Si ton équipe FinOps continue de réconcilier facture et usage à coups d’exports PDF parsés à la main, FOCUS 1.4 est une bonne excuse pour arrêter. Commence par un test du nouveau format ContractApplied sur un échantillon de factures avant de toucher à ton pipeline de production, et vérifie la version FOCUS réellement exportée par ton fournisseur plutôt que de la supposer.

Sur AKS, un pod peut consommer du CPU, de la mémoire et de la bande passante sans qu’aucune ligne de facturation Azure ne le dise explicitement : la facture arrive au niveau du nœud, pas du pod. Répartir ce coût entre les équipes qui partagent le cluster reste, encore aujourd’hui, un bricolage de tags et de règles maison. C’est précisément ce que la FinOps Foundation a cherché à corriger avec la version 1.3 de sa spécification FOCUS, ratifiée le 5 décembre 2025.

Le problème : un coût, plusieurs consommateurs

FOCUS (FinOps Open Cost and Usage Specification) normalise le format des données de facturation cloud pour que les mêmes requêtes fonctionnent chez AWS, Azure, GCP ou un fournisseur SaaS. On avait détaillé la version 1.2 et son arrivée dans Azure Cost Management dans cet article. Mais la 1.2 ne disait rien de précis sur la répartition des coûts partagés, pods Kubernetes, instances de base de données mutualisées, chaque fournisseur appliquant sa propre logique, non documentée, non comparable d’un cloud à l’autre.

Ce que la 1.3 ajoute concrètement

Split cost allocation calculé par le fournisseur

Le dataset Cost and Usage passe à 65 colonnes avec cette version, selon la spécification officielle, et une partie sert justement à exposer la méthode de répartition qu’utilise le fournisseur de données, plutôt que de laisser chaque équipe FinOps deviner. L’exemple donné par la fondation : le coût d’une VM sous-jacente peut désormais être ventilé entre les pods Kubernetes qui tournent dessus, sans ressaisie manuelle.

Contract Commitments : un dataset séparé

Les engagements contractuels (dates de début/fin, unités restantes, descriptions) sortent du dataset de coûts et d’usage pour former leur propre jeu de données, avec 13 colonnes dédiées. Logique : ces informations sont souvent plus sensibles (négociation, remises) et méritent des permissions d’accès distinctes de celles appliquées à la facturation courante.

Recency et Completeness

Chaque dataset doit désormais porter un horodatage de dernière mise à jour et un statut de complétude. Sans ça, impossible de savoir si une ligne de coût est définitive ou encore sujette à révision, un problème classique avec les coûts cloud, souvent réajustés après coup (remises rétroactives, corrections de facturation).

Service Provider vs Host Provider

Les colonnes historiques Provider et Publisher restent lisibles en 1.3 mais passent en dépréciées, elles disparaîtront en 1.4. Elles sont remplacées par une distinction plus fine entre le fournisseur qui vend la ressource et celui qui l’héberge réellement, utile dès qu’il y a de la revente dans la chaîne (marketplace, CSP, reseller).

Le support vendor n’a pas encore rattrapé le papier

Selon le communiqué de la Linux Foundation, AWS a annoncé la disponibilité générale de FOCUS 1.2 au moment de cette sortie. Microsoft et Google sont cités comme contributeurs à la 1.3, de même qu’Alibaba, Databricks, Grafana, Huawei, Oracle Cloud Infrastructure, OVHcloud et Tencent, mais sans qu’aucun d’eux confirme publiquement un export FOCUS 1.3 disponible à ce jour. Concrètement : Azure Cost Management exporte en FOCUS 1.2 (voir l’article dédié ci-dessus), pas encore en 1.3. Avant de refaire tes dashboards de répartition de coûts autour des nouvelles colonnes, vérifie d’abord ce que ton export Azure/AWS/GCP expose réellement : le Validator 2.0 de la fondation ne couvre lui-même que les exigences de la 1.2 pour l’instant.

Et la 1.4, déjà en préparation

La fondation travaille déjà sur la 1.4, avec un dataset de factures FOCUS et des dimensions de contrat élargies, annoncée selon le blog officiel de la FinOps Foundation en parallèle d’un nouveau projet, Tokenomicon, pensé pour la gouvernance des coûts de tokens IA. Si tu ne factures pas encore d’inférence LLM à l’échelle, ce n’est pas la priorité : la répartition des coûts partagés de la 1.3 a plus de valeur immédiate pour un cluster Kubernetes ou une flotte de bases de données mutualisées que les tokens IA de la 1.4.

Ce que ça change pour ton reporting

Si ton fournisseur expose déjà du FOCUS 1.2, la bascule vers 1.3 demande surtout d’ajouter les nouvelles colonnes de répartition à tes requêtes existantes : le format de base ne change pas de philosophie. En revanche, séparer les Contract Commitments dans tes modèles de reporting vaut la peine d’être anticipé maintenant, avant que ton équipe sécurité ne pose la question des permissions d’accès aux clauses contractuelles.

FAQ

FOCUS 1.3 est-il rétrocompatible avec la 1.2 ?

Oui pour l’essentiel : les colonnes Provider et Publisher de la 1.2 restent lisibles en 1.3, simplement marquées comme dépréciées en vue de leur retrait en 1.4.

Azure expose-t-il déjà du FOCUS 1.3 ?

Pas à notre connaissance au moment de la rédaction : Microsoft est cité comme contributeur à la 1.3, mais Azure Cost Management reste documenté sur la 1.2.

Faut-il migrer ses dashboards dès maintenant ?

Seulement si ton fournisseur expose déjà les nouvelles colonnes. Sinon, la priorité reste de vérifier la couverture FOCUS de ton export actuel avant d’investir du temps sur une version pas encore disponible côté data.

Si tu gères des coûts Kubernetes ou des bases partagées entre équipes, surveille l’annonce du support FOCUS 1.3 côté Azure/AWS/GCP dans les prochains mois : c’est là que la répartition des coûts partagés deviendra enfin automatisable plutôt que bricolée en interne.

Tu as acheté des réservations Azure il y a 18 mois pour des VM qui ont depuis changé de taille, de région, ou qui n’existent plus. Tu paies toujours le même engagement mensuel, mais la réduction ne s’applique plus à grand-chose. Un Savings Plan aurait suivi le mouvement automatiquement — alors faut-il échanger tes réservations maintenant, et à quel prix ?

Microsoft a mis en place un mécanisme de bascule en self-service entre réservations et Savings Plans, avec des règles précises sur ce qui est éligible, combien tu peux échanger à la fois, et comment calculer le bon engagement de remplacement. On a déjà couvert la restriction d’échange qui arrive au 1er février 2027 — ici, on regarde comment t’en servir dès maintenant, dans le bon sens.

Réservation ou Savings Plan : la différence tient en une phrase

Une réservation t’engage sur un type d’instance précis, dans une région précise, pour un an ou trois ans. Un Savings Plan t’engage sur une dépense horaire, appliquée automatiquement à l’ensemble des services de calcul éligibles, dans toutes les régions. Microsoft recommande la réservation pour des charges stables et prévisibles, sans changement anticipé de type d’instance ni de région — c’est là qu’elle offre la meilleure réduction. Le Savings Plan convient mieux à des charges qui évoluent, qui changent de famille d’instance ou qui migrent de région.

La documentation officielle propose d’ailleurs une séquence d’optimisation à suivre dans l’ordre, pour ne pas gaspiller de l’argent sur des engagements mal dimensionnés :

1. élimine d’abord les ressources inutilisées ou surdimensionnées — une réduction ne compense jamais du gaspillage ;
2. échange les réservations sous-utilisées pour une configuration qui correspond mieux à ton usage actuel ;
3. transforme en Savings Plan les réservations rigides dont l’usage est devenu variable ;
4. achète de nouvelles réservations uniquement pour les charges stables et bien comprises ;
5. complète avec de nouveaux Savings Plans, dimensionnés sur une base déjà optimisée.

Le trade-in, concrètement

Tu peux échanger jusqu’à 100 réservations en une seule opération d’achat de Savings Plan, directement depuis le portail Azure (Réservations > sélectionner les réservations à échanger > Exchange). Azure annule les réservations, te rembourse au prorata, et annule les paiements mensuels futurs le cas échéant.

Attention toutefois à l’éligibilité : seules les réservations Azure Virtual Machines, Dedicated Hosts, Azure App Service et les réservations de bases de données (SQL Database, SQL Managed Instance, PostgreSQL, MySQL, Cosmos DB…) peuvent être échangées contre un Savings Plan — respectivement compute ou base de données. Aucune autre réservation n’est éligible au trade-in. Et le sens inverse n’existe pas : impossible d’échanger un Savings Plan contre une réservation, ni contre un autre Savings Plan.

Dernier point qui surprend souvent : le nouveau Savings Plan doit couvrir au moins l’engagement restant de la réservation échangée. Exemple donné par Microsoft — une réservation de 3 ans à 100 $/mois, échangée après le 18ᵉ paiement, doit être remplacée par un Savings Plan dont l’engagement total sur sa durée est d’au moins 1 800 $. Tu ne peux donc pas t’en servir pour réduire artificiellement ton engagement en cours de route.

Calculer le bon engagement horaire

Le Savings Plan se négocie en engagement horaire, pas en quantité d’instances — il faut donc convertir. Microsoft documente la méthode : prends le coût annuel upfront de l’instance que tu veux couvrir dans le calculateur de prix Azure, puis divise ce montant par 8 760 (nombre d’heures dans une année, pour un engagement d’un an) ou par 26 280 (trois ans). Multiplie le résultat par le nombre d’instances à couvrir, répète pour chaque type de produit à échanger, et additionne le tout pour obtenir l’engagement horaire total à saisir au moment de l’achat.

Cette méthode suppose une utilisation à 100 % des ressources couvertes — en pratique, mieux vaut partir de tes données réelles de Cost Management (onglet Réservations > Utilisation) plutôt que de l’hypothèse optimiste du calcul théorique, pour éviter de sur-engager ou sous-engager ton nouveau Savings Plan.

Pourquoi ça devient urgent avant 2027

On a détaillé dans un article précédent ce qui change pour les réservations avant le 1er février 2027 : à partir de cette date, les réservations achetées perdent définitivement le droit à l’échange classique (exchange) pour tout service couvert par les Savings Plans — VM, App Service, SQL Database et équivalents. Les réservations achetées avant cette date gardent le droit à un dernier échange. En sont exclues les réservations pour des produits en fin de vie, et celles pour des services non couverts par les Savings Plans comme Azure VMware Solution, qui ne sont pas concernées par cette restriction.

Le trade-in vers un Savings Plan, documenté ici, reste une politique distincte et n’est pas touché par cette échéance — mais elle donne une bonne raison de trancher maintenant plutôt que d’attendre : si une réservation ne te convient plus, c’est le moment de l’échanger pour une configuration plus adaptée ou de la transformer en Savings Plan, avant que l’option du simple échange ne se referme pour tes achats futurs.

Notre avis : ne généralise pas, mais ne t’interdis rien non plus

Pour une charge réellement stable depuis plus d’un an — même type de VM, même région, aucun changement prévu — la réservation reste le meilleur calcul : la réduction y est généralement supérieure à celle d’un Savings Plan équivalent, à condition d’être pleinement utilisée. Le trade-in n’a alors aucun intérêt. En revanche, dès que tu doutes de la stabilité d’une charge sur les 12 à 36 prochains mois, ou que tu as plusieurs réservations sous-utilisées qui dorment dans ton rapport d’utilisation, le calcul penche nettement vers le Savings Plan : la flexibilité qu’il apporte vaut largement l’écart de réduction, surtout avec la fenêtre d’échange qui se referme en 2027.

Sur la résiliation : la politique de plafond à 50 000 $ d’annulation sur une fenêtre glissante de 12 mois par profil de facturation ou inscription unique n’est pas modifiée par ce mécanisme de trade-in. Et Microsoft précise ne pas facturer actuellement de frais de résiliation anticipée sur les trade-ins, tout en se réservant le droit de le faire à l’avenir, sans date annoncée pour l’instant.

Remboursement : la mécanique change selon ton type de compte

Si tu es client Enterprise Agreement, le remboursement est ajouté à ton Azure Prepayment (l’ancien engagement monétaire) s’il est encore actif ; sinon, un crédit est ajouté à ton terme d’accord en cours, valable 90 jours — au-delà, le crédit non utilisé expire. Si l’achat initial provenait d’un dépassement, le remboursement prend la forme d’une note de crédit partielle, sans impact sur les factures passées ou suivantes.

Côté Microsoft Customer Agreement avec carte bancaire, la facture d’origine est annulée et une nouvelle est générée ; le remboursement part sur la carte utilisée pour l’achat initial — si cette carte n’est plus valide, il faut ouvrir une demande de support pour récupérer les fonds.

FAQ

Puis-je échanger un Savings Plan contre une réservation ?

Non. L’échange ne fonctionne que dans un sens : d’une réservation éligible vers un Savings Plan. Une fois converti, il n’y a pas de retour en arrière possible vers une réservation.

Mes réservations Azure VMware Solution sont-elles concernées par la restriction de 2027 ?

Non — Azure VMware Solution n’est pas couvert par les Savings Plans, donc les réservations pour ce service restent exclues de la restriction d’échange qui entre en vigueur au 1er février 2027.

Qui a le droit de faire l’échange dans mon organisation ?

Il faut être propriétaire de l’ordre de réservation concerné, et avoir le rôle d’acheteur de Savings Plan ou être propriétaire de l’abonnement visé pour l’achat. Attention : les permissions d’écriture EA Admin ou de contributeur de profil de facturation, suffisantes pour un achat direct de Savings Plan, ne suffisent pas pour un trade-in.

Y a-t-il des frais si j’annule au lieu d’échanger ?

Pour une annulation classique (hors trade-in), le plafond reste de 50 000 $ par fenêtre glissante de 12 mois, sans frais de résiliation anticipée actuellement facturés par Microsoft sur les trade-ins — une situation que Microsoft peut faire évoluer sans date communiquée à ce jour.

Avant toute décision, passe par Cost Management > Réservations > Utilisation pour repérer les réservations sous-utilisées — c’est ce rapport, pas une intuition, qui doit guider le choix entre garder, échanger ou transformer en Savings Plan. On avait posé les bases de ce suivi dans notre guide sur la maîtrise des coûts Azure avec Cost Management.

À partir du 1er février 2027, une réservation Azure achetée après cette date ne pourra plus être échangée si le service correspondant est aussi couvert par un savings plan — Machines Virtuelles, App Service, Azure SQL Database et les services équivalents. Ce n’est pas une rumeur ni une annonce à venir : c’est déjà écrit dans la documentation officielle de facturation Azure. Pour une équipe FinOps, ça change la fenêtre de décision dès maintenant, pas dans quinze mois.

On avait déjà détaillé FOCUS 1.2 dans Azure Cost Management et posé les bases de la maîtrise des coûts Azure avec Cost Management. Cette fois, il s’agit d’un sujet plus pointu mais tout aussi concret : la politique de resserrement progressif qui touche les réservations Azure, et comment t’y préparer sans attendre la dernière minute.

Deux échéances, pas une seule

La première est déjà passée mais continue de produire des effets : depuis le 1er juillet 2026, Microsoft n’accepte plus l’achat ni le renouvellement de certaines réservations de VM dites legacy — les séries Av2, Amv2, Bv1, D, Ds, Dv2, Dsv2, F, Fs, Fsv2, G, Gs, Ls et Lsv2 en engagement d’un an, et Dv3, Dsv3, Ev3 et Esv3 en engagement d’un et trois ans. Les réservations déjà en cours restent valables jusqu’à leur terme, mais aucun renouvellement n’est plus possible pour ces familles. Si tu as encore des VM Dv2 ou Dsv2 en production avec une réservation qui arrive à expiration, c’est le moment d’y regarder de près : Microsoft documente précisément la marche à suivre pour ces réservations retirées.

La seconde échéance, plus large, arrive le 1er février 2027 : à partir de cette date, une réservation nouvellement achetée pour un service couvert par un savings plan (VM, App Service, SQL Database notamment) ne bénéficiera plus que d’un seul échange possible — contre zéro limite aujourd’hui. Les réservations achetées avant cette date gardent ce droit à un échange final, même après l’échéance. Ce changement est documenté dans la page officielle sur le trade-in des réservations vers un savings plan.

Pourquoi Microsoft pousse vers les savings plans

Une réservation classique t’engage sur une famille de VM précise, dans une région précise, pour un ou trois ans. Un savings plan t’engage sur un montant de dépense horaire, valable sur l’ensemble des services de calcul éligibles, dans toutes les régions. Microsoft documente lui-même la logique d’arbitrage dans son guide pour choisir entre savings plan et réservation, avec un ordre de priorité qui a du sens pour n’importe quelle équipe FinOps : d’abord redimensionner les ressources inutilisées ou surdimensionnées, puis échanger les réservations sous-utilisées contre une configuration qui correspond mieux au besoin réel, ensuite transformer les réservations rigides restantes en savings plan flexible, et seulement après ça, acheter de nouveaux engagements.

Le calcul du troisième échange a une règle précise à connaître avant de s’engager : le nouveau savings plan doit couvrir un engagement total au moins égal à l’engagement restant de la réservation échangée. Concrètement, pour une réservation de trois ans à 100 $/mois échangée après son 18ᵉ paiement, le nouveau savings plan doit représenter un engagement cumulé d’au moins 1 800 $ sur sa durée — pas question de ressortir avec un engagement plus léger que ce qui restait à payer.

Ce que ça veut dire pour ta stratégie, concrètement

Si tu gères encore un parc avec des réservations VM sur des familles legacy (Dv2, Dsv2, Fsv2 en tête), la fenêtre pour un dernier renouvellement avant retrait pure et simple est déjà fermée depuis juillet — il ne reste que la modernisation vers une série récente ou la bascule en savings plan. Pour tout le reste de ton portefeuille de réservations, le vrai sujet, c’est le nombre d’échanges restants : jusqu’au 31 janvier 2027, tu peux encore échanger sans limite de quantité (jusqu’à 100 réservations par opération). Après, chaque réservation achetée n’aura droit qu’à un aller simple vers un savings plan.

Dans les faits, ça pousse clairement vers une chose : arrêter d’acheter des réservations VM par défaut pour tout ce qui n’est pas un socle réellement stable et prévisible sur plusieurs années. Pour une charge qui évolue — montée en charge saisonnière, migration de série de VM prévue, changement de région probable — le savings plan est désormais le choix le plus rationnel, et plus seulement une option de confort. Les réservations gardent leur intérêt pour les workloads franchement figés (un contrôleur de domaine, une base qui ne bougera pas), là où elles offrent la meilleure remise quand elles sont pleinement utilisées.

FAQ

Mes réservations déjà achetées cessent-elles de fonctionner le 1er juillet 2026 ou le 1er février 2027 ?

Non. Les deux échéances concernent les nouveaux achats et renouvellements, pas les réservations déjà en cours : elles continuent de produire leurs remises jusqu’à leur date d’expiration normale.

Azure VMware Solution est-il concerné par la restriction d’échange de 2027 ?

Non, les réservations pour des services non couverts par un savings plan, comme Azure VMware Solution, sont explicitement exclues de cette restriction.

Combien de réservations puis-je échanger en une seule opération ?

Jusqu’à 100 réservations par achat de savings plan, sans changement annoncé sur cette limite pour l’instant.

Microsoft va-t-il facturer des frais de résiliation anticipée ?

Pas à ce jour. Le plafond de résiliation sans frais reste à 50 000 $ sur une fenêtre glissante de 12 mois, et Microsoft s’est engagé à prévenir six mois à l’avance avant d’introduire d’éventuels frais.

En résumé

Deux dates, deux logiques : le 1er juillet 2026 a fermé la porte sur plusieurs séries de VM reservations historiques, le 1er février 2027 fermera celle des échanges illimités. Si ton portefeuille de réservations n’a pas été revu depuis le printemps, c’est le bon moment pour le faire — avant que la fenêtre d’échange sans contrainte ne se referme.

Si tu gères des coûts sur plusieurs clouds, tu connais la galère : chaque fournisseur a son propre export, ses propres noms de colonnes, ses propres conventions de date. AWS appelle ça UnblendedCost, Azure CostInBillingCurrency, GCP encore autre chose. Résultat, ton équipe FinOps passe plus de temps à écrire des scripts de normalisation qu’à analyser les vraies dérives de coûts.

C’est exactement le problème que la FinOps Foundation essaie de résoudre avec FOCUS (FinOps Open Cost and Usage Specification), et Azure Cost Management l’implémente depuis un moment déjà. Sauf que la version disponible aujourd’hui dans Azure — le dataset 1.2-preview — n’est toujours pas exactement calée sur FOCUS 1.2, et la fondation a déjà publié une version 1.3. Voyons ce qui a vraiment changé, ce qui manque encore côté Azure, et comment t’en servir sans te faire piéger par les détails.

FOCUS, en une phrase

FOCUS est un schéma de colonnes standardisé pour les données de coûts et d’usage cloud, porté par la FinOps Foundation (elle-même sous l’ombrelle de la Linux Foundation). L’idée : au lieu que chaque fournisseur expose son format maison, tout le monde publie (au moins en option) un export avec les mêmes colonnes — BilledCost, EffectiveCost, ChargePeriodStart, ServiceCategory, etc. Tu écris tes tableaux de bord une fois, ils fonctionnent sur AWS, Azure, GCP et le reste sans réécriture.

Microsoft, AWS, Google Cloud, Oracle Cloud, Alibaba, Huawei, Tencent, Databricks, Grafana et OVHcloud soutiennent tous FOCUS à des degrés divers. Ce n’est pas un gadget marketing : c’est devenu le format d’échange de référence pour tout ce qui touche aux FinOps hubs, aux outils tiers de gestion de coûts (CloudHealth, Vantage, nOps…) et aux rapports Power BI du FinOps toolkit Microsoft.

Ce qui change vraiment dans le dataset 1.2-preview d’Azure

Côté Azure Cost Management, le dataset FOCUS actuel a pour identifiant de schéma 1.2-preview, créé le 13 juin 2025 — toujours en préversion, donc, malgré le nom. Quatre colonnes bougent par rapport à la 1.1 :

• BillingAccountType : nouvelle colonne, qui indique le type d’entité derrière BillingAccountId (« Billing Account » pour un contrat Enterprise Agreement, « Billing Profile » pour un Microsoft Customer Agreement).
• SubAccountType : nouvelle colonne, même logique mais pour SubAccountId.
• InvoiceId : promue au rang de colonne standard (elle vivait avant sous x_InvoiceId, le préfixe réservé aux extensions propriétaires de chaque fournisseur).
• PricingCurrency : même chose, promue depuis x_PricingCurrency.

Si tu migrais déjà depuis du FOCUS 1.0 ou 1.0r2, ce sont ces quatre-là qu’il faut ajouter à tes requêtes ou tes modèles Power BI. Attention à une subtilité au passage : 1.0r2 n’est pas une nouvelle version du spec, juste un correctif de format de date (les secondes sont désormais explicites — 2024-01-01T00:00:00Z plutôt que 2024-01-01T00:00Z). Si un de tes parseurs de date casse après une migration, c’est probablement ça.

Le conformance score n’est pas 100 %, et c’est documenté

Microsoft publie un rapport de conformité complet, chose que peu de fournisseurs cloud font aussi ouvertement. Le score actuel du dataset Azure FOCUS 1.2-preview est de 94 % : 325 exigences MUST sur 349 sont pleinement supportées, 16 partiellement, 8 pas du tout. Ce n’est pas dramatique pour un usage courant de reporting, mais si tu bâtis un outil qui dépend d’une exigence précise, vérifie-la dans le rapport de conformité complet avant de t’en servir en prod.

Créer un export FOCUS dans Azure Cost Management

C’est un des trois modèles proposés dans les exports Cost Management, à côté de « actual » et « amortized ». Les grandes étapes :

1. Portail Azure → Cost Management → sélectionne le scope voulu → Exports → + Create.
2. Onglet Basics : choisis le template Cost and usage (FOCUS).
3. Onglet Datasets : donne un préfixe d’export unique (par exemple focus-prod-2026).
4. Onglet Destination : type de stockage Azure Blob, compression None, et surtout Overwrite data = Enabled si tu veux un export quotidien qui écrase le fichier de la veille plutôt que d’accumuler des doublons.
5. Review + Create, puis Run now pour ne pas attendre le prochain cycle planifié.

Deux limites à connaître avant de te lancer : le scope groupe de gestion (management group) n’est pas supporté pour les exports FOCUS — il faut exporter par abonnement ou par profil de facturation — et si tu exportes au niveau groupe de gestion tout court (avec un autre format), le multi-devise n’est pas géré non plus. Pour une organisation multi-abonnements avec des devises différentes, prévois donc des exports séparés plutôt qu’un export consolidé unique.

FinOps hubs : l’usage le plus courant de ces exports

Si tu pousses ces données vers FinOps hubs (Microsoft Fabric ou Azure Data Explorer en backend), le format FOCUS est directement pris en charge et réduit le volume de données à traiter par rapport aux exports actual/amortized bruts. Le coût annoncé démarre à 120 $/mois pour un cluster Data Explorer à un nœud, plus environ 10 $/mois par million de dollars surveillés — ou 5 $/million si tu te passes de Data Explorer/Fabric et que tu restes sur du stockage brut. Pour une boîte qui gère quelques centaines de milliers de dollars de cloud par mois, ça reste anecdotique face au temps gagné à ne plus maintenir un pipeline de normalisation maison.

FOCUS 1.3 est déjà là — Azure, pas encore

La FinOps Foundation a annoncé FOCUS 1.3 le 11 décembre 2025 à San Francisco, avec trois apports notables : des colonnes pour l’allocation des coûts partagés (répartir un coût d’infrastructure entre plusieurs conteneurs ou bases de données qui la consomment), un dataset séparé dédié aux engagements contractuels (dates, unités restantes, sans mélanger ça avec les lignes de coût), et un horodatage obligatoire avec indicateur de complétude pour distinguer une ligne définitive d’une ligne encore révisable. AWS a profité de l’annonce pour confirmer la disponibilité générale de son propre export FOCUS 1.2 le même jour.

Azure, de son côté, en est toujours au dataset 1.2-preview au moment de la rédaction de cet article — pas de date publique communiquée pour un passage en 1.3 ou même en 1.2 stable (non-preview). Concrètement : bâtis tes pipelines FinOps sur FOCUS maintenant, la valeur est déjà là, mais ne prends pas de dépendance dure sur une exigence 1.3 tant que le dataset Azure n’a pas suivi.

FAQ

FOCUS remplace-t-il les exports « actual » et « amortized » ?

Non, les trois coexistent. FOCUS combine en réalité les deux dans un seul fichier (via les colonnes BilledCost et EffectiveCost) et réduit le temps de traitement, mais si un outil tiers attend spécifiquement le format natif Azure, garde l’export correspondant en parallèle le temps de migrer.

Faut-il du FinOps hubs pour profiter de FOCUS ?

Non. Tu peux consommer un export FOCUS brut depuis n’importe quel outil qui sait lire du CSV/Parquet — Power BI, un notebook Python, un pipeline dbt. FinOps hubs ajoute juste l’orchestration et le stockage optimisé si le volume le justifie.

Le scope groupe de gestion, c’est un vrai problème ?

Ça dépend de ta structure. Si tu as un seul groupe de gestion avec une devise unique, tu peux contourner en exportant à ce niveau avec un autre format puis en convertissant. Si tu es multi-devises, il faut accepter des exports par abonnement — plus de fichiers à gérer, mais des données propres.

Passe à l’action

Si tu n’as encore aucun export FOCUS configuré, le geste le plus rentable cette semaine, c’est de créer un export « one-time » sur ton abonnement de prod pour voir concrètement à quoi ressemblent les colonnes chez toi, avant de programmer un export quotidien. Tu verras vite si ton usage actuel (réservations, savings plans, ressources partagées) colle bien aux 94 % de conformité annoncés — ou si tu tombes justement dans les 6 % qui manquent encore.

Pour aller plus loin sur la maîtrise des coûts Azure au global, notre article sur FinOps en 2026 et Cost Management pose les bases, et si tu gères un cluster Kubernetes, l’attribution des coûts AKS par namespace complète bien ce sujet côté conteneurs.

Tu as sans doute déjà vécu ça : une facture Azure qui grimpe d’un coup après le déploiement d’un service IA, sans que personne ne sache vraiment pourquoi. Les coûts de calcul GPU, les tokens consommés par un modèle managé, les instances de fine-tuning qu’on oublie d’éteindre… la facturation à l’usage de l’IA casse les habitudes de pilotage financier classiques. C’est exactement le problème que le FinOps Framework 2026 de la FinOps Foundation vient adresser de façon structurée. Dans cet article, tu vas voir ce qui a changé dans ce framework, pourquoi l’IA y a désormais sa propre catégorie, et comment appliquer concrètement ces principes sur Azure avec le FinOps toolkit.

Pourquoi les coûts IA cassent les modèles FinOps classiques

Le FinOps « traditionnel » s’est construit autour du cloud public : tu réserves de la capacité, tu optimises tes VM, tu négocies des remises sur engagement, et la facture reste globalement prévisible d’un mois sur l’autre. Les charges IA ne respectent pas ces règles. Un cluster de GPU H100 loué à l’heure, un modèle managé facturé au token, un pipeline de fine-tuning qui tourne une nuit entière : la variance de coût peut être énorme d’une semaine à l’autre, et elle dépend directement de décisions prises par des équipes produit ou data qui n’ont pas forcément de visibilité sur l’impact financier de leurs choix.

Résultat : les tableaux de bord FinOps historiques, pensés pour du cloud IaaS/PaaS classique, ne suffisent plus à donner une image fidèle de la dépense IA — ni à l’attribuer correctement à la bonne équipe ou au bon produit.

Ce que change le FinOps Framework 2026

La FinOps Foundation a fait évoluer son framework de référence en 2026 pour répondre à ce constat. Trois changements structurants à retenir :

Une définition élargie : au-delà du seul cloud

Le framework ne parle plus seulement de « maximiser la valeur business du cloud », mais de maximiser la valeur business de la technologie au sens large — cloud public, SaaS, data center on-premise, plateformes data (Snowflake, Databricks, BigQuery) et IA. L’idée : une organisation qui pilote ses coûts IA en silo, sans les rapprocher du reste de sa dépense technologique, perd en cohérence de décision.

Une catégorie technologique dédiée à l’IA

C’est le changement le plus concret pour toi : le framework introduit désormais une page de guidance dédiée « FinOps for AI », qui traite explicitement de la complexité des coûts IA, de leur imprévisibilité, et des besoins de gouvernance associés — sachant qu’une dépense IA peut être répartie simultanément entre data center, cloud public et SaaS.

Un alignement stratégique avec la direction (Executive Strategy Alignment)

Nouvelle capacité du framework : le FinOps ne se limite plus au reporting de coûts, il devient un partenaire direct des décisions de budget et d’investissement technologique — utile quand une direction doit arbitrer entre financer un projet IA supplémentaire ou renforcer l’infrastructure existante.

Concrètement, comment appliquer ça sur Azure

Microsoft n’a pas attendu 2026 pour outiller le FinOps sur Azure, mais l’arrivée de cette catégorie IA dans le framework donne une bonne occasion de vérifier que ton setup est prêt à absorber la variabilité des coûts IA.

FinOps hubs et FinOps toolkit

Le FinOps toolkit de Microsoft reste ton point d’entrée : il fournit des modèles ARM/Bicep pour déployer des FinOps hubs (plateforme de reporting basée sur Cost Management, Azure Data Explorer ou Microsoft Fabric), des rapports Power BI prêts à l’emploi, et un module PowerShell pour automatiser les exports de coûts. Pour une charge IA qui varie fortement d’un jour à l’autre, avoir un export de coûts quotidien plutôt que mensuel change vraiment la donne côté visibilité :

# Créer un export de coûts quotidien avec le module PowerShell FinOps toolkit
Install-Module -Name FinOpsToolkit -Scope CurrentUser

New-FinOpsCostExport `
    -Name "export-couts-ia-quotidien" `
    -Scope "/subscriptions/<subscription-id>" `
    -StorageAccountId "/subscriptions/<subscription-id>/resourceGroups/rg-finops/providers/Microsoft.Storage/storageAccounts/safinopshub" `
    -StorageContainer "cost-exports" `
    -Dataset "FocusCost"

FOCUS pour allouer correctement les coûts IA

La spécification FOCUS (FinOps Open Cost and Usage Specification) normalise le format des données de coûts pour qu’elles soient exploitables sans transformation lourde, quel que soit le fournisseur cloud. Pour des ressources IA facturées de façon hétérogène (à l’heure, au token, à la capacité réservée), c’est ce qui te permet de ramener tout ça à des colonnes communes — ServiceCategory, ChargeCategory, EffectiveCost — et donc de construire des rapports d’attribution par équipe ou par projet IA qui tiennent la route.

Les pièges courants à éviter

Sur le terrain, la plupart des dérapages de coûts IA viennent de trois causes assez classiques : des ressources GPU provisionnées « au cas où » et jamais redimensionnées après les tests, l’absence de tags de coût cohérents sur les workloads IA (donc impossible de savoir quelle équipe consomme quoi), et des environnements de fine-tuning ou d’expérimentation laissés actifs after-hours faute d’automatisation d’arrêt. Si tu as déjà mis en place du tagging et des budgets Azure pour tes charges classiques, la bonne nouvelle est que les mêmes réflexes s’appliquent à l’IA — il faut juste les appliquer plus tôt dans le cycle de vie du projet, avant que les coûts ne deviennent difficiles à démêler.

FAQ

Le FOCUS spec couvre-t-il déjà les services IA managés d’Azure ?

FOCUS normalise la structure des données de coûts, pas un service en particulier : tant qu’un service IA facture via Cost Management (ce qui est le cas des principaux services Azure AI), ses données peuvent être exposées au format FOCUS. Vérifie toujours la couverture exacte dans la documentation du toolkit, qui évolue régulièrement.

Faut-il une équipe FinOps dédiée pour appliquer ces principes à l’IA ?

Non, surtout si ton organisation est petite ou moyenne : l’essentiel est d’impliquer les équipes qui décident des ressources IA (data, ML, plateforme) dans la boucle de visibilité des coûts, pas forcément de créer un rôle dédié dès le départ.

Le FinOps toolkit est-il gratuit ?

Oui, le toolkit lui-même est open source ; tu paies uniquement l’infrastructure Azure sous-jacente (stockage, Data Explorer ou Fabric) utilisée pour héberger tes hubs de reporting.

En résumé

Le FinOps Framework 2026 acte ce que beaucoup d’équipes infra vivaient déjà sur le terrain : les coûts IA ne se pilotent pas comme des coûts cloud classiques. Si tu gères des charges IA sur Azure, c’est le bon moment pour vérifier ton dispositif de reporting — exports quotidiens, tagging, FOCUS — avant que la prochaine facture ne te surprenne. Si tu veux creuser l’attribution de coûts sur des workloads conteneurisés, notre article sur FinOps pour Kubernetes avec AKS Cost Analysis complète bien cette approche, et notre guide FinOps 2026 sur Azure Cost Management reste la bonne base si tu démarres tout juste ta démarche.

Un cluster AKS partagé entre cinq équipes, une seule ligne de facturation sur ta note Azure, et personne ne sait qui consomme quoi. Tu reconnais la situation ? C’est le problème numéro un du FinOps appliqué à Kubernetes : la granularité de facturation d’Azure s’arrête au groupe de ressources, alors que la vraie consommation se joue au niveau du pod et du namespace.

Depuis 2026, Azure propose une réponse native à ce problème avec l’add-on AKS Cost Analysis, construit directement sur le projet open source OpenCost. Dans cet article, tu vas voir comment l’activer, comment lire les données qu’il produit, et comment t’en servir pour bâtir un vrai showback ou chargeback entre équipes.

Pourquoi Cost Management seul ne suffit pas sur Kubernetes

Microsoft Cost Management fait très bien son travail au niveau des ressources Azure — VM, disques, load balancers, IP publiques. Le problème, c’est qu’un cluster AKS mutualise ces ressources entre des dizaines d’applications qui n’ont pas le même profil de consommation. Un cluster avec un seul workload, tu peux t’en sortir en lisant directement le coût du groupe de ressources. Dès que plusieurs équipes partagent le même cluster, tu as besoin d’une couche supplémentaire capable de répartir ce coût par namespace, par label, ou par déploiement.

C’est exactement le rôle de l’add-on de cost analysis : il capture la consommation réelle (CPU, mémoire, stockage, réseau) au niveau du pod, puis réconcilie ces données avec ta facture Azure pour obtenir un coût précis et vérifiable — pas une simple estimation proportionnelle au nombre de pods.

Activer AKS Cost Analysis

L’add-on nécessite un cluster en tier Standard ou Premium (pas disponible sur le tier Free). Sur un cluster existant :

az aks update \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --enable-cost-analysis

Ou dès la création :

az aks create \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --location $LOCATION \
  --enable-managed-identity \
  --generate-ssh-keys \
  --tier standard \
  --enable-cost-analysis

Compte entre 8 et 24 heures avant que les premières données remontent dans le portail. Si tu gères plusieurs clusters dans le même abonnement, il faut activer l’add-on sur chacun individuellement — l’agrégation multi-cluster ne se fait qu’au niveau de la vue Cost Management, pas au niveau de la collecte.

Lire les données : les trois vues Kubernetes de Cost Management

Une fois l’add-on actif, trois nouvelles vues apparaissent dans Cost Management > Cost analysis :

• Kubernetes clusters — coût agrégé par cluster, pour une vue macro rapide
• Kubernetes namespaces — coût agrégé par namespace, tous clusters confondus dans l’abonnement : c’est la vue à utiliser pour du chargeback par équipe si chaque équipe a son namespace
• Kubernetes assets — coût détaillé par ressource individuelle au sein du cluster

Ces vues nécessitent un contrat Enterprise Agreement ou Microsoft Customer Agreement — les autres types d’abonnement Azure n’y ont pas accès pour l’instant. Détail important pour la lecture des chiffres : les coûts se répartissent en quatre catégories bien distinctes.

Type de charge	Signification
Idle charges	Capacité disponible mais non utilisée par aucun workload — ton indicateur numéro un de sur-provisionnement
System charges	Capacité réservée par AKS sur chaque nœud pour kubelet et le runtime — incompressible
Service charges	Uptime SLA, Microsoft Defender for Containers, et autres services activés sur le cluster
Unallocated charges	Coûts qui n’ont pas pu être rattachés à un namespace précis

Un taux d’idle charges élevé est en général le signal le plus actionnable : ça veut dire que tu payes pour de la capacité réservée que personne n’utilise, et que revoir tes requests/limits ou activer le cluster autoscaler te fera économiser plus vite qu’en négociant une remise.

Aller plus loin : chargeback par équipe avec les tags de node pool

Pour un vrai modèle de chargeback (facturation interne, pas juste de la visibilité), combine la vue namespace avec des tags posés sur tes node pools à la création :

az aks nodepool add \
  --resource-group $RESOURCE_GROUP \
  --cluster-name $CLUSTER_NAME \
  --name teamdata \
  --labels team=data cost-center=CC-4471 \
  --node-count 3

Ces labels remontent dans les rapports personnalisés Cost Management et te permettent de générer un rapport par centre de coût, même quand plusieurs équipes partagent physiquement les mêmes nœuds. Pour la théorie complète du modèle de répartition (showback vs chargeback, gestion des coûts partagés), la documentation officielle Microsoft détaille l’ensemble du sujet : View Kubernetes costs sur Microsoft Learn.

Le socle open source : OpenCost

L’add-on AKS Cost Analysis n’est pas une invention propriétaire de Microsoft — il s’appuie sur OpenCost, un projet incubé par la Cloud Native Computing Foundation devenu le standard de facto pour l’allocation de coûts Kubernetes. L’avantage : si tu es multicloud ou si tu gères aussi des clusters hors Azure, la même logique d’allocation (par namespace, deployment, label) s’applique avec les mêmes concepts, ce qui évite de réapprendre un modèle différent par fournisseur.

Optimiser une fois que tu vois enfin les coûts

Une fois la visibilité en place, les leviers d’optimisation classiques deviennent enfin actionnables avec des chiffres précis à l’appui : réduire les requests/limits surdimensionnés repérés par un fort taux d’idle charges, activer le cluster autoscaler plutôt que sur-provisionner en prévention, basculer les node pools non critiques vers des VM Spot, et migrer de Container Insights vers Prometheus managé pour réduire la facture Log Analytics. Le guide officiel des bonnes pratiques de coût AKS détaille l’ensemble de ces leviers : Best practices for cost optimization in AKS.

FAQ

L’add-on AKS Cost Analysis a-t-il un coût supplémentaire ?

Non, l’add-on lui-même est gratuit. Tu payes uniquement les ressources normales de ton cluster ; ce que tu gagnes, c’est la granularité de lecture, pas un coût additionnel.

Ça fonctionne sur un cluster multi-tenant avec des centaines de namespaces ?

Oui, c’est justement le cas d’usage principal. Plus tu as de namespaces et d’équipes partageant un cluster, plus la valeur de l’outil augmente par rapport à une lecture au niveau du groupe de ressources.

Que faire si mon abonnement n’est pas Enterprise Agreement ou Microsoft Customer Agreement ?

Les vues Kubernetes de Cost Management ne seront pas disponibles pour l’instant. Tu peux dans ce cas déployer OpenCost directement en self-hosted sur ton cluster via Helm, sans dépendre du type de contrat Azure.

Est-ce compatible avec les workloads Kubernetes 1.37 ?

Oui, aucune contrainte de version côté Kubernetes. Si tu as prévu une montée de version prochainement, vérifie d’abord notre article sur les nouveautés de Kubernetes 1.37 pour anticiper d’éventuels impacts sur tes node pools.

En résumé

Le FinOps sur Kubernetes bute presque toujours sur le même mur : une facture globale, aucune granularité. AKS Cost Analysis lève ce mur en quelques heures d’activation, sans agent tiers à maintenir. Si le sujet FinOps t’intéresse plus largement, notre article sur la maîtrise des coûts Azure avec Cost Management complète bien celui-ci côté vision globale de l’abonnement. Prochaine étape logique : active l’add-on sur ton cluster le moins visible côté coûts, et regarde ce que la vue namespace te révèle après 24 heures.

Tu regardes ta facture Azure du mois et tu ne reconnais plus grand-chose ? Tu n’es pas seul. Entre les ressources oubliées, les réservations jamais achetées et les équipes qui provisionnent sans se soucier du coût, la dérive budgétaire cloud est devenue un classique. C’est exactement le problème que le FinOps essaie de résoudre — et en 2026, la discipline change de dimension. Le FinOps Framework vient d’être mis à jour en profondeur, et Microsoft a densifié son outillage natif autour d’Azure Cost Management. Dans cet article, tu vas voir ce qui a changé, quels outils Azure utiliser concrètement, et comment démarrer une démarche FinOps sans tout révolutionner du jour au lendemain.

Le FinOps Framework 2026 : trois évolutions qui changent la donne

Porté par la FinOps Foundation, le framework de référence a été révisé en 2026 pour refléter un constat simple : la discipline ne se limite plus à surveiller la facture Azure ou AWS du mois. Trois changements structurent cette nouvelle version.

Executive Strategy Alignment : FinOps s’invite au comité de direction

Une nouvelle capacité formalise ce que beaucoup d’équipes FinOps matures faisaient déjà de façon informelle : porter les arbitrages de coût au niveau exécutif. Elle couvre l’alignement avec les priorités de la direction, la stratégie d’investissement pluriannuelle, la priorisation des produits et le soutien aux décisions stratégiques. Concrètement, ça veut dire que tes rapports de coûts ne doivent plus seulement dire « voilà ce qu’on a dépensé », mais « voilà ce que ça nous rapporte et ce qu’on te recommande d’arbitrer ».

De nouvelles catégories technologiques : SaaS, data platforms et IA

Le framework ne se limite plus au cloud public. Il couvre désormais le SaaS, les data centers on-premises, les plateformes de données cloud (Snowflake, Databricks…) et l’intelligence artificielle, chacune avec sa propre guidance. Si tu géres des coûts de tokens LLM ou des clusters Databricks à côté de ton abonnement Azure, ce n’est plus un angle mort du framework.

Les FinOps Scopes redéfinis autour du métier

Les « scopes » ne sont plus uniquement pensés autour de l’infrastructure (une souscription, un tag) mais comme des segments de dépense alignés sur des questions métier concrètes : combien coûte telle fonctionnalité produit, tel client, telle équipe. C’est un changement de posture : partir du besoin business plutôt que de la topologie technique.

Les outils Microsoft pour piloter tes coûts Azure au quotidien

Sur le plan pratique, tu n’as pas besoin d’attendre pour appliquer ces principes : Azure fournit déjà l’essentiel de l’outillage nécessaire.

Azure Cost Management : budgets, alertes et détection d’anomalies

Azure Cost Management reste le socle : analyse des coûts, budgets avec seuils d’alerte, et détection automatique d’anomalies basée sur ton historique d’usage normalisé. La bonne pratique documentée par Microsoft est de poser des seuils à 90 % (dépense idéale), 100 % (budget cible) et 110 % (alerte de dépassement), sur des alertes réelles ET prévisionnelles :

az consumption budget create \
  --budget-name "budget-prod-rg" \
  --amount 5000 \
  --category cost \
  --time-grain monthly \
  --start-date 2026-10-01 \
  --end-date 2027-09-30 \
  --resource-group "rg-prod" \
  --notifications '{
    "Actual_GreaterThan_90_Percent": {
      "enabled": true,
      "operator": "GreaterThan",
      "threshold": 90,
      "contactEmails": ["equipe-infra@monentreprise.fr"]
    },
    "Forecasted_GreaterThan_110_Percent": {
      "enabled": true,
      "operator": "GreaterThan",
      "threshold": 110,
      "thresholdType": "Forecasted",
      "contactEmails": ["equipe-infra@monentreprise.fr"]
    }
  }'

Pense aussi à activer tag inheritance dans Cost Management : ça t’évite de te retrouver avec des ressources orphelines impossibles à rattacher à une équipe ou un projet au moment de faire les comptes.

FinOps toolkit : hubs, Power BI et alertes automatisées sur les ressources inactives

Le FinOps toolkit de Microsoft complète l’outillage natif avec des composants prêts à déployer : les FinOps hubs pour centraliser et normaliser tes exports de coûts dans un data lake, des rapports Power BI, et surtout « FinOps alerts », une solution basée sur Azure Logic Apps qui scanne périodiquement ton environnement pour repérer les ressources inactives (VM arrêtées mais toujours facturées, disques orphelins, IP publiques non utilisées) et notifie automatiquement les équipes responsables. C’est le genre d’automatisation qui te fait gagner un vrai temps d’ingénieur, plutôt que de dépouiller un classeur Excel chaque fin de mois.

FOCUS : un format commun pour comparer tes coûts multi-fournisseurs

Si tu gères plusieurs fournisseurs cloud ou SaaS, la spécification FOCUS (FinOps Open Cost and Usage Specification) mérite ton attention : c’est un format de données de coûts standardisé, désormais supporté nativement par les exports Cost Management vers Azure Data Lake Storage. Ça t’évite de réécrire un pipeline de normalisation à la main dès que tu ajoutes un fournisseur.

Mettre en place une démarche FinOps concrète, sans tout révolutionner

Tu n’as pas besoin d’une équipe FinOps dédiée pour commencer. Voici un chemin réaliste :

• Commence par les alertes, pas par le budget parfait. Un seuil approximatif qui prévient d’une dérive vaut mieux qu’aucune alerte en attendant le budget idéal.
• Structure ton tagging (équipe, projet, environnement) et active l’héritage de tags pour limiter les coûts non attribuables.
• Passe en revue les recommandations Azure Advisor régulièrement — c’est la source la plus fiable de pistes d’optimisation immédiates (VM à redimensionner, réservations à envisager).
• Automatise la détection des ressources inactives avec FinOps alerts plutôt que de compter sur une revue manuelle mensuelle.
• Documente qui décide quoi : qui peut ajuster un budget, qui reçoit les alertes de dépassement, qui arbitre entre performance et coût. Sans ça, les meilleurs outils du monde ne servent à rien.

Si tu poses tes fondations de gouvernance (tagging, landing zones structurées) en même temps que ta démarche FinOps, tu gagnes du temps sur les deux fronts — c’est d’ailleurs l’un des arguments pour passer aux Azure Verified Modules sur tes landing zones : une infrastructure standardisée dès le départ rend le suivi des coûts par équipe ou projet beaucoup plus simple qu’un rattrapage a posteriori.

FAQ

Le FinOps, c’est réservé aux grandes entreprises avec une grosse facture cloud ?

Non. Les principes (visibilité, alertes, responsabilisation des équipes) s’appliquent dès qu’un abonnement Azure dépasse quelques centaines d’euros par mois. Ce qui change avec la taille, c’est le degré de formalisation : une petite équipe peut se contenter de budgets et d’alertes bien réglés, sans capacité dédiée ni comité exécutif.

Quelle différence entre FinOps et un simple contrôle budgétaire ?

Le contrôle budgétaire classique regarde a posteriori si on est dans les clous. Le FinOps vise à donner aux équipes techniques une visibilité en temps réel sur l’impact financier de leurs choix d’architecture, pour qu’elles puissent arbitrer elles-mêmes entre coût et performance, au moment où elles conçoivent — pas six mois plus tard en comité budgétaire.

Faut-il un outil tiers ou les outils natifs Azure suffisent ?

Pour démarrer, Azure Cost Management et le FinOps toolkit couvrent l’essentiel : budgets, alertes, anomalies, tableaux de bord Power BI. Les outils tiers deviennent pertinents surtout en environnement multi-cloud complexe, où tu as besoin d’une vue consolidée au-delà d’Azure — c’est justement le rôle que FOCUS est censé faciliter, tiers ou pas.

Conclusion

Le FinOps 2026 n’est plus seulement une affaire de tableurs et d’alertes de fin de mois : c’est un cadre qui invite à connecter la donnée de coût aux décisions produit et aux priorités de la direction. Mais tu n’as pas besoin d’attendre d’avoir tout ce dispositif en place pour commencer. Configure tes premières alertes de budget cette semaine, active FinOps alerts sur tes ressources inactives, et construis à partir de là. C’est ce genre de petites victoires régulières qui fait tenir une démarche FinOps dans la durée — bien plus qu’un grand plan jamais terminé.