Entrazure
« Le renouvellement est arrivé et on ne peut pas le signer »
La situation revient assez souvent pour qu’on l’entende dans les mêmes mots. Le parc VMware est stable depuis des années, personne ne demandait à y toucher, et l’équipe infrastructure avait une longue liste de choses plus urgentes. Puis l’offre de renouvellement est arrivée.
La structure a changé autant que le montant. Les licences perpétuelles avec soutien ont cédé la place à des abonnements groupés, les éditions ont été regroupées, et des engagements minimaux de cœurs font qu’une petite grappe peut être facturée comme si elle était plus grosse qu’elle ne l’est. La direction n’est pas ambiguë, et les finances l’ont remarqué.
Une décision prévue dans trois ans se prend en trois mois, par une équipe qui exploite tout le reste. L’approvisionnement veut une réponse avant l’échéance. Le responsable infrastructure sait que le parc contient des serveurs dont personne n’explique la fonction et des dépendances que personne n’a cartographiées. Et quelqu’un propose de tout déplacer pendant une longue fin de semaine.
C’est ce moment-là qui fait dérailler une sortie de VMware : les dégâts se font dans les trois premières semaines de planification, pas la nuit du basculement.
Pourquoi la réponse habituelle échoue
Tout déplacer tel quel, dimensionné sur l’alloué. C’est l’approche la plus fréquente et la plus coûteuse. On exporte l’inventaire vCenter, on associe chaque machine virtuelle au gabarit Azure le plus proche, on additionne, on présente un montant mensuel. Ce montant est faux, souvent largement, pour une raison structurelle : une grappe sur site est sursouscrite. Vous avez acheté des cœurs physiques une fois et vous en avez alloué beaucoup plus en virtuel par-dessus, parce que la plupart des machines dorment la plupart du temps. Azure facture ce qui est provisionné, en continu. Reproduire l’alloué à l’identique fait passer un parc sursouscrit sur un compteur, et la première facture complète est le moment où le programme perd sa crédibilité. Tout ce qui suit devient un exercice de récupération mené sous suspicion.
Changer d’hyperviseur. Passer à Hyper-V, Nutanix ou Proxmox, garder le modèle opérationnel, reporter la question. L’attrait est évident : les compétences se transposent et rien ne change côté application. Le problème, c’est que l’effort de migration est comparable à celui d’un déplacement vers Azure. Vous payez donc la perturbation au complet pour arriver dans une position structurellement identique, trois ou quatre ans plus tard, face à qui possédera ce produit à ce moment-là. C’est un choix défendable pour une exigence de souveraineté ou de latence qui ne peut réellement pas être satisfaite autrement. C’en est un mauvais quand il est fait pour la raison habituelle : c’est l’option qui demande le moins de décisions.
Prendre Azure VMware Solution pour la destination. AVS exécute votre environnement vSphere sur du matériel Azure dédié, et ça règle un vrai problème : quand la date de renouvellement arrive avant toute réarchitecture possible, ça vous sort du contrat sans toucher à une machine virtuelle. Le défaut apparaît quand on le vend comme état final. Vous avez alors des engagements de capacité chez Azure au lieu d’engagements de licences sur site, la même prolifération de machines, et aucun des services gérés qui justifiaient le déplacement. AVS est un pont, et un pont sans sortie écrite dans le plan n’est qu’une version plus longue du problème.
Planifier les vagues à partir d’un chiffrier. Une découverte faite en interrogeant les responsables applicatifs produit une carte de dépendances assurée et incomplète. Les manques sont toujours du même type : la tâche planifiée sur un serveur non géré qui écrit le fichier dont dépend la clôture financière, l’adresse IP codée en dur dans une appliance où personne ne s’est connecté depuis 2019, le serveur de licences épinglé à une adresse MAC. Ces éléments n’apparaissent pas en entrevue parce que les gens qui les connaissaient sont partis. Ils apparaissent à 2 h du matin la nuit du basculement.
Comment nous menons une sortie
Une découverte fondée sur le trafic observé. Azure Migrate avec cartographie des dépendances sur plusieurs semaines d’activité réseau réelle, assez longtemps pour attraper les comportements de fin de mois et de trimestre. Le livrable est une carte de ce qui parle réellement à quoi, plus un profil d’utilisation par machine, ce qui rend le redimensionnement défendable plutôt qu’optimiste.
Quatre dispositions, tranchées charge par charge. Retirer, parce qu’une part significative de tout parc ne reçoit aucun trafic et n’existe que parce que la suppression faisait peur. Déplacer, pour les machines qui doivent bouger telles quelles. Replateformer, quand la destination est un service géré plutôt qu’une machine : SQL Server vers Azure SQL Managed Instance, serveurs de fichiers vers Azure Files, couches web vers App Service. Conserver, pour ce qui reste sur site par latence, interface physique ou résidence, ramené sous Azure Arc pour vivre sous les mêmes politiques que le reste.
Un modèle de coût avant l’engagement. Dimensionnement sur l’utilisation mesurée, puis réservations et plans d’économies sur le noyau stable du parc, Avantage Hybride Azure là où les licences Windows Server et SQL Server avec Software Assurance le permettent, et le scénario où les chiffres ne fonctionnent pas présenté à côté de l’autre. Même discipline que notre optimisation des coûts cloud, appliquée avant que la dépense existe.
La landing zone d’abord. Groupes d’administration, Azure Policy, réseau hub-and-spoke, identité et journalisation centralisée sont en place avant l’arrivée de la première charge. Migrer dans une souscription non gouvernée, c’est se garantir un projet de gouvernance dix-huit mois plus tard, quand tout devra être déplacé une deuxième fois. C’est le mandat landing zone Azure de quatre semaines, mené en parallèle de la découverte.
Des vagues avec retour arrière. Groupées par grappe de dépendances, pas par service. Critères d’acceptation convenus par vague, environnement source conservé jusqu’à leur atteinte, DNS comme interrupteur, limite de temps annoncée pour la décision de retour. La première vague est petite et répétée volontairement.
Le mandat qui livre ça
Deux à quatre semaines d’évaluation produisant la carte de dépendances, la disposition par charge, le modèle de coût avec et sans réservations, et un plan de vagues daté. C’est aussi la meilleure pièce à emporter dans une négociation de renouvellement, parce qu’il transforme « on pourrait bouger » en calendrier.
La landing zone tourne en parallèle sur quatre semaines. Les vagues suivent, dimensionnées pour tenir dans une fenêtre de maintenance. Quand le calendrier l’impose, nous évaluons si Azure VMware Solution doit porter ce qu’on ne peut pas réarchitecturer à temps, sa sortie étant inscrite dans le même plan.
Vous gardez la carte de dépendances, le Terraform de la landing zone dans votre dépôt, le modèle de coût, le plan de vagues et une liste de déclassement avec les licences qu’elle libère.
Une migration est le moment le moins cher pour régler la résidence des données et la journalisation d’audit : l’ architecture de conformité se conçoit donc dans le mouvement, la résidence étant imposée par politique au niveau du groupe d’administration, hors de portée d’une souscription future. Les environnements cliniques ajoutent des contraintes de cloisonnement, décrites dans nos travaux en santé. C’est aussi le moment naturel pour passer l’identité et l’accès réseau en modèle zero trust : le réseau plat que vous quittez mérite rarement d’être reproduit.
Questions fréquentes
Notre renouvellement est dans quatre mois. Est-ce suffisant pour bouger ?
C’est suffisant pour savoir exactement ce que vous faites et pour avoir commencé, ce qui est une bien meilleure position de négociation qu’une signature sous contrainte. Quatre mois couvrent la découverte, la landing zone et les deux premières vagues. Ça ne couvre pas la sortie complète d’un parc, et quiconque le promet prévoit d’être ailleurs la fin de semaine du basculement.
Azure VMware Solution : destination ou étape ?
Étape, avec une date de sortie écrite. AVS fait tourner votre environnement vSphere existant sur du matériel Azure, ce qui est utile quand la date de renouvellement arrive avant toute réarchitecture possible. Traité comme point d’arrivée, il reproduit le problème d’origine dans une référence Azure, avec ses propres engagements de capacité. Nous l’utilisons quand les dépendances NSX, des appliances liées à vSphere ou le calendrier en font la réponse honnête, et nous inscrivons la sortie dans le même plan.
Est-ce que ça coûtera vraiment moins cher que de renouveler ?
Parfois oui, parfois non, et l’écart tient entièrement au dimensionnement. Un déplacement un pour un des vCPU alloués vers des machines Azure coûte presque toujours plus cher, parce qu’une grappe sur site est sursouscrite et qu’Azure facture ce qui est provisionné. Dimensionné sur l’utilisation observée, avec réservations et Avantage Hybride Azure, le portrait change. Nous montons ce modèle avant votre engagement, et nous montrons aussi la version où ça ne fonctionne pas.
Et les serveurs que personne n’arrive à identifier ?
Tous les parcs en ont. La cartographie des dépendances sur plusieurs semaines de trafic réel dit qui parle à qui, et c’est ainsi qu’un serveur sans propriétaire connu se classe comme porteur ou comme retirable. Ceux qui ne reçoivent aucun trafic sont le gain le moins cher de tout le programme.
Peut-on garder des charges sur site ?
Oui, et pour des systèmes industriels ou cliniques contraints par la latence, c’est souvent la bonne décision. L’objectif est d’arrêter d’exploiter deux modèles opérationnels sans lien. Azure Arc ramène les serveurs, grappes Kubernetes et instances SQL restants sous les mêmes politiques, la même supervision et la même gestion des mises à jour que le reste.
Quel est le plan de retour arrière si une vague échoue ?
Chaque vague conserve l’environnement source intact et allumé jusqu’à l’atteinte des critères d’acceptation, avec le DNS comme interrupteur et une limite de temps documentée pour la décision. Le retour arrière est répété pour la première vague, pas improvisé à la troisième. Un plan de migration sans chemin de retour écrit est un plan qui n’a pas été réfléchi.