À retenir

  • La facture Kubernetes explose parce que ses deux moteurs, les requests des pods et la capacité de nœud inactive, sont invisibles par défaut. Vous payez la capacité réservée, pas l’usage.
  • Le FinOps est une boucle, pas un projet : Inform (rendre la dépense visible par équipe), Optimize (dimensionner, spot, autoscaling), Operate (empêcher le retour du gaspillage).
  • Le plus gros levier est le dimensionnement. Le rapport 2026 de Cast AI situe le surprovisionnement CPU autour de 69 % — pour l’essentiel du pur gaspillage.
  • Le spot combiné à l’autoscaling retire 70 à 90 % de la facture de calcul sur les bons workloads ; la gouvernance-as-code empêche les économies de s’éroder dès que l’attention se déplace.
  • Les équipes sans pratique FinOps gaspillent environ 32 à 40 % de leur dépense cloud ; les équipes matures ramènent ce chiffre à 15–20 %.

Kubernetes a rendu le calcul élastique. Il a aussi rendu la facture opaque. Un cluster planifiera volontiers des pods qui demandent huit fois le CPU qu’ils consomment, laissera tourner des nœuds à moitié vides toute la nuit, et ne dira jamais à la finance quelle équipe en est responsable. Résultat : une ligne budgétaire qui croît plus vite que le trafic, et une réunion trimestrielle que personne n’apprécie.

Ce n’est pas un manque d’outillage que l’on comble en achetant une solution. C’est une discipline : le FinOps appliqué à la mécanique propre de Kubernetes. D’après les travaux de la CNCF sur le FinOps pour Kubernetes, 68 % des organisations ont vu leurs coûts Kubernetes augmenter, dont environ la moitié au-delà de 20 %. Les équipes qui inversent la tendance ne trouvent pas un tableau de bord magique. Elles rendent la dépense visible, agissent sur le gaspillage, et posent des garde-fous pour qu’il ne revienne pas.

Pourquoi la facture Kubernetes est invisible par défaut

Vous êtes facturé sur la capacité que vous réservez, pas sur celle que vous utilisez. Le champ resources.requests d’un pod réserve du CPU et de la mémoire sur un nœud, que le workload y touche ou non. Fixez ces requests comme une marge de sécurité confortable, multipliez par des centaines de pods, et le scheduler organise les nœuds autour de nombres sans grand rapport avec la réalité. L’écart entre le demandé et l’utilisé, c’est le gaspillage — et rien, dans un cluster par défaut, ne le fait remonter.

Le second nombre invisible est la capacité de nœud inactive. Quand les requests sont gonflées, le scheduler ne peut pas empaqueter serré, et vous faites tourner plus de nœuds que le workload réel n’en exige. Chaque nœud est une instance entière sur la facture. Aucun des deux n’apparaît sur l’invoice du fournisseur cloud, qui rapporte des instances et des disques, pas des namespaces et des équipes. Ce décalage comptable est le cœur du problème : la facture cloud parle le langage de l’infrastructure, tandis que vos responsables de coût raisonnent dans le langage des applications.

Le FinOps est une boucle, pas un nettoyage ponctuel

Le FinOps, tel que défini par la FinOps Foundation, repose sur trois phases qui se répètent : Inform, Optimize, Operate. Inform, c’est la visibilité : allouer la dépense aux équipes et aux applications qui la génèrent, pour que le coût ait un propriétaire. Optimize, c’est l’action : dimensionner les requests, basculer le tolérant aux pannes sur du spot, éliminer les ressources inactives, appliquer les remises d’engagement. Operate, c’est la durabilité : suivre le coût par rapport aux objectifs métier en continu pour que les économies ne se dégradent pas.

La plupart des chantiers de réduction échouent parce qu’ils s’arrêtent après un seul passage d’optimisation. Quelqu’un consacre un sprint au dimensionnement, la courbe baisse, et six mois plus tard elle est revenue à son point de départ parce que rien n’a changé le comportement qui produisait le gaspillage. La boucle est tout l’intérêt. Un nettoyage ponctuel est un instantané ; le FinOps est la pratique qui tient la ligne.

