Depuis la finalisation du rachat de VMware par Broadcom en novembre 2023, le modèle de licence a changé plus vite que la plupart des organisations ne pouvaient l’anticiper. Le sujet ne se limite pas à une hausse de tarif : il concerne la disparition des droits perpétuels, le basculement vers une métrique par cœur physique, la réduction du catalogue et la transformation de produits autrefois acquis séparément en bundles plus larges.
Pour les administrateurs, l’impact est d’abord contractuel et budgétaire. Pour les équipes d’architecture, il est aussi technique : certains environnements doivent désormais arbitrer entre conserver une plate-forme existante, redimensionner les hôtes, accepter des fonctions incluses mais inutilisées, ou évaluer des alternatives. Les chiffres publiés par des clients, intégrateurs et analystes montrent des situations très contrastées, mais convergent sur un point : le coût de renouvellement n’est plus prévisible à partir de l’ancien prix de maintenance.
Une rupture : fin des licences perpétuelles et des contrats de support associés
Avant le changement de modèle, une organisation pouvait acquérir une licence perpétuelle vSphere, vSAN ou d’un produit associé, puis maintenir un contrat de support et de mises à jour. La licence restait utilisable tant que l’organisation souhaitait conserver la version installée, même après l’expiration du support. Le renouvellement annuel couvrait principalement l’accès aux correctifs, aux nouvelles versions et au support éditeur.
Ce modèle a été abandonné. Broadcom a annoncé l’arrêt de la vente des licences perpétuelles VMware et la transition vers des abonnements. Les nouvelles souscriptions donnent droit à l’usage du logiciel pour une période déterminée, généralement un, trois ou cinq ans selon l’offre et le canal de vente. Lorsque l’abonnement prend fin sans renouvellement, le droit contractuel d’utilisation prend fin également.
Cette différence est essentielle dans une stratégie d’infrastructure :
- avec une licence perpétuelle, l’environnement peut continuer à tourner, sous réserve des contraintes de sécurité et de support ;
- avec un abonnement, la continuité légale d’exploitation dépend du renouvellement ;
- le coût n’est plus concentré au moment de l’achat initial, mais devient une charge récurrente ;
- le renouvellement est exposé aux évolutions futures de la grille tarifaire et du catalogue.
Les anciens contrats SnS, pour Support and Subscription, n’ont pas simplement été renommés. Les clients doivent, à terme, migrer vers les offres d’abonnement applicables. Les conditions exactes dépendent de la date d’échéance, des produits détenus, des accords existants et du contrat de distribution. Il faut donc éviter de raisonner uniquement en équivalence de SKU : l’analyse doit intégrer les droits acquis, les dates de renouvellement, les minimums de souscription et le périmètre fonctionnel réellement consommé.
Du socket au cœur : une métrique qui pénalise les hôtes très denses
Le changement le plus visible dans les feuilles de calcul est l’abandon de la licence par processeur ou socket au profit d’une licence par cœur physique. VMware avait déjà proposé des mécanismes tenant compte des cœurs, mais le modèle historique vSphere restait largement compris comme une métrique par CPU physique, avec des limites de cœurs par socket selon les générations de contrats. Pour aller plus loin, consultez les alternatives sérieuses à VMware.
Dans le modèle d’abonnement actuel, la consommation est calculée sur les cœurs physiques actifs des processeurs des hôtes ESXi. Les threads SMT ou Hyper-Threading ne sont pas comptés comme des cœurs distincts. En revanche, un serveur bi-socket équipé de deux processeurs de 32 cœurs nécessite 64 cœurs souscrits, et non plus deux licences processeur.
Un minimum de 16 cœurs par processeur physique s’applique couramment dans les offres VMware. Ainsi, un hôte avec deux processeurs de 12 cœurs sera généralement comptabilisé pour 32 cœurs, soit 16 par socket. Ce plancher a un effet limité sur les serveurs récents fortement dotés, mais il peut dégrader le ratio économique de certains petits hôtes, sites distants ou clusters de gestion.
Exemple simplifié pour un cluster de quatre hôtes :
| Configuration par hôte | Ancienne logique par socket | Nouvelle logique par cœur |
|---|---|---|
| 2 CPU x 16 cœurs | 2 licences CPU | 32 cœurs |
| 2 CPU x 24 cœurs | 2 licences CPU | 48 cœurs |
| 2 CPU x 32 cœurs | 2 licences CPU | 64 cœurs |
| 2 CPU x 48 cœurs | 2 licences CPU | 96 cœurs |
Dans l’ancien modèle, ces quatre configurations pouvaient présenter un coût de licence vSphere comparable si elles occupaient deux sockets. Dans le nouveau modèle, l’écart suit directement la densité en cœurs. Un renouvellement doit donc partir d’un inventaire matériel précis, et non du nombre de serveurs ou de sockets.
La collecte peut être réalisée depuis PowerCLI, en distinguant bien les cœurs physiques du nombre de processeurs logiques :
Connect-VIServer -Server vcenter.example.local
Get-VMHost | Select-Object `
Name,
@{N='Sockets';E={$_.ExtensionData.Hardware.CpuInfo.NumCpuPackages}},
@{N='CoeursPhysiques';E={$_.ExtensionData.Hardware.CpuInfo.NumCpuCores}},
@{N='ThreadsLogiques';E={$_.ExtensionData.Hardware.CpuInfo.NumCpuThreads}} |
Sort-Object Name
Pour consolider la consommation théorique de cœurs à partir des hôtes connectés :
$hosts = Get-VMHost | Where-Object {$_.ConnectionState -eq 'Connected'}
$totalCores = ($hosts | Measure-Object `
-Property {$_.ExtensionData.Hardware.CpuInfo.NumCpuCores} `
-Sum).Sum
$totalCores
Ce calcul ne remplace pas une proposition commerciale : des règles de minimum par processeur, des hôtes de secours, des environnements de PRA et des exclusions contractuelles peuvent modifier le volume final. Il donne toutefois une base factuelle pour détecter les architectures les plus exposées.
Rationalisation du catalogue : VVF et VCF au centre
Broadcom a fortement réduit le nombre d’éditions et de produits VMware commercialisés séparément. Les offres mises en avant pour l’infrastructure sont notamment VMware vSphere Foundation, ou VVF, et VMware Cloud Foundation, ou VCF.
VVF cible les environnements de virtualisation vSphere qui ont besoin d’un socle d’exploitation plus large que l’hyperviseur seul. Le bundle regroupe notamment des composants relevant de vSphere, vCenter, vSAN et des fonctions d’opérations et de gestion. Son contenu exact, les limites de capacité et les droits d’usage doivent être vérifiés dans le guide de licence applicable à la date de commande : la composition des bundles et les dénominations commerciales ont évolué depuis 2023.
VCF couvre un périmètre plus large, orienté vers une plate-forme de cloud privé intégrée. Il inclut des capacités de calcul, de stockage, de réseau, d’automatisation et d’opérations qui étaient auparavant acquises à travers plusieurs licences ou gammes distinctes. Dans de nombreuses architectures, cela inclut notamment la virtualisation réseau et des composants d’automatisation.
Le problème n’est pas qu’un bundle soit intrinsèquement inadapté. Une organisation exploitant réellement vSAN, la virtualisation réseau, l’automatisation et une couche d’opérations peut trouver une cohérence opérationnelle à un ensemble intégré. La difficulté apparaît lorsque le bundle impose l’achat de fonctions qui ne sont ni déployées ni prévues. Pour aller plus loin, consultez le calcul du coût total de possession.
Quelques cas fréquents :
- un cluster utilisant un SAN externe et n’ayant pas de projet vSAN ;
- une plate-forme de virtualisation réseau déjà fournie par une solution tierce ;
- une petite ferme vSphere pour laquelle les composants d’automatisation de VCF sont disproportionnés ;
- des filiales ou sites industriels ayant peu d’hôtes, mais devant satisfaire un minimum de souscription ;
- des environnements où les équipes n’ont ni les compétences ni le besoin d’exploiter tous les composants inclus.
La disparition de certaines offres d’entrée de gamme a renforcé cet effet. Des éditions historiquement adaptées aux petites et moyennes infrastructures, ainsi que l’édition gratuite de l’hyperviseur, ne constituent plus une voie d’acquisition comparable dans le catalogue actuel. Le résultat est une rupture particulière pour les laboratoires, les petites structures, les sites isolés et les usages non productifs qui s’appuyaient sur l’hyperviseur gratuit.
Il convient aussi de séparer deux notions souvent confondues : l’accès aux binaires et le droit de production. La disponibilité d’une image d’installation ou d’une période d’évaluation ne crée pas un droit permanent d’exploitation. Les équipes doivent documenter la finalité de chaque environnement : production, développement, recette, formation, laboratoire ou reprise après sinistre.
Hausse des coûts : ce que rapportent les clients et ce que les chiffres permettent réellement d’affirmer
Le marché a largement relayé des hausses de coût très importantes, parfois de plusieurs centaines de pour cent. Ces témoignages sont réels, mais ils ne doivent pas être transformés en règle universelle. Il n’existe pas un pourcentage unique applicable à tous les clients VMware.
Les écarts dépendent notamment de cinq paramètres :
- le nombre de cœurs physiques par hôte ;
- les produits et éditions précédemment détenus ;
- la part des fonctions désormais imposées dans le bundle ;
- la durée d’engagement et les remises contractuelles ;
- la comparaison retenue : coût de maintenance annuel, coût total sur trois ans, ou coût total de possession incluant matériel et exploitation.
Des enquêtes d’acheteurs IT et des déclarations publiques de responsables informatiques ont fait état de renouvellements multipliés par deux, par trois, voire davantage dans certains cas. Des organisations utilisant auparavant une combinaison de licences perpétuelles et de maintenance ont parfois comparé leur ancienne maintenance annuelle à un abonnement couvrant un périmètre fonctionnel plus large. Cette méthode reflète un impact budgétaire concret, mais elle n’est pas toujours une comparaison strictement homogène.
À l’inverse, une entreprise qui consommait déjà plusieurs briques VMware, qui possède des hôtes modérément denses et qui négocie un engagement pluriannuel peut observer une évolution plus contenue. Le point central est donc moins de chercher un taux de hausse moyen que de calculer le delta pour son propre parc.
Une méthode de comparaison utile consiste à produire trois scénarios sur la même période, par exemple trois ans :
| Scénario | Éléments à inclure |
|---|---|
| Maintien à court terme | Support restant, renouvellements obligatoires, risque de fin de support |
| Migration vers VVF ou VCF | Cœurs souscrits, minimums, durée, services associés, formation |
| Alternative | Licences ou support, migration, conversion des VM, sauvegarde, exploitation, risque |
Le coût de migration vers une autre plate-forme ne doit pas être sous-estimé. Il inclut souvent la refonte des procédures de sauvegarde, de supervision, de PRA, d’automatisation, de sécurité, de réseau virtuel et de gestion des images. Mais l’inverse est également vrai : conserver VMware sans chiffrer le coût récurrent sur plusieurs échéances revient à reporter une décision financière structurante.
Réactions des grands comptes : négociation, gel et diversification
Les réactions des grandes organisations sont hétérogènes, mais plusieurs tendances ressortent des prises de parole publiques, des appels d’offres et des retours d’intégrateurs.
La première est la renégociation agressive. Les grands comptes disposent parfois d’accords-cadres, de volumes importants et de capacités à s’engager sur plusieurs années. Ils cherchent à obtenir des remises, des protections tarifaires et des droits d’usage explicites. Le sujet n’est plus seulement le prix unitaire par cœur : les clients négocient aussi les conditions de renouvellement, les environnements de secours, les filiales, les fusions-acquisitions et les droits de mobilité.
La deuxième est le gel des extensions non indispensables. Lorsque le coût marginal d’un hôte supplémentaire augmente avec sa densité en cœurs, les équipes peuvent différer des projets de capacité, consolider autrement les charges ou prolonger temporairement un matériel existant. Ce choix doit être encadré, car il peut entrer en conflit avec les objectifs de sécurité, de performance ou de renouvellement matériel.
La troisième est la diversification. Plusieurs organisations ont lancé des évaluations de plates-formes alternatives, souvent sans plan de migration immédiat. L’objectif est de réduire la dépendance à un fournisseur, de disposer d’un levier de négociation et d’identifier les charges réellement portables. Les premières candidates sont généralement les VM peu couplées aux fonctions avancées de l’écosystème VMware, les environnements de développement et les nouveaux projets. Pour aller plus loin, consultez un témoignage de migration.
Enfin, certains grands comptes choisissent de rester sur VCF parce qu’ils utilisent déjà une part importante des briques incluses, ou parce que le coût et le risque d’une migration dépassent le différentiel de licence à court terme. C’est une décision rationnelle lorsqu’elle s’appuie sur des données, pas une adhésion implicite au nouveau modèle.
Construire un dossier de renouvellement exploitable
Un renouvellement VMware ne devrait plus être traité comme un simple achat de support. Il faut constituer un dossier de décision contenant au minimum :
- l’inventaire des hôtes, sockets, cœurs physiques et rôles de cluster ;
- les versions vSphere, vCenter, vSAN et produits connexes ;
- les fonctionnalités effectivement utilisées : HA, DRS, vMotion, vSAN, réseau virtuel, automatisation, opérations ;
- les environnements de production, de PRA, de recette et de laboratoire ;
- les dates de fin de contrat et les droits existants ;
- la projection de capacité matérielle à trois ou cinq ans ;
- le coût complet des scénarios de maintien, de migration vers un bundle et d’alternative ;
- les dépendances applicatives et opérationnelles qui rendent une migration complexe.
L’analyse des fonctionnalités utilisées peut commencer par les extensions déployées dans vCenter. Cette commande ne fournit pas une preuve de licence, mais aide à identifier les produits intégrés à l’environnement :
Get-View ExtensionManager | ForEach-Object {
$_.ExtensionList | Select-Object Key, Version, Description
} | Sort-Object Key
Il faut ensuite distinguer les composants installés de ceux qui apportent une valeur opérationnelle. Un produit peut être présent dans l’inventaire mais peu ou pas utilisé. À l’inverse, une fonction apparemment simple, comme la migration à chaud ou l’intégration de la sauvegarde, peut représenter une dépendance majeure.
Le changement de licence VMware depuis Broadcom est donc un sujet d’architecture autant que de procurement. La fin du perpétuel transforme le rapport au renouvellement. La facturation par cœur remet la densité CPU au centre des arbitrages. Les bundles VVF et VCF peuvent simplifier certains portefeuilles, mais imposent parfois un périmètre fonctionnel plus large que le besoin réel. Dans ce contexte, la meilleure réponse consiste à quantifier le parc, documenter les usages, vérifier les droits contractuels et comparer des scénarios homogènes sur plusieurs années.
