Votre sortie de VMware fera mal à moins de démarrer maintenant : le plan d’action d’un CTO sur 12 mois

Votre hyperviseur est désormais un risque porté jusqu’au conseil d’administration. Après la refonte des licences par Broadcom, beaucoup d’entreprises ont découvert que leur facture vSphere n’augmentait pas seulement — elle doublait, parfois pire. Et ce n’est pas hypothétique : un opérateur des États‑Unis aurait commencé à déplacer des dizaines de milliers de VM hors de VMware tout en se battant au tribunal. S’ils ne supportent pas le verrouillage, pourquoi pensez‑vous que vous le pourrez ?

On ne règle pas ça avec un communiqué de presse ni avec un « lift‑and‑shift » en deux semaines. La migration à chaud inter‑hyperviseurs n’existe pas. Vos abstractions NSX ne se traduisent pas en 1:1 en dehors de VMware. Et prendre la voie de la facilité — « mettez tout sur EC2 » — vous livrera une nouvelle facture de 2–3x votre coût on‑prem entièrement amorti une fois ajoutés l’egress, les instances réservées, la sauvegarde et l’inévitable sur‑provisionnement de performance.

Voici la vérité qui dérange : il vous faut un plan de sortie discipliné, et il commence ce trimestre. Ci‑dessous : un plan sur 12 mois, des options technologiques avec de vrais compromis, et les pièges que j’ai vus exploser des équipes qui couraient vers la sortie.

Le cadre de décision : quatre voies viables pour sortir de VMware

Choisissez une trajectoire en fonction du mix de charges, des compétences, des contraintes de latence et de la conformité. C’est une question de portefeuille, pas de concours de beauté.

1) HCI à dominante KVM (Proxmox VE, Harvester, dérivés d’oVirt)

Idéal pour : parcs majoritairement Linux, échelle modérée (de dizaines à quelques centaines de nœuds), équipes à l’aise avec l’exploitation Linux.

• Pourquoi ça marche : KVM est l’hyperviseur de facto chez AWS, GCP et de nombreux clouds. Proxmox VE offre une interface et une API propres, le clustering, la migration à chaud et la sauvegarde native. Harvester (KubeVirt + Longhorn) ajoute un substrat Kubernetes si vous souhaitez harmoniser l’exploitation des VM et des conteneurs.
• Économie : Proxmox VE est gratuit à l’usage ; les abonnements au dépôt enterprise coûtent environ 110 € à 935 € par socket CPU et par an selon le niveau de support. Même avec support, vous atterrirez généralement à 10–30 % de vos dépenses logicielles VMware historiques pour une capacité équivalente.
• Compromis : vous perdez une partie de l’ergonomie NSX/vSAN. Vous reconstruirez les overlays réseau (OVN/OVS) et le stockage (Ceph/ZFS/Longhorn) vous‑même ou avec un partenaire.

2) OpenStack (avec KVM, OVN, Ceph)

Idéal pour : clouds privés multi‑équipes, besoins multi‑locataires, forte maturité ops.

• Pourquoi ça marche : OpenStack fournit des primitifs IaaS (compute, réseau, stockage) avec quotas, projets et des API solides. C’est ce qui se rapproche le plus d’un EC2 privé.
• Économie : le logiciel est open source ; le coût, c’est l’exploitation. Prévoyez d’investir dans une couverture SRE 24/7 et du CI/CD pour la plateforme cloud elle‑même.
• Compromis : complexité. Si votre équipe n’a jamais opéré de plan de contrôle, n’apprenez pas sur votre sortie de prod.

3) Alternatives HCI commerciales (Nutanix AHV)

Idéal pour : parcs mixtes Windows/Linux, équipes qui souhaitent le fini de VMware sans VMware.

• Pourquoi ça marche : plan de management mature, outils invités Windows, stockage et réseau intégrés. AHV, c’est KVM sous le capot avec le plan de contrôle Nutanix.
• Économie : vous paierez un vrai prix, mais pour beaucoup d’organisations cela reste inférieur au TCO du « nouveau VMware » une fois déduits les bundles Broadcom dont vous n’avez pas besoin.
• Compromis : une nouvelle relation fournisseur, avec son risque de feuille de route. Moins de flexibilité DIY que Proxmox/OpenStack.

4) Rehost dans le cloud public (EC2/Azure/GCP)

Idéal pour : petits parcs ou équipes déjà à >70 % cloud où l’on‑prem n’est que de la dette technique.