Dimensionnement : cessez de payer des requests que vous n’utilisez pas

Le dimensionnement est le levier le plus puissant disponible, car les requests surdimensionnées sont la racine des deux coûts invisibles. Le rapport 2026 de Cast AI sur le coût Kubernetes mesure un surprovisionnement CPU d’environ 69 % sur les clusters analysés : pour trois cœurs réservés, deux restent inactifs et facturés. Ramenez les requests vers l’usage réel et deux choses se produisent en même temps : le gaspillage de réservation disparaît, et le scheduler empaquette sur moins de nœuds.

Le mécanisme est simple, mais facile à rater à la main. Le Vertical Pod Autoscaler observe la consommation réelle et recommande des requests à partir des données plutôt que d’une supposition anxieuse. Lancez-le d’abord en mode recommandation, lisez les chiffres, puis appliquez. Fixez les requests au régime permanent réel du workload, gardez des limits raisonnables pour protéger les voisins bruyants, et réévaluez quand les profils de trafic évoluent. C’est un travail ingrat, et c’est là que se trouve l’essentiel de l’argent.

Spot et autoscaling : 70 à 90 % de moins sur les bons workloads

Les instances spot offrent la plus forte remise unitaire du cloud, généralement 70 à 90 % sous l’on-demand, et en 2026 la gestion des interruptions est assez mature pour un usage en production. Le piège est que le fournisseur peut reprendre la capacité avec un court préavis : le spot est donc réservé au travail qui tolère la disparition d’un nœud — services sans état derrière un load balancer, batch et CI, tout ce qui se replanifie proprement. Les singletons avec état et les chemins critiques en latence restent sur l’on-demand.

L’outil qui rend cela praticable est un autoscaler conscient des workloads. Karpenter provisionne les nœuds au plus près des pods en attente, mélange spot et on-demand selon une politique, et draine gracieusement les nœuds interrompus pour qu’une reprise soit un non-événement plutôt qu’un incident. Associez le spot à des requests serrées et vous cumulez les gains : moins de nœuds, et chaque nœud bien moins cher. C’est cette combinaison qui transforme une facture inquiétante en facture ennuyeuse.

Gouvernance-as-code : empêcher les économies de refluer

L’optimisation s’érode dès que l’attention se déplace, à moins que les garde-fous ne vivent dans le cluster. C’est là que les moteurs de politique prennent tout leur sens : Kyverno et Open Policy Agent permettent d’encoder les règles de coût en politique d’admission, pour que le cluster refuse le gaspillage avant même sa planification. Rejeter les pods sans requests, plafonner les requests surdimensionnées, bloquer les workloads qui réclament l’équivalent d’un nœud entier de mémoire sans justification, exiger le label de centre de coût qui rend l’allocation possible.

Le glissement va du nettoyage à la prévention. Un sprint de dimensionnement corrige le gaspillage d’hier ; une politique d’admission empêche celui de demain d’être créé. La politique-as-code est aussi ce qui permet à une petite équipe plateforme de tenir la ligne sur des dizaines de clusters et des centaines de développeurs sans devenir un guichet manuel. Le garde-fou s’exécute à chaque apply, pour toujours, et ne se fatigue jamais.

Les métriques qui font vraiment bouger la facture

La dépense cloud totale est un chiffre retardé qui ne dit rien d’actionnable. Les métriques qui pilotent les décisions sont le coût par namespace, le coût par application, l’utilisation CPU et mémoire, et le pourcentage de ressources inactives. Le coût par namespace donne un propriétaire au gaspillage. L’utilisation dit si les requests collent à la réalité. Le pourcentage d’inactivité, c’est la marge que vous payez sans l’utiliser.

