ACTUALITÉS

Sortir de VMware : OpenShift, Proxmox… ou modèle d'exploitation ?

03 novembre 2026

News

#Hebergement

#OpenSource

#Maitrise

Sortir de VMware, c'est souvent comparer OpenShift, Proxmox ou OpenStack. Le vrai critère : le modèle d'exploitation que vous pourrez tenir.

Face à un choix de plateforme, le premier réflexe est de chercher un tableau comparatif et un gagnant. Ce format rassure, mais il repose sur une erreur de catégorie. Cet article propose une grille de décision fondée sur deux repères : votre point de départ et votre capacité d'exploitation.

Sortir de VMware : pourquoi le comparatif est mal posé

Chercher une alternative VMware conduit souvent à aligner des produits dans un même tableau. Or ces solutions n'occupent pas la même couche de l'infrastructure ; les noter sur les mêmes critères n'a donc pas de sens.

Un hyperviseur, comme VMware vSphere ou Proxmox VE, découpe des serveurs physiques en machines virtuelles (VM). Un IaaS, ou infrastructure en libre-service, ouvre ces ressources à plusieurs équipes par API : c'est le rôle d'OpenStack. Un orchestrateur comme Kubernetes déploie et fait tourner des conteneurs sur un parc de serveurs.

Enfin, une plateforme applicative comme OpenShift ajoute à Kubernetes pipelines, registre d'images, observabilité et sécurité intégrés. Ces couches se superposent autant qu'elles se substituent. Un cluster Kubernetes peut ainsi tourner sur des VM Proxmox ou OpenStack.

Sortir de VMware : chaque solution occupe sa propre couche

On ne compare pas un hyperviseur, un IaaS et une plateforme de conteneurs sur les mêmes critères.

Ce raisonnement prolonge notre panorama des alternatives open source à VMware, qui présente les solutions une à une. Hyper-V et Nutanix, très cités, sortent de ce périmètre open source et ne sont pas traités ici.

Le bon point de départ n'est donc pas le produit. C'est le modèle d'exploitation que l'entreprise peut porter : ses équipes, son budget, sa capacité à changer d'avis.

Ce qui a rendu la question légitime malgré tout

Si le comparatif est mal posé, il n'est pas absurde pour autant. Deux évolutions l'ont rendu presque inévitable.

La convergence par le haut

La frontière entre les couches s'est brouillée par le haut. Annoncé en août 2020 avec OpenShift 4.5, OpenShift Virtualization exécute des machines virtuelles sur la même plateforme que les conteneurs. Il dérive du projet open source KubeVirt.

Une plateforme de conteneurs entre ainsi sur le terrain de l'hyperviseur, et la comparaison devient légitime. Cette option fait partie de l'OpenShift opéré par Alter Way.

Une disponibilité générale ne garantit pas pour autant la maturité terrain. La parité fonctionnelle avec un hyperviseur éprouvé se vérifie charge par charge, notamment pour le stockage et le réseau.

La pression sur les socles historiques

Par le bas, le socle historique a changé de modèle économique. En décembre 2023, VMware a annoncé la fin de la vente de licences perpétuelles et le passage à l'abonnement.

Un changement de modèle de licence oblige à requalifier un budget, donc à rouvrir les choix d'infrastructure. L'échéance de renouvellement devient l'occasion de reposer la question d'ensemble : que veut-on exploiter, et comment ?

Les quatre points de départ possibles

Plutôt que de partir du produit, partez de votre situation. Chacune mène à des options différentes, avec son propre piège : migration d'hyperviseur ou changement de plateforme.

Socle de virtualisation historique, applications peu conteneurisées

C'est le cas typique pour sortir de VMware sans projet de conteneurisation. Si la cible reste des VMs, Proxmox en entreprise convient à un socle de virtualisation simple. OpenStack s'impose si plusieurs équipes doivent consommer l'infrastructure en libre-service.

Si la conteneurisation est engagée, OpenShift Virtualization permet de converger. Le piège : changer d'hyperviseur sans revoir l'exploitation, et reproduire les mêmes coûts sur un autre socle.

Kubernetes déjà en production, opéré en interne

