Comment migrer vos applications de VMs vers Kubernetes en 2026 ? Les étapes clés !

Alors, on vous arrête tout de suite, migrer vos applications de VMs vers Kubernetes, ce n'est pas fait pour tout le monde et en plus, ce n'est pas si simple que ça en a l'air ! On vous a donc créé un guide complet pour vous aider : audit applicatif, préparation du cluster, conteneurisation et pièges à éviter… Même si théoriquement la migration n'aura bientôt plus de secrets pour vous, gardez en tête qu'elle est différente pour chaque application et qu'il faut donc vous adapter !

Pourquoi migrer vos applications vers Kubernetes en 2026 ?

Avant, déployer une application, c'était réserver une VM, la configurer à la main, prier pour qu'elle tienne en prod, puis recommencer. Migrer vers Kubernetes n'était alors une perspective lointaine, réservée aux grandes équipes avec des moyens.

Aujourd'hui, en 2026, Kubernetes est partout : il est devenu la norme de l'orchestration, autant pour les vieux du terminal qui ont connu l'époque des VMs montées à la main que pour les juniors qui ont découvert l'infra directement avec des clusters.

Mais Kubernetes est aussi victime de son propre succès : on a tendance à migrer parfois vers Kube non pas parce qu'on en a réellement besoin, mais simplement parce que c'est devenu le standard. Pourtant, « faire du Kube pour faire du Kube », c'est souvent une erreur. Une migration doit répondre avant tout à un vrai besoin métier, et pas juste suivre une tendance tech.

D'ailleurs, vous saviez que le cluster Kubernetes que vous venez de provisionner chez votre cloud provider tourne lui-même sur des VMs ? Les VMs ne sont pas mortes, simplement plus discrètes !

Mais alors, avant de foncer tête baissée, comment savoir quand il faut migrer vos applications de VMs vers Kubernetes ? Est-ce que Kubernetes est réellement fait pour vous ? Est-ce vraiment la solution qui va vous permettre de déployer le cœur léger ? La réponse ci-dessous, ou si vous préférez nous écouter, on a aussi fait un podcast sur le sujet !

Est-ce que Kubernetes est fait pour vous ?

Kubernetes apporte énormément de choses : scalabilité, résilience, automatisation... Mais il faut savoir qu'il apporte aussi son lot de complexité, et cette partie-là, on en parle moins d'habitude.

Alors avant de foncer tête baissée dans Kubernetes, pensez à vos besoins ! En règle générale, si vous avez un gros volume d'applications à héberger et que vous voulez maîtriser toutes les couches : Kubernetes est fait pour vous !

A contrario, si vous ne souhaitez pas maitriser toutes les couches, Kube n'est pas le plus adapté. Il existe des services qui sont une surcouche comme ECS, AzureAzure est la plateforme de Cloud de Microsoft. Container Apps ou encore Scaleway Container ServerlessLe terme serverless se dit d'un traitement qui ne nécessite pas de serveur (à comprendre ici : dont on ne s'occupe pas du serveur) par exemple pour ce genre de cas. Et puis, si vous avez peu d'applications et peu de besoin d'orchestration ou de scalabilité, il faut plutôt se tourner vers un service managé ! Déployer sur Kubernetes pour une application, même pour s'amuser, ça n'en vaut pas la peine.

Avant de démarrer, il faut donc bien analyser vos applications, leurs contraintes et leurs dépendances pour déterminer si Kubernetes est réellement la bonne cible pour votre projet. Si, après cette phase d'analyse, Kubernetes apparaît comme la bonne solution, alors vous pouvez vous lancer !

La suite ressemble un peu à une notice Ikea : on avance étape par étape, on suit le plan et, normalement, on évite de finir avec trois vis en trop :) 

Étape 1 : Réaliser un audit de vos applications avant de les migrer vers Kubernetes

Note en haut de la notice : Si jamais on ne souhaite pas migrer ses applications sur VMs sur Kubernetes, mais sur un service managé, on retrouve bien souvent les mêmes contraintes en lien avec la conteneurisation de l'application. Cette phase d'audit peut donc s'appliquer dans tous les cas !

