Instances réservées : le taux de couverture qui ne prouve rien

6 Min. de lecture

94 % de couverture de l’engagement figuraient dans le rapport trimestriel, surlignés en vert. L’équipe était fière. Personne n’a demandé quelle partie de la facture cloud était réellement éligible à l’engagement, et c’est précisément cette question qui détermine si le chiffre a une valeur ou simplement une bonne apparence.

Les points clés en bref

• La couverture ne mesure pas ce que la plupart des gens pensent : Un taux de couverture élevé ne dit rien sur la quantité de charge réellement éligible à un engagement. Sans la base d’éligibilité, le chiffre est un rapport à une taille inconnue.
• FOCUS 1.4 sépare les éléments couverts des éléments éligibles : Depuis le 4 juin 2026, la colonne CommitmentProgramEligibilityDetails indique pour quels programmes une position est éligible, indépendamment de l’existence d’un engagement. C’est la première fois que cela est standardisé entre les fournisseurs.
• L’effet de levier se situe avant l’achat : Qui calcule les taux de couverture ajustés à l’éligibilité voit des potentiels d’économie inutilisés avant de signer la prochaine réservation de trois ans, au lieu de les rechercher a posteriori sur le tableau de bord.

Lié :Cloud Broker contre les coûts multi-cloud  /  Quand la répatriation cloud est rentable

Le chiffre que tout le monde rapporte et que presque personne ne remet en question

La couverture de l’engagement fait partie des premiers indicateurs que l’équipe FinOps présente. Elle décrit quelle partie de l’utilisation éligible à l’engagement est réellement couverte par des instances réservées, des plans d’économie ou des engagements similaires. Cela semble clair. Le problème réside dans le mot « éligible à l’engagement ».

Une couverture de 94 % comme dans l’exemple ci-dessus n’est que aussi pertinente que la base sur laquelle elle se fonde. La capacité Spot, certains services gérés, certains modèles de licence et les charges de travail en dehors des régions d’engagement ne sont souvent pas considérés comme éligibles à l’engagement. Si cette base se réduit, le taux augmente sans que cela n’entraîne une diminution des dépenses. Une équipe peut donc être fière de ce taux tandis qu’une partie importante de la facture est facturée au tarif On-Demand complet et ne figure simplement pas dans l’indicateur.

Jusqu’à présent, cette lacune était difficile à combler car chaque fournisseur définit et exporte l’éligibilité différemment. Qui opère avec AWS, Azure et Google Cloud en parallèle construit une logique propre à chaque fournisseur pour déterminer ce qui est éligible. Cette logique devient obsolète avec chaque nouveau type d’instance. L’indicateur plus honnête qu’est le taux de couverture ajusté à l’éligibilité reste une estimation pour la plupart des équipes.

Ces 17 nouvelles colonnes dans le dataset de l’engagement contractuel ne sont pas une fin en soi. Elles sont la reconnaissance que les décisions d’engagement sans cette structure étaient prises sur des demi-connaissances jusqu’à présent.

Ce que FOCUS 1.4 introduit entre les données couvertes et non couvertes

FOCUS, la spécification ouverte pour les données de coûts et d’utilisation cloud, a ratifié la version 1.4 le 4 juin 2026. Deux nouveaux jeux de données, 47 nouvelles colonnes. La nouveauté clé pour cette discussion est un seul champ dans le jeu de données de coûts et d’utilisation : CommitmentProgramEligibilityDetails.

Ce champ est un objet JSON qui liste pour chaque position les programmes de commitment pour lesquels cette position était qualifiée. Chaque entrée mentionne un type de programme, indépendamment de savoir si un engagement est actuellement appliqué. Ainsi, pour la première fois, il est directement indiqué dans les données brutes ce qui était couvert et ce qui ne l’était pas. Le taux de couverture ajusté à l’éligibilité peut être calculé à partir de cela, au lieu de l’estimer, même si l’agrégation continue de se produire dans les propres outils. Les praticiens peuvent identifier les potentiels d’économie inutilisés et comparer les options de commitment entre les fournisseurs sans avoir à maintenir une logique d’éligibilité propre à chaque fournisseur.

Un exemple de calcul rend la différence tangible. Si un cluster fonctionne à 60 % sur une capacité Spot, cette proportion n’est pas du tout éligible à un engagement. Une couverture déclarée de 90 % ne concerne alors que les 40 % restants. La charge Spot élevée est complètement exclue de l’examen. La vue ajustée à l’éligibilité inverse la question. Elle mesure combien de la charge vraiment couverte est couverte et révèle quelle partie de la facture n’était jamais dans le jeu de l’engagement. Qui ne présente que le premier chiffre sur la diapositive optimise un indicateur qui ne correspond pas à sa propre structure de coûts.

