Kubernetes gaspille votre budget cloud : ce que les DSI européens commencent à comprendre

# Kubernetes gaspille votre budget cloud : ce que les DSI européens commencent à comprendre

Vous avez migré vers Kubernetes il y a deux ou trois ans, convaincu que l'orchestration de conteneurs allait rationaliser vos coûts d'infrastructure. Aujourd'hui, votre facture cloud ressemble à un relevé bancaire que vous n'osez plus ouvrir. Ce n'est pas une malchance. C'est une tendance documentée, et elle touche une grande partie des organisations qui ont déployé Kubernetes sans accompagner la bascule d'une vraie discipline FinOps.

Le problème n'est pas Kubernetes. C'est la façon dont on l'utilise.

Kubernetes est un outil remarquable. Il a standardisé le déploiement applicatif d'une manière qui semblait impossible il y a dix ans. Mais cette flexibilité a un revers : elle permet aussi de surprovisioner massivement sans que personne ne s'en aperçoive immédiatement.

Le mécanisme est bien connu des équipes plateforme. Les développeurs définissent des *requests* et des *limits* CPU/mémoire pour leurs pods. Par précaution — ou par manque de données réelles sur la consommation — ils surchargent ces valeurs. Le cluster réserve des ressources qui ne seront jamais utilisées. Les nœuds tournent à 20 ou 30 % de leur capacité réelle. Et le fournisseur cloud, lui, facture à la ressource allouée, pas à la ressource consommée.

Ajoutez à cela des namespaces qui prolifèrent, des environnements de développement et de staging qui restent allumés le week-end, des PersistentVolumes orphelins qui s'accumulent, et vous obtenez un gaspillage structurel qui s'installe silencieusement dans votre organisation.

Ce n'est pas un problème technique au sens strict. C'est un problème de gouvernance et de visibilité.

Pourquoi ce sujet remonte maintenant dans les comités de direction

Depuis 2024, la pression sur les budgets IT s'est durcie dans la plupart des ETI et PME européennes. Le cycle d'euphorie du cloud — où l'élasticité justifiait des sur-dépenses temporaires — est terminé. Les directions financières ont appris à lire une facture AWS ou Azure, et elles posent des questions auxquelles les DSI peinent parfois à répondre précisément.

En parallèle, la maturité Kubernetes a progressé. Les organisations qui ont déployé leurs premiers clusters il y a trois ou quatre ans arrivent aujourd'hui à un stade où la question n'est plus "est-ce que ça tourne" mais "est-ce que ça tourne de façon acceptable financièrement". Ce passage de la phase d'adoption à la phase d'optimisation est un moment charnière.

Il y a aussi une dimension réglementaire qui change les arbitrages. Le Data Act européen, entré en application, et les exigences croissantes liées à NIS2 poussent certaines organisations à requalifier leurs charges de travail selon leur sensibilité. Ce mouvement de cartographie crée une opportunité : si vous devez de toute façon auditer ce qui tourne où, autant en profiter pour rationaliser la ressource.

La question souverainete : pertinente, mais pas pour les raisons qu'on croit

Quand on parle d'optimisation Kubernetes dans un contexte européen, la souveraineté s'invite naturellement dans la conversation. Mais pas toujours pour les bonnes raisons.

L'argument souvent entendu est celui du coût : "migrer vers un fournisseur cloud européen permettrait de réduire la facture". C'est une simplification qui mérite d'être questionnée. Le coût brut des ressources compute n'est pas systématiquement inférieur chez un acteur européen. Ce n'est pas l'argument le plus solide.

En revanche, il y a deux angles où la dimension souveraine devient réellement opérationnelle pour un DSI.

Le premier, c'est le contrôle des données de supervision. Quand vous utilisez les outils d'observabilité natifs d'un grand hyperscaler américain pour piloter votre cluster Kubernetes, vos métriques d'utilisation, vos logs applicatifs, vos traces de performance transitent et sont stockés dans une infrastructure soumise au droit américain — notamment au Cloud Act. Pour des charges de travail sensibles, industrielles ou soumises à des contraintes sectorielles, c'est un risque que certains RSSI commencent à documenter formellement.

Le second angle, c'est la dépendance aux abstractions propriétaires. Les services managés Kubernetes des hyperscalers — EKS, AKS, GKE — fonctionnent très bien, mais ils créent des dépendances à des couches d'intégration spécifiques qui compliquent une éventuelle réversibilité. Ce n'est pas de la théorie : des DSI qui ont voulu changer de fournisseur après trois ans de fonctionnement ont découvert que leur Kubernetes n'était plus vraiment standard.

