VMware post-Broadcom, l'arbre de décision pour un DSI de PME/ETI

1. Ce qui s'est passé depuis novembre 2023

L'acquisition de VMware par Broadcom pour 69 milliards de dollars a été finalisée le 22 novembre 2023. Dans les semaines qui ont suivi, le nouveau propriétaire a exécuté une restructuration agressive qui suit un schéma déjà appliqué à CA Technologies et Symantec Enterprise : réduction des SKU, abandon des licences perpétuelles, consolidation des programmes partenaires autour des très grands comptes.

Le calendrier, pour les DSI de PME et d'ETI, tient en quatre dates clés :

• Décembre 2023 : fin des licences perpétuelles VMware. Les clients existants conservent leur droit d'usage, mais ne reçoivent plus de mises à jour sans contrat de support actif.
• Février 2024 : nouveau catalogue : deux bundles seulement, VMware vSphere Foundation (VVF) pour les environnements simples, VMware Cloud Foundation (VCF) pour les SDDC complets. Les anciens SKU (vSphere Essentials Plus, vSphere Standard, vSAN autonome) disparaissent.
• Avril 2025 : minimum de facturation porté à 72 cœurs par commande. Un cluster 3 nœuds équipé de CPU 16 cœurs (48 cœurs réels) est désormais facturé pour 72 cœurs.
• 2025-2026 : remontées tarifaires progressives sur les renouvellements, avec majorations observées entre +150 % et +600 % selon la base installée, l'historique d'achat et la taille de l'entreprise.

À ce contexte s'ajoute la fermeture du programme VMware Cloud Service Provider historique : les MSP régionaux qui revendaient VMware via des licences mensuelles ont été re-qualifiés dans un programme « White Label » plus restrictif, avec des exigences de volume qui excluent de facto la majorité des MSP indépendants. La chaîne d'approvisionnement elle-même s'est rétrécie.

2. Décomposer la facture : où part l'argent ?

La tentation est de se concentrer sur « le prix de vSphere ». C'est une erreur d'analyse. Le TCO d'un environnement VMware en PME se compose de cinq lignes, et la licence de l'hyperviseur n'en est pas toujours la plus lourde.

Quand Broadcom multiplie la ligne « hyperviseur » par 3 à 5, le TCO global monte de 40 à 80 %. Si vous regardez uniquement la licence, le choc paraît insoutenable. Si vous regardez la structure complète, deux leviers apparaissent : réduire la facture VMware, ou simplifier l'architecture pour faire disparaître plusieurs lignes en même temps.

Cette distinction conditionne le bon chemin de sortie. Un remplacement d'hyperviseur à architecture constante (Proxmox, Hyper-V) soigne la ligne 1. Un basculement vers l'hyperconvergence (Nutanix, Scale HC3) attaque en plus les lignes 2 et 3. Les deux stratégies ont leur place, selon le contexte.

3. Arbre de décision, sortir de VMware en six questions

Les décisions d'infrastructure se prennent rarement sur un tableau comparatif. Elles se prennent sur une séquence de questions dont les réponses éliminent des options. Voici l'arbre que nous utilisons en échange technique pour cadrer un arbitrage.

En sortie de cet arbre, trois profils se dessinent très nettement :

• Profil A, site unique, équipe IT, workloads « standards » : Proxmox VE avec support éditeur, ou Hyper-V si l'écosystème est déjà Microsoft. Migration en conservant le SAN.
• Profil B, multi-sites, peu de ressources IT locales : Scale Computing HC3. Un cluster principal au siège, des micro-clusters sur les sites secondaires. Suppression totale de la couche SAN et simplification radicale de l'exploitation.
• Profil C, ETI > 500 VM, SDDC en place : négociation serrée de VCF sur 3 ans avec sortie partielle planifiée (edge → Scale, core → maintien VMware), puis re-évaluation au terme.

4. Quatre chemins de sortie, comparaison sans complaisance

4.1. Proxmox VE

Ce qu'on y gagne. Open-source, KVM sous-jacent mature, Ceph intégré pour le stockage distribué, licences de support abordables (Proxmox Server Solutions GmbH). Le projet a gagné en crédibilité industrielle en 2024-2025 avec l'arrivée de nombreux réfugiés VMware. Compatibilité SR-IOV, Secure Boot, Live Migration, réplication au niveau du stockage ; pas d'équivalent direct à vMotion, mais des alternatives suffisantes pour la plupart des cas.