• Pourquoi ça marche : chemin le plus rapide pour échapper à un renouvellement VMware. Écosystème riche pour PRA, sauvegardes et services managés.
• Économie : le choc de l’étiquette est courant. Une fois stabilisé, attendez‑vous à 1,5–3,0x vs. un cluster on‑prem bien opéré de même profil de performance, selon l’egress et votre discipline sur les RI.
• Compromis : latence, résidence des données et maîtrise des coûts. N’empruntez pas ce chemin pour des workloads bavards, très gourmands en stockage et à faible marge sauf si vous aimez les factures surprises.

Votre plan de sortie VMware sur 12 mois

0–30 jours : gel, inventaire, baseline

• Geler les fonctionnalités : n’introduisez plus de constructs spécifiques NSX/vSAN. Pas de nouvelles dépendances SRM.
• Inventoriez comme un prêteur : exportez via RVTools ou votre CMDB, mais validez par échantillonnage sur les OS invités réels. Étiquetez chaque VM avec propriétaire, RTO/RPO, CPU/RAM/IOPS, OS et dépendances (DNS/AD/NTP, bases de données, bus de messages).
• Baseline de coûts : les 12 derniers mois de lignes VMware, tickets de support, licences de sauvegarde, électricité et espace. Il vous faut cela pour défendre le business case.
• Tuez les « pet projects » : si personne ne peut nommer le propriétaire d’une VM en 48 heures, mettez‑la sur une trajectoire de dépréciation. Le poids mort tue les migrations.

30–90 jours : choisir la cible, construire un pilote

• Choisissez votre voie. Si vous avez surtout du Linux et une exploitation en interne, Proxmox VE avec Ceph est la voie la plus pragmatique et rapide. Si vous avez besoin de projets et quotas multi‑locataires, évaluez OpenStack. Si le confort d’admin Windows et une UX premium comptent, shortlistez Nutanix AHV. Si votre parc est minuscule ou déjà à 80 % cloud, planifiez un rehost.
• Montez un pilote : minimum 3 nœuds (cache NVMe, NICs 25/50 Gbps, 256–512 Go de RAM). Pour Proxmox, ajoutez Proxmox Backup Server. Pour le stockage, démarrez avec Ceph ou des miroirs ZFS selon l’échelle.
• Réalisez des conversions : utilisez virt‑v2v pour les VM Linux et Windows (retirez VMware Tools, installez les pilotes virtio). Attendez‑vous à une fenêtre de maintenance ; la migration à chaud inter‑hyperviseurs n’existe pas.
• Validez les fondamentaux : sauvegardes, restaurations, snapshots, création de templates et RBAC. Si vous n’avez pas restauré un DC Windows depuis votre nouvelle pile, vous n’avez rien testé.

90–180 jours : réseau, stockage et vague 1

• Plan réseau : recréez VLAN et overlays avec OVN/OVS ou votre fabric de switches. Transposez les règles de pare‑feu NSX vers des pare‑feu en hôte ou en amont. Placez DHCP/DNS sous une HA correcte.
• Plan stockage : vSAN ≠ Ceph. Démarrez avec 3–5 hôtes MON/MDS avec SSD/NVMe. Validez les IOPS sous vos workloads réels. Activez TRIM/UNMAP sur les invités pour éviter le bloat I/O.
• Automatisation : adoptez l’IaC dès maintenant. Utilisez les providers OpenTofu/Terraform pour Proxmox ou votre plateforme choisie. Cuisinez des images dorées avec Packer/Cloud‑Init.
• Migrations de la vague 1 : choisissez trois classes : une appli stateless, une base de données moyenne et un service Windows (impression/ADCS/legacy métier). Validez performance et opérabilité. Documentez les runbooks réellement utilisés, pas ceux que vous aviez rédigés.

180–270 jours : montée en charge, PRA et gouvernance

• Élargir l’échelle : étendez jusqu’à la capacité cible. Ajoutez une seconde baie ou un second cluster pour le PRA. Répliquez les sauvegardes hors site. Pour Proxmox, testez les pertes de quorum et le « fencing » du cluster.
• Schémas de PRA : acceptez la réalité : le basculement sera à froid‑vers‑tiède pour la plupart des VM. Scripttez l’ordre de boot, les bascules DNS et la promotion des bases. Chronométrez l’exercice ; si votre RTO indique 60 minutes et que vous faites 140, ajustez le plan ou le SLA.
• Observabilité : Prometheus + Grafana pour hôtes et invités ; exporters Proxmox ou OpenStack ; agrégation de logs avec Loki/ELK. Surveillez les « noisy neighbors » et encadrez‑les avec des limites de ressources ou des nœuds dédiés.
• Accès et audit : SSO pour consoles et API, jetons de courte durée, MFA obligatoire. Si des prestataires participent (nearshore ou autres), verrouillez sur la posture des appareils et des allowlists IP.

