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 de coûts.

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 de trajectoires.

• Maintien et rationalisation

  Risque

  Coût total

  Continuité de service

  Conserver VMware en réduisant le périmètre, les fonctions ou les ressources souscrites.

  Bénéfice

  Limite la rupture opérationnelle et préserve les compétences existantes.

  Risque

  Maintient une dépendance contractuelle et des coûts qui peuvent rester élevés.

• Migration complète

  Risque

  Coût total

  Continuité de service

  Viser une cible unique, à condition que toutes les dépendances puissent être traitées.

  Bénéfice

  Simplifie durablement l’architecture, l’exploitation et le support.

  Risque

  Concentre les risques dans un programme de migration lourd et potentiellement irréversible.

• Migration progressive

  Risque

  Coût total

  Continuité de service

  Organiser une coexistence temporaire avec des vagues, des responsabilités et des critères de sortie.

  Bénéfice

  Permet de tester la cible et de réduire le risque avant généralisation.

  Risque

  Impose temporairement un double run, des coûts supplémentaires et une gouvernance stricte.

• Segmentation durable

  Risque

  Coût total

  Continuité de service

  Affecter des familles d’usages différentes à plusieurs plateformes, avec un périmètre et un modèle de support explicites.

  Bénéfice

  Adapte chaque plateforme aux usages réellement pertinents.

  Risque

  Multiplie durablement les compétences, les outils, les procédures et les contrats de support.

Le coût total intègre les licences, la migration, la coexistence, l’exploitation, les compétences, le support et la réversibilité.

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.

La segmentation durable 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 des plateformes. Elle doit construire une décision défendable, adaptée à son parc, à ses équipes, à ses risques et à ses contraintes financières.

Avant de consulter le marché, elle doit avoir qualifié son existant, défini le service à reconstruire, identifié ses critères éliminatoires et chiffré plusieurs trajectoires possibles. Sans ce travail, l’appel d’offres risque de comparer des solutions avant même que le besoin réel soit stabilisé.

La consultation peut ensuite permettre de préciser les architectures, les conditions de support et les coûts. Mais l’organisation ne devrait pas engager irréversiblement sa trajectoire ni généraliser la solution retenue avant d’avoir testé son exploitation sur un périmètre représentatif.

Une sortie complète de VMware n’est d’ailleurs pas toujours la réponse la plus rationnelle. Le maintien rationalisé, la migration progressive ou la segmentation durable peuvent constituer de meilleures trajectoires, à condition d’être explicitement gouvernés.

La bonne alternative n’est pas celle qui obtient la meilleure note dans une matrice. C’est celle que l’organisation peut migrer, exploiter, supporter et, demain, quitter dans des conditions maîtrisées.