Depuis que Broadcom a finalisé son rachat de VMware, le calcul économique d’une infrastructure virtualisée a changé. Les licences perpétuelles ont disparu, le portefeuille s’est réduit à une poignée de bundles par abonnement, et la tarification est passée à un modèle par cœur. Les devis de renouvellement reviennent généralement 2 à 5 fois plus élevés que ce que les équipes payaient auparavant. Pour de nombreux CTO et architectes à travers l’Europe, la question n’est plus « faut-il regarder les alternatives » mais « vers quoi migrer, et dans quel ordre ».
Ceci est un playbook, pas un argumentaire commercial. Nous sommes un cabinet de conseil en ingénierie, pas un fournisseur de cloud, et nous n’avons donc aucune plateforme à vous vendre. L’objectif est de vous donner les concepts, les standards ouverts et une cartographie honnête des options afin que vous puissiez prendre une décision adaptée à votre stack.
Pourquoi les équipes quittent VMware
Les facteurs sont les mêmes dans toutes les organisations avec lesquelles nous échangeons :
- Le coût. La licence par cœur pénalise les hôtes à forte densité. Un serveur à deux sockets équipé de deux CPU de 16 cœurs, qui nécessitait auparavant deux licences CPU, compte désormais pour 64 cœurs. Combiné à la consolidation des bundles, de nombreux renouvellements dépassent largement les dépenses antérieures.
- Le bundling. vSphere, vSAN, NSX et la suite Aria sont désormais regroupés dans de larges abonnements comme VMware Cloud Foundation (VCF) et vSphere Foundation (VVF). Si vous n’utilisiez que vSphere, vous payez peut-être des capacités que vous ne déployez jamais.
- L’enfermement et la pression de fin de support. vSphere 7 a atteint la fin du support général en octobre 2025, et vSphere 8 est prévu pour octobre 2027. Les licences perpétuelles continuent de fonctionner, mais sans correctifs ni support, le compte à rebours est bien réel.
- La perturbation de l’écosystème. Les changements dans les programmes partenaires et Cloud Service Provider (le modèle VCSP est passé sur invitation uniquement début 2026) ont poussé certaines relations d’hébergement managé vers une renégociation.
Rien de tout cela n’implique que vous devez tout arracher au prochain trimestre. Cela signifie que vous devez connaître vos options et disposer d’une voie de sortie crédible.
Il n’existe pas de remplaçant unique à VMware
C’est le point le plus important de tout ce playbook. VMware a regroupé la virtualisation du calcul, le stockage (vSAN), le réseau (NSX) et la gestion (vCenter, Aria) dans une seule stack. Aucun projet open source ne remplace tout cela avec un produit unique. La bonne approche consiste à associer les options aux charges de travail, à privilégier les standards ouverts (KVM, QEMU, libvirt, Ceph, OVN/Open vSwitch, les API OCI et Kubernetes) et à choisir les outils adaptés à chaque couche.
Voici le panorama général, regroupé selon les domaines où chaque option excelle. Considérez-les comme représentatifs, ni exhaustifs, ni comme une recommandation d’un outil par rapport à un autre.
Plateformes orientées VM (l’expérience la plus proche de vCenter)
- Proxmox VE - KVM associé à LXC, avec clustering intégré, migration à chaud et intégration Ceph. Très adapté aux PME et au mid-market, ainsi qu’à la virtualisation on-prem simple où la simplicité prime.
- oVirt - le projet amont de l’ancien Red Hat Virtualization. Désormais maintenu par la communauté après le désengagement de Red Hat, et à la base de produits comme Oracle Linux Virtualization Manager. Un modèle datacenter/cluster/hôte familier pour les équipes qui appréciaient la structure de vCenter.
- Harvester - la plateforme hyperconvergée open source de SUSE, bâtie sur Kubernetes, KubeVirt et Longhorn. Elle offre une interface centrée sur les VM tout en reposant sur une plomberie cloud-native en dessous.
Plateformes de cloud privé (IaaS avec multi-tenancy et self-service)
- OpenStack - l’option la plus complète et la plus modulaire, avec des projets distincts pour le calcul (Nova), le réseau (Neutron, généralement OVN), le stockage (Cinder, Swift) et l’identité (Keystone). Excellent à grande échelle, mais réellement complexe et qui récompense une équipe d’exploitation compétente.
- Apache CloudStack - un IaaS intégré et opinionné, plus rapide à mettre en place qu’OpenStack, avec un support multi-hyperviseur et un réseau mature. Populaire auprès des fournisseurs de services et des telcos.
- OpenNebula - léger et pragmatique, bien adapté à l’edge, à l’hybride et aux clouds privés de petite à moyenne taille où l’on souhaite de l’orchestration sans le poids opérationnel d’OpenStack.
Approches Kubernetes-native
Si votre feuille de route est déjà cloud-native, vous pouvez faire converger VM et conteneurs sur un même plan de contrôle :
- KubeVirt - exécute les VM comme des ressources Kubernetes. C’est un projet CNCF (entré en revue de graduation fin 2025) avec une base d’adoptants croissante, et le moteur derrière plusieurs produits de virtualisation commerciaux.
- Cluster API - provisionnement déclaratif et gestion du cycle de vie des clusters Kubernetes, souvent associé à KubeVirt ou au bare metal pour un modèle cluster-as-a-service.
Pour la migration en masse de VM vers le monde Kubernetes, le projet open source Forklift (la base du Migration Toolkit for Virtualization de Red Hat) se connecte à vCenter, inventorie les VM, convertit les disques et réalise des migrations à froid ou à chaud.
Comment choisir
Partez de vos charges de travail et de votre équipe, pas d’une liste restreinte de produits. Quelques questions qui distinguent systématiquement les bons choix des choix douloureux :
- Que faites-vous réellement tourner ? Surtout des VM Windows et Linux à longue durée de vie ? Une plateforme orientée VM est la voie de moindre résistance. Vous conteneurisez déjà ? Une approche Kubernetes-native peut consolider deux stacks en une seule.
- Avez-vous besoin de multi-tenancy et de self-service ? Si oui, vous êtes sur le terrain du cloud privé (OpenStack, CloudStack, OpenNebula) plutôt que sur celui d’un gestionnaire d’hyperviseur mono-tenant.
- Quelle est votre maturité opérationnelle ? La puissance d’OpenStack s’accompagne d’un coût réel en day-2. Soyez honnête sur le fait d’avoir - ou de recruter, ou d’externaliser - les compétences pour l’exploiter.
- Quelles fonctionnalités VMware sont porteuses ? vMotion, HA, DRS, vSAN, la micro-segmentation NSX et Site Recovery Manager ont tous des équivalents open source, mais ils correspondent rarement un à un. Inventoriez les fonctionnalités dont vous dépendez vraiment, pas celles que vous avez licenciées.
- La réalité du stockage et du réseau. La plupart des approches open source s’appuient sur Ceph pour le stockage et sur OVN/Open vSwitch pour le réseau. Votre SAN, votre fabric et vos politiques de segmentation existants nécessiteront une conception réfléchie, pas un copier-coller.
Une approche de migration par phases
Les migrations échouent lorsqu’elles sont traitées comme une bascule unique. Séquencez le travail et réduisez le risque à chaque étape.
1. Évaluer
Construisez un inventaire complet : VM, dépendances, organisation du stockage, politiques réseau et de sécurité, et exposition aux licences avec leurs échéances. Notez chaque charge de travail selon sa tolérance à l’interruption, sa complexité et sa sensibilité en matière de conformité. Le résultat est un backlog de migration priorisé, pas un tableur qui se périme.
2. Concevoir
Choisissez la ou les plateformes cibles par groupe de charges de travail et concevez explicitement l’architecture de stockage et de réseau. C’est ici que vous associez les politiques NSX aux security groups OVN, vSAN à Ceph, et le placement de type DRS à votre nouvel ordonnanceur. Décidez aussi de la mécanique de migration : migration à froid ou à chaud, outillage et rollback.
3. Piloter
Montez la cible dans un lab et migrez 10 à 20 % de charges de travail équivalentes à la production. Mesurez la parité de performance, validez le failover HA, testez la sauvegarde et la restauration, et éprouvez vos politiques de sécurité. Un pilote de deux à quatre semaines fait remonter les surprises tant qu’elles coûtent peu.
4. Migrer
Avancez par vagues, séquencées selon le risque, en maintenant un impact en production faible par vague (un plafond de 10 à 15 % est une règle empirique raisonnable). Commencez par les environnements dev/test sans état, puis les couches web, puis les bases de données et les systèmes critiques. Conservez l’ancien environnement comme cible de rollback jusqu’à validation de chaque vague.
5. Exploiter
Une nouvelle plateforme exige de nouveaux runbooks, une nouvelle supervision, une cadence de patching, une planification de capacité et des procédures de PRA. Prévoyez un transfert de compétences afin que l’équipe s’approprie l’exploitation day-2 plutôt que de dépendre indéfiniment de celui qui a mené la migration.
Pièges à anticiper
- Le problème des 10 %. Un petit ensemble d’applications dépendantes uniquement de VMware crée l’essentiel de la friction de migration. Identifiez-les tôt ; elles dicteront votre calendrier.
- Le réseau est plus difficile que le calcul. Les vSwitches, les port groups et les politiques NSX ne se transfèrent pas directement. Les incohérences de VLAN et la recréation des politiques sont une cause majeure d’interruptions prolongées.
- Les tests de PRA prennent des mois, pas des semaines. Ne le découvrez pas à l’approche de la mise en production. Impliquez les parties prenantes de la conformité et du PRA dès la phase de conception.
- Sous-estimer le day-2. La licence que vous annulez est remplacée par une responsabilité opérationnelle. Budgétez pour les compétences, l’automatisation et l’observabilité.
- La monogamie d’outil. Résistez à la tentation de tout standardiser sur une seule plateforme avant que le pilote ne l’ait prouvé. Les parcs mixtes sont normaux et souvent optimaux.
L’atout de la souveraineté européenne
Pour les organisations européennes, et allemandes en particulier, cette migration est aussi une opportunité de souveraineté. Faire tourner une infrastructure open source sur des capacités hébergées dans l’UE supprime d’un coup deux couches de dépendance externe : le logiciel n’est pas contrôlé par la feuille de route ou la tarification d’un fournisseur étranger unique, et les données restent sous juridiction de l’UE. Cette combinaison - open source et résidence des données dans l’UE - est exactement ce que visent les cadres derrière la récente impulsion franco-allemande en faveur de la souveraineté numérique et les efforts de Cloud Sovereignty de la Commission européenne.
L’enjeu stratégique, c’est le levier de négociation. Les standards ouverts garantissent que vos charges de travail restent portables, que vous négociez en position de choix plutôt que de dépendance, et que votre posture de conformité (GDPR, règles sectorielles sur les données) est intégrée dès la conception plutôt qu’ajoutée après coup. Ici, la souveraineté est une capacité que l’on conçoit, pas une case à cocher.
FAQ
Proxmox est-il un véritable remplaçant de VMware ?
Pour les environnements orientés VM, oui. Proxmox VE couvre le clustering, la migration à chaud, la HA et le stockage adossé à Ceph. Ce n’est pas un IaaS de cloud privé complet ; si vous avez besoin de self-service multi-tenant, regardez plutôt OpenStack, CloudStack ou OpenNebula.
Proxmox vs VMware - quelle est la plus grande différence pratique ?
L’architecture et l’écosystème. VMware propose une stack étroitement intégrée et mono-fournisseur ; Proxmox assemble des composants ouverts (KVM, LXC, Ceph). Vous échangez l’intégration fournisseur et les contrats de support entreprise contre la maîtrise des coûts, l’absence de licence par cœur et l’absence d’enfermement.
Combien de temps prend une migration VMware ?
Cela dépend de la taille du parc et de la part de charges de travail dépendantes uniquement de VMware, mais raisonnez en trimestres, pas en semaines. Un plan par phases avec un véritable pilote et une bascule par vagues est ce qui maintient le risque et l’interruption sous contrôle.
Devons-nous tout migrer hors de VMware d’un coup ?
Non. Les licences perpétuelles continuent de fonctionner sans support, ce qui laisse du temps. La plupart des équipes migrent par vagues et conservent une empreinte VMware qui se réduit pendant la transition.
Les VM et les conteneurs peuvent-ils tourner sur une même plateforme ?
Oui. KubeVirt exécute les VM comme des objets Kubernetes, ce qui permet de faire converger les deux sur un seul plan de contrôle. Cela convient aux équipes déjà investies dans des opérations cloud-native.
Le rôle de Rapid Solutions
Nous sommes un cabinet de conseil en ingénierie neutre vis-à-vis des fournisseurs, avec des bureaux à Amsterdam et Dubaï. Nous ne vendons pas de plateforme : notre recommandation est donc guidée par vos charges de travail, votre équipe et vos besoins de conformité - pas par ce que nous aurions à monétiser. Nous accompagnons l’évaluation, la conception de la cible, le pilote, la migration par vagues et le modèle d’exploitation day-2, avec une approche open-source-first et souveraine par conception de bout en bout.
Si vous faites face à un renouvellement VMware ou planifiez une sortie, contactez Rapid Solutions et nous vous aiderons à construire une trajectoire de migration adaptée à la stack que vous exploitez réellement.