Sortir de VMware : les décisions à prendre avant de choisir une alternative

La pression contractuelle, budgétaire ou stratégique pousse de nombreuses organisations à réexaminer leur socle VMware. La réaction naturelle consiste à ouvrir un comparatif : Hyper-V, Azure Local, Nutanix AHV, Proxmox VE ou une autre plateforme. C’est précisément là que le raisonnement peut dérailler.

Depuis le rachat de VMware par Broadcom, le sujet ne se limite pas à une hausse de prix. Le portefeuille a été resserré autour d’offres par abonnement plus intégrées, notamment VMware Cloud Foundation et VMware vSphere Foundation. Le portefeuille commercial ne se limite pas à ces deux offres, mais les produits, les bundles et les conditions accessibles dépendent du contexte contractuel et peuvent évoluer. À cela s’ajoute l’évolution régulière des offres et de leurs mécanismes de licence, qui complique la visibilité nécessaire pour piloter une infrastructure sur plusieurs années.

Ces solutions ne couvrent pas le même périmètre. Certaines sont d’abord des hyperviseurs ou des fonctions de système d’exploitation ; d’autres sont des plateformes intégrées associant calcul, stockage, administration et services hybrides. Hyper-V, Azure Local, Nutanix AHV, Proxmox VE et VMware ne peuvent donc pas être comparés ligne à ligne sans avoir préalablement défini le service attendu. À défaut, la comparaison produit des conclusions trompeuses.

La décision ne consiste donc pas à élire un produit. Elle consiste à définir un service d’infrastructure cible et une trajectoire que l’organisation sait tenir. Le besoin doit conduire la trajectoire technique, pas l’inverse. Le produit vient ensuite.

« Sortir de VMware » n’est pas un objectif suffisamment précis. Une DSI peut chercher à réduire une dépense, retrouver de la prévisibilité contractuelle, diminuer une dépendance fournisseur, traiter une échéance de support, simplifier l’exploitation ou profiter d’un renouvellement matériel pour transformer son infrastructure.

Ces motivations ne conduisent pas aux mêmes choix. Si la priorité est économique, la rationalisation du périmètre VMware peut être plus efficace qu’une migration globale. Si le problème est une dépendance jugée excessive, remplacer un fournisseur par une plateforme dont l’exploitation dépend d’un autre écosystème ne résout pas nécessairement le sujet. Si l’urgence vient du support, une mise à niveau peut être indispensable avant même d’engager une sortie.

Broadcom documente aujourd’hui VCF et VVF selon un calcul fondé sur les cœurs physiques, avec un minimum de seize cœurs par processeur. Le support général de vSphere 7 a pris fin le 2 octobre 2025. Ces éléments constituent des contraintes factuelles. La décision de migrer reste, elle, une conclusion propre à chaque organisation.

La première décision doit donc être formulée en une phrase mesurable : quel risque ou quel coût veut-on réduire, dans quel délai, et sans dégrader quel niveau de service ?

Une machine virtuelle ne fonctionne pas seulement grâce à un hyperviseur. Elle dépend d’une chaîne de services : administration centralisée, haute disponibilité, stockage, réseau, sauvegarde, restauration, PRA, supervision, gestion de capacité, identité, sécurité, automatisation, correctifs, support et procédures d’exploitation.

Cette cartographie doit partir de l’usage réel. Une fonction licenciée mais jamais utilisée n’a pas à être reconstruite. À l’inverse, une automatisation discrète ou une procédure de restauration maîtrisée par deux personnes peut être critique sans apparaître dans une matrice commerciale.

Les plateformes peuvent illustrer ces différences sans être classées. Azure Local peut répondre à une logique de gestion hybride et prend désormais en charge plusieurs modèles d’architecture, notamment certains déploiements avec stockage SAN externe. Ces possibilités restent soumises à des exigences matérielles, logicielles et tarifaires précises. Le mode déconnecté constitue quant à lui une architecture distincte, avec un plan de contrôle local et des prérequis propres. Nutanix Move facilite certains scénarios de migration depuis VMware, mais son existence ne dispense pas de vérifier chaque système invité, réseau, stockage et fenêtre d’arrêt. Proxmox VE dispose d’un support par abonnement ; la capacité réelle à l’exploiter dépend aussi de la couverture des outils tiers et du dispositif de support retenu.

Le bon critère n’est pas « compatible ». Il est : « compatible avec notre niveau de service, notre architecture et notre capacité de diagnostic en incident ».

Une licence supprimée n’est pas automatiquement une économie nette. Le calcul doit distinguer quatre catégories.