Le deuxième bloc concerne le pont entre l’ingénierie et la comptabilité. FOCUS 1.4 complète un jeu de données de détails de facture avec les champs qui figurent sur la facture émise, de la devise de paiement à la date d’échéance en passant par le numéro de commande. S’y ajoute un jeu de données de période de facturation qui connaît les limites de facturation réelles du facturateur. Qui a déjà essayé de calculer proprement une clôture mensuelle alors que la période de facturation d’un fournisseur ne commence pas le 1er du mois connaît la valeur de cette complémentarité apparemment sèche.

Au total, cela déplace ce qui est considéré comme une source fiable. La télémétrie de l’utilisation montre ce qui s’est passé techniquement. Ce n’est que la comparaison avec le détail de la facture qui montre ce qui a vraiment été calculé. Pour une équipe FinOps, c’est la différence entre un chiffre plausible et un chiffre prouvable.

Ce que les équipes de plateforme devraient changer avant la prochaine réservation

La conséquence évidente est un changement d’indicateur clé. Ce n’est pas la couverture brute qui doit figurer sur la diapositive, mais le taux de couverture ajusté à l’éligibilité plus le montant absolu en Euro, qui malgré l’éligibilité, est facturé aux conditions On-Demand. Ce deuxième chiffre est gênant. Il nomme l’argent qui est sur la table avant que quelqu’un ne justifie une nouvelle réservation de trois ans.

La deuxième étape est architecturale. Tant que la plateforme déduit ses décisions de coûts uniquement à partir des données d’utilisation, le détail de la facture reste un processus comptable secondaire. Il est plus judicieux de tirer les données de facturation comme source équivalente dans le pipeline de coûts et de les comparer à la télémétrie. Ce n’est que alors que Shift-Left dans FinOps porte plus qu’un simple slogan, parce que les chiffres auxquels les équipes de développement réagissent correspondent à la facture qui arrive en fin de mois.

Un indice sur l’attente appartient à cela. La spécification est ratifiée, les outils suivent.

Qui prépare aujourd’hui des décisions d’engagement devrait exiger la vue d’éligibilité maintenant, même si elle est provisoirement encore composée de champs spécifiques aux fournisseurs. Le standard fournit le langage pour cela. La confusion coûteuse entre couvrant et couvert peut maintenant être proprement nommée, et c’est la condition préalable pour l’éliminer.

Foire aux questions

Quelle est la différence entre Coverage et Eligibility ?

L’Eligibility décrit quelle utilisation est qualifiée pour un engagement. La Coverage décrit quelle proportion de cette utilisation qualifiée est réellement couverte. Une couverture élevée sur une base d’éligibilité faible peut masquer des coûts à la demande importants.

Que signifie exactement la colonne CommitmentProgramEligibilityDetails ?

Il s’agit d’un champ JSON sur l’ensemble de données de coûts et d’utilisation qui indique, pour chaque position, les programmes d’engagement pour lesquels cette position était qualifiée, indépendamment de l’applicabilité d’un engagement. Cela permet de calculer directement le taux de couverture ajusté à l’éligibilité à partir des données, sans logique spécifique au fournisseur.

À quoi servent les nouveaux ensembles de données Invoice Detail et Billing Period ?

Invoice Detail reproduit les champs de la facture émise, tels que la devise de paiement, la date d’échéance et le numéro de commande. Billing Period connaît les limites de facturation réelles du fournisseur. Ensemble, ils permettent une comparaison propre entre l’utilisation et la facture, même si les périodes de facturation ne suivent pas le mois civil.

À partir de quand peut-on tester FOCUS 1.4 en production ?

La spécification a été ratifiée le 4 juin 2026. Le validateur de conformité pour la version 1.4 est attendu au troisième trimestre 2026, d’ici là, la vérification formelle se fera par rapport à FOCUS 1.3. Les champs de données peuvent être utilisés dès que le fournisseur concerné les exporte.

Devons-nous reconfigurer nos outils FinOps maintenant ?

Pas immédiatement. Il est judicieux d’introduire le taux de couverture ajusté à l’éligibilité comme indicateur supplémentaire et de traiter la vérification de facture comme une source de données équivalente. Les deux peuvent être réalisés de manière transitoire avec des champs spécifiques au fournisseur, FOCUS 1.4 les standardise simplement.

Source de l’image : Générée par IA (juin 2026)

Images de l’article : Générées par IA (mai 2026)