Inventaire VMware: pourquoi les migrations dérapent malgré des exports propres

Un inventaire peut être exact et inutilisable. C'est fréquent.

On confond souvent deux choses:

• un inventaire d'actifs,
• une cartographie d'exploitation.

Le premier décrit ce qui existe. Le second décrit ce qui casse quand on bouge une pièce.

Ce qu'on découvre en audit croisé

Quand on croise vCenter, flux réseau, historique incidents et preuves de restauration, les surprises arrivent vite:

• services low-profile mais critiques dans la chaîne métier,
• dépendances implicites portées par des scripts anciens,
• ownership applicatif incertain sur des briques sensibles,
• écart entre succès backup et capacité réelle de restore.

C'est là que les vagues de migration "logiques" deviennent risquées.

Une erreur classique de séquencement

Construire les vagues par commodité technique:

• cluster,
• volumétrie,
• fenêtre disponible.

Ça paraît rationnel. Mais sans dépendances métier, on expose les zones invisibles.

J'ai vu des projets migrer des workloads jugés secondaires, puis découvrir qu'ils supportaient une partie critique des flux de production.

Pourquoi c'est aussi un sujet de gouvernance

Une cartographie faible n'est pas seulement un sujet d'ingénierie. C'est un sujet de décision.

Si l'incertitude est élevée, la gouvernance doit l'assumer:

• vagues plus petites,
• critères de rollback plus conservateurs,
• points de validation supplémentaires.

Faire comme si la visibilité était bonne revient à prendre du risque sans le nommer.

Position

On ne réduit pas la complexité par communication. On la réduit par confrontation aux faits.

Avant de parler vitesse de migration, il faut parler qualité d'inventaire exploitable. Sinon on déplace le problème vers le post go-live, quand il coûte le plus cher.