Réduire le lock-in infrastructure : une approche pragmatique
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, par exemple, n'est pas uniforme. Un environnement qui utilise uniquement vSphere avec du stockage NFS externe et des VMs Linux a une dépendance hyperviseur relativement limitée — l'hyperviseur peut être remplacé sans toucher aux applications ni à la majeure partie 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 pour tous les opérations courantes — là, la dépendance est profonde et le coût de sortie est réel.
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 VMs 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, staging. Ces environnements peuvent absorber une coupure sans impact métier, et ils permettent de rôder les procédures.
3. Outils et scripts — remplacer les scripts PowerCLI par des solutions équivalentes sur la plateforme cible. Ce travail peut être fait en parallèle des migrations, et il réduira la dépendance opérationnelle avant même que toutes les VMs aient migré.
4. Production critique en dernier — avec rollback validé, critères go/no-go définis, et l'organisation en capacité d'absorber une opération à risque.
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 workloads critiques sur lesquelles le timing de migration ne peut pas être contraint par le rythme du programme global
La coexistence n'est pas un échec. C'est une posture architecturale qui assume que les transformations prennent du temps et que la production ne peut 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 workload — documentée et validée par la DSI
- Le processus d'exception — comment déroger si une contrainte le justifie
- Les critères de fin de programme — quand peut-on considérer que la dépendance est réduite à un niveau 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 et coûter plus cher la première année (si on intègre le coût des licences de coexistence, la formation et les incidents résiduels).
Migrer sans maintenir la capacité de rollback — réduire le lock-in VMware en se mettant dans une situation où on ne peut plus y revenir si nécessaire n'est pas de l'autonomie. C'est du risque non maîtrisé.
Oublier la dépendance humaine — remplacer VMware par Proxmox change le profil de lock-in, pas sa nature. Si toute l'expertise Proxmox repose sur un seul ingénieur, le lock-in est simplement déplacé vers une personne plutôt qu'un éditeur.
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, si un nouvel éditeur présente une meilleure proposition dans 3 ans, évaluer cette proposition sur 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.