VM vs Kubernetes : comment choisir la bonne infrastructure pour vos applications ?

On a consacré tout un épisode de notre podcast sur le sujet de la migration de ses VMs vers Kubernetes, et autour de la table, ça n'a pas manqué de débattre ! Dans cet article, on se concentre sur l'étape avant la migration : comment choisir la bonne infrastructure pour vos SI ? Et si vous avez déjà tranché pour Kubernetes et que vous voulez savoir comment migrer concrètement votre infrastructure, on a aussi un article dédié à ça : Comment migrer vos applications de VMs vers Kubernetes en 2026 ?

VM vs Kubernetes : on pose les bases de l'infrastructure

Kubernetes, Docker, VM… Avant d'aller plus loin, quelques définitions :

Une machine virtuelle (VM), c'est un système d'exploitation virtualisé qui tourne sur des machines physiques, avec un hyperviseur entre les deux. En termes de responsabilité c'est simple : tout ce qui est en dessous de la VM, c'est l'hébergeur qui s'en charge. Tout ce qui est au-dessus (configuration de l'OS, installation des apps, sauvegardes…), c'est vous.

Un conteneur Docker, c'est quelque chose de bien plus léger. Il n'y a pas de virtualisation complète de l'OS : il partage le kernel de la machine hôte, ce qui lui permet de consommer bien moins de ressources. Le principe, c'est de mettre plusieurs conteneurs sur une même machine, et de les faire tourner ensemble de manière bien plus efficace qu'avec des VMs.

Kubernetes (ou "Cube" comme on dit souvent), c'est l'orchestrateur qui va gérer tout ça : déploiement automatisé, planification, répartition de charge entre les conteneurs. C'est puissant mais ça se paye en complexité.

Et fun fact au passage : quand vous achetez un cluster Kubernetes chez un cloud provider, il tourne... sur des VMs ! Les VMs n'ont pas disparu, elles sont juste cachées plus bas dans la stack :)

Infrastructure SI : les différentes solutions d'hébergement de conteneurs

Kubernetes n'est pas le seul chemin dès qu'on parle de conteneurs. Il y a en réalité tout un spectre de solutions :

1. Hébergement d'un conteneur sur une VM, on le lance à la main ou via ligne de commande. C'est simple mais assez limité.
2. Docker Compose, on orchestre plusieurs conteneurs via un fichier de configuration. C'est une solution idéale pour les setups plus modestes.
3. Orchestrateurs managés (ECS sur AWS, Container Apps sur Azure), le cloud gère l'orchestration pour vous. C'est pratique, mais on maîtrise un peu moins les opérations.
4. Kubernetes autogéré ou managé (EKS, AKS, GKE...), la solution complète, avec tout le contrôle qu'elle implique.

La bonne question à se poser n'est donc pas vraiment "VM vs Kubernetes ?", mais plutôt "où est-ce que je me situe sur cette échelle par rapport à mes besoins réels ?"

Kubernetes c'est bien, mais pas pour tous le monde !

Spoiler : Kubernetes, c'est pas la solution universelle pour votre infrastructure. Kubernetes entraîne systématiquement une surcharge au niveau de la consommation de ressources. Alors le calcul est simple : si votre charge de travail n'est pas suffisante, vous allez consommer presque plus en infrastructure qu'en application réelle, ce qui serait plutôt dommage !

Kubernetes se justifie vraiment quand :

• Vous avez une charge de travail conséquente à faire tourner
• Vous avez des besoins de load balancing, de scalabilité automatique
• Vous gérez plusieurs applications à déployer et orchestrer
• Vous voulez reprendre la maîtrise de votre infra sans dépendre à 100% d'un cloud provider

Mais dans le cas d'une seule petite application avec peu de trafic, des alternatives plus légères feront très bien l'affaire : un simple docker compose, ou des solutions managées comme les Container Apps d'Azure ou leur équivalent chez AWS. Pas besoin de sortir l'artillerie lourde avec un Kubernetes à chaque fois :)

À l'inverse, même une seule application avec une très grosse volumétrie peut justifier Kubernetes. C'est la charge qui compte, pas le nombre d'applications de votre infra. Et au final, la question VM vs Kubernetes n'est pas si binaire que ça !

Maîtriser les coûts de votre infrastructure : Kubernetes vs services managés

La maitrise des coûts sur Kubernetes, c'est un sujet sur lequel beaucoup d'équipes se font surprendre. La bonne nouvelle : les coûts d'un cluster Kubernetes sont bien plus prévisibles que ceux de beaucoup de services managés. Vous payez des VMs (les nodes) à l'heure, vous savez exactement ce que vous avez commandé.

Les services serverless et autres solutions facturées à l'usage peuvent exploser si vous ne faites pas attention. Et comme on a trop souvent vu des factures cloud exploser à cause d'une architecture serverless mal calibrée, la tendance actuelle c'est justement de revenir vers des architectures reposant sur des nodes fixes pour reprendre la maîtrise des coûts !

Le défi au démarrage, c'est de bien sizer votre cluster ; mais on doit bien l'avouer, c'est difficile de connaître la charge réelle d'une application qu'on n'a pas encore fait tourner. C'est souvent après deux ou trois ans qu'on commence à vraiment optimiser finalement. Mais au moins, les surprises à la hausse sont rares, ce qui n'est pas toujours le cas avec du serverless ou des services managés à la consommation.

Infrastructure Kubernetes: vers la fin des VMs ?

VM vs Kubernetes, ce n'est pas une finalité en soit : ça dépend surtout de votre contexte ! Ce qui est sur c'est que recréer des VMs dans le cloud pour faire exactement pareil qu'avant, c'est inutile : vous n'avez aucun gain en coût, aucun gain en puissance, vous faites juste pareil ailleurs.

Par contre, certaines applications ne sont tout simplement pas faites pour tourner dans des conteneurs, que ce soit pour des raisons techniques, de licence, ou de dette legacy trop lourde à résorber. Dans ces cas-là, garder une VM est une décision tout à fait raisonnable, et un mix VM / Kubernetes en parallèle est une configuration courante.

VM vs Kubernetes : les 3 questions à se poser pour choisir votre infrastructure

Pour faire simple, avant de décider si Kubernetes est la bonne option pour vous, posez-vous 3 questions :

1. Est-ce que ma charge de travail le justifie ? Kubernetes, ça consomme des ressources rien qu'à tourner. Si vous avez une petite application avec peu de trafic, des solutions plus légères suffiront et vous coûteront moins cher.

2. Est-ce que mon équipe a les compétences pour le maintenir ? Ce n'est forcément pas une technologie facile d'accès. Il faut une comprendre du réseau, des concepts d'orchestration et de la sécurité des conteneurs. Se former avant de se lancer, c'est obligatoire !

3. Est-ce que je fais du Kubernetes pour les bonnes raisons ? "Parce que c'est hype" ou "parce que c'est ce que font les grandes boîtes", c'est tentant mais ce n'est pas une vraie raison. Si votre besoin réel peut être couvert par du docker-compose ou un service managé, partez plutôt sur ça.

Si vous avez répondu oui aux trois, alors vous êtes prêt à vous lancer ! Maintenant, le plus dur reste à faire. Pour vous aider dans votre migration vers Kubernetes, c'est par ici : Comment migrer vos applications de VMs vers Kubernetes en 2026 ?

Et si vous préférez nous avoir dans les oreilles plutôt que de nous lire, rendez-vous sur le podcast : https://www.youtube.com/watch?v=V_qkpBKK3r4