VMware après Broadcom : quelles conséquences pour votre infrastructure ?
Ce qui était annoncé comme une consolidation marché s'est révélé être, pour beaucoup de DSI, un point d'inflexion stratégique. Les impacts du rachat de VMware par Broadcom ne sont pas uniformes, ils ne sont pas tous négatifs, et ils méritent une lecture calme avant une décision précipitée.
Ce qui a réellement changé du côté des licences
La première vague de choc a été tarifaire. Broadcom a restructuré l'offre VMware autour de bundles (VMware Cloud Foundation et vSphere Foundation), abandonnant la granularité des licences perpétuelles sur lesquelles beaucoup d'entreprises s'étaient organisées.
Le modèle perpetual + support n'existe plus en version neuve. Tout passe par l'abonnement. Pour des organisations qui avaient amorti leur VMware sur 5 à 8 ans, le passage à un modèle récurrent représente une rupture budgétaire réelle, pas juste un ajustement.
Ce que beaucoup de analyses oublient : la hausse ne s'applique pas uniformément. Les petites installations (moins de 50 nœuds) et les grandes entreprises sous Enterprise Agreement ont eu des trajectoires très différentes. Certains comptes ont vu leurs coûts multipliés par 3 à 5. D'autres ont négocié des transitions raisonnables. Il n'y a pas une seule réalité Broadcom.
L'impact organisationnel : la vraie complexité
Au-delà du tarif, ce qui perturbe le plus les équipes IT, c'est l'instabilité du contrat de confiance avec l'éditeur.
VMware avait construit une relation long terme avec les équipes d'exploitation. Certifications reconnues, écosystème partenaire stable, documentation de référence, support prévisible. Broadcom a perturbé tout cela simultanément : changements de canaux de distribution, disparition de certains programmes partenaires, modifications du support technique, uncertainty sur la roadmap produit.
La charge cognitive portée par les responsables infrastructure depuis 12 mois est significative. Ce n'est pas la même chose de gérer un fournisseur que d'avoir à redéfinir une architecture qui était justement bâtie sur la stabilité de cet écosystème.
Ce que ça change sur la trajectoire d'architecture à 5 ans
Avant Broadcom, la trajectoire par défaut pour beaucoup d'entreprises était : renouveler VMware, continuer à consolider, peut-être explorer vSAN ou NSX marginalement. Un chemin balisé.
Cette trajectoire n'est plus automatique. Et ce n'est pas nécessairement un problème.
Les arbitrages qu'on observe sur le terrain vont dans trois directions :
1. Renouvellement préservé sous conditions — pour les environnements fortement intégrés avec les couches supérieures (VMware Aria, NSX, vSAN), la migration a un coût qui peut dépasser le coût de renouvellement sur 3 ans. Dans ces cas, le renouvellement Broadcom reste rationnel, même si inconfortable.
2. Migration progressive — pour les environnements essentiellement hyperviseur (vSphere sans NSX ni vSAN), la migration vers Proxmox VE ou XCP-ng est techniquement accessible. Elle demande de la méthode, pas nécessairement une refonte architecturale complète.
3. Coexistence longue durée — la trajectoire la plus fréquente sur le terrain. VMware maintenu sur les charges les plus intégrées, migration progressive des charges moins dépendantes sur 18 à 36 mois.
Les risques de la décision précipitée
La pression budgétaire pousse certaines DSI à vouloir sortir de VMware vite. C'est compréhensible. C'est rarement la bonne réponse.
Les migrations précipitées génèrent des coûts cachés que les analyses ROI surfaciques ne capturent pas : temps de re-formation opérationnelle, incidents de production pendant la phase de consolidation des pratiques, retravail des runbooks, interruptions partielles de service.
Ce qu'on recommande comme posture
Pas de dogme. La décision dépend de l'entreprise, pas d'une position idéologique sur VMware ou Broadcom.
Ce qu'on conseille systématiquement avant tout arbitrage :
- Cartographier la dépendance réelle : est-ce que l'infrastructure utilise uniquement vSphere, ou aussi NSX/vSAN/Arc/Aria ?
- Modéliser les trois scénarios sur 3 ans : renouvellement intégral, migration complète, coexistence hybride.
- Ne pas confondre problème de licence et problème d'architecture : parfois l'infrastructure a besoin d'évoluer pour des raisons qui n'ont rien à voir avec Broadcom. La séparation des sujets clarifie les décisions.
- Définir la capacité de transformation de l'équipe : une migration, même bien conçue, demande de la bande passante opérationnelle.
Ce que ça ne change pas
Les fondamentaux restent les mêmes. La production doit continuer. Le PRA doit fonctionner. Les équipes doivent pouvoir opérer. L'hyperviseur est un composant dans un système plus large.
Après Broadcom comme avant Broadcom, l'infrastructure doit être opérée par des gens qui la comprennent, avec des procédures testées, sur une architecture dont les dépendances sont connues.
Le reste est une question de coût, de calendrier, et de risque. Trois dimensions sur lesquelles on peut construire une décision rationnelle.