Aller au contenu
Annuaire
Rubriques
Informatique

VMware : comparer les alternatives sans sous-estimer la migration

VMware : comparer les alternatives sans sous-estimer la migration
L’essentiel

Après les changements commerciaux engagés par Broadcom, Proxmox VE, Hyper-V et les plateformes fondées sur KVM reviennent dans les discussions des DSI. Mais le vrai comparatif dépasse largement les licences : sauvegarde, exploitation, compétences et réversibilité peuvent décider

À retenir

Après les changements commerciaux engagés par Broadcom, Proxmox VE, Hyper-V et les plateformes fondées sur KVM reviennent dans les discussions des DSI. Mais le vrai comparatif dépasse largement les licences : sauvegarde, exploitation, compétences et réversibilité peuvent décider

Le devis VMware arrive, et une question autrefois théorique devient urgente : pourrait-on faire autrement ? Depuis le rachat par Broadcom, les changements de licences et de commercialisation ont poussé les directions informatiques à rouvrir ce dossier. Proxmox VE, Hyper-V et les offres fondées sur KVM constituent des pistes crédibles. Pourtant, déplacer des machines virtuelles n’est que la partie visible du chantier. Le véritable enjeu consiste à reconstruire un service fiable, sauvegardé et exploitable à trois heures du matin. À l’horizon de septembre 2026, voici une grille de lecture fondée sur les transformations déjà engagées, sans présumer des tarifs ou catalogues futurs.

Le choc commercial oblige à refaire les comptes

Finalisé en novembre 2023, le rachat de VMware par Broadcom a été suivi d’un recentrage du portefeuille et d’une transition vers les abonnements, au détriment des nouvelles licences perpétuelles. La place accrue des ensembles VMware Cloud Foundation et VMware vSphere Foundation a modifié les repères d’achat. Les évolutions du réseau de partenaires ont également compliqué certaines relations commerciales. Leur effet varie toutefois selon les contrats, les remises, les produits utilisés et les échéances de renouvellement : il n’existe pas de hausse universelle applicable à toutes les entreprises.

Pour une DSI, la première étape n’est donc pas de télécharger un autre hyperviseur. C’est de reconstituer sa situation : droits acquis, fin du support, clauses contractuelles, consommation réelle et dépendances. Une entreprise qui exploite intensivement NSX, vSAN et les automatismes de VMware ne mène pas le même projet qu’une PME hébergeant quelques serveurs sur un stockage partagé. Le coût de sortie dépend davantage de cet écart que du nombre brut de machines virtuelles.

Trois familles, trois logiques de choix

Proxmox VE : accessible, mais pas sans exigences

Proxmox VE combine notamment KVM pour les machines virtuelles et LXC pour les conteneurs système. Son interface centralisée, ses fonctions de cluster et ses possibilités de stockage en font un candidat naturel pour de nombreuses infrastructures. L’abonnement apporte notamment accès au dépôt entreprise et au support, sans conditionner l’accès aux fonctionnalités principales. Mais l’apparente simplicité de prise en main ne remplace pas la maîtrise de Linux, du réseau et du stockage. Un cluster Ceph mal dimensionné reste un cluster fragile, quelle que soit l’économie réalisée sur les licences.

Hyper-V : regarder Windows Server, pas un produit disparu

Hyper-V conserve un intérêt particulier dans les organisations déjà structurées autour de Windows Server et des outils Microsoft. Il faut cependant distinguer le rôle Hyper-V intégré à Windows Server de l’ancien produit gratuit Hyper-V Server, dont la dernière version est 2019. Le calcul économique doit intégrer les droits Windows des systèmes invités, les outils d’administration et le support. La familiarité avec Active Directory ne suffit pas : exploitation des clusters, stockage et diagnostic de performance réclament des compétences spécifiques.

Les offres KVM : comparer des plateformes complètes

KVM est une technologie de virtualisation, pas une offre opérationnelle unique. Proxmox l’utilise, mais d’autres plateformes l’intègrent dans des architectures et des modèles de support très différents. Nutanix AHV ou les solutions reposant sur KubeVirt illustrent cette diversité. Dans ce dernier cas, rapprocher machines virtuelles et Kubernetes peut servir une stratégie de plateforme ; cela peut aussi introduire une complexité inutile. Il faut comparer le produit administrable, son cycle de vie et ses responsabilités de support, plutôt que cocher simplement « compatible KVM ».

La sauvegarde peut faire basculer le classement

Une machine qui démarre sur l’hyperviseur cible n’est pas encore un service sécurisé. L’outil de sauvegarde sait-il découvrir les nouvelles machines, garantir la cohérence applicative et restaurer rapidement un fichier, une base ou un serveur complet ? Les fonctions disponibles sur VMware ne se retrouvent pas automatiquement ailleurs. Les intégrations évoluent : leur disponibilité doit être vérifiée pour la version exacte envisagée, pas déduite d’une annonce ou d’une feuille de route.

Le pilote doit donc inclure une restauration réelle, chronométrée et documentée. Il faut aussi déterminer comment conserver et relire les sauvegardes historiques après la sortie de VMware. Garder temporairement une capacité de restauration sur l’ancienne plateforme peut être nécessaire, avec les droits et les coûts associés. Enfin, immutabilité, copie isolée et séparation des comptes d’administration restent des exigences indépendantes de l’hyperviseur. Changer de socle ne corrige pas une protection insuffisante contre les rançongiciels.

Comparer des situations de panne, pas seulement des fonctions

Les tableaux commerciaux alignent haute disponibilité, migration à chaud et réplication. Or deux cases cochées peuvent masquer des comportements très différents. Que se passe-t-il lorsqu’un hôte tombe pendant une maintenance ? Lorsqu’un lien réseau devient instable ? Lorsque le stockage ralentit sans s’arrêter ? Le quorum, les mécanismes d’isolation et les conditions de redémarrage des machines comptent davantage qu’une démonstration sans incident.

Un banc d’essai représentatif doit reproduire quelques charges significatives : base transactionnelle, serveur de fichiers, application ancienne et traitement nocturne. Mesurer uniquement le processeur laisserait de côté la latence disque, les pointes mémoire ou la durée des sauvegardes. Il faut également tester supervision, alertes, correctifs, certificats et gestion des accès. Une plateforme acceptable est celle que l’équipe peut diagnostiquer et remettre en service, pas seulement installer.

Le coût complet inclut deux infrastructures et du temps humain

Un comparatif sérieux porte sur plusieurs années, avec des hypothèses explicites. Il additionne abonnements, support, matériel, sauvegarde, formation et accompagnement, puis les dépenses transitoires. Pendant la migration, l’entreprise peut payer deux environnements, conserver des capacités libres pour les bascules et financer des interventions hors horaires ouvrés. Les économies récurrentes ne doivent pas effacer cette bosse initiale.

  • Compatibilité : vérifier systèmes invités, pilotes, appliances et conditions de support des éditeurs applicatifs.
  • Exploitation : chiffrer l’adaptation des scripts, de la supervision, de l’inventaire et des procédures.
  • Compétences : prévoir formation, disponibilité des experts et couverture des astreintes.
  • Réversibilité : documenter l’export des données, les formats et les conditions d’une nouvelle sortie.

Le logiciel libre réduit certaines dépendances commerciales, mais ne supprime ni les intégrations ni le besoin de compétences rares. Inversement, rester chez VMware peut être rationnel pour un périmètre fortement intégré. L’objectif n’est pas de gagner un concours de licences bon marché : c’est d’obtenir un coût prévisible pour un niveau de service démontré.

Migrer par vagues, avec une porte de retour

Le scénario le plus robuste commence par un inventaire des dépendances, puis un pilote non critique mais représentatif. Viennent ensuite des vagues limitées, assorties de critères de validation et d’un retour arrière réaliste. Après des écritures sur la nouvelle plateforme, rallumer l’ancienne machine ne suffit plus : il faut traiter la divergence des données. Cette difficulté justifie des répétitions et l’implication des responsables applicatifs.

Et maintenant ? Pour septembre 2026 et au-delà, l’hypothèse raisonnable est celle de choix plus segmentés plutôt que d’un remplacement uniforme : conserver certains usages VMware, déplacer les charges standardisées et moderniser séparément les applications qui le justifient. Cette diversification peut renforcer le pouvoir de négociation, mais augmente aussi la charge d’exploitation. La bonne alternative sera celle dont la DSI aura prouvé la restauration, le fonctionnement en panne et la soutenabilité humaine — avant de signer son départ.

Sur votre appareil

Comprendre cet article

L’analyse utilise l’intelligence locale du navigateur lorsqu’elle existe, sinon un résumé extractif. Le texte n’est envoyé à aucun service extérieur.

Facebook X LinkedIn

Ensuite A lire aussi