Le procès Tesco contre Broadcom n’est plus seulement une dispute sur les licences. C’est devenu un signal pour toutes les équipes d’infrastructure encore dépendantes de VMware : partir est possible, mais ça ne s’improvise pas, et plus la plateforme est critique, plus il faut commencer tôt.
Contexte et enjeux
Selon des documents consultés par The Register, Tesco a décidé de quitter VMware et certains produits mainframe de Broadcom tout en maintenant sa procédure judiciaire au Royaume-Uni. L’audience devant la High Court n’est pas prévue avant une fenêtre allant du 1er novembre 2027 au 25 février 2028, mais la partie technique, elle, a déjà commencé : le distributeur britannique dit devoir chercher des alternatives, faire appel à du support tiers et prendre des risques opérationnels sous la pression du calendrier.
Computer Weekly précise que Tesco a lancé ses travaux de migration dès avril 2025, avec l’ambition de déployer une alternative à VMware dans toute l’organisation d’ici fin 2027. L’entreprise reconnaît que ce délai génère coûts, perturbations et risques commerciaux, d’autant qu’elle doit aussi remplacer des logiciels mainframe utilisés dans des processus critiques.
Les faits
L’origine du conflit remonte à un contrat de 2021, par lequel Tesco avait acheté des licences perpétuelles de produits VMware, plus des abonnements et du support jusqu’en 2026 avec option de prolongation. Après le rachat de VMware par Broadcom, le modèle commercial a changé, et Tesco affirme n’avoir pas pu accéder aux services dans les conditions attendues. Broadcom conteste cette lecture.
La tension économique est concrète. Tesco indique qu’en avril 2026, Broadcom proposait 23,5 millions de dollars, environ 17,4 millions de livres, pour un an de VMware Cloud Foundation 9.0 et de support mainframe. Selon le distributeur, cela représentait une hausse d’environ 175 % par rapport au prix qu’il jugeait juste pour VMware, et de 350 % pour les produits mainframe. Tesco décrit une sortie qui exige de travailler à un rythme exceptionnel, avec du support tiers, et une alternative qui ne s’intègre pas directement avec des outils de sauvegarde déjà en place, comme Veeam et Zerto.
| Zone à examiner | Question clé avant migration |
|---|---|
| Charges de travail | Quelles VM sont critiques, héritées, appliances ou candidates à la reconstruction ? |
| Réseau | Utilise-t-on NSX, microsegmentation, BGP, overlay, DFW ou règles par étiquettes ? |
| Stockage | Y a-t-il vSAN, SAN externe, NFS, iSCSI, Ceph, ZFS ou baies dédiées ? |
| Sauvegarde et DR | Les outils actuels supportent-ils la nouvelle plateforme avec le même niveau de fonctionnalités ? |
| Automatisation | Quels scripts, API, Terraform, Ansible ou pipelines dépendent de vCenter ? |
| Support | Qui répond en cas d’incident en production ? |
| Exploitation | L’équipe maîtrise-t-elle Linux, KVM, Ceph, réseaux et dépannage du nouvel environnement ? |
Analyse et implications
La lecture technique ne doit pas être qu’une entreprise peut éteindre VMware un vendredi et tout relancer ailleurs le lundi. Cette sortie peut se faire à faible risque, à condition d’être bien planifiée. David Carrero, cofondateur de Stackscale (Aire), spécialisé dans l’infrastructure cloud privé et Proxmox, le résume simplement : la migration ne doit pas être une fuite, mais un projet de continuité. Inventaire, conception, pilotes, phases successives, plans de retour arrière et support doivent être définis avant de déplacer la moindre charge critique.
Cette approche change la dynamique : il ne s’agit pas de choisir Proxmox VE, Hyper-V, OpenShift Virtualization, XCP-ng ou Nutanix sur le seul critère du prix de licence, mais de vérifier quelles charges sont migrables, quelles fonctions VMware sont réellement utilisées, et quelles dépendances n’ont pas d’équivalent direct. NSX et son pare-feu distribué sont difficiles à remplacer bloc par bloc, Hyper-V garde un sens là où l’investissement Microsoft est déjà lourd, Nutanix réduit la friction initiale sans effacer la dépendance à un fournisseur, et XCP-ng reste une option de niche. Ces arbitrages rejoignent ceux décrits dans les trois voies de modernisation du datacenter déjà explorées par des entreprises confrontées au même choix.
Proxmox VE combine KVM, LXC, stockage défini par logiciel, réseau, clustering, haute disponibilité et outils de récupération dans une plateforme open source, et sa fonction de migration a progressé : depuis la version 8.2, un importateur intégré permet de migrer des VM depuis VMware ESXi via l’interface web et l’API, ce qui réduit le travail manuel de conversion de disques. Veeam propose désormais une documentation dédiée à Proxmox VE dans Backup & Replication, avec ses propres exigences. Ça ne signifie pas que toutes les fonctions de VMware sont répliquées à l’identique, mais ça lève une des objections classiques à Proxmox dans les entreprises déjà équipées en outils de sauvegarde.
Proxmox n’est pas « VMware gratuit », c’est une autre façon d’opérer l’infrastructure. Chez VMware, beaucoup de complexité est absorbée par vCenter, ESXi, vSAN, NSX et l’écosystème de partenaires. Sous Proxmox, l’administrateur doit être à l’aise avec Linux, KVM, Ceph, ZFS, les ponts réseau, les VLAN et le firewalling. Un atout pour une équipe expérimentée, un risque réel si l’on sous-estime la complexité.
La grande leçon du cas Tesco, c’est que l’hyperviseur ne vit jamais seul. Une entreprise ne dépend pas que de VMware pour faire tourner ses VM, elle s’appuie aussi sur son réseau, ses API, ses outils de sauvegarde, ses mécanismes de reprise et ses intégrations fournisseurs. D’où la nécessité de migrer par couches plutôt qu’en bloc.
| Fonction dans VMware | Risque habituel lors de la migration | Comment le réduire |
|---|---|---|
| vCenter | Automatisations et processus dépendant des API | Inventaire des scripts, jobs et outils avant le pilote |
| ESXi | Différences de pilotes, contrôleurs et démarrage | Tests par système d’exploitation et type d’appliance |
| vSAN | Changement de modèle de stockage | Pilote avec charges réelles et tests de panne |
| NSX | Microsegmentation et dépannage avancé | Repenser la sécurité, pas une copie directe des règles |
| Sauvegarde | Fonctions non équivalentes dans la nouvelle plateforme | Valider la restauration, pas seulement la sauvegarde |
| DR | RPO/RTO différents | Tests de récupération documentés |
| Support | Changement d’interlocuteur et de SLA | Contrat clair avec le fabricant, l’intégrateur ou le MSP |
Perspectives
Le pire serait de croire qu’une migration VMware se résume à convertir des disques. C’est un projet d’architecture : certaines VM se migrent telles quelles, d’autres doivent être reconstruites, des appliances remplacées, des services déplacés en conteneurs, et certaines charges resteront temporairement sous VMware tant qu’une alternative fiable n’est pas validée.
La réaction instinctive face à une hausse de prix est de foncer vers le remplacement le plus rapide. Mais un départ précipité peut mener à un autre verrouillage : migrer vers une plateforme fermée sans évaluer coûts futurs, support, feuille de route et portabilité règle le problème de 2026 en créant celui de 2029. C’est pour ça que beaucoup d’entreprises comparent plusieurs options à la fois, Proxmox pour le cloud privé et la virtualisation ouverte, Hyper-V ou Azure Local en terrain Microsoft, OpenShift Virtualization quand Kubernetes est central, Nutanix pour une HCI intégrée, XCP-ng dans les stacks ouverts basés sur Xen. Il n’y a pas de réponse universelle : un cluster edge pour un point de vente n’a pas les mêmes exigences qu’un datacenter avec NSX ou qu’une plateforme SaaS.
Le cas Tesco illustre les risques de la dépendance, mais aussi une opportunité. Beaucoup d’organisations ont gardé VMware pendant des années simplement parce que ça fonctionnait, sans jamais revalider si c’était encore le meilleur choix pour chaque charge. La pression de Broadcom force cette remise à plat, comme le montre aussi l’évolution du marché deux ans après le rachat de VMware. Bien menée, une migration réduit les coûts, simplifie les environnements, purge la dette technique et améliore les sauvegardes. Sortir de VMware est possible. Le faire à risque minimal suppose d’accepter une réalité peu visible : la migration commence plusieurs mois avant de déplacer la première VM.
Questions fréquentes
Que fait Tesco avec VMware ?
Tesco migre hors de VMware et des produits mainframe de Broadcom, tout en poursuivant une action juridique liée au conflit de licences et de support.
Pourquoi le cas Tesco compte-t-il pour le marché ?
Il montre qu’une grande entreprise avec des systèmes critiques peut engager une sortie de VMware, même si le processus reste coûteux, complexe et risqué sous pression.
Proxmox peut-il remplacer VMware ?
Dans beaucoup de scénarios oui, notamment pour le cloud privé, les PME ou les équipes techniques expérimentées. Mais il ne remplace pas automatiquement des fonctions avancées comme NSX ou certains aspects du DR.
Quel est le principal risque lors d’une migration ?
Rarement l’hyperviseur en soi : plutôt les dépendances réseau, sauvegarde, stockage, automatisation, sécurité, appliances et support.
Comment réduire les risques lors d’une migration ?
Avec un inventaire précis, des pilotes, des phases progressives, des tests de restauration, un plan de retour arrière, un support clairement défini et une architecture cible pensée en amont pour les charges critiques.
source : The Register
