Le procès Tesco contre Broadcom n’est plus seulement une dispute sur les licences. Il est devenu un signal pour toutes les équipes d’infrastructure encore dépendantes de VMware : partir est possible, mais cela ne s’improvise pas. Et plus la plateforme est critique, plus il est essentiel de commencer avant que le calendrier ne l’impose.
Selon des documents consultés par The Register, Tesco a décidé de quitter VMware ainsi que certains produits mainframe de Broadcom tout en maintenant sa procédure judiciaire au Royaume-Uni. La procédure ne sera pas entendue devant la High Court avant une fenêtre ouverte du 01/11/2027 au 25/02/2028, mais la partie technique est déjà en marche : le distributeur britannique affirme devoir rechercher des alternatives, faire appel à des supports tiers et prendre des risques opérationnels en raison de l’urgence de la migration.
Computer Weekly ajoute que Tesco a commencé les travaux de migration en avril 2025, avec pour ambition de déployer une alternative à VMware dans l’ensemble de l’organisation d’ici fin 2027. La société explique que ce délai engendre des coûts, des disruptions et des risques commerciaux, surtout parce qu’elle doit également remplacer des logiciels mainframe utilisés dans des processus critiques.
Le problème ne se limite plus à VMware : c’est la dépendance
L’origine du conflit réside dans un contrat de 2021 par lequel Tesco a acheté des licences perpétuelles de produits VMware, en plus de abonnements et de services de support jusqu’en 2026, avec une option de prolongation. Après l’acquisition de VMware par Broadcom, le modèle commercial a changé et Tesco soutient n’avoir pas pu accéder aux services dans les conditions qu’il attendait. Broadcom rejette cette interprétation.
La tension économique est manifeste. Tesco indique qu’en avril 2026, Broadcom proposait une offre de 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 aux prix qu’il considérait comme en droit de payer pour VMware, et une hausse de 350 % pour les produits mainframe.
Au-delà du litige, le message pour le marché est clair : lorsqu’une plateforme de virtualisation devient une couche critique sur plusieurs années, en sortir n’est plus une simple question de changer d’hyperviseur. Il faut revoir rétrocompatibilités, réseaux, automatisations, supervision, sécurité, reprise après sinistre, licences, appliances, intégrations et support.
Tesco ne décrit pas un changement confortable. Il affirme que la sortie exige de travailler “à un rythme exceptionnel”, avec du support tiers, et avec une alternative qui, selon ses déclarations, ne s’intègre pas directement avec des outils de sauvegarde déjà employés, tels que Veeam et Zerto.
La migration à faible risque débute bien avant la coupure
La lecture technique ne doit pas être que toute entreprise peut éteindre VMware un vendredi et tout relancer sur une autre plateforme le lundi. La bonne compréhension est que cette sortie peut s’effectuer avec un risque minimal, si elle est bien planifiée.
David Carrero, cofondateur de Stackscale (Aire), spécialisé dans l’infrastructure cloud privé et Proxmox, explique cela d’un point de vue pratique : la migration ne doit pas être une fuite, mais un projet de continuité. Inventaire, conception, pilotes, phases successives, plans de rétrogradation et support doivent être définis avant de déplacer des charges critiques.
Cette approche modifie la dynamique. Il ne s’agit pas simplement de choisir Proxmox VE, Hyper-V, OpenShift Virtualization, XCP-ng, Nutanix ou autre alternative en se basant uniquement sur le coût de licence. Il faut plutôt vérifier quelles charges peuvent être migrées, quelles fonctions de VMware sont réellement utilisées et quelles dépendances n’ont pas d’équivalent direct.
| 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, APIs, 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 ? |
Les discussions techniques autour du cas révèlent ces mêmes points : NSX et son pare-feu distribué sont difficiles à remplacer un par un, Proxmox séduit dans de nombreux environnements, Hyper-V est pertinent là où un fort investissement Microsoft existe, Nutanix réduit la friction initiale mais maintient une dépendance au fournisseur, et XCP-ng apparaît comme une option dans certains niches. La conversation montre également de vraies questions sur le SDN, la microsegmentation, la compatibilité avec Veeam/Zerto, et les coûts de sortie de chaque plateforme.
Proxmox gagne du terrain, mais ne remplace pas tout automatiquement
Proxmox VE est devenue l’une des alternatives les plus discutées, car elle combine KVM, LXC, stockage défini par logiciel, réseau, clustering, haute disponibilité et outils de récupération dans une plateforme open source. Sa documentation officielle la présente comme une solution complète de virtualisation d’entreprise, open source, avec gestion web et support pour VM et conteneurs.
De plus, Proxmox a amélioré la fonctionnalité la plus importante pour les utilisateurs de VMware : la migration. 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 en partie le travail manuel consistant à convertir des disques et à reconstruire des configurations à la main.
Le support de tiers mûrit aussi. Veeam propose déjà une documentation spécifique pour Proxmox VE dans Backup & Replication, avec ses propres exigences et compatibilités. Cela ne signifie pas que toutes les fonctions de VMware sont répliquées à l’identique ni que toute migration peut se faire sans modifications, mais cela supprime une des objections classiques à Proxmox dans les entreprises utilisant déjà des outils de sauvegarde intégrés.
Il faut néanmoins faire preuve de prudence. Proxmox n’est pas “VMware gratuit”. C’est une autre façon d’opérer l’infrastructure. Chez VMware, de nombreuses complexités sont intégrées à vCenter, ESXi, vSAN, NSX et à l’écosystème de partenaires. En Proxmox, l’administrateur doit être plus proche de Linux, KVM, Ceph, ZFS, les ponts réseau, VLAN, firewalling et stockage. Cela peut être une énorme avantage pour des équipes expérimentées, mais un risque si on sous-estime la complexité.
Le vrai coût réside dans les fonctions considérées comme acquises
Une des grandes leçons du cas Tesco est que l’hyperviseur ne vit pas seul. Beaucoup d’entreprises ne dépendent pas uniquement de VMware pour faire tourner leurs VM. Elles s’appuient aussi sur leur réseau, leur écosystème, leurs API, leurs outils de sauvegarde, leurs mécanismes de reprise, leurs intégrations avec les fabricants et leurs procédures internes.
C’est pourquoi la migration doit se faire par couches.
| 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 | Differences 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 restauration, pas seulement sauvegarde |
| DR | RPO/RTO différents | Tests de récupération documentés |
| Support | Changement d’interlocuteur et SLA | Contrat clair avec le fabricant, intégrateur ou MSP |
Le pire serait de penser qu’une migration VMware n’est qu’un projet de conversion de disques. C’est un projet d’architecture. Certaines VM peuvent être migrées, d’autres doivent être reconstruites, des appliances remplacées, des services déplacés en containers, et des charges peuvent devoir rester temporairement dans VMware jusqu’à ce qu’une alternative fiable soit en place.
Sortir de VMware ne signifie pas tomber dans un autre piège
La réaction instinctive face à une augmentation des prix est de rechercher la solution la plus rapide pour remplacer VMware. Mais un départ précipité peut conduire à un autre verrouillage. Migrer de VMware vers une plateforme fermée, sans évaluer coûts futurs, support, roadmap, compatibilité ou portabilité, peut régler le problème de 2026, mais en créer un autre en 2029.
C’est pourquoi beaucoup d’entreprises comparent plusieurs options : Proxmox pour le cloud privé et la virtualisation ouverte, Hyper-V ou Azure Local si une forte base Microsoft existe, OpenShift Virtualization si Kubernetes est au cœur de la stratégie, Nutanix si l’on privilégie une HCI intégrée, ou XCP-ng dans des environnements valorisant un stack ouvert basé sur Xen.
Il n’y a pas de réponse universelle. Mais une règle est claire : l’alternative doit être choisie en fonction des charges, pas de la mode. Un cluster en edge pour la vente ne répondra pas aux mêmes exigences qu’un datacenter avec NSX, qu’un environnement dans le secteur public, une plateforme SaaS ou une PME avec trois hôtes et une baie partagée.
L’opportunité : reprendre le contrôle de l’infrastructure
Le cas Tesco illustre les risques liés à la dépendance, mais aussi une opportunité. Beaucoup d’organisations ont maintenu VMware pendant des années parce que ça fonctionnait, sans vraiment réévaluer si cela restait la meilleure option pour chaque charge. La pression de Broadcom les oblige à faire cette analyse.
Bien menée, une migration peut réduire les coûts, simplifier les environnements, supprimer la dette technique, améliorer les backups, éliminer les VM obsolètes, redessiner les réseaux, et mieux séparer les services critiques. Elle peut aussi ouvrir la porte à un cloud privé européen, du bare-metal, du Proxmox géré, des modèles hybrides et des architectures plus transparentes.
L’essentiel est de ne pas confondre urgence et improvisation. Tesco agit parce que son calendrier contractuel et judiciaire l’y contraint. D’autres ont encore du temps : cet espace doit être utilisé pour faire l’inventaire, piloter des tests, valider la restauration, définir le support, et planifier des migrations par étapes.
Sortir de VMware est possible. Le faire avec un risque minimal demande d’accepter une réalité peu visible : la migration débute plusieurs mois avant de déplacer la première VM.
Questions fréquentes
Que fait Tesco avec VMware ?
Tesco a décidé de migrer hors de VMware et des produits mainframe de Broadcom, tout en poursuivant une action juridique concernant le conflit de licences et de support.
Pourquoi le cas Tesco est-il important pour le marché ?
Parce qu’il démontre qu’une grande entreprise avec des systèmes critiques peut entamer une sortie de VMware, même si le processus est coûteux, complexe et risqué sous pression.
Proxmox peut-il remplacer VMware ?
Il peut le faire dans beaucoup de scénarios, notamment pour le cloud privé, les PME, les fournisseurs ou les environnements dotés d’é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 ?
Ce n’est pas souvent l’hyperviseur en soi, mais 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 (« phases en ondée »), des tests de restauration, un plan de rétrogradation, un support clairement défini, et une architecture cible conçue en amont pour les charges critiques.
