VMware sous Broadcom : le guide de désengagement que les DSI français ne peuvent plus ignorer

# VMware sous Broadcom : le guide de désengagement que les DSI français ne peuvent plus ignorer

> *En 2026, l'acquisition de VMware par Broadcom n'est plus une menace abstraite. C'est une réalité opérationnelle qui remodèle les budgets, les contrats et les marges de manœuvre des équipes IT. Ce guide s'adresse aux DSI, CTO et RSSI qui veulent sortir de la posture d'attente pour engager une trajectoire de désengagement maîtrisée.*

Pourquoi ce sujet ne tolère plus l'attentisme

La bascule est documentée. Depuis le rachat finalisé fin 2023, Broadcom a restructuré en profondeur le modèle commercial de VMware : fin des licences perpétuelles, migration forcée vers des abonnements, recentrage sur un portefeuille réduit, remontée significative des coûts pour les structures qui ne correspondent pas au profil « grand compte stratégique ».

Pour les collectivités publiques, les établissements hospitaliers, les ministères et les opérateurs d'importance vitale français qui ont massivement déployé vSphere, vSAN ou NSX au cours des quinze dernières années, la situation est celle-ci : une infrastructure critique repose sur un acteur américain dont la politique tarifaire et contractuelle échappe désormais totalement à toute influence européenne.

La question n'est plus « faut-il migrer ? » mais « comment structurer la migration sans casser la production ? »

Étape 1 — Cartographier l'exposition réelle avant toute décision

Avant d'engager quoi que ce soit, les équipes IT doivent produire une cartographie honnête de leur dépendance VMware. Cela signifie :

• Inventorier les composants effectivement utilisés : hyperviseur seul, ou stack étendue (vSAN, NSX, vCenter, Aria) ? La profondeur de l'intégration détermine le coût réel du désengagement.
• Identifier les workloads critiques vs. les workloads substituables : toutes les VM ne se valent pas. Certaines peuvent migrer en quelques semaines, d'autres portent des applications métiers avec des dépendances profondes qui nécessitent des mois de préparation.
• Dater les échéances contractuelles : quand expire votre contrat de support actuel ? Broadcom a imposé des cycles de renouvellement qui créent des fenêtres de pression. Connaître ses dates, c'est conserver un levier de négociation ou de sortie.
• Évaluer la compétence interne : vos équipes maîtrisent-elles une technologie alternative ? Si non, la formation est un prérequis, pas une option.

Cette cartographie doit être produite en interne, sans s'appuyer sur un partenaire dont le modèle économique dépend des licences VMware.

Étape 2 — Distinguer les trois trajectoires possibles

Il n'existe pas une seule réponse à la dépendance VMware. Les équipes IT doivent avoir une lecture claire des trois trajectoires disponibles, chacune avec ses implications opérationnelles.

Trajectoire A — Statu quo négocié : maintien de VMware avec renégociation contractuelle agressive. Cette trajectoire est défendable à court terme pour les structures dont la migration représente un risque opérationnel trop élevé. Elle n'est pas une solution durable : elle repousse le problème et renforce la dépendance.

Trajectoire B — Migration vers une alternative open source : basculement progressif vers des technologies comme Proxmox VE ou OpenStack pour la couche hyperviseur. Ces solutions sont matures, documentées, et exploitées en production dans plusieurs administrations européennes. Elles restituent la maîtrise du code et de la roadmap. L'enjeu est la montée en compétence des équipes et la gestion de la période de cohabitation.

Trajectoire C — Cloud souverain qualifié : externalisation maîtrisée vers un hébergeur certifié SecNumCloud, qui prend en charge la couche d'infrastructure. Cette trajectoire soulage les équipes IT opérationnelles mais transfère la responsabilité de la souveraineté sur un tiers — à choisir avec une rigueur contractuelle maximale.

Ces trajectoires ne sont pas exclusives. Une organisation complexe peut très bien engager la trajectoire B sur ses workloads standards et la trajectoire C sur ses données les plus sensibles.

Étape 3 — Évaluer concrètement Proxmox VE comme alternative de premier niveau

Proxmox VE mérite une évaluation sérieuse, pas un rejet par habitude ou par méconnaissance. Développé par la société autrichienne Proxmox Server Solutions, il repose sur KVM et LXC, dispose d'une interface de gestion centralisée, supporte la haute disponibilité, la réplication, et s'intègre dans des environnements de sauvegarde standards.

Concrètement, pour une équipe IT habituée à vSphere :

• La prise en main est accessible : l'interface web est fonctionnelle, la documentation est en anglais et en français, la communauté est active.
• La migration des VM existantes est outillée : des outils permettent de convertir des images VMware (formats VMDK) vers des formats compatibles. Ce n'est pas trivial à grande échelle, mais c'est documenté et répété.
• Le support commercial existe : Proxmox propose des abonnements de support avec SLA, ce qui lève l'objection classique du « on ne peut pas aller en production sans support ».
• L'ancrage européen est réel : siège en Autriche, code source ouvert, pas de dépendance à une politique de licences opaque.

Le point de vigilance : Proxmox ne couvre pas nativement l'ensemble des fonctionnalités d'une stack VMware avancée (NSX pour la partie réseau défini par logiciel, par exemple). L'évaluation doit être fonctionnelle, pas dogmatique.

Étape 4 — Structurer un pilote de migration sans mettre la production en danger

Aucune migration d'infrastructure ne doit commencer en production. Le pilote est non négociable. Voici comment le structurer avec rigueur :

1. Sélectionner 3 à 5 workloads représentatifs mais non critiques pour constituer le périmètre pilote. L'objectif est de tester les procédures, pas de prouver que ça fonctionne sur un cas trivial.

2. Monter un environnement de destination isolé sur du matériel dédié ou en environnement de test. Ne pas partager les ressources avec la production pendant la phase pilote.

3. Mesurer et documenter : temps de migration effectif, incidents rencontrés, écarts de performance, compétences mobilisées. Ces données alimentent le business case pour la migration complète.

4. Inclure les équipes applicatives dans le pilote dès le début. Les problèmes de compatibilité applicative se découvrent en faisant tourner les applications, pas en migrant des VM à vide.

5. Définir des critères de succès explicites avant de lancer le pilote, pas après. Sans critères, l'évaluation sera biaisée par les résistances internes.

La durée réaliste d'un pilote sérieux est de six à douze semaines. En deçà, les conclusions sont insuffisamment robustes.

Étape 5 — Traiter la question des compétences comme un risque de premier rang

C'est le point le plus sous-estimé dans les plans de migration. Les équipes IT qui ont passé dix ans sur VMware ont des réflexes, des automatismes, des scripts. Le changement de plateforme ne se réduit pas à un changement d'outil : c'est un changement de culture opérationnelle.

Actions concrètes :

• Identifier les profils internes qui ont déjà une exposition à Linux, KVM ou OpenStack. Ce sont vos premiers relais.
• Prévoir du temps de formation structuré : pas des tutoriels YouTube, mais des formations avec mise en pratique sur environnement réel. Plusieurs organismes français proposent des formations certifiantes sur ces technologies.
• Planifier une montée en charge progressive des équipes : on ne peut pas demander à une équipe de cinq personnes de migrer une infrastructure de plusieurs centaines de VM tout en assurant la continuité de service.
• Documenter au fur et à mesure : chaque procédure maîtrisée dans l'ancien environnement doit avoir son équivalent documenté dans le nouveau. C'est un travail ingrat mais stratégique pour réduire la dépendance à des individus clés.

Étape 6 — Intégrer la dimension contractuelle et réglementaire dès le départ

Un désengagement VMware mal préparé sur le plan juridique peut créer autant de risques qu'il en résout.

• Analyser les clauses de portabilité dans vos contrats actuels : avez-vous le droit d'exporter vos configurations, vos données, vos images VM sans restriction ? Cette vérification juridique est préalable à toute action technique.
• Pour les opérateurs régulés (OIV, établissements de santé, collectivités sous NIS2) : la migration d'infrastructure est un changement majeur qui peut déclencher des obligations de notification ou de validation auprès des autorités compétentes (ANSSI). Ne pas le découvrir en cours de migration.
• Exiger des garanties contractuelles équivalentes auprès du nouvel hébergeur ou du prestataire de support open source : SLA, réversibilité, localisation des données, conditions de résiliation. Le changement de dépendance ne doit pas créer une nouvelle dépendance non maîtrisée.
• Documenter la décision de migration : dans un contexte où la gouvernance IT est auditée, avoir un dossier de décision tracé (cartographie des risques, alternatives évaluées, critères de choix) protège les équipes dirigeantes et les DSI en cas de questionnement ultérieur.

Ce que ce guide ne dit pas

Ce guide ne dit pas que la migration est simple. Elle ne l'est pas. Il ne dit pas non plus qu'il faut migrer tout, tout de suite. Ce serait irresponsable.

Il dit ceci : la fenêtre dans laquelle les organisations françaises et européennes peuvent engager cette migration avec du temps, des ressources et une certaine sérénité se réduit à chaque renouvellement de contrat VMware signé sans condition de sortie. Chaque année passée à attendre est une année où la dépendance se consolide, où les compétences alternatives s'atrophient, et où le coût réel du désengagement augmente.

La souveraineté numérique n'est pas un principe de communication institutionnelle. C'est un ensemble de décisions techniques et contractuelles concrètes, prises ou non prises, par des DSI et des équipes IT qui ont d'autres urgences mais qui, précisément pour cette raison, ont besoin d'un cap clair.