Les coûts supprimés sont ceux qui disparaissent réellement avec le périmètre migré. Les coûts conservés restent nécessaires quelle que soit la plateforme : systèmes d’exploitation invités, stockage déjà amorti, réseau physique, sécurité ou exploitation courante. Les coûts déplacés réapparaissent ailleurs : nouveau support, sauvegarde, supervision, intégration, compétences ou matériel compatible. Les coûts transitoires couvrent l’inventaire, le pilote, la conversion, les tests, la double exploitation, les retours arrière et les remédiations.

La sauvegarde montre bien le piège. Veeam prend en charge des environnements Proxmox VE récents, mais sa documentation mentionne encore des limites, notamment sur certains stockages, les conteneurs LXC et la réplication de VM. Ce n’est ni une condamnation de Proxmox ni un détail : c’est une invitation à vérifier si le service de protection attendu peut être reproduit, adapté ou remplacé.

Le coût complet doit aussi intégrer la réversibilité. Une migration peut réduire une dépendance immédiate tout en augmentant le coût de la prochaine sortie. Une DSI doit donc chiffrer non seulement l’arrivée sur la cible, mais sa capacité à la quitter.

Une matrice de cent critères donne une illusion d’objectivité. Une option peut obtenir une bonne moyenne et rester inutilisable à cause d’un seul point : système invité non supporté, architecture de stockage incompatible, absence de restauration attendue, matériel non certifié, contrainte réseau, support insuffisant ou compétence indisponible.

La bonne méthode commence par des critères éliminatoires. Ils doivent couvrir les charges critiques, la sauvegarde et la restauration, la haute disponibilité, le PRA, la sécurité, le stockage, le réseau, le support et les contraintes de connectivité. Les options restantes peuvent ensuite être évaluées sur des préférences : simplicité, automatisation, expérience d’administration ou trajectoire financière.

Les scénarios se regroupent alors en quatre familles.

Le maintien et la rationalisation consistent à conserver VMware en réduisant le périmètre, les fonctions ou les ressources souscrites. La migration complète vise une cible unique et suppose que toutes les dépendances puissent être traitées. La migration progressive organise une coexistence temporaire avec des vagues, des responsabilités et des critères de sortie. La segmentation durable affecte des familles d’usages différentes à plusieurs plateformes.

Chaque scénario doit avoir un responsable clairement désigné, un budget et des critères de décision. En cas de coexistence temporaire, il doit aussi prévoir une date de sortie. Sans gouvernance explicite, une transition technique devient rapidement une architecture permanente subie.

Cette dernière trajectoire peut être rationnelle. Elle peut aussi installer une duplication permanente des compétences, outils et procédures. Le multi-hyperviseur n’est pas une stratégie par nature : il le devient seulement lorsque chaque plateforme possède un périmètre stable, une justification et un modèle de support.

Un pilote qui fait démarrer quelques VM prouve une faisabilité technique limitée. Il ne prouve pas que la plateforme est exploitable.

Le test doit couvrir un cycle réel : migration, validation applicative, sauvegarde, restauration, supervision, maintenance, panne d’un nœud, diagnostic, escalade de support et retour arrière. Il doit inclure des charges représentatives, y compris une charge difficile, sans reprendre l’intégralité du parc. Les équipes qui exploiteront la cible doivent conduire le test ou, au minimum, y participer directement.

Le pilote doit aussi produire des éléments de décision : temps opérateur, incidents rencontrés, dépendances découvertes, procédures à réécrire, compétences manquantes et conditions de généralisation. Sans critères de succès et d’arrêt définis avant le test, il devient une démonstration technique orientée vers la solution déjà préférée.

L’organisation ne devrait pas engager irréversiblement sa trajectoire avant cette épreuve. Sinon, elle transforme des inconnues techniques et humaines en engagement financier.

Une DSI n’a pas besoin d’un classement universel. Elle a besoin d’une décision défendable, reliée à son parc, à ses équipes, à ses risques et à ses contraintes financières.

Avant tout appel d’offres ou notation détaillée, elle doit disposer d’un inventaire qualifié, de critères éliminatoires, de scénarios chiffrés et d’un pilote représentatif. Elle doit surtout accepter qu’une sortie complète ne soit pas toujours la réponse la plus rationnelle : le maintien rationalisé, la coexistence temporaire ou la segmentation peuvent être de meilleures trajectoires si elles sont explicitement gouvernées.

La bonne alternative n’est pas celle qui gagne la matrice : c’est celle que l’organisation peut migrer, exploiter, supporter et quitter dans des conditions maîtrisées.