Le sujet VMware/Broadcom est sur toutes les lèvres depuis la finalisation du rachat, le 22 novembre 2023. Cependant, beaucoup d’organisations l’abordent comme un problème purement technique ou d’outillage.
Chez Inside, la lecture est différente : ce qui se joue dépasse VMware. Le terme de “dévirtualisation”, volontairement provocateur de la part du Gartner, sert surtout à nommer une réalité plus large : la fin d’une dépendance devenue trop coûteuse, et la fin d’un cycle d’infrastructure. Gartner parle d’une disruption majeure et anticipe qu’environ 35% des workloads aujourd’hui sous VMware fonctionneront sur une autre plateforme d’ici 2028.
Cette situation ouvre une opportunité pour moderniser avec méthode, plutôt que de remplacer un outil par un autre : architecture plus modulaire, standards plus ouverts, et pilotage du changement par la valeur.
Suite à un meet-up organisé sur ce sujet par Inside, Vincent Barthez, Responsable Digital Foundation, partage dans cette interview sa grille de lecture et une démarche concrète pour cadrer et piloter cette “dévirtualisation”.
Pourquoi la “dévirtualisation” s’est-elle imposée comme sujet prioritaire pour les DSI depuis le rachat de VMware par Broadcom ?
Le sujet a pris cette ampleur parce qu’il s’agit d’une succession d’annonces qui a touché trois leviers sensibles pour une DSI : l’économie, la capacité à être servi/soutenu, et la dépendance.
Côté marché, Gartner parle d’une « disruption la plus significative depuis des décennies » sur la virtualisation serveur et pointe des hausses de coûts souvent de 300 à 400% chez des clients VMware, avec une perte de confiance liée aussi aux questions de support et de roadmap. Dans le même temps, Gartner projette que plus d’un tiers des workloads VMware fonctionneront sur une autre plateforme d’ici 2028. Ces deux signaux ont fait basculer le sujet du “problème technique” vers le “risque stratégique”.
Ensuite, l’écosystème a vécu une succession d’ondes de choc : fin de la vente des licences perpétuelles au profit d’un modèle abonnement, reconfiguration du channel et des programmes partenaires, disparition de la version gratuite d’ESXi… autant de marqueurs qui ont accéléré la prise de conscience “dépendance”.
Enfin, le débat s’est élargi parce que des organisations ont commencé à rendre publics des virages vers des approches plus cloud-native, Kubernetes en tête. Michelin, par exemple, a communiqué sur une trajectoire open-source autour de Kubernetes après un passage par Tanzu.
À partir de là, “dévirtualisation” est devenu un mot-valise : Gartner l’a remis en circulation en 2024 dans ses analyses. Le Gartner considère également à juste titre que cette crise est une opportunité de modernisation et de réduction de la dette technique (LIEN https://insidegroup.fr/expertises/ops-infrastructure/dette-technique/) . Chez Inside nous utilisons “dévirtualisation” surtout pour illustrer un enjeu concret : sortir d’une dépendance à un acteur unique et reprendre la main sur l’architecture et la trajectoire du SI.
C’est une occasion unique d’entamer une démarche de modernisation, en en profitant pour tirer quelques leçons du passé ! La “dévirtualisation” ne signe pas la fin de la virtualisation. Elle signe la fin d’une dépendance.
Pourquoi le choc VMware/Broadcom révèle-t-il une évolution plus profonde du marché et du cycle de vie des infrastructures IT ?
Le choc VMware/Broadcom sert de révélateur d’un cycle récurrent dans les infrastructures : divergence (un nouveau besoin crée des silos), convergence (la puissance et la standardisation résorbent une partie de la complexité), concentration (quelques acteurs verrouillent la valeur et reprennent la main sur les prix), puis disruption (les standards et l’open source répliquent les concepts, autrement). C’est le signe d’une dépendance devenue trop coûteuse et d’un modèle qui arrive à ses limites.
Si nous prenons du recul, trois mouvements de fond accélèrent cette bascule.
Premièrement, la concentration des Hyperscalers. L’hypervision est restée de niche car elle nécessite de nombreuses compétences complexes pour être économiquement exploitable. Nous avons assisté à une concentration des acteurs qui ont exploité la virtualisation et l’hyperconvergence pour récupérer le marché de l’infrastructure en jouant sur les économies d’échelle.
Deuxièmement, la disruption « Compute » par les conteneurs. Docker puis Kubernetes ont rendu accessibles des patterns d’industrialisation qui réduisent la dépendance à une “flotte de VM” et déplacent le centre de gravité vers des plateformes standardisées.
Troisièmement, la nouvelle divergence IA. Le CPU ne suffit plus ! Le coût unitaire des accélérateurs se chiffre en dizaines de milliers de dollars. Les racks montent vers des densités très élevées, et l’interconnexion devient critique avec des technologies type InfiniBand 400 Gb/s.
C’est précisément pour traverser ces cycles sans subir chaque bascule d’éditeur ou de technologie qu’une architecture modulaire devient le vrai sujet.
Conteneurs, Kubernetes, besoins IA : ces évolutions poussent vers des architectures plus légères et standardisées, qui simplifient les plateformes et augmentent la flexibilité.
Quelles sont alors les solutions à mettre en place pour construire une architecture modulaire et résiliente ?
L’enjeu n’est pas de remplacer VMware par une autre solution équivalente, mais de construire une architecture modulaire. Cette approche repose sur une idée simple : séparer les couches, privilégier des standards ouverts, et raisonner comme un cloud provider plutôt que comme un exploitant d’outils.
Concrètement, je démarre par une lecture en deux temps pour me positionner comme le ferai un Cloud Provider. D’abord, penser en couches car une architecture résiliente et flexible sépare les préoccupations : une couche “core & sécurité” (IAM, DNS, gestion des secrets), un backbone réseau dimensionné pour la performance et la séparation des flux, une protection périmétrique cohérente, puis des nœuds compute convergés qui exécutent les workloads.
Ensuite, penser en “boxes” pour éviter le “lock-in” : chaque composant doit rester remplaçable. Le ciment entre les briques, ce sont les standards ouverts, pas des mécanismes propriétaires. Cela passe par des API standardisées comme l’API Kubernetes, par du découplage applicatif via des brokers de messages (Kafka, RabbitMQ), et par une discipline : ne jamais être bloqué par une technologie, seulement par une implémentation que vous avez choisie.
Enfin, je structure cette modularité avec une “tour des services informatiques” : une fondation matérielle (compute, stockage, réseau), un socle système, des mécanismes d’isolation et d’exécution, puis des services software-defined. Au-dessus, un niveau d’orchestration qui pilote les mondes virtualisés et cloud-native. L’objectif reste constant : garder la maîtrise de l’architecture, sans reconstruire une dépendance “propre” après avoir fui celle d’hier.
Au lieu d’opposer les solutions, assemblons-les logiquement !
Peux-tu partager des exemples de stacks pragmatiques, adaptées à différents contextes de DSI, qui tendent vers cette architecture résiliente ?
Nous n’avons pas chez Inside de stack idéale à proposer, parce que les contextes sont rarement comparables. Ce qui fonctionne, c’est une logique d’assemblage : partir de votre réalité (legacy, exigences de sécurité, edge, multi-clusters, besoins de facturation interne) et choisir une combinaison cohérente, opérable, remplaçable. L’objectif reste le même : garder la maîtrise, sans recréer une dépendance déguisée.
Pour partager quelques exemples, sur un contexte PME ou parc mixte avec des VMs “legacy” qui doivent continuer à vivre et des premiers clusters Kubernetes, une stack Proxmox + Ceph est intéressante : une plateforme intégrée, pragmatique, avec une logique d’unification du run.
Sur un contexte cloud-native pur, notamment quand le besoin est l’immutabilité, une exploitation “cluster par cluster” et une bonne adéquation à l’edge, une stack Kubernetes + Talos + Cilium + Longhorn est efficace, Talos assumant une approche OS minimaliste et immuable pensée pour Kubernetes.
Quand la complexité vient du nombre de clusters, l’enjeu bascule vers la gouvernance et l’industrialisation : Rancher apporte une réponse très concrète pour centraliser l’authentification et les déploiements. Enfin, pour des organisations qui visent un cloud privé IaaS avec du multi-tenant, de la refacturation et des ressources hétérogènes, des stacks de type OpenStack/CloudStack sont pertinentes.
Il y a aussi des pièges à éviter. L’ironie classique, c’est de quitter une dépendance pour retomber sur une solution dont la gouvernance ou le modèle peut changer unilatéralement. Analysez le risque de concentration, pas seulement le prix !
Comment piloter cette dévirtualisation et ce changement par la valeur ?
Pour piloter ce changement par la valeur, je dois vous parler de la méthode ! Ce n’est pas juste un projet technique, c’est un programme de transformation organisationnel et financier.
Notre approche s’articule autour de trois piliers. D’abord rationaliser : démarrer par un audit de l’existant, cartographier le parc applicatif, comprendre les dépendances (réseau, stockage, bases, middleware) et l’obsolescence. Ensuite, utiliser l’approche 6R pour décider : retirer ce qui doit disparaître, retenir temporairement ce qui ne peut pas bouger, rehoster quand la priorité est la vitesse, replatformer et refactorer quand la valeur justifie l’effort. Cette phase de tri évite de migrer la dette.
Puis moderniser : concevoir une cible hybride pragmatique, avec trois îlots lisibles. Un îlot de stabilité pour les workloads critiques, un îlot d’agilité autour de Kubernetes et du DevOps, et un îlot de scalabilité via le cloud pour absorber les pics et certains usages data/IA. Le point dur n’est pas la cible, c’est la cohabitation : flux inter-plateformes, vagues de migration par strates, sécurité et supervision unifiées. Enfin piloter : mettre le FinOps au centre pour mesurer, arbitrer, ajuster, et démontrer que chaque choix technique produit une valeur soutenable.
Pour vous, la démarche FinOps est un facteur clé de succès de cette transformation des infrastructures ?
Oui, la démarche FinOps n’est pas réservée au Cloud ! C’est une pratique opérationnelle et culturelle qui vise à maximiser la valeur des dépenses technologiques, en organisant la décision entre IT, finance et métiers. La FinOps Foundation l’assume explicitement dans sa définition, mise à jour en janvier 2025.
Avancer par étapes permet de réduire les risques, de maîtriser les coûts et d’éviter les migrations trop brutales. Le FinOps joue ici un rôle clé : mesurer, piloter et ajuster les dépenses pour garantir que chaque choix technique apporte réellement de la valeur et reste soutenable dans le temps.
Le FinOps se décline sur trois niveaux. D’abord, donner de la visibilité : coût complet licence + infra + run + support, puis allocation par application ou service métier. Ensuite, organiser l’optimisation : dimensionnement, arbitrages de plateforme, gestion de l’obsolescence, décisions rationnelles entre rehost/replatform/refactor selon le retour attendu. Enfin, installer la gouvernance : règles, budgets, responsabilités, rituels de revue, pour éviter qu’une migration par étapes se transforme en empilement durable de coûts.
Le FinOps, c’est le GPS de votre transformation : il rend les arbitrages visibles, discutables, et tenables dans la durée !
En synthèse, comment Inside accompagne ses clients dans cette démarche de dévirtualisation et de maîtrise de la dépendance ?
Notre accompagnement vise à rendre la trajectoire lisible et pilotable au travers d’une feuille de route pragmatique, découpée en étapes, avec des décisions guidées par la valeur et la soutenabilité. L’objectif n’est pas de “sortir de VMware” par principe, mais de sécuriser une transformation qui redonne de la marge de manœuvre, sans migration big bang.
Nous commençons par une phase Audit & Opportunité : analyse 6R du portefeuille applicatif en priorisant les périmètres les plus coûteux, cartographie des coûts actuels et projetés avec une lecture FinOps, et identification des alternatives techniques à challenger par des PoC. Ensuite, la phase Fondation & PoC consolide la cible : tests sur des cas réels, design de la landing zone cible, et mise en place des outils et rituels de pilotage FinOps. Vient alors la phase Migration & Modernisation : premières vagues “rehost” pour sécuriser rapidement, puis démarrage des chantiers replatform/refactor autour de Kubernetes lorsque la valeur le justifie. Enfin, l’optimisation continue s’installe : industrialisation, pilotage FinOps en continu, gestion de la performance et des arbitrages dans la durée.
Ce cadre permet de se projeter parce qu’il répond à trois attentes DSI très concrètes : une trajectoire claire, une priorisation par la valeur, et une exécution progressive qui maîtrise les risques et les coûts. Avancer vite, mais bien. Découper pour réduire les risques. Mesurer pour améliorer. Installer une dynamique continue.
Si vous envisagez une trajectoire de dévirtualisation ou de réduction de dépendance, nous pouvons démarrer par un atelier de cadrage pour qualifier vos options et construire une feuille de route actionnable.
Echangeons sur la stratégie à adopter pour piloter votre dévirtualisation !