OpenCost, projet CNCF, alloue la dépense cloud réelle au niveau du namespace, du contrôleur et du pod, traduisant la facture d’infrastructure dans le langage applicatif dans lequel vos équipes raisonnent. Cette traduction est tout l’enjeu. Dès qu’une équipe voit son propre chiffre et qu’elle est mesurée dessus, le comportement change sans qu’aucun mandat ne soit émis. La visibilité assortie de la responsabilité fait plus que n’importe quelle optimisation isolée, parce qu’elle fait de l’optimisation le travail de quelqu’un.

Là où les équipes se bloquent

Le schéma que nous voyons se répéter : une équipe sait que la facture est trop élevée, mène un passage héroïque de dimensionnement, économise 30 % pendant un trimestre, et la regarde remonter parce que rien n’a opérationnalisé la discipline. Le manque est rarement la connaissance de ce qu’il faut faire. C’est le câblage qui rend la chose durable : une allocation en laquelle chaque équipe a confiance, un autoscaling et un spot configurés pour le vrai mix de workloads, et une politique qui tient la ligne sans humain dans la boucle.

Ce câblage relève du platform engineering, et c’est ce que nous construisons. Nous traitons le coût comme une propriété de la plateforme, réconciliée en continu au même titre que la fiabilité et la sécurité, et non comme un tableur que quelqu’un rapproche en fin de trimestre. L’objectif est un cluster où la voie économique et la bonne voie ne font qu’une, imposée par le système plutôt que par la vigilance.

Réponses directes

Questions fréquentes

Qu'est-ce que le FinOps Kubernetes ?

Le FinOps Kubernetes réunit l'ingénierie, la finance et les opérations pour maîtriser le coût des workloads sur Kubernetes. Il suit la boucle Inform, Optimize, Operate de la FinOps Foundation : rendre la dépense visible par équipe et par application, agir sur le gaspillage via le dimensionnement et le spot, puis opérer en continu.

Pourquoi les coûts Kubernetes sont-ils si difficiles à maîtriser ?

Parce que les deux nombres qui pilotent la facture, les requests des pods et la capacité de nœud inactive, sont invisibles par défaut. Un cluster vous facture la capacité réservée, pas l'usage : des requests surdimensionnées et des nœuds à moitié vides gonflent la dépense sans que personne ne possède ce gaspillage.

Qu'est-ce que le dimensionnement (rightsizing) sur Kubernetes ?

Le dimensionnement aligne les requests CPU et mémoire d'un workload sur ce qu'il consomme réellement. La plupart des équipes surdimensionnent par prudence ; le rapport 2026 de Cast AI mesure un surprovisionnement CPU proche de 69 %. Le Vertical Pod Autoscaler recommande des requests fondées sur l'usage observé plutôt que sur une supposition.

Combien les instances spot font-elles économiser sur Kubernetes ?

Les instances spot (ou préemptibles) réduisent généralement le coût de calcul de 70 à 90 % par rapport à l'on-demand. La contrepartie est l'interruption : un nœud peut être repris avec un court préavis. Les workloads tolérants aux pannes, sans état et batch sont les bons candidats, idéalement planifiés par un autoscaler comme Karpenter.

Quelles métriques de coût une équipe Kubernetes doit-elle suivre ?

Allez au-delà de la dépense cloud totale. Suivez le coût par namespace, le coût par application, l'utilisation CPU et mémoire, et le pourcentage de ressources inactives. Ces chiffres révèlent où va l'argent et qui en est responsable. OpenCost, projet CNCF open source, alloue la dépense au niveau du namespace et du workload.

Faut-il un outil FinOps, ou peut-on démarrer en open source ?

Vous pouvez démarrer en open source. OpenCost fournit l'allocation par namespace, Kyverno impose des garde-fous de coût sous forme de politique, et le Vertical Pod Autoscaler pilote le dimensionnement. Les plateformes commerciales ajoutent l'automatisation et le reporting multi-cluster, mais c'est la discipline, pas l'outil, qui fait bouger la facture.