Avant de se lancer dans une migration de vos applications VMs vers K8S, il faut déjà savoir ce qu'on a entre les mains. Ça paraît évident, mais beaucoup de projets commencent par : « Yeah ! On va faire du Kubernetes ! » avant même d'avoir pris le temps de regarder l'existant.

La première étape est donc de faire un état des lieux des applications et de réaliser un audit, mais attention, ce n'est pas juste un sujet d'infra : c'est un vrai travail collaboratif entre les équipes Dev et Infra.

Il faut donc comprendre comment les applications communiquent, cartographier les dépendances, identifier les bases de données, les API externes, les stockages, les tâches planifiées, les échanges réseau, etc. Une application n'est presque jamais juste un exécutable qui tourne tout seul dans son coin, elle est plutôt comme un des rouages d'un écosystème bien plus grand.

Il faut ensuite se poser les bonnes questions :

• L'application peut-elle être conteneurisée dans Docker ?
• Est-elle stateless ? (une app stateful est possible mais complexifie la migration)
• Peut-elle tourner en multi-instances ?
• Y a-t-il des WebSockets ?
• Y a-t-il des accès disque partagés (NFS, montages réseau) ?
• Y a-t-il des cron jobs pouvant se lancer en doublon ?
• Y a-t-il une dette technique (extensions inutilisées, dépendances fantômes) ?

Il n'y a pas de bonne ou de mauvaise réponse, elles vont surtout vous permettre de savoir à quoi s'attendre avant de se dire : "Ok, let's go !"

Il y a aussi des cas où la réponse n'est pas forcément évidente ; une vieille application Windows Server héritée d'un autre temps, par exemple. Elle n'a alors parfois pas beaucoup d'intérêt à être conteneurisée. À ce moment-là, il faut peser le pour et le contre : est-ce que l'effort demandé vaut réellement le gain obtenu ?

Il n'y a aucune règle qui dit qu'il faut tout migrer d'un coup : il est conseillé de conserver certains composants en VM, notamment les parties plus legacy, et de ne migrer que ce qui apporte une vraie valeur. Et si votre application est déjà conteneurisée sur la VM, c'est un gros plus ! C'est une bonne étape de transition avant de sauter le pas directement dans un Kubernetes. Et puis bonus, il faut aussi bien vérifier si l'application est container ready :)

La première page de la notice est vérifiée.

Étape 2 : Préparer l'infrastructure Kubernetes

La page de la notice que tout le monde zappe pour aller plus vite et qui explique pourquoi il reste toujours 3 vis à la fin.

Même si aujourd'hui créer un cluster sur Kubernetes ne semble pas être si compliqué, ça ne s'improvise pas, il faut un peu d'expérience en la matière avant de le faire, et surtout pour un cluster de production !

Le vrai sujet, c'est plutôt tout ce qu'il y a autour du cluster, parce qu'un cluster vide ne fait pas grand-chose tout seul, il faut préparer le terrain avant d'y envoyer les applications : réseau, namespaces, ingress, sécurité, gestion des accès, etc… Toute cette partie qu'on a tendance à mettre de côté au début parce qu'on veut rapidement déployer.

Il y a aussi un sujet qui fait débat : vouloir tout automatiser dès le premier jour. Sortir Terraform, écrire toute l'infrastructure complète, gérer tous les cas possibles, etc. Cela risque d'être long, mais c'est un beau cadeau que l'on se fait pour la suite.

En effet, le cluster Kubernetes que l'on crée pour effectuer des tests n'a pas forcément besoin d'être provisionné avec Terraform. En revanche, une fois que Kubernetes a été éprouvé et que l'on est certain qu'il fonctionne correctement, il est important d'utiliser Terraform dès l'environnement de recette. Si toutes les configurations sont réalisées à la main, on ne pourra pas garantir que les tests effectués en recette fonctionneront également en production, alors qu'avec Terraform, vous pouvez dormir sur vos deux oreilles.

Le mieux, c'est généralement d'avancer progressivement : versionner son infrastructure, construire les briques au fur et à mesure, et prendre le temps de valider ce qui est mis en place.

