Étude de cas
D'un hébergement VM à Kubernetes : migration par vagues pour une ETI
Comment une ETI a quitté son hébergement VM pour Kubernetes, avec supervision centralisée et sans interruption de service majeure.
Contexte
Une ETI faisait tourner ses applications sur un hébergement VM classique : serveurs provisionnés manuellement, déploiements longs, peu de visibilité sur l'état réel de l'infrastructure. Chaque montée de version demandait une fenêtre de maintenance, et l'équipe IT passait plus de temps à maintenir les machines qu'à faire évoluer le produit.
Défi
Moderniser l'infrastructure sans perturber l'activité métier : passer de VMs isolées à une orchestration Kubernetes, industrialiser les déploiements et mettre en place une supervision capable d'alerter avant que les utilisateurs ne subissent une panne.
Approche
- Assessment : cartographie des applications, des dépendances et des contraintes de bascule
- Landing zone Kubernetes : cluster, réseau, secrets, GitOps et conventions de déploiement
- Migration par vagues : conteneurisation progressive lot par lot, avec plan de rollback testé à chaque étape
- GitOps : pipelines GitLab, manifests versionnés, déploiements déclenchés depuis le dépôt
- Supervision : métriques, logs centralisés, alertes sur la santé du cluster et des applications
- Transfert de compétences : documentation et accompagnement des équipes sur kubectl, Helm et GitLab
Résultats
- Migration par vagues sans interruption de service majeure pour les utilisateurs
- Déploiements automatisés via GitOps (GitLab) — fini les manipulations manuelles sur chaque VM
- Supervision centralisée : dashboards, alertes proactives et traçabilité des incidents
- Architecture scalable : le cluster absorbe les montées en charge sans reprovisionner des serveurs un par un
Stack
Kubernetes, GitLab, GitOps, stack de supervision (métriques, logs, alertes).