270–360 jours : vagues de bascule et décommissionnement

• Calendrier des vagues : traitez cela comme le calendrier d’un lancement produit. Communiquez les fenêtres de gel aux parties prenantes 30 jours à l’avance ; faites des répétitions à blanc des mouvements complexes dans un cluster de staging.
• Optimisation des performances : attribuez des CPU dédiés pour les bases sensibles à la latence, activez hugepages quand c’est pertinent, privilégiez virtio‑scsi aux types de disques hérités et vérifiez l’alignement NUMA sur les grosses machines.
• Durcissement de la sécurité : UEFI Secure Boot sur les hôtes, disques de boot chiffrés, passthrough TPM si nécessaire, pipelines de patch des hôtes. Si vous utilisez AMD EPYC, évaluez SEV‑ES pour le chiffrement mémoire des VM sur des clusters multi‑locataires hostiles.
• Réduisez VMware : éteignez les hôtes décommissionnés. Archivez les configs. Ne conservez qu’un petit îlot si vous y êtes forcés (ex. appliances verrouillées par le fournisseur). Allez aux négociations de renouvellement avec des faits d’usage, pas des impressions.

Ce que cela coûte vraiment

Des chiffres à apporter à la finance. Ils sont indicatifs ; remplacez‑les par vos vrais devis et tarifs d’énergie.

• Matériel : un serveur 1U bi‑socket moderne avec 256–512 Go de RAM, 2×25 Gbps NIC et une paire de SSD NVMe 1,6–3,2 To se situe entre US$6k et $12k selon le fournisseur et les remises. Vous voudrez 6–12 nœuds pour démarrer si vous remplacez un parc vSphere modeste.
• Énergie : un nœud de virtualisation idle autour de 150–250 W et monte à 300–500 W en charge. Dix nœuds à 300 W en moyenne = ~3 kW. À $0.12/kWh, cela représente ~ $315/mois d’électricité par 3 kW avant refroidissement et surcoût de PUE.
• Logiciel/support : les abonnements Proxmox VE par socket CPU coûtent environ 110 € (Basic) à 935 € (Premium) par an ; beaucoup d’équipes choisissent Standard (~280 €/socket) pour le dépôt enterprise + support. Ceph est open source ; n’envisagez un support payant que si vous manquez de compétences internes. AHV et les distributions OpenStack varient ; vous payerez pour le support et la commodité.
• Humain : c’est le vrai coût. Attendez‑vous à 1–2 ETP focalisés pendant 6–12 mois pour planifier, piloter et migrer un parc de 150–300 VM, plus l’aide des propriétaires applicatifs pour les tests. Si vous n’avez pas cette capacité, un pod SRE nearshore dédié avec 6–8 heures de recouvrement peut compresser le calendrier sans ruiner la feuille de route de votre équipe.

Les pièges qui font exploser les délais

• Essayer de migrer à chaud entre hyperviseurs. Impossible. Prévoyez des fenêtres de bascule avec des synchros delta, pas de la magie. Utilisez rsync/ZFS send pour pré‑stager les données quand c’est possible.
• Sous‑estimer le travail Windows. Retirez proprement VMware Tools, pré‑installez les pilotes virtio et validez l’activation/la licence. La synchro de temps et la confiance de domaine vous tendront des embuscades à 2 h du matin.
• Ignorer les traductions NSX. Les règles de pare‑feu distribuées et la micro‑segmentation ne se porteront pas toutes seules. Soit vous les reconstruisez en amont (Palo Alto, Fortinet, etc.), soit vous implémentez des règles en hôte et acceptez un peu de foisonnement.
• Penser que les perfs vSAN se transposeront à l’identique. Ceph et Longhorn se comportent différemment sous des écritures aléatoires. Lancez fio selon vos patterns réels, pas ceux du marketing.
• Sauter les répétitions de sauvegarde/restauration. Une sauvegarde jamais restaurée est une histoire, pas un contrôle. Prouvez des restaurations complètes de VM et au niveau fichier depuis votre nouvelle pile avant toute bascule de prod.
• Écarter les propriétaires. Si les owners applicatifs découvrent la migration via un mail de statut, vous raterez la VAB et reviendrez en arrière. Faites‑les entrer tôt dans les war rooms.

Et Kubernetes ?

Kubernetes n’est pas un hyperviseur. Si vous êtes déjà très orientés conteneurs, profitez‑en pour éliminer une partie de la prolifération de VM — mais ne transformez pas votre sortie de VMware en réécriture de plateforme. Deux schémas sensés :