L'équipe a assemblé elle-même réseau, stockage, registre et observabilité autour de Kubernetes. Deux voies s'ouvrent : rester sur ce Kubernetes, ou adopter une distribution qui intègre et maintient ces briques.

Le piège : sous-estimer le coût du maintien de l'assemblage. Chaque brique suit son propre cycle de versions, à tester et à recombiner.

Besoin d'un IaaS souverain ou multi-tenant

Certaines DSI servent des équipes isolées les unes des autres : c'est le multi-tenant. D'autres doivent maîtriser la localisation de leurs données. OpenStack répond à ces deux besoins.

Le piège : sa complexité d'exploitation. Ses nombreux composants exigent des compétences pointues en réseau défini par logiciel (SDN) et en stockage distribué.

Démarrage sans historique d'infrastructure

Une nouvelle activité ou une filiale part d'une page blanche. Un Kubernetes managé suffit à une petite équipe. OpenShift se justifie quand l'équipe grandit et que l'outillage intégré fait gagner du temps.

Le piège : surdimensionner la plateforme, et payer une exploitation que l'activité ne justifie pas encore.

Les critères qui décident réellement

Ces critères ne classent pas les solutions. Ils décrivent l'engagement que l'organisation peut tenir, ou non. La grille ci-dessous les croise avec les quatre points de départ.

Critère	Socle VM historique	Kubernetes interne	IaaS souverain ou multi-tenant	Sans historique
Exploitation et compétences	Profils VM répandus ; compétences Kubernetes à acquérir en cas de convergence	Équipe plateforme dédiée ; dépendance aux personnes	Profils SDN et stockage distribué, rares	Taille de l'équipe à projeter avant de choisir
Coût sur trois ans	Entretien des systèmes invités, multiplié par le nombre de VM	Main-d'œuvre d'assemblage qui croît avec les briques	Main-d'œuvre principalement	Souscription ou service managé à proportionner à l'activité
Réversibilité	Conversion des disques et fenêtres d'arrêt	Forte vis-à-vis des éditeurs, faible vis-à-vis des personnes	API standard ; dépendance aux experts	Adhérence aux services du fournisseur
Trajectoire applicative	Quels logiciels resteront en VM ?	Quelles VM résiduelles absorber ?	Usages VM en libre-service	Conteneurs dès le départ
Conformité et souveraineté	Localisation et hébergeur à requalifier	Preuves de conformité à outiller soi-même	Maîtrise de la localisation	Qualification de l'hébergeur à vérifier

Modèle d'exploitation et compétences

Chaque option exige un savoir-faire quotidien : administration de VM, réseau défini par logiciel ou Kubernetes. La question n'est pas seulement de l'avoir, mais de pouvoir le recruter et le garder.

Un socle assemblé en interne crée aussi une dépendance aux personnes qui l'ont monté. Leur départ devient le risque principal, que l'infogérance de plateformes permet de partager.

Coût total sur trois ans

La licence ou la souscription n'est qu'une ligne du budget. Sur trois ans, la main-d'œuvre, le support et la dette d'exploitation pèsent souvent davantage.

Un socle sans licence peut coûter cher en ingénieurs ; une souscription réduit l'effort d'assemblage. Deux socles en parallèle, VM et conteneurs, signifient aussi deux jeux de compétences et deux astreintes.

Réversibilité et dépendance à l'éditeur

Que faut-il pour sortir du modèle choisi ? Des formats ouverts et des charges portables réduisent le coût de sortie. À l'inverse, les extensions propres à une plateforme créent une adhérence à connaître dès le départ.

Chez Alter Way, la trajectoire de sortie est prévue dès la conception de l'architecture.

Trajectoire applicative

Vos applications seront-elles conteneurisées, et à quel horizon ? Logiciels propriétaires et applications Windows restent souvent en VM. Construire une plateforme de conteneurs sans charge à y placer ajoute un socle sans bénéfice.

L'arbitrage entre VM ou conteneurs se fait application par application, pas pour tout le parc.

Conformité et souveraineté

Ce sont deux critères distincts. La conformité porte sur le respect de référentiels sectoriels et la capacité à le prouver en audit. La souveraineté porte sur la localisation des données, la maîtrise juridique et la qualification des hébergeurs.