Les limites à connaître, et elles sont importantes.

• Complexité opérationnelle de Ceph. Le stockage distribué est souvent vendu comme un remplaçant direct du SAN : ce n'est pas le cas. Ceph exige un dimensionnement rigoureux (ratio OSD/MON/MGR, PG count, réseau dédié 10/25 GbE minimum, domaines de panne corrects) et une vraie maîtrise des scénarios de recovery. Un rebuild mal anticipé sur un cluster de 3 nœuds peut saturer le réseau et dégrader les I/O production pendant plusieurs heures. C'est un métier à part entière, et il se perd si on ne le pratique pas régulièrement.
• Stabilité en charge mixte. Proxmox se comporte très bien sur des workloads homogènes (fermes Linux, LXC, VM web). Sur des profils PME mixtes (SQL Server bruyant + Exchange + fileserver + RDS), la pile KVM + Ceph + ZFS peut montrer des latences irrégulières si le tuning I/O (cache, barrière, queue depth, BBU du contrôleur) n'est pas rigoureux. Les post-mortems publiés sur le forum Proxmox en 2024-2025 témoignent régulièrement de pertes de performance liées à un Ceph mal paramétré plus qu'à l'hyperviseur lui-même.
• Support éditeur décalé. Proxmox Server Solutions GmbH est basé à Vienne (Autriche). Le support, même en niveau « Premium », est délivré en heures ouvrées locales (fuseau CET/CEST, lundi–vendredi). Il n'existe pas d'astreinte 24/7 commercialisée par l'éditeur. Pour un incident critique survenu un dimanche soir ou le 25 décembre, vous dépendez exclusivement de votre MSP local, qui doit avoir des compétences Ceph de niveau 2/3. Pour comparaison : Scale Computing, Nutanix et Microsoft proposent tous un support 24/7 via leurs canaux partenaires.
• Écosystème tiers plus pauvre. Proxmox Backup Server est honnête mais en deçà de Veeam sur les environnements mixtes (pas d'application-aware pour SQL/Exchange sans scripts), monitoring et orchestration reposent sur des briques à assembler soi-même (Prometheus + Grafana + alertmanager).
• Produit d'administrateur, pas produit d'utilisateur. L'interface est fonctionnelle mais ne masque pas la complexité sous-jacente. Un administrateur non averti peut prendre de mauvaises décisions (ex. : supprimer un OSD à chaud, créer un pool en taille 2 pour « gagner de la place »). Avec Scale ou Nutanix, ces actions dangereuses sont soit impossibles, soit assorties de garde-fous.

Verdict pragmatique : Proxmox est un excellent choix si vous avez une équipe IT avec une vraie appétence Linux, un MSP partenaire qui maîtrise Ceph, et une tolérance à la résolution d'incidents en J+1 hors heures ouvrées autrichiennes. Dans les autres cas, la promesse « open-source et moins cher » se paie sur la ligne exploitation.

4.2. Microsoft Hyper-V + Windows Server 2022/2025

Ce qu'on y gagne. Hyperviseur intégré gratuitement à toute licence Windows Server (édition Standard ou Datacenter). Sur Windows Server 2025, Storage Spaces Direct permet de constituer un stack hyperconvergé maison. Intégration parfaite avec Active Directory, Azure Arc, Microsoft 365. Veeam supporte Hyper-V nativement, l'écosystème de sauvegarde et de monitoring est riche. Pour une PME déjà ancrée dans l'écosystème Microsoft, c'est l'option qui minimise le choc culturel.

Les limites à connaître.

• Patch Tuesday et redémarrages mensuels. Windows Server reste soumis aux cumulative updates mensuelles, dont la grande majorité imposent un redémarrage du système. En pratique, cela signifie au moins 12 redémarrages par an par hôte du cluster, orchestrés par roulement (Live Migration des VM d'un nœud à l'autre, patch, reboot, bascule inverse). Sur un cluster 3 nœuds avec 50 VM, compter 2 à 4 heures de fenêtre de maintenance mensuelle, avec un véritable plan de bascule à documenter et à tester. Aucun autre hyperviseur fondé sur KVM de cette liste n'impose cette cadence de reboots côté hôte.
• Hot-patching disponible… mais payant et conditionnel. Microsoft a généralisé le hotpatching pour Windows Server 2025 en disponibilité générale depuis le 1er juillet 2025. Il évite 8 redémarrages sur 12 par an (4 mois « baseline » restent obligatoires). Mais : (a) exige Windows Server 2025 (pas 2022), (b) exige un enrôlement via Azure Arc : (c) facturé 1,50 $ USD par cœur et par mois en abonnement. Pour un cluster PME 3 nœuds × 2 CPU × 16 cœurs = 96 cœurs, cela représente ≈ 1 730 $ / an de coût récurrent supplémentaire, à intégrer au TCO. Sans hotpatching, le rythme mensuel reste la règle.
• Storage Spaces Direct exigeant. S2D exige du matériel certifié très spécifique (NICs RDMA-capable, NVMe homogène, contrôleurs HBA en mode pass-through), un minimum de 4 nœuds pour la résilience « tolérance = 1 » et une connaissance fine du tuning (tiering, cache, résilience mirror/parity). La densité I/O reste inférieure à vSAN ou SCRIBE sur profils mixtes, et les incidents de rééquilibrage post-panne sont bien documentés dans la communauté.
• Compétences inégales sur le marché. Les administrateurs Hyper-V expérimentés sont plus rares que les administrateurs VMware historiques. Le recrutement ou la montée en compétence d'un MSP partenaire est à anticiper.

Verdict pragmatique : Hyper-V reste un très bon choix pour une PME entièrement dans l'écosystème Microsoft, avec une équipe IT qui maîtrise déjà Windows Server. Le calcul TCO honnête intègre cependant, si la criticité le justifie, l'abonnement hot-patching via Azure Arc, ou une organisation de fenêtres de maintenance mensuelles rigoureuses.

4.3. Nutanix AHV

Ce qu'on y gagne. Hyperconvergence haut de gamme, hyperviseur KVM-dérivé (AHV) inclus, Prism Central pour l'administration multi-site, politiques de résilience fines (FTT-1, FTT-2, EC-X pour l'érasure coding). Écosystème DR mature (Nutanix Mine pour la sauvegarde intégrée, NC2 pour le cloud hybride).

Les limites à connaître. Ciblage historique mid-market / enterprise. Les tarifs par cœur restent élevés et la complexité du licensing (Starter/Pro/Ultimate, AOS, Files, Calm…) fait écho à VMware pré-Broadcom. Sur un cluster 3 nœuds PME, Nutanix coûte souvent plus cher qu'un VMware + SAN d'hier.

4.4. Scale Computing HyperCore (HC3)

Ce qu'on y gagne. Architecture simplifiée de bout en bout : hyperviseur KVM modifié + SCRIBE (Scale Computing Reliable Independent Block Engine) qui remplace à la fois le système de fichiers VM, le RAID local et la réplication inter-nœud. Pas de SAN, pas de switch FC, pas de gestionnaire de stockage séparé. Licensing simple : un abonnement par nœud. Cluster minimum à 3 nœuds, résilience nœud-perdu native. Migration VMware-vers-Scale outillée (Scale Move, adapté à la conversion chaude). Déclinaisons « edge » compactes (Simply NUC Onyx, Lenovo ThinkEdge SE100) pour sites distants sans armoire climatisée.

Écosystème matériel, plus ouvert qu'il n'y paraît. Contrairement à une idée répandue, HyperCore ne se limite pas à une appliance Scale propriétaire. Les Technology Alliance Partners officiels couvrent en 2026 : Lenovo (gamme ThinkSystem, ThinkEdge SE100 pour l'edge), Dell (PowerEdge, y compris la réutilisation de nœuds VxRail existants de 14ᵉ à 16ᵉ génération via une licence d'intégration software-only), HPE (ProLiant validés), Supermicro (plateformes x86 certifiées edge et datacenter) et Simply NUC (mini-PC Onyx pré-intégrés pour l'edge et le retail). Ce dernier point est important sur le terrain : une PME qui hérite d'un parc VxRail récent peut y faire tourner HyperCore sans renouveler les serveurs, uniquement en basculant les licences. C'est un chemin de sortie VMware à CapEx réduit, peu communiqué mais concret.

Les limites à connaître.

• Écosystème SDN et orchestration plus étroit. Sur la sauvegarde, le paysage 2026 est largement couvert : Veeam avec son plug-in officiel SC//HyperCore (agentless, app-aware SQL/Exchange/Oracle/AD, CBT, immuabilité) et Acronis Cyber Protect avec son agent agentless dédié. Les outils in-guest classiques (agents Windows/Linux) fonctionnent sans restriction. En revanche, les produits fortement couplés aux APIs vSphere avancées, SDN type NSX, orchestration vRealize, micro-segmentation granulaire, n'ont pas d'équivalent direct chez Scale. Si vous en dépendez aujourd'hui, il faudra revoir la chaîne, pas simplement la reconnecter.
• Lock-in logiciel plutôt que matériel. Le matériel est ouvert à plusieurs constructeurs, mais HyperCore lui-même reste un produit propriétaire indissociable de la souscription Scale Computing. Pas de version open-source téléchargeable : la portabilité d'un cluster hors de l'éditeur n'existe pas.
• Ciblage orienté edge / multi-sites. Scale excelle sur les environnements distribués 3-20 nœuds. Sur un datacenter central dense > 500 VM avec exigences SDN avancées (micro-segmentation fine, overlays VXLAN complexes), l'offre reste moins mature qu'un Nutanix Prism + Flow ou un NSX.

5. Pourquoi HC3 se détache sur le profil PME 20-200 VM

Le critère qui fait la différence n'est pas le prix de l'hyperviseur. C'est la suppression du SAN. Dans un cluster 3 nœuds classique VMware, la baie de stockage partagée représente 20 à 30 % du CapEx et génère un SPOF latent (contrôleur défaillant en dépannage = cluster dégradé). Elle impose aussi des compétences pointues : zoning FC, MPIO, tuning des queues, maintenance firmware coordonnée avec l'hyperviseur.

SCRIBE, en répliquant les blocs entre les 3 nœuds et en plaçant les I/O chaudes sur le NVMe local, rend cette couche inutile. L'administrateur voit deux ressources : du CPU, de la capacité. Pas de datastore, pas de LUN, pas de thin provisioning manuel. La courbe d'apprentissage s'écrase.

Sur le terrain, nous observons que cette simplification se traduit par une réduction nette du temps d'exploitation : moins d'opérations récurrentes (pas de rééquilibrage de LUN, pas de Storage vMotion, patching plus simple car tout est dans un seul firmware), moins d'incidents corrélés (stockage + hyperviseur = un seul stack). Ce n'est pas un argument marketing, c'est un gain d'exploitation mesurable.

Les limites inverses sont réelles : on perd les APIs vSphere riches, la granularité du SDN NSX, l'énorme écosystème de snapshots et de réplication tiers. Si votre environnement héberge un SAP HANA ou un cluster Oracle avec des exigences de stockage très spécifiques, HC3 n'est pas la réponse. Pour 80 % des workloads PME (AD, fileserver, ERP, SQL, RDS, applications métier, quelques Linux), c'est une réponse suffisante et nettement moins coûteuse à exploiter.

6. Edge Computing et PME multi-sites, cas d'exploitation observé

Un argument souvent sous-estimé dans l'arbitrage post-Broadcom : la géographie de l'entreprise. Une PME avec un siège et cinq agences n'a pas les mêmes contraintes qu'une PME mono-site. Sur plusieurs sites, la dualité « serveurs centraux + liens VPN lents » a longtemps été la norme. Elle est aujourd'hui dépassée : les applications métier modernes (GED, ERP, vidéosurveillance IP, IA locale) ont besoin de latence < 10 ms, ce que même une bonne fibre n'offre pas toujours en cas de congestion WAN.

Le Edge Computing apporte une réponse concrète : traiter les données là où elles sont produites, à l'agence ou à l'usine, sans imposer un aller-retour systématique vers le datacenter central. Scale Computing a construit son catalogue autour de cette idée : les nœuds HE150 (micro-format, sans ventilation active) sont conçus pour s'installer derrière un comptoir, dans un placard ou en armoire industrielle, sans climatisation dédiée.

Ce basculement n'est pas qu'une affaire de coûts. Il a aussi un effet sur la résilience : une agence équipée d'un cluster local continue à faire tourner sa vidéosurveillance, sa téléphonie et son ERP en autonomie pendant une coupure WAN prolongée. C'est une différence qualitative par rapport au modèle « tout centralisé » qui fait tomber les agences dès que la fibre du siège tombe.

7. Migration VMware → autre hyperviseur : ce qu'on ne vous dit pas assez

La plupart des présentations commerciales vendent une migration « à chaud » indolore. La réalité est plus nuancée.

Les trois techniques de conversion

• Cold V2V. VM arrêtée, disques convertis (VMDK → QCOW2 pour KVM/Proxmox/HC3, ou VHDX pour Hyper-V), VM redémarrée. Fiable, fenêtre de coupure = temps de conversion + re-démarrage. Outils : StarWind V2V Converter, qemu-img, outils natifs de la cible.
• Hot V2V. VM active, bloc-à-bloc via un agent ou un snapshot de base + sync incrémental, bascule finale courte. Scale Move, Nutanix Move, Veeam InstantRecovery. Fenêtre de coupure : quelques minutes par VM.
• Backup-restore. Sauvegarde Veeam ou Acronis sur VMware, restauration comme VM native sur la cible. Veeam supporte en restauration cross-hyperviseur Hyper-V, AHV, et SC//HyperCore depuis la v13 via son plug-in officiel. Acronis Cyber Protect couvre également VMware, Hyper-V, SC//HyperCore et permet une conversion différée des VM d'une plateforme à l'autre. Cette approche permet aussi d'étaler la migration en réutilisant l'outil de sauvegarde déjà en place.

Les pièges fréquents (retours d'exploitation 2024-2026)

• EFI vs BIOS. Une VM Windows en EFI sur vSphere peut refuser de démarrer après conversion si le bootloader n'est pas re-généré. Plan B : EasyRE, bcdboot, ou conversion vers BIOS en amont.
• VMware Tools. À désinstaller avant conversion, sous peine de laisser des pilotes orphelins qui consomment du CPU et perturbent le démarrage.
• Version matérielle (HW version 19+). Fonctionnalités propriétaires (vTPM, NVDIMM virtuel) non portables. Auditer avant migration.
• Snapshots accumulés. Un snapshot VMware vivant depuis 6 mois est quasi systématiquement source de corruption à la conversion. À consolider avant toute opération.
• Licences invités. Les licences Windows Server OEM liées au matériel VMware ne migrent pas. Prévoir Datacenter ou licences en volume. Les licences SQL Server par cœur peuvent changer d'assiette.
• Intégrations tiers. vRealize Operations, NSX policies, tags vSphere : tout est à reconstruire. Documenter avant migration, pas pendant.

Ordre de grandeur observé

Sur nos migrations 2024-2026, la règle empirique est : compter 1 jour par 10 VM de complexité moyenne, audit et tests inclus. Un environnement 3 nœuds / 50 VM se migre sur 3 à 5 semaines en travaillant en heures ouvrées, 1 à 2 semaines avec des fenêtres de nuit. Ajouter 2 semaines d'observation post-migration avant de déposer les anciens équipements.

8. Sortir du débat « hyperviseur », ce que Broadcom a vraiment changé

L'acquisition a accéléré une prise de conscience qui était latente : pour une PME de 20 à 200 VM, la virtualisation n'est plus un axe de différenciation technique. C'est de l'infrastructure commoditisée, qui doit coûter peu, s'exploiter vite, et libérer du temps pour les sujets qui comptent vraiment : cybersécurité, continuité d'activité, applications métier, conformité NIS2.

Dans ce cadre, le bon critère de choix n'est plus « quel hyperviseur a le meilleur vMotion ». C'est « quelle architecture me permet d'avoir un stack stable avec un effort d'exploitation proportionné à ma taille ». Pour certains, la réponse sera Proxmox avec un partenaire local. Pour d'autres, Hyper-V pour rester dans l'écosystème Microsoft. Pour beaucoup d'environnements PME 20–200 VM sur plusieurs sites, ce sera Scale Computing HC3.

L'arbitrage n'est jamais binaire. Il dépend de la base installée, du cycle matériel, des compétences internes et du modèle de support acceptable. Mais il est inévitable, et le temps joue contre les clients VMware qui espèrent un retour en arrière de Broadcom. Il ne viendra pas.