Ce que font concrètement les équipes qui s'en sortent mieux

Observer les organisations qui ont réussi à reprendre le contrôle de leur consommation Kubernetes permet de dégager quelques constantes — sans prétendre à l'exhaustivité.

La première, c'est l'instrumentation avant l'action. Impossible d'optimiser sans visibilité fine sur la consommation réelle. Des outils comme Opencost — projet open source issu de la CNCF — permettent d'associer un coût à chaque namespace, chaque workload, chaque équipe. Ce travail de *cost allocation* est souvent la révélation qui débloque les discussions internes : quand une équipe produit voit que son environnement de recette coûte autant que son environnement de production, les comportements changent.

La deuxième, c'est la politique de *rightsizing* outillée. Revoir manuellement les requests et limits de chaque déploiement est une tâche impossible à l'échelle. Des mécanismes comme le Vertical Pod Autoscaler, utilisé en mode recommendation sans application automatique dans un premier temps, permettent de collecter des données réelles et de proposer des ajustements argumentés aux équipes de développement. L'objectif n'est pas de contraindre, mais de donner aux développeurs des données qu'ils n'avaient pas.

La troisième, c'est la gestion des environnements non-production. Une partie significative du gaspillage se concentre là. Des pratiques simples — extinction programmée des clusters de développement hors des heures ouvrées, limitation stricte des ressources dans les namespaces de staging — peuvent produire des effets visibles relativement rapidement.

Sur la dimension outillage souverain, Scaleway — pour ne citer qu'un acteur — propose une offre Kubernetes managée (Kapsule) hébergée en Europe, avec des outils d'observabilité intégrés dont les données restent sous juridiction européenne. Ce n'est pas une solution universelle, et migrer un cluster existant n'est jamais anodin. Mais pour de nouveaux projets ou des charges de travail sensibles, c'est une option qui mérite d'être évaluée sérieusement plutôt que d'être écartée par défaut.

Dans le domaine de l'observabilité spécifiquement, des acteurs comme Coroot — stack open source d'observabilité orientée eBPF — permettent de déployer une solution de supervision complète en mode self-hosted, sans que vos données de performance ne quittent votre périmètre. C'est un choix d'architecture, pas un choix commercial. Mais il répond à une vraie question que certains RSSI posent maintenant par écrit.

Ce que ça implique pour votre organisation

La réalité opérationnelle, c'est que l'optimisation Kubernetes n'est pas un projet ponctuel. C'est une discipline continue qui nécessite une collaboration entre les équipes plateforme, les équipes de développement et la direction financière. Sans ce triangle de responsabilité, les gains obtenus lors d'une campagne d'optimisation s'érodent en quelques mois au gré des nouveaux déploiements.

Cela implique de faire évoluer certaines pratiques organisationnelles. Les équipes de développement doivent être responsabilisées sur le coût de leurs ressources — pas punitiver, mais informées en temps réel. Les équipes plateforme doivent sortir d'une posture purement technique pour jouer un rôle de conseil et d'alerte sur les dérapages. Et la DSI doit se doter d'indicateurs de suivi qui remontent au niveau direction.

Sur la question de la souveraineté, le conseil le plus honnête est celui-ci : ne refaites pas votre architecture pour des raisons idéologiques. En revanche, si vous êtes en train de repenser votre plateforme pour des raisons d'optimisation — ce que beaucoup font en ce moment — c'est le bon moment pour intégrer la question de la réversibilité et du contrôle des données dans vos critères de choix. C'est nettement moins coûteux d'y penser en amont qu'en sortie de contrat.

Pour conclure : Kubernetes n'est pas le problème

Kubernetes a tenu ses promesses sur le plan technique. Le problème, c'est que nous avons collectivement sous-estimé la discipline organisationnelle que sa mise en œuvre à l'échelle requiert. Ce n'est pas la première fois qu'une technologie puissante génère des coûts cachés importants quand elle est adoptée sans accompagnement.

La question ouverte — et elle mérite d'être posée dans vos propres organisations — c'est de savoir si vous avez aujourd'hui la visibilité suffisante pour savoir ce que chaque euro dépensé sur votre infrastructure Kubernetes produit réellement. Pas en théorie, pas dans un PowerPoint de justification budgétaire. En pratique, workload par workload.

Si la réponse est non, c'est peut-être par là qu'il faut commencer. Avant de parler de migration, de souveraineté ou d'optimisation, il faut d'abord voir clairement. Et ça, c'est un travail que vous pouvez commencer cette semaine.