L'échec le plus fréquent d'une sortie de VMware n'est pas technique. Il consiste à mobiliser l'équipe infrastructure sur un audit avant d'avoir obtenu un mandat de direction, à produire trois mois d'analyses, puis à voir le projet mis en pause faute de validation politique. Les équipes se démobilisent, et le sujet revient un an plus tard depuis zéro.
La deuxième erreur, presque aussi coûteuse, est de traiter la sortie comme un projet alors qu'il s'agit d'un programme pluriannuel. Sur un parc de deux à cinq cents machines virtuelles hétérogènes, l'ordre de grandeur va de treize à trente-trois mois. Penser l'opération comme une bascule en une fois produit un calendrier auquel personne ne croit dès le deuxième trimestre.
Cet article traite la question de la décision : ce qui la structure, ce qui la fait dérailler, et les quatre moments où il reste possible de s'arrêter sans perdre ce qui a été investi. Le déroulé technique d'une migration est un autre sujet, que nous avons traité ailleurs, en anglais.
Portée
- S'adresse aux directions des systèmes d'information, responsables infrastructure et architectes qui ont un parc VMware en production et un budget à arbitrer.
- Suppose une équipe d'exploitation interne et des contrats de support en cours. Une organisation qui démarre de zéro suit un modèle différent.
- Les durées correspondent à un parc de 200 à 500 machines virtuelles. Divisez par 1,5 en dessous, multipliez par 2 au-delà de 500.
- Aucun chiffre de coût absolu n'est donné : ils dépendent trop du contrat, du parc et du pays pour être utiles hors contexte.
Rester est une option, et elle doit figurer dans le comparatif
Commençons par la seule décision que la plupart des documents sur le sujet omettent.
Le contexte a changé — le rachat de VMware par Broadcom fin 2023, le passage à un modèle par abonnement, le regroupement des produits en offres intégrées, et la refonte du programme partenaire pour les fournisseurs de services. Ces faits expliquent pourquoi la question se pose aujourd'hui dans des organisations où elle ne se posait pas il y a trois ans.
Ils n'impliquent pas mécaniquement qu'il faille partir. Une organisation dont le parc est réduit, dont l'équipe maîtrise l'outillage depuis dix ans, dont les applications critiques dépendent d'appliances validées sur une seule plateforme, et dont le renouvellement contractuel est encore lointain, peut légitimement conclure que le coût du changement dépasse le gain attendu.
Faire figurer « rester » comme scénario chiffré dans le comparatif n'est pas une précaution rhétorique. C'est ce qui rend la recommandation finale défendable devant un comité de direction, parce qu'elle montre que l'alternative a été évaluée plutôt qu'écartée.
Cinq phases, et quatre points de sortie
Le programme se découpe en cinq phases : cadrage et sponsorship, audit et choix de la cible, préparation et démonstration de faisabilité, pilote, puis bascule à l'échelle.
Entre chacune, un jalon formel. Et voici la formulation qui change la nature de l'exercice : ce sont des points de sortie possibles, pas des passages obligés.
Un comité de direction qui doit approuver un programme de trente mois hésite, et il a raison. Un comité à qui l'on demande d'approuver une phase de deux mois, avec un livrable défini et une décision explicite à l'issue, décide. La différence n'est pas cosmétique : elle transforme un engagement massif et irréversible en une série d'engagements courts et révisables.
Les quatre jalons portent chacun sur une question distincte. Le premier : le mandat et le budget pluriannuel sont-ils actés ? Le deuxième : le dossier de décision chiffré désigne-t-il une cible ? Le troisième : la faisabilité est-elle démontrée et le retour arrière testé ? Le quatrième : les procédures sont-elles industrialisées et réplicables ?
Un programme qui échoue au troisième jalon a coûté six à onze mois et a produit une connaissance réelle de son parc. Ce n'est pas un échec, c'est une décision informée. Un programme sans jalons qui s'enlise au dix-huitième mois est autre chose.
Le poste de coût que tout le monde oublie
Pendant une partie du programme, vous payez deux plateformes. Les abonnements en cours ne s'arrêtent pas le jour où la première machine virtuelle bascule ; ils s'arrêtent quand la dernière a basculé et que le préavis contractuel est purgé.
Cette double facturation s'étale sur douze à vingt-quatre mois selon la taille du parc. D'après ce que nous observons sur les programmes que nous accompagnons, elle représente une part significative du budget total — de l'ordre de quinze à vingt-cinq pour cent. C'est une estimation de terrain, pas une donnée publiée, et elle varie fortement selon la durée de la phase de bascule.
L'important n'est pas le pourcentage exact, c'est qu'il figure dans le dossier initial. Un dossier de décision qui compare le coût annuel de la plateforme actuelle au coût annuel de la cible, sans la période de recouvrement, présente un gain qui n'existe pas encore et une trésorerie qui ne se comporte pas comme annoncé.
Trois autres postes se retrouvent régulièrement sous-évalués : la formation des équipes, la réécriture des procédures d'exploitation, et le temps d'ingénierie interne consacré au programme pendant que l'exploitation courante continue.
Le choix de la cible n'est pas un choix technique
Trois alternatives dominent aujourd'hui les projets de cloud privé, et aucune n'est meilleure dans l'absolu.
Proxmox VE est le remplacement le plus direct pour une PME ou une ETI qui veut retrouver rapidement des fonctions équivalentes sans changer de paradigme d'exploitation.
OpenStack — version courante 2026.1 « Gazpacho » — s'adresse aux infrastructures de grande taille et aux opérateurs, là où le besoin est celui d'un cloud privé multi-locataire avec une interface programmable.
OpenShift Virtualization convient aux organisations qui ont déjà une stratégie Kubernetes ou un projet de modernisation applicative, et qui veulent exploiter machines virtuelles et conteneurs sur une même plateforme. Son outil de migration a récemment gagné une capacité de déport de la copie vers la baie de stockage, contribuée au projet amont, qui sort le transfert de données du réseau — ce qui change l'arithmétique des fenêtres de bascule sur les gros volumes.
Le critère décisif n'est presque jamais la fiche technique. Il est ailleurs : quelles compétences existent dans l'équipe, et lesquelles peut-on acquérir dans le calendrier ? L'organisation a-t-elle besoin d'un support contractuel avec engagement, ou peut-elle assumer un modèle communautaire ? Une contrainte de conformité impose-t-elle une certification ou une localisation particulière ? Et quel est le rapport souhaité entre investissement initial et charge courante ?
Une équipe de trois personnes qui exploite VMware depuis douze ans et qui n'a jamais touché à Kubernetes ne migrera pas vers une plateforme Kubernetes en dix-huit mois sans un plan de montée en compétences qui pèse autant que le projet technique. Ce n'est pas une objection à cette cible ; c'est une ligne du budget.
L'ordre de migration se lit dans les dépendances, pas dans la criticité
Le réflexe est de migrer d'abord ce qui est le moins critique et de terminer par le cœur de métier. C'est à moitié juste, et la moitié fausse fait des dégâts.
L'ordre est déterminé par la cartographie des dépendances applicatives. Une application B qui consomme une application A se migre après A. Et surtout, les services d'infrastructure transverses ferment la marche : annuaire, résolution de noms, synchronisation de temps, pare-feu, supervision, sauvegarde. Ils doivent rester disponibles pendant toute la durée du programme, donc ils ne peuvent basculer qu'une fois que tout ce qui en dépend a déjà basculé.
C'est aussi l'étape la plus risquée du programme, et elle arrive à la fin, quand l'équipe est fatiguée et que le sponsor considère l'affaire pliée. Prévoyez-la comme un projet en soi, avec ses propres fenêtres de maintenance.
Cette cartographie est le livrable le plus sous-investi de la phase d'audit. Elle est fastidieuse, elle ne produit aucun résultat visible, et c'est elle qui détermine si la phase de bascule se déroulera par vagues ordonnées ou par découvertes successives.
Le retour arrière se teste, il ne se documente pas
La démonstration de faisabilité porte sur une machine virtuelle témoin, migrée de bout en bout jusqu'à la validation fonctionnelle par le métier. Elle comporte un second volet que l'on saute volontiers : exécuter le retour arrière, puis le ré-exécuter.
Un plan de retour arrière rédigé mais jamais joué n'est pas un plan, c'est une intention. Le jour où il servira, ce sera en production, sous pression, sur une application que quelqu'un attend.
La règle correspondante est sans nuance : si le retour arrière échoue à la démonstration, on ne passe pas au pilote. Deux ou trois semaines de plus à ce stade coûtent infiniment moins qu'un incident au premier lot.
N'achetez pas deux fois le même parc
La tentation naturelle est d'acquérir la totalité du matériel cible avant de commencer. Cela double l'investissement matériel et immobilise une trésorerie pendant toute la durée du programme.
L'approche qui fonctionne consiste à acquérir vingt à quarante pour cent de la capacité cible, à absorber les premières vagues avec cette marge, puis à reconstituer le reste par recyclage : à mesure que les vagues basculent, les serveurs libérés sont réinstallés et intégrés au nouveau cluster.
Ce cycle demande une coordination fine entre trois équipes — celle qui migre, celle qui exploite encore l'ancienne plateforme, celle qui exploite la nouvelle. Il impose aussi de conserver en permanence une marge de capacité de vingt à trente pour cent, faute de quoi un incident matériel pendant une vague bloque tout.
Ce que cet article ne traite pas
Le déroulé technique d'une migration, ses phases et ses points de blocage, traité séparément. Les contraintes de licence des éditeurs tiers — bases de données et progiciels — dont les conditions varient selon la plateforme d'exécution et qui méritent une analyse juridique propre à chaque contrat. Les modalités de résiliation et les préavis, qui dépendent de votre contrat et non d'une règle générale. Et le cas d'une reprise vers le cloud public, qui répond à une logique différente de celle d'un cloud privé.
Si vous ne retenez qu'une chose : n'engagez pas le programme, engagez la phase suivante. Le mandat avant l'audit, l'audit avant la cible, la faisabilité avant le pilote, et à chaque jalon la possibilité assumée de s'arrêter.
Nous conduisons ces programmes phase par phase, du cadrage à la dernière vague, sous migration et sortie de VMware, et nous produisons les dossiers de décision chiffrés qui les précèdent dans le cadre de notre audit et conseil en architecture. Un cadrage de deux heures suffit généralement à savoir si votre parc relève d'un programme de treize mois ou de trente.
