Audit VMware et stratégie de sortie Broadcom
Contexte de mission
Ce groupe industriel opère sur plusieurs sites géographiques avec une infrastructure VMware centralisée. Quand le renouvellement Broadcom s'est annoncé avec une hausse significative, la DSI s'est retrouvée dans une position inconfortable : ni la dépendance applicative réelle, ni le coût précis du maintien, ni les risques d'une sortie n'étaient objectivement documentés.
L'objectif n'était pas de "migrer vers Proxmox". C'était d'avoir une position technique solide avant tout arbitrage stratégique.
:::Contexte de mission Renouvellement Broadcom à 8 mois. Absence de visibilité sur les dépendances applicatives, l'exposition financière réelle et la faisabilité d'une migration sans rupture de production. :::
Ce que l'audit a révélé
Sur 180 VMs inventoriées, le périmètre fonctionnel réel était nettement plus complexe que la cartographie déclarée. Plusieurs services qualifiés "non critiques" dans la documentation participaient à des chaînes de traitement industriel. Des dépendances middleware existaient dans des scripts d'exploitation locaux, invisibles dans vCenter.
:::Observation terrain L'inventaire vCenter était propre. La cartographie des dépendances réelles, elle, était dans les têtes des exploitants — pas dans la documentation. :::
Le PRA existant supposait un ordre de reprise qui ne correspondait plus au comportement applicatif actuel. Il avait été documenté deux ans plus tôt et n'avait jamais été rejoué.
Analyse de l'exposition Broadcom
Trois scénarios ont été modélisés sur 3 ans :
- Renouvellement VMware complet — coût Broadcom projeté avec les nouvelles conditions de licence
- Migration progressive vers Proxmox — coût de migration + infrastructure cible, par vagues
- Coexistence hybride temporaire — maintien partiel VMware sur charges dépendantes, migration du reste en priorité
La comparaison financière a montré un écart substantiel dès l'année 2, même en intégrant le coût complet de la migration.
:::Arbitrage retenu La DSI a retenu le scénario 3 : migration progressive par dépendances métier, maintien temporaire VMware sur un sous-ensemble identifié, sortie totale sous 18 mois. :::
Plan de migration par vagues
L'audit a produit une matrice de migration organisée non par commodité cluster mais par dépendances métier. Chaque vague comprend :
- les charges déplaçables sans impact sur les suivantes,
- un critère go/no-go technique avant de démarrer,
- un point de rollback défini et documenté,
- un délai de décision rollback explicite (non laissé à l'appréciation du moment).
Les charges les plus dépendantes et les plus critiques ont été positionnées en dernières vagues, après que la confiance opérationnelle soit établie sur les premières.
Ce qui a changé la décision
Le point de bascule n'a pas été le benchmark de peformance. C'est la simulation d'incident réalisée en atelier avec les équipes ops et applicatives réunies.
Quand on a demandé "qui valide une bascule applicative en cas d'incident lors de la migration ?" — silence. Quand on a demandé "quel est le délai de décision pour un rollback ?" — trois réponses différentes.
:::Ce qui a changé la décision La DSI a arrêté de discuter de vitesse de migration. Elle a demandé : des vagues plus petites, une coexistence plus longue, et une matrice de rollback opposable. :::
Résultat
Rapport d'audit remis à la DSI et au COMEX. Arbitrage stratégique réalisé sur base technique et financière objective, déconnectée des arguments commerciaux Broadcom. Plan de migration par vagues approuvé avec critères go/no-go définis en amont de chaque étape.