Une plateforme peut exceller sur l'une sans répondre à l'autre.

OpenShift vs Kubernetes : ce que la distribution apporte

Kubernetes est le moteur. OpenShift en est une distribution, c'est-à-dire un ensemble assemblé, testé et supporté par Red Hat. La comparaison porte donc sur ce que l'on délègue, et sur ce que cela coûte.

Ce qu'apporte OpenShift	Contrepartie
Rythme fixé par l'éditeur ; une plateforme non mise à jour sort du support	Composants choisis par l'éditeur, moindre latitude d'architecture
Sécurité par défaut : politiques restrictives dès l'installation	Applications parfois à adapter à ces restrictions
Cycle de vie : versions cohérentes, mises à jour outillées	Rythme fixé par l'éditeur ; une plateforme non mise à jour sort du support
Support éditeur	Souscription, qui croît avec la taille du parc

Avec Kubernetes seul, ces apports se construisent à la main, du durcissement Linux des nœuds à la chaîne de déploiement. Notre accompagnement Kubernetes couvre les deux voies.

Trois scénarios de décision

Ces scénarios sont anonymisés et recomposés à partir de situations de terrain. La même grille y aboutit à trois décisions différentes.

Scénario 1 : ETI sur VMware, applications d'éditeurs, petite équipe

Applications métiers non conteneurisables, équipe infrastructure de trois personnes. Décision : Proxmox avec stockage Ceph, infogéré, via une migration de VMware vers Proxmox.

Scénario 2 : Kubernetes interne à bout de souffle, VM résiduelles

Un Kubernetes monté en interne tourne en production, à côté de quelques VM restées sur VMware. L'équipe plateforme s'épuise à maintenir l'assemblage.

Décision : OpenShift et sa virtualisation intégrée. Une seule plateforme pour VM et conteneurs, un cycle de vie pris en charge.

Scénario 3 : secteur réglementé, applications conteneurisées, audits réguliers

Exigences de conformité fortes, audits annuels. Décision : OpenShift, pour sa sécurité par défaut, son cycle de vie supporté et ses correctifs gérés par l'éditeur.

Son Compliance Operator, module de contrôle de configuration, automatise les vérifications : profils CIS, NIST SP 800-53, PCI-DSS…

Questions fréquentes

Quelle solution pour remplacer VMware ?

Il n'existe pas de remplaçant unique. Pour rester sur des machines virtuelles, Proxmox VE et OpenStack sont les principales options open source. Pour converger vers les conteneurs, OpenShift exécute VM et conteneurs sur une même plateforme. Le bon choix dépend des compétences de l'équipe et de la trajectoire applicative, plus que des fonctionnalités.

Proxmox peut-il remplacer VMware ?

Oui, pour un parc de machines virtuelles classique. Proxmox VE s'appuie sur l'hyperviseur KVM, gère la haute disponibilité et intègre Ceph pour le stockage distribué. Sa console web reste simple à prendre en main. Les écarts portent surtout sur l'écosystème d'outils tiers, à vérifier avant migration.

OpenShift peut-il remplacer VMware ?

Techniquement oui, puisqu'il exécute des VM aux côtés des conteneurs. Ce remplacement a du sens si une partie du parc est ou sera conteneurisée. Pour un parc entièrement virtualisé, il impose des compétences Kubernetes et une souscription sans bénéfice proportionné. La bascule se valide charge par charge.

Quelle différence entre OpenShift et Kubernetes ?

Kubernetes est un orchestrateur de conteneurs open source, maintenu par une large communauté. OpenShift est une distribution commerciale de Kubernetes éditée par Red Hat, disponible par souscription. Elle ajoute console, registre, pipelines, sécurité renforcée et support. Kubernetes laisse plus de latitude ; OpenShift livre un ensemble intégré et maintenu.

Conclusion : choisir un modèle d'exploitation, pas un produit

Pour sortir de VMware, OpenShift, Proxmox et OpenStack ne se situent pas sur le même plan. Le choix se joue sur le modèle d'exploitation que l'entreprise peut porter dans le temps, pas sur les fonctionnalités.