Si jamais vous souhaitez versionner, les commandes kubectl lancées dans tous les sens directement sur le cluster, ce n'est pas votre meilleure option. Au début, on se dit que ce n'est qu'une petite modification de rien du tout, puis une deuxième arrive, puis une troisième... Et quelques semaines plus tard, plus personne ne sait pourquoi telle ressource existe ni pourquoi elle est configurée comme ça. On finit alors avec un cluster qui ressemble à un vieux grenier où on a empilé des choses pendant des années : ça fonctionne encore, mais plus personne n'a envie de regarder dedans.

On vous conseille plutôt de miser sur un bon combo Terraform et Helm, qui permettent tous les deux de versionner, mais pas la même chose et qui sont donc complémentaires. Terraform, c'est l'infrastructure et Helm, la configuration Kubernetes. Votre grenier est alors bien construit grâce à Terraform et bien aménagé avec Helm.

On n'oublie pas non plus les bases qu'on avait déjà avec les VMs : séparer ses environnements reste indispensable (recette, préproduction, production, etc.) !

Il y a aussi le cas qui arrive parfois au milieu du projet : le on-premise ! Là, on ajoute une couche supplémentaire à l'histoire avec du VPN, du réseau hybride, des contraintes existantes et des systèmes qu'on ne peut pas simplement remplacer du jour au lendemain. Ce n'est pas insurmontable, mais ça se prépare, parce qu'on en est pas fan de ce genre de surprise découverte en milieu de migration.

À ce stade, la plupart des gens se rendent compte que créer le cluster, c'était la partie la plus simple, et ils avaient raison !

Étape 3 : Conteneuriser et déployer vos applications sur Kubernetes

Ok, maintenant on sait que Kubernetes correspond au besoin, on a fait le point sur l'existant et l'infrastructure est prête, on peut donc enfin commencer à conteneuriser et déployer.

Par contre, ce n'est toujours pas le moment d'appuyer sur le gros bouton « tout migrer ».

L'erreur classique, c'est de vouloir déplacer tout le système d'un seul coup, mais mieux vaut traiter chaque application indépendamment. Ça permet d'avancer progressivement, de corriger les problèmes au fur et à mesure et surtout d'éviter un énorme chantier, impossible à débugger.

• On commence généralement par construire l'image Docker de l'application puis définir les manifestes Kubernetes : Deployment, Service, Ingress, etc.
• Ensuite vient une partie un peu moins visible mais très importante : définir comment les applications communiquent entre elles. Avec les NetworkPolicies, par exemple, l'idée n'est pas d'autoriser tout le monde à parler avec tout le monde. Ouvrir tous les flux peut sembler pratique au départ, mais c'est souvent le meilleur moyen de se retrouver avec une immense autoroute réseau à l'intérieur du cluster.
• Il ne faut pas oublier les Liveness et Readiness probes. Kubernetes n'est pas tout puissant : il faut lui expliquer quand une application est réellement prête et quand elle ne l'est plus.

Petit conseil de fin de notice : Allez-y étape par étape

• Déployer le container tout seul
• Rajouter la couche sécurité
• Rajouter la couche monitoring

On peut facilement oublier les deux dernières couches et s'arrêter au "Ça marche !", mais Kubernetes n'est pas sécurisé par défaut (bien au contraire), et il ne se monitore pas tout seul… Il est donc important de se donner les outils pour voir ce qu'il se passe dans le Kube.

Bases de données et Kubernetes : service managé ou dans le cluster ?

Il y a toujours ce sujet qui finit par arriver quand on parle de migrer ses applications vers Kubernetes : les bases de données. Est-ce qu'il faut les mettre dans le cluster ou utiliser un service managé type RDS, Cloud SQL ? Les deux camps ont de bons arguments.

Les services managés ont beaucoup pour eux : backups automatiques, snapshots, restauration, haute disponibilité et peu de gestion opérationnelle à faire derrière ; vous payez, ça tourne, vous dormez tranquillement. Le problème, c'est que vous payez, et pas qu'un peu, surtout dans une architecture micro-services où on se retrouve avec une dizaine de petites bases, et un service managé par base : ça chiffre très, très vite.

C'est là que les bases dans le cluster reprennent du sens ! Si vous avez déjà un cluster qui tourne, y faire tourner vos bases ne coûte pas grand-chose de plus.

Aujourd'hui, les opérateurs Kubernetes changent un peu la donne, des outils comme CloudNativePG prennent en charge une bonne partie des sujets compliqués : réplication, backup, failover, etc. et alors l'écart avec le service managé se réduit. Mais attention, il faut toujours vérifier que tout fonctionne correctement et soit bien configuré, car si jamais l'opérateur change d'une version à une autre et qu'on se retrouve sans backup, ça peut vite être embêtant.

Il y a quelques années, mettre une base de données dans Kubernetes laissait perplexe, aujourd'hui le débat est moins clair, et dans quelques années, tous les produits auront sûrement leur opérateur bien maintenu.

Donc la vraie réponse à "Base de donnéesUne base de données (ou BDD), est un ensemble d'informations stockées dans un dispositif informatique. dans le cluster ou service managé ? " : bah, ça dépend, de votre charge, de votre architecture, de votre envie à gérer vous-même… En gros, ça dépend du prix de votre tranquillité. Si ce prix est trop élevé, il va alors falloir faire le tout vous-même et ça va demander de la maintenance.

Les erreurs à éviter lors d'une migration vers Kubernetes

Ou ce qui arrive quand on a appuyé sur le gros bouton rouge sans lire la notice.

Pour éviter quelques coups de panique pendant une migration, il y a des pièges qui reviennent régulièrement et auxquels vous pouvez vous préparer :

• Bien spécifier les ressources de vos containers. Si vous ne définissez pas de limits et de requests, Kubernetes ne saura pas quelle quantité de ressources vous donner. Dans ce cas, votre conteneur est le dernier de ses soucis, et en cas de problème, ce sera votre application qui disparaîtra la première du cluster.
• « Mon pod s'est arrêté tout seul ». Souvent, il y a une explication ! Kubernetes est une vraie pipelette et le problème est surtout de savoir où regarder : logs des pods, événements du cluster, describe, métriques etc. Avant de penser à un bug mystérieux, il faut commencer par jouer les Sherlock Holmes et bien analyser chaque détail de votre architecture.
• Sous-estimer l'importance des logs. Un pod qui démarre puis s'arrête immédiatement peut disparaître avant même qu'on ait eu le temps de comprendre ce qu'il s'est passé. Centraliser des logs devient alors indispensable.
• Penser que Kubernetes résout tous les problèmes. Les sujets identifiés pendant l'audit ne disparaissent pas par magie une fois dans Kubernetes. Les WebSockets, le stockage partagé ou certaines dépendances un peu particulières sont souvent les mêmes et finissent par provoquer des incidents en production.
• Négliger la sécurité réseau. Kubernetes est généralement plus riche qu'un simple firewall VM, mais aussi un peu plus complexe. Ce n'est pas forcément la partie la plus amusante à mettre en place, mais c'est rarement celle qu'on regrette d'avoir faite correctement.

Conclusion : faut-il vraiment migrer ses applications de VMs vers Kubernetes en 2026 ?

Migrer vos applications de VMs vers Kubernetes n'est pas aussi simple que ça, faire les choses proprement demande de la méthode et de la rigueur : comprendre l'existant, préparer un socle solide puis avancer application par application.

Aujourd'hui, Kubernetes s'est installé assez naturellement comme un standard, même pour des équipes qui n'ont jamais connu l'époque où l'on configurait des VMs à la main. Mais il n'a pas remplacé les VMs ni ne les a fait disparaître, elles sont juste un peu plus discrètes qu'avant.

Au final, Kubernetes n'a pas changé ce qu'on exécute, il a surtout changé la manière dont on pense et gère nos workloads.

Et si vous deviez retenir une seule chose : ne migrez pas parce que vous en entendez parler partout, migrez parce que vous en avez besoin. Le reste : l'audit, les manifests, les nuits à débugger des probes, ça s'apprend avec le temps.

Pour aller plus loin que ce guide, on a justement enregistré un épisode de podcast sur le sujet avec la team AXOPEN. Vous y retrouverez des retours d'expérience terrain sur la migration des applis hébergées sur des VMs vers Kubernetes : les prérequis, les bonnes pratiques, les outils indispensables et aussi, les questions qui fâchent ! Et pour tous ceux qui se lancent, bonne migration à vous :)