• KubeVirt ou Harvester pour le sous‑ensemble de VM qui doivent vivre près de vos clusters. Fonctionne bien pour des services Linux et certaines applis stateful. Pas un bon refuge pour de vieilles applis Windows métier.
• Split brain intentionnel : faites tourner Proxmox/OpenStack pour les VM, Kubernetes pour les conteneurs. Fédérez l’identité et l’observabilité. N’imposez pas une API unique au nom de l’élégance.

Sécurité et conformité : ne reconstruisez pas les risques d’hier

• Identifiants de courte durée : utilisez OIDC/SAML vers l’API/la console de virtualisation avec MFA imposée et des TTL de session. Tuez la culture des mots de passe admin longue durée.
• Secrets et images : attestation de la chaîne d’images. Signez les templates de VM. Stockez les secrets dans un coffre‑fort central avec des accès par projet.
• Résidence des données et confidentialité : si vous opérez dans ou servez des États des États‑Unis qui durcissent les règles de données, gardez télémétrie et sauvegardes confinées à la région. Traitez les métadonnées (notamment géolocalisation et IP) comme régulées — l’actualité va dans ce sens.
• Durcissement des hôtes : UEFI Secure Boot, TPM, chiffrement intégral des disques système et cadence rapide pour microcode/mises à jour noyau. N’attendez pas une tempête de CVE pour pratiquer les redémarrages roulants.

Quand un pod nearshore aide vraiment

Il ne s’agit pas d’empiler des ressources sur une migration. Il s’agit de garder vos ingénieurs cœur de métier focalisés sur le produit tandis qu’une équipe spécialisée prend en charge le gros œuvre non différenciant : assainissement d’inventaire, builds d’hôtes, mise en service réseau/stockage, runbooks de conversion et bascules en heures non ouvrées. Au Brazil, vous aurez 6–8 heures de recouvrement avec les fuseaux horaires US et des talents Linux seniors 20–30 % moins chers que l’onshore US — sans les 10–12 heures de décalage de l’offshore. Exploitez ce recouvrement pour les sujets épineux : problèmes de pilotes sur Windows Server 2012 R2, tuning des placement groups Ceph ou ACL OVN qui ne se comportent pas comme NSX.

Retour à la réalité sur les délais

Nous avons vu des parcs de 150–300 VM migrer en 6–9 mois avec une équipe dédiée et une forte implication des owners applicatifs. Au‑delà de 1 000 VM, planifiez 9–18 mois en vagues. Si votre direction attend « fin de trimestre » parce qu’un fournisseur cloud a agité des crédits, opposez un calendrier de migration lié à la criticité applicative et à la saisonnalité business. La précipitation se paie en nuits de rollback et en dommages réputationnels, pas en points de héros.

Pourquoi commencer maintenant

Deux raisons. D’abord, l’horloge de votre renouvellement tourne. Chaque mois de retard rétrécit vos options et donne du levier à l’incumbent. Ensuite, le marché bouge. Que T‑Mobile communique publiquement sur une sortie massive de VMware est un signal, pas une anomalie. Les délais d’approvisionnement matériel restent irréguliers en 2026. Vous voulez passer vos bons de commande avant que tout le monde ne se réveille avec le même plan B.

Points clés

• Choisissez une voie selon votre mix de workloads et votre maturité ops : HCI KVM (Proxmox/Harvester), OpenStack, Nutanix AHV, ou un rehost cloud ciblé.
• La migration à chaud inter‑hyperviseurs n’existe pas. Prévoyez des fenêtres de bascule avec données pré‑stagées et runbooks testés.
• Budgétez surtout pour l’humain, pas le logiciel. Comptez 1–2 ETP focalisés pendant 6–12 mois pour migrer 150–300 VM.
• Reconstruisez réseau et stockage délibérément : OVN/OVS pour les overlays, Ceph/ZFS/Longhorn pour le stockage. N’assumez pas que les comportements NSX/vSAN se retrouvent à l’identique.
• Testez les restaurations avant toute bascule de prod. Une sauvegarde jamais restaurée est une rumeur.
• Profitez de la sortie pour moderniser la sécurité : SSO/MFA sur les consoles, images signées, hôtes chiffrés et accès de courte durée.
• Des pods nearshore avec 6–8 heures de recouvrement peuvent compresser les délais sans dérailler votre roadmap produit.
• Commencez maintenant pour garder du levier en négociation et éviter l’embouteillage matériel/fournisseurs quand les autres se précipiteront vers la sortie.