Le lock-in éditeur est devenu un sujet chaud depuis Broadcom. Certaines équipes en parlent avec une urgence de principe, comme si dépendre d'un éditeur était en soi une faute de gouvernance. Ce n'est pas si simple.
Toute infrastructure dépend de quelque chose : un hyperviseur, un OS, un protocole réseau, une solution de backup. Zéro lock-in est une illusion. La vraie question est : de quoi dépend-on, à quel degré, et quel est le coût de changer ?
Comprendre sa dépendance réelle avant de vouloir la réduire
La première étape n'est pas un plan de migration. C'est un inventaire honnête.
La dépendance VMware n'est pas uniforme. Un environnement limité à vSphere, à du stockage NFS externe et à des VM Linux présente une dépendance relativement contenue : l'hyperviseur peut évoluer sans refonte majeure des applications ou du réseau.
Un environnement qui utilise NSX pour la microsegmentation, vSAN pour le stockage distribué, Aria pour l'automatisation et vCenter avec des scripts PowerCLI maison présente une dépendance plus profonde et un coût de sortie supérieur.
L'inventaire couvre :
- Les dépendances hyperviseur "pures" (VMs qui tournent sur vSphere)
- Les dépendances réseau (NSX, vDS, port groups personnalisés)
- Les dépendances stockage (vSAN, VMDK-linked processes)
- Les dépendances outils (scripts, API, intégrations ITSM/monitoring)
- Les dépendances humaines (certifications, réflexes, documentation interne)
La réduction progressive : par composant, pas par révolution
La meilleure trajectoire de réduction du lock-in n'est pas "tout migrer maintenant". C'est réduire sa dépendance par composant, en commençant par les composants où la migration est la moins risquée et le gain est mesurable.
Ordre de priorité habituel en environnement mixte :
1. Nouveaux workloads en priorité sur la cible : ne pas déployer de nouvelles VM sur VMware si l'objectif est la sortie. Chaque nouvelle VM déployée sur VMware est une VM à migrer plus tard.
2. Charges non critiques en premier : développement, test et staging permettent de rôder les procédures avant d'engager la production critique.
3. Outils et scripts : remplacer les scripts PowerCLI par des solutions équivalentes sur la plateforme cible. Ce travail peut avancer en parallèle des migrations et réduire la dépendance opérationnelle avant le dernier lot de VM.
4. Production critique en dernier : engager ces charges avec un retour arrière validé, des critères GO/NO-GO définis et une organisation capable d'absorber l'opération.
Ce qu'on peut préserver de VMware pendant la transition
Ce n'est pas parce qu'on réduit sa dépendance VMware qu'il faut tout migrer simultanément.
Garder certains composants VMware provisoirement peut être rationnel :
- vCenter comme interface de gestion hybride pendant la coexistence
- Composants applicatifs fortement intégrés à NSX, jusqu'à ce que la refonte réseau soit planifiée et budgétée séparément
- Certaines charges critiques dont le calendrier de migration ne peut pas être imposé par le rythme du programme global
La coexistence constitue une posture architecturale assumée : les transformations prennent du temps et la production ne doit pas être mise en danger au nom de la cohérence architecturale.
La gouvernance du changement : la dimension oubliée
La réduction du lock-in est un programme de transformation. Il a besoin d'un sponsor clair, d'un calendrier, de ressources dédiées, et d'un processus de décision pour les exceptions.
Sans gouvernance formelle, le lock-in se reconstitue naturellement. Les équipes reviennent aux outils familiers. Les nouveaux workloads sont déployés sur la plateforme qu'elles connaissent. La dette architecturale s'accumule.
Ce qui doit être formalisé :
- La plateforme cible par type de charge, documentée et validée par la DSI
- Le processus d'exception, avec les contraintes qui autorisent une dérogation
- Les critères de fin de programme, qui définissent le niveau de dépendance acceptable
Les erreurs à éviter
Confondre réduction du lock-in et réduction des coûts. Les deux peuvent coïncider, mais ce ne sont pas le même objectif. Une migration VMware → Proxmox peut réduire la dépendance éditeur tout en coûtant plus cher la première année lorsque l'on intègre coexistence, formation et incidents résiduels.
Migrer sans maintenir la capacité de retour arrière. Réduire le lock-in VMware en supprimant toute possibilité de retour crée un risque non maîtrisé.
Oublier la dépendance humaine. Remplacer VMware par Proxmox change le profil du lock-in, pas sa nature. Si toute l'expertise Proxmox repose sur un seul ingénieur, la dépendance est déplacée vers une personne.
Ce que ça ressemble quand c'est bien fait
L'organisation qui a bien géré sa réduction de lock-in ne rate pas de fenêtre de maintenance parce qu'elle attend une décision d'architecture. Elle opère sa plateforme avec ses propres outils, ses propres procédures testées, et une équipe qui comprend ce qu'elle opère.
Elle peut aussi réévaluer une proposition future selon ses mérites techniques et économiques, sans être contrainte de rester ou de partir pour des raisons non maîtrisées.
C'est ça, l'architecture souveraine.