Audit VMware avant migration: ce qui casse les plans trop propres

La version comité est presque toujours la même: "on a 240 VMs, un PRA, des sauvegardes, on peut planifier la sortie." C'est rassurant. Et souvent faux, au moins en partie.

Sur cette mission, trois sites, production industrielle, fenêtres de changement serrées. Au départ, la DSI voulait un chiffrage et un calendrier. Au bout de dix jours d'audit, la bonne question n'était plus "quand on démarre", mais "où est notre point de non-retour".

Ce qui semblait solide

Sur le papier:

• inventaire vCenter propre,
• PRA documenté,
• supervision active,
• ownership applicatif "connu".

En atelier terrain, c'était plus nuancé.

• Des services qualifiés "non critiques" participaient en réalité à des chaînes de production.
• Des dépendances middleware existaient dans les scripts d'exploitation, pas dans la doc.
• Le PRA supposait un ordre de reprise qui ne correspondait plus au comportement applicatif actuel.

Rien d'exotique. C'est exactement ce qu'on rencontre sur des environnements qui ont évolué vite pendant plusieurs années.

Le vrai problème n'était pas VMware

Le sujet n'était pas "VMware est mauvais" ou "Proxmox est mieux". Le sujet était plus simple: la décision de migration reposait sur une vérité technique partielle.

Quand la cartographie de dépendances est incomplète, le planning devient une hypothèse déguisée en certitude.

On l'a vu tout de suite:

• deux lots de migration pensés comme indépendants partageaient une dépendance réseau commune,
• certaines sauvegardes "vertes" n'avaient pas de preuve de restauration récente,
• des runbooks de reprise mentionnaient des prérequis qui n'existaient plus en production.

Ce qui a fait bouger la décision

Le point de bascule n'a pas été un benchmark. C'est un atelier de simulation incident.

Quand on a déroulé un scénario de bascule avec les équipes ops et applicatives ensemble, trois écarts sont apparus:

1. Le délai de décision rollback n'était pas défini.
2. La responsabilité de validation applicative n'était pas claire.
3. Le RTO annoncé ne couvrait pas les dépendances transverses.

À ce moment, le débat "vitesse de migration" a perdu sa priorité. La DSI a demandé autre chose: des vagues plus petites, une coexistence plus longue, et une matrice de rollback opposable.

Arbitrages assumés

On a retenu une trajectoire moins spectaculaire, mais plus solide:

• migration par dépendance métier, pas par commodité cluster,
• maintien de certains composants VMware en parallèle, temporairement,
• validation PRA ciblée avant tout déplacement de charges critiques,
• critères go/no-go définis avant chaque vague, pas la veille.

Oui, cela allonge le programme. Oui, cela coûte plus cher à court terme.

Mais cela évite surtout le scénario classique: go-live "réussi" suivi de trois semaines d'instabilité et d'arbitrages sous stress.

Observation de terrain qu'on oublie souvent

Une migration n'échoue pas toujours le jour J. Elle échoue parfois un mois plus tard, quand l'équipe exploitation absorbe les effets de bord avec des runbooks incomplets et une charge mentale trop élevée.

Le risque n'est pas seulement technique. Il est organisationnel.

• qui décide en 15 minutes de rollback ou de poursuite,
• qui valide la reprise fonctionnelle côté métier,
• qui tient la continuité si deux incidents s'enchaînent.

Si ces réponses ne sont pas claires avant la migration, elles ne le seront pas pendant l'incident.

Position

Un audit VMware utile ne sert pas à justifier une décision déjà prise. Il sert à rendre la décision robuste.

Parfois, l'audit confirme qu'on peut accélérer. Parfois, il oblige à ralentir. Dans les deux cas, c'est une bonne nouvelle: on sort du marketing de trajectoire et on revient à l'ingénierie de continuité.