10 erreurs d’architecture et de ROI dans l’exode post-VMware
10 erreurs d’architecture et de ROI que personne n’a évaluées dans l’exode post‑VMware
Les alternatives VMware open source sont viables. Mais « viable » et « adapté à votre entreprise » sont des questions radicalement différentes qui exigent une analyse technique, financière et de gouvernance avant d’engager votre infrastructure pour une décennie.
Erreur 01 sur 10
Confondre urgence et stratégie
L’acquisition de VMware par Broadcom en novembre 2023 pour 61 milliards de dollars a déclenché le plus grand séisme dans la virtualisation d’entreprise depuis plus d’une décennie. Et le mot « séisme » est encore en dessous de la réalité. Licences perpétuelles supprimées, ~8 000 SKUs consolidés en 4 bundles, minimum d’achat de 72 cœurs et hausses de prix rapportées entre 150 % et 1 500 %. Tesco a déposé une plainte de 100 millions de livres. Fidelity a alerté sur des risques pour 50 millions de clients. Autant dire que le paysage invitait à courir.
Et c’est exactement ce qui s’est passé : beaucoup ont couru, mais pas toujours dans la bonne direction. Une enquête CloudBolt (2026) a révélé que 63 % ont changé leur stratégie de migration au moins deux fois (oui, deux fois). Gartner estime que la part de marché de VMware passera de 70 % à 40 % d’ici 2029, mais le chemin jusque-là est parsemé de virages qui méritent nettement plus de réflexion qu’ils n’en reçoivent.
Perspective SIXE
L’urgence créée par Broadcom est parfaitement compréhensible — personne n’aime voir sa facture multipliée du jour au lendemain. Mais chaque décision d’infrastructure prise sous pression devient de la dette technique que vos équipes hériteront pendant des années. La première bonne décision est de séparer la réponse tactique immédiate de la stratégie à moyen terme et d’évaluer chacune avec des critères différents. Respirez, planifiez, puis agissez.
Erreur 02 sur 10
Ignorer la gouvernance du projet open source
Tout l’open source ne se vaut pas — loin de là. La différence la plus pertinente pour une décision d’entreprise à long terme n’est pas la licence, mais quelque chose que presque personne ne vérifie : qui contrôle le projet et quels mécanismes protègent la communauté si les priorités commerciales changent.
Proxmox Server Solutions GmbH est une entreprise privée autrichienne avec un capital social de 35 000 € et une équipe estimée entre 14 et 24 personnes. Des gens formidables, certainement, mais il n’existe ni fondation indépendante, ni conseil de gouvernance ouvert, ni représentation communautaire dans les décisions de développement. Autrement dit : l’avenir de votre plateforme de virtualisation dépend des choix d’une seule entreprise.
Comparez avec la Fondation MariaDB, où aucune entreprise ne peut occuper plus de 25 % des sièges au conseil — un mécanisme qui a protégé le projet lorsque MariaDB Corporation a été rachetée par K1 en septembre 2024. Ou avec OpenStack, désormais sous la Linux Foundation, avec une gouvernance distribuée entre des centaines d’organisations. Ça, c’est un filet de sécurité.
Question clé
Votre plateforme de virtualisation — celle sur laquelle tourneront vos applications métier pendant les 10 prochaines années — est-elle gouvernée par une fondation indépendante, un consortium ou une seule entreprise privée de moins de 25 employés ? Ce n’est pas une question rhétorique : la réponse a des implications directes sur le risque de verrouillage fournisseur à long terme.
Erreur 03 sur 10
Ne pas lire le Contributor Licence Agreement
On sait — lire un CLA n’est pas exactement un programme de vendredi soir. Mais ça vaut le coup. Le CLA de Proxmox accorde à l’entreprise une licence perpétuelle, mondiale et irrévocable sur toutes les contributions, avec le droit de les relicencier sous des termes commerciaux ou propriétaires. Ce mécanisme n’est pas problématique en soi, mais c’est exactement la combinaison structurelle (entreprise unique + AGPL + CLA permissif) qui a précédé chaque changement de licence majeur des sept dernières années. C’est un peu comme voir les nuages d’orage s’accumuler et dire « je suis sûr qu’il ne pleuvra pas ».
| Projet | Année | Changement | Conséquence | Gouvernance |
|---|---|---|---|---|
| MongoDB | 2018 | AGPL → SSPL | Retiré de Debian/Red Hat | Single vendor |
| Elasticsearch | 2021 | Apache 2.0 → SSPL | Fork : OpenSearch (Linux Foundation) | Single vendor |
| HashiCorp | 2023 | MPL 2.0 → BSL | Fork : OpenTofu · IBM : 6,4 Mds $ | Single vendor |
| Redis | 2024 | BSD → SSPL | Fork : Valkey (Linux Foundation) | Single vendor |
| MinIO | 2021–26 | Apache → AGPL → Abandonné | Dépôt : « NO LONGER MAINTAINED » | Single vendor |
| Kubernetes | — | — | Apache 2.0 stable | Fondation (CNCF) |
| PostgreSQL | — | — | Licence PostgreSQL stable | Communauté |
| Linux | — | — | GPLv2 stable | Fondation (LF) |
Vous voyez le schéma ? Il est assez limpide : aucun projet soutenu par une fondation indépendante n’a jamais subi un changement de licence unilatéral. Pas un seul. Ce constat devrait nourrir toute évaluation de risque, quelle que soit la plateforme envisagée.
Erreur 04 sur 10
Supposer que les coûts d’abonnement resteront stables
Toute entreprise qui développe du logiciel open source a besoin de monétiser son travail, et c’est parfaitement légitime — personne ne vit d’amour et d’eau fraîche. La question n’est pas de savoir si les prix augmenteront (ils augmenteront, comme partout), mais si vous les intégrez dans votre modèle de coût total de possession.
L’abonnement Community de Proxmox est passé de 49,90 € à 120 €/an (~140 % d’augmentation), et en janvier 2026, tous les niveaux ont augmenté de 3,8 à 4,3 %. Le nouveau Proxmox Datacenter Manager exige qu’au moins 80 % des nœuds disposent d’un abonnement Basic ou supérieur (370+ €/socket/an). Ça vous rappelle quelque chose ? À nous aussi.
OpenStack, Ceph et les autres alternatives VMware ont aussi leurs propres structures de coûts. Aucune plateforme n’est gratuite en production — si quelqu’un vous dit le contraire, souriez poliment et demandez la facture. La vraie différence réside dans les coûts prévisibles et ceux qui dépendent de décisions unilatérales.
Perspective SIXE
Lorsque nous évaluons des alternatives avec nos clients, nous modélisons toujours trois scénarios de coûts : optimiste, réaliste et défavorable, avec des projections à 5 et 10 ans intégrant d’éventuels changements de licences. Oui, c’est plus de travail. Mais c’est aussi la seule façon de construire un TCO qui ne s’effondre pas au premier changement de tarif.
Erreur 05 sur 10
Sous-estimer la complexité opérationnelle d’OpenStack
Soyons justes avec OpenStack : il tourne en production avec plus de 45 millions de cœurs dans des organisations comme Walmart, GEICO ou LINE Corp. Sa gouvernance — désormais sous la Linux Foundation — est parmi les plus solides de l’écosystème. Ce sont de véritables atouts.
Mais (il y a toujours un mais) le projet lui-même reconnaît que 44 % des fournisseurs IT et 39 % des entreprises déclarent avoir du mal à trouver des professionnels qualifiés. La plateforme comprend plus de 30 projets de services. Déployer et opérer ce stack nécessite des équipes expérimentées en systèmes distribués que la plupart des équipes VMware ne possèdent pas — non par manque de talent, mais parce que ce sont des compétences fondamentalement différentes. C’est comme demander à un brillant chef de cuisine méditerranéenne de concourir en sushi : les deux sont de la gastronomie de haut vol, mais les compétences ne se transfèrent pas automatiquement.
Nuance importante
OpenStack peut être le choix idéal pour les organisations avec l’échelle et les équipes adéquates. Le modèle managé (Canonical, Mirantis, Platform9) résout une partie de la complexité, mais ajoute des coûts et de la dépendance. La question n’est pas « OpenStack oui ou non ? » mais « nos équipes, notre budget et notre échelle correspondent-ils à ce qu’OpenStack exige pour briller ? »
Erreur 06 sur 10
Croire que Ceph, c’est « juste cocher la case »
Ceph est un système puissant qui tourne en production dans des environnements impressionnants : CERN, Bloomberg et DigitalOcean, entre autres. Mais la distance entre un cluster Ceph à hyperscale et un déploiement typique de 3 à 5 nœuds dans une migration VMware, c’est comme la distance entre piloter un Airbus et un ULM : les deux volent, mais les règles sont très différentes.
Les benchmarks StarWind en environnement Proxmox HCI montrent que Ceph a atteint 270 000 IOPS en charges mixtes 4K, contre 1 088 000 IOPS pour LINSTOR/DRBD et 1 199 000 pour StarWind VSAN. Et les risques des clusters de petite taille méritent une attention particulière : perdre un nœud dans un cluster de 3 avec réplication 3x peut laisser le système en lecture seule. Pas exactement ce qu’on souhaite un lundi à 3 h du matin.
Les alternatives à considérer incluent LINSTOR/DRBD avec des performances proches du natif, StorPool avec des latences sub-100 µs, et IBM Storage Virtualize avec une intégration entreprise éprouvée. Chacun a ses forces, ses limites et ses exigences d’expertise.
Perspective SIXE
La couche de stockage est sans doute la décision la plus critique et la moins réversible de toute la migration. C’est là qu’on ne peut pas se permettre d’improviser. Elle doit être évaluée avec des tests réels sur des charges de travail réelles — pas avec des benchmarks génériques ni des « ça marche super bien chez quelqu’un que je suis sur LinkedIn ». C’est précisément là qu’un intégrateur expérimenté sur plusieurs plateformes de stockage apporte le plus de valeur.
Erreur 07 sur 10
Ne pas inventorier les fonctionnalités entreprise qui disparaissent
VMware a passé plus d’une décennie à construire des fonctionnalités sur lesquelles de nombreuses organisations ont bâti leurs processus opérationnels. Ce sont ces choses qui « marchent tout simplement » — jusqu’à ce qu’elles ne soient plus là. Et quand elles disparaissent, l’impact va bien au-delà de la technologie.
Équilibrage automatique (DRS)
Proxmox n’a pas d’équivalent natif : il faut du scripting maison. OpenStack offre une fonctionnalité partielle via le scheduling Nova. Dans les deux cas, retroussez vos manches.
Tolérance aux pannes et DR
VMware FT/SRM fournissent un basculement automatique. Les alternatives open source nécessitent une orchestration manuelle avec réplication ZFS, Ansible et runbooks. Ça fonctionne, mais quelqu’un doit le construire et le maintenir.
SDN et microsegmentation
Proxmox SDN supporte VLANs/VXLANs/EVPN, mais IPAM/DHCP sont en « tech preview » (comprendre : pas tout à fait prêt). Il n’y a pas d’équivalent au firewall distribué de NSX.
Certifications éditeurs
SAP, Oracle et Microsoft ne certifient pas Proxmox. NVIDIA AI Enterprise n’est pas officiellement supporté non plus. Si vous dépendez de ces certifications, c’est un détail qu’il vaut mieux ne pas négliger.
Automatisation et API
Les providers Terraform pour Proxmox sont maintenus par la communauté. L’API exige de spécifier manuellement le nœud cible. Rien de rédhibitoire, mais ces frictions s’additionnent.
Support 24/7
Proxmox fonctionne en horaires autrichiens (7 h–17 h CET), sans option 24/7 à aucun niveau. Quand la production tombe à 3 h du matin, il n’y a littéralement personne à appeler. Et non, Google ne compte pas.
Aucune de ces limitations n’invalide la plateforme — soyons clairs. Mais chacune représente un écart à combler par de l’ingénierie, des outils ou du conseil, et chaque solution de contournement a un coût qui doit figurer dans votre modèle financier. Faire comme si elles n’existaient pas, c’est la recette idéale pour des surprises désagréables.
Erreur 08 sur 10
Calculer le ROI uniquement sur la ligne des licences
Les économies sur les licences sont réelles. Mais présenter ces économies comme le ROI du projet, c’est comme évaluer un déménagement au seul prix du camion : techniquement correct, pratiquement incomplet.
Gartner estime que les services de migration coûtent entre 300 et 3 000 dollars par VM. 44 % des organisations subissent des interruptions non planifiées pendant la migration. Et les projets estimés à 6 mois se transforment régulièrement en 24 — un constat désormais très documenté.
Les coûts cachés qui érodent votre ROI
Formation : 5 000–15 000 $/ingénieur + 3–6 mois de productivité réduite (votre équipe apprend vite, mais pas du jour au lendemain). Intégration : sauvegarde, supervision, CMDB, automatisation — des connecteurs matures pour VMware qui n’existent tout simplement pas pour Proxmox. Développement sur mesure : scripts d’équilibrage, DR, monitoring = dette technique interne. Turnover : quand l’ingénieur qui les a construits s’en va, le savoir-faire part avec lui. Et c’est toujours au pire moment.
Erreur 09 sur 10
Concevoir pour le Jour 1 et oublier le Jour 2
La migration n’est que le début — la lune de miel, si vous voulez. Le vrai coût se manifeste dans les opérations quotidiennes, année après année.
Cybernews a révélé que de nombreuses organisations ayant migré vers Proxmox ne maintiennent pas les mises à jour de sécurité. C’est compréhensible : quand tout l’effort se concentre sur la migration, on oublie facilement qu’ensuite, il faut encore opérer. À grande échelle, l’interface devient peu réactive avec plusieurs milliers de VMs, et pmxcfs atteint ses limites autour de 11 000 VMs.
Sécurité et conformité
Gestion des CVE, durcissement, audits (ISO 27001, RGPD, NIS2). Quel SLA de réponse aux vulnérabilités critiques chaque plateforme offre-t-elle ? Question gênante, mais indispensable.
Télémétrie et observabilité
Les alternatives open source (Prometheus, Grafana, Zabbix) sont excellentes — elles le sont vraiment — mais elles nécessitent intégration et maintenance dédiées. Elles ne se configurent pas toutes seules.
Sauvegarde et restauration
Proxmox Backup Server est fonctionnel, mais il joue dans une autre catégorie d’écosystème comparé à Veeam, Commvault ou IBM Spectrum Protect.
Dette technique
Chaque script personnalisé est du code à maintenir, documenter, tester et transmettre. La dette technique est invisible jusqu’à ce qu’elle ne le soit plus — et alors, c’est la seule chose que vous voyez.
Erreur 10 sur 10
Croire que la technologie est la décision
Migrer depuis VMware n’est pas un projet technologique : c’est une transformation opérationnelle qui touche les personnes, les processus, les fournisseurs, les budgets et les risques. La technologie compte, bien sûr. Mais ce n’est qu’une pièce du puzzle.
La migration VMware n’est pas un problème technologique. C’est un problème de découplage opérationnel déguisé en problème technologique.— Keith Townsend, The CTO Advisor
Les questions qui comptent vraiment : quel niveau de risque de gouvernance est acceptable pour nous ? Avons-nous l’équipe nécessaire — ou pouvons-nous la former à temps ? Quel est notre TCO réel à 5 et 10 ans ? Comment protégeons-nous l’investissement si le projet open source change de cap ? Quelles charges de travail migrons-nous d’abord, et lesquelles ne devraient peut-être jamais bouger ? Et qui sera notre partenaire technique quand les choses ne se passeront pas comme prévu ? (Parce qu’à un moment, ça arrivera. C’est la vie.)
Notre conviction
L’open source est, sans aucun doute, la bonne réponse pour l’infrastructure du futur. Nous n’avons aucun doute là-dessus. La question n’est pas de savoir s’il faut migrer, mais comment le faire avec la rigueur que la décision mérite. La différence entre une migration réussie et une qui génère des années de maux de tête tient à la qualité de l’analyse en amont, à l’architecture choisie et à l’accompagnement expert tout au long du processus. Et si après avoir lu tout ça, vous avez envie d’en discuter, nous sommes là.
La meilleure migration est celle qui se fait avec discernement, pas dans la précipitation
Plus de 15 ans de conception, de déploiement et d’exploitation d’infrastructures critiques. Nous connaissons VMware, Proxmox, OpenStack, Ceph, IBM Storage et les alternatives parce que nous travaillons avec toutes. Aucune préférence : uniquement la solution qui correspond à votre entreprise.
