Le devis de renouvellement arrive, et une infrastructure devient soudain un sujet de direction générale. Depuis le rachat de VMware par Broadcom, finalisé en novembre 2023, les changements commerciaux ont poussé les entreprises à réexaminer leurs choix. Mais quitter VMware n’est pas simplement remplacer une ligne de dépenses par une autre. C’est déplacer des applications, reconstruire des automatismes et parfois renégocier tout un écosystème. La migration la moins chère sur catalogue peut devenir la plus coûteuse en production. À l’horizon de septembre 2026, voici comment poser le calcul sans oublier ce qui se cache derrière les machines virtuelles.
Ce qui a changé : le contrat autant que la technologie
Après l’acquisition, Broadcom a engagé un recentrage du portefeuille VMware, avec la fin de la commercialisation de nombreuses licences perpétuelles et une transition vers des abonnements. Les offres ont été regroupées, notamment autour de VMware Cloud Foundation et de VMware vSphere Foundation. La réorganisation des circuits de vente et des programmes partenaires a également modifié les repères des clients et prestataires.
Ces évolutions, documentées dès 2023 et 2024, constituent le point de départ de cette analyse. Les conditions applicables en septembre 2026 doivent, elles, être vérifiées sur les propositions contractuelles : périmètres, minimums de souscription et droits d’usage peuvent évoluer. Il n’existe pas de pourcentage universel de hausse : l’effet dépend du contrat antérieur, des remises, du matériel et des fonctions réellement nécessaires.
Commencer par l’inventaire que personne ne veut faire
Combien de machines virtuelles possédez-vous ? La réponse paraît simple jusqu’à ce que surgissent les environnements de secours, les serveurs oubliés et les appliances fournies par des éditeurs. Un inventaire utile ne compte pas seulement les VM. Il relie chaque charge à un propriétaire, une criticité, une dépendance et une exigence de disponibilité.
Il faut ensuite cartographier les services VMware effectivement utilisés : haute disponibilité, mobilité à chaud, stockage vSAN, réseau NSX, automatisation ou reprise après sinistre. Une VM classique se déplace souvent plus facilement qu’une architecture dont les règles réseau et les procédures d’exploitation reposent sur ces composants. Le nombre de VM ne mesure donc pas, à lui seul, la difficulté du départ.
- Identifier les applications dont l’éditeur impose ou certifie une plateforme.
- Mesurer CPU, mémoire, stockage et entrées-sorties sur des périodes représentatives.
- Recenser sauvegardes, supervision, sécurité, scripts et outils de provisionnement.
- Documenter les fenêtres d’arrêt acceptables et les objectifs de reprise.
Comparer trois trajectoires, pas deux logos
Rester, mais redimensionner
Le maintien mérite un scénario complet, sans être traité comme un renoncement. Consolider des hôtes, supprimer les VM inutiles ou adapter le niveau de service peut réduire le périmètre à souscrire. Lorsque la tarification dépend des cœurs physiques, le choix des processeurs et la densité des serveurs deviennent aussi des décisions financières. Attention toutefois à ne pas sacrifier les marges de secours pour optimiser une facture.
Changer de plateforme de virtualisation
Nutanix AHV, Microsoft Hyper-V, Proxmox VE ou des plateformes fondées sur KVM représentent des pistes, mais pas des produits interchangeables. Certains choix s’inscrivent dans une architecture hyperconvergée ; d’autres demandent davantage d’intégration. Il faut comparer les fonctions nécessaires, le support disponible, les compétences locales et la compatibilité matérielle. Une base open source peut réduire le coût logiciel sans supprimer celui de l’exploitation.
Refondre sélectivement
Déplacer certaines applications vers des services cloud, des conteneurs ou des offres managées peut être pertinent. Ce n’est pourtant plus une simple migration d’hyperviseur : architecture, sécurité et modèle économique changent. KubeVirt permet notamment d’exécuter des VM dans un environnement Kubernetes, mais ne dispense pas de maîtriser celui-ci. La modernisation doit répondre à un besoin applicatif, pas seulement à une urgence contractuelle.
Le vrai coût se trouve entre les lignes
Le calcul doit couvrir une même durée et un même niveau de service pour chaque scénario. Trois à cinq ans constituent souvent un horizon de travail utile, à adapter aux contrats et au renouvellement matériel. Additionner abonnements et serveurs ne suffit pas : il faut distinguer dépenses récurrentes, investissement de transition et exposition au risque.
La double exploitation est fréquemment sous-estimée. Pendant la bascule, anciennes et nouvelles plateformes coexistent. Il faut financer leurs supports, leurs capacités et parfois leurs sauvegardes simultanément. Si le calendrier dépasse une échéance contractuelle, un renouvellement supplémentaire peut absorber une partie des économies espérées. Le temps nécessaire à la migration est donc une variable financière majeure.
Viennent ensuite les coûts périphériques : remplacement d’un outil de sauvegarde, adaptation des agents de sécurité, nouveaux connecteurs de supervision, formation et assistance spécialisée. Les licences des systèmes d’exploitation et des bases de données doivent aussi être réexaminées selon leurs règles contractuelles. Changer d’hyperviseur ne garantit aucune économie sur ces couches, et peut modifier les conditions de mobilité ou d’affectation des licences.
Enfin, il faut valoriser le travail interne. Les semaines consacrées aux conversions, aux tests et aux astreintes ne sont pas gratuites parce que les salariés sont déjà présents. Elles retardent d’autres projets. Un budget crédible distingue les dépenses additionnelles de ce coût d’opportunité, puis prévoit une réserve pour les applications récalcitrantes plutôt que de supposer une migration parfaitement linéaire.
Un pilote doit prouver la restauration, pas seulement le démarrage
Voir une VM démarrer sur une autre plateforme rassure. Cela ne prouve ni ses performances à pleine charge, ni sa sauvegarde, ni son redémarrage après une panne. Le pilote doit inclure plusieurs profils : application ancienne, base de données exigeante, appliance éditeur et service soumis à une forte contrainte de disponibilité. Les cas difficiles éclairent davantage le budget que les machines de démonstration.
Pour chaque profil, mesurer le temps humain, l’indisponibilité et les adaptations nécessaires. Tester aussi une restauration complète, la perte d’un hôte et le retour arrière. Ce dernier doit rester réalisable après les changements de données intervenus sur la cible. Sans procédure explicite, la « réversibilité » n’est qu’une promesse. Ces résultats permettent d’estimer des vagues de migration réalistes, avec leurs exceptions.
Décider avec des scénarios, pas une économie affichée
Le dossier final devrait présenter une hypothèse centrale, une favorable et une dégradée : calendrier allongé, capacité supplémentaire ou support renforcé. Il doit montrer quand les économies cumulées compensent la transition. Si cet équilibre dépend d’une exécution sans incident, la décision est fragile. Une trajectoire hybride peut être rationnelle : conserver temporairement les charges complexes et déplacer d’abord les environnements simples.
Et maintenant ? Pour les entreprises qui arbitrent en septembre 2026, l’enjeu prospectif est moins de trouver un remplaçant définitif que de retrouver une liberté de négociation. Des sauvegardes portables, une automatisation documentée et des applications moins dépendantes d’une seule plateforme pourraient réduire le coût du prochain changement. La meilleure stratégie n’est pas nécessairement de partir vite : c’est de pouvoir rester sans subir, et partir sans improviser.
