Décider de l'infrastructure : VMware, migration, data center
Trois questions, une seule base de chiffres : combien coûte réellement votre existant, combien coûtera une cible déjà optimisée, combien coûte le passage de l'un à l'autre. Les outils des fournisseurs livrent le format attendu ; nous remplaçons leurs hypothèses par vos coûts réels.
Trois questions, une seule base de chiffres
- Statu quo optimisé : l'existant après réduction, renégociation et rationalisation, la référence honnête de toute comparaison
- Hybride rééquilibré : ce qui gagne à migrer migre, le reste est optimisé sur place
- Migration intégrale : toutes les charges vers la cible, vague par vague
- Hypothèses explicites : double exploitation, licences Windows, SQL Server, Oracle et VMware, egress, infogérance
- Crédits de migration et remises d'engagement en lignes distinctes, à faire confirmer par le fournisseur ; le scénario sans crédits est toujours montré
Huit étapes, en général six à huit semaines
Les durées sont indicatives et se fixent au cadrage selon la taille du parc ; plusieurs étapes se recouvrent.
Cadrer la décision
En atelier avec votre DSI et votre direction financière : question à trancher (sortie complète, datacenter seul, mixte, renouvellement VMware), périmètre et exclusions explicites, cibles, devise, horizon, règles de décision (taux d'actualisation, capex et opex, cash ou amortissement). Pour une sortie de VMware, cette semaine de cadrage comprend la lecture du devis de renouvellement, l'inventaire RVTools et le choix des scénarios. Un responsable nommé par source.
Collecter
Exports et contrats en l'état, sans retraitement de votre part : inventaire de l'hyperviseur, CMDB des serveurs physiques, 95e centile CPU et mémoire sur 30 jours, bases, lien application vers serveur ; d'abord le devis de renouvellement de l'hyperviseur, puis immobilisations, maintenance, hébergement, licences, sauvegarde.
Qualifier chaque machine
Sources rapprochées par nom de machine normalisé, écarts de comptage expliqués avant de choisir une source de référence. Chaque machine reçoit une disposition : migrer, retenir sur site, remplacer par un service managé, retirer, exclure ou à qualifier.
Reconstituer l'existant
Coût complet par plateforme, par pools de coûts alloués aux machines, puis trajectoire « ne rien faire » : opex indexé, renouvellement de l'hyperviseur à sa date, refresh matériel par cohortes, fins de support. Vos propres coûts, quand vous les fournissez, prévalent.
Chiffrer une cible optimisée
Chaque machine dimensionnée sur ses pics mesurés, dans la famille qui correspond à son profil ; hors production à l'usage ; licence incluse ou apportée selon l'éligibilité réelle ; bases vers services managés ; stockage sur l'utilisé, jamais sur le provisionné.
Chiffrer la transition
Vagues cohérentes avec le plan de votre intégrateur, double exploitation recalculée ligne par ligne jusqu'au décommissionnement, refresh gelé dès qu'un segment migre, coût de migration par serveur, par base et en coûts fixes de programme.
Scénarios et réconciliation
Une série de scénarios et leurs sensibilités, bornés par un combiné favorable et un combiné défavorable, puis un tableau qui explique l'écart avec chaque estimation en circulation : outils des fournisseurs, rapports de l'intégrateur, benchmarks.
Restituer et décider
Quatre ou cinq chiffres clés et trois messages à votre DSI et à votre direction financière : la variable dominante de l'existant, les leviers FinOps de la cible, la discipline de programme.
Le calcul, expliqué simplement
- Rester = coût de maintien indexé (environ 3 % par an par défaut) + renouvellement du matériel par cohortes d'achat + hyperviseur au prix de son renouvellement, à partir de sa date.
- Migrer = cible en régime établi × montée en charge des vagues + support + coût de migration + double exploitation (ce que coûte encore chaque segment jusqu'à son décommissionnement) + existant conservé, moins crédits et remises.
- Économie par période = rester moins migrer. Nous suivons l'économie cumulée, l'économie nette sur l'horizon et l'économie en régime établi ; ROI = économie nette / coût de migration net des crédits ; VAN au taux de votre direction financière ; période de retour : la première où le cumul devient durablement positif.
- La cible : ressource requise = ressource actuelle × pic au 95e centile / 0,8, arrondie aux tailles d'instances ; stockage = espace utilisé + 20 %. Sans mesure, un pic par défaut documenté est signalé comme hypothèse à lever. Tarifs publics de la région cible, hors taxes, engagement de 3 ans sans paiement initial en base ; engagement d'un an et paiement à l'usage en scénarios ; évolution des prix cloud fixée à zéro par prudence.
- Le même modèle de VM sur bare metal : le nombre de nœuds est fixé par la plus forte de trois contraintes. CPU : vCPU à héberger rapportés aux cœurs du nœud × ratio vCPU par cœur, moins les ressources que la plateforme réserve sur chaque nœud ; ce ratio est fixé par environnement, plus prudent en production, et validé avec l'éditeur. Mémoire : après cette réserve et le taux d'utilisation cible. Stockage : capacité consommée après réduction de données et facteur de réplication. Un nœud de résilience s'ajoute en production.
- L'existant : des pools de coûts (matériel annualisé et maintenance, hyperviseur, hébergement et énergie, stockage, réseau, licences, sauvegarde) alloués aux machines au prorata des vCPU, avec un contrôle : la somme des allocations égale le total. Les coûts de personnel restent hors du TCO infrastructure de base, pour que la comparaison reste indiscutable ; un volet coût complet est proposé en option.
- Le renouvellement se compte en cœurs licenciables par hôte, minimums par processeur et autres minimums du contrat appliqués, tels que le devis réel les fixe, après le retrait des VM éteintes et des réplicas inutiles.
- Le matériel est montré selon deux conventions, cash aux dates de refresh ou amortissement lissé, avec l'effet de chacune. Les économies sont décomposées par composant : compute, stockage, bases, réseau, support.
Une distribution, pas un chiffre. Chaque scénario est le même modèle avec un jeu de paramètres modifié : renouvellement de l'hyperviseur, cycle de refresh, gel des renouvellements, délai de décommissionnement, modèle d'engagement, cible sans right-sizing, licence apportée, périmètre, absence de crédits, coût complet avec personnel.
Les critères présentés au comité : économie en régime établi, économie nette et ROI, VAN, période de retour, écart entre les combinés favorable et défavorable, part de l'économie qui repose encore sur des benchmarks.
Cinq issues, une référence et leur combinaison
Même périmètre, même horizon de 5 à 6 ans, même coût complet, vague par vague et double exploitation comprise : chaque voie est un jeu de paramètres du même modèle.
Statu quo optimisé
Même plateforme, assiette réduite avant le renouvellement : right-sizing, consolidation des hôtes, retrait des VM éteintes et des réplicas inutiles. Toujours calculé : sans lui, n'importe quelle alternative gagne sur le papier.
- À modéliser : les mêmes postes que le renouvellement, sur l'assiette réduite, plus l'effort de capacity management
- Données décisives : métriques CPU et mémoire, taux de consolidation atteignable, VM à retirer
Rester et renégocier
Rien ne change côté exploitation ; le contrat passe en abonnement par cœur, édition VCF ou VVF.
- À modéliser : souscription par cœur physique, avec les minimums par processeur et les autres minimums du contrat vérifiés sur le devis réel ; édition et bundles imposés ; matériel, hébergement, stockage, licences, sauvegarde et réseau
- Données décisives : devis réel de renouvellement, cœurs licenciables par hôte, échéances des contrats et du refresh
- Tient en général : parc récent et dense, horizon de sortie lointain, peu de compétences sur les alternatives
- Vigilance : engagement long sur un parc appelé à décroître, édition plus riche que le besoin, pénalités de renouvellement tardif
Changer d'hyperviseur sur site
Même datacenter, conversion des VM, nouvel outillage d'exploitation : par exemple Nutanix, Hyper-V ou Azure Local, Proxmox VE, OpenShift Virtualization.
- À modéliser : souscriptions par cœur ou par nœud, matériel réutilisable ou non, conversion et tests, formation, sauvegarde, supervision et reprise compatibles, double exploitation pendant la conversion
- Données décisives : compatibilité du matériel et des OS invités, support des applications certifiées par leurs éditeurs, compétences internes
- Tient en général : datacenter conservé pour d'autres raisons (latence, informatique industrielle, contrat d'hébergement long), matériel récent
- Vigilance : coût de conversion et de requalification, maturité de l'écosystème de sauvegarde et de reprise, support des éditeurs
Héberger le même modèle de VM chez un hyperscaler
Sortie du datacenter sans refonte des VM, outils d'exploitation conservés : par exemple Azure VMware Solution, Google Cloud VMware Engine ou Amazon EVS en licence VCF portable, ou une solution HCI sur instances bare metal.
- À modéliser : nœuds dimensionnés par la plus forte de trois contraintes (CPU, mémoire, stockage), avec résilience ; licences de l'hyperviseur ; paiement à l'usage, engagement d'un an ou de 3 ans comparés par environnement ; réseau, liens dédiés et sauvegarde
- Données décisives : inventaire des VM et stockage consommé, profil horaire de chaque environnement, prix régionaux et devis
- Tient en général : échéance d'hébergement contraignante, étape transitoire avant une modernisation
- Vigilance : licences qui peuvent dépasser l'infrastructure en engagement long, engagement 24/7 appliqué à du hors production, disponibilité des instances dans la région
Migrer vers le cloud public
VM converties en instances natives dimensionnées sur l'usage (rehost, replatform), bases vers des services managés.
- À modéliser : cible optimisée (pics mesurés, familles adaptées, Start & Stop), licences incluses ou apportées, stockage sur l'utilisé, sauvegarde, reprise, réseau, support ; transition (vagues, double exploitation, migration, crédits)
- Données décisives : métriques d'utilisation, éligibilité des licences, plan de vagues, devis de l'intégrateur
- Tient en général : parc à renouveler, forte part de hors production, volonté de modernisation, cible optimisée et engagée
- Vigilance : cible à l'identique ou à la demande plus chère que l'existant, stockage et bases souvent plus chers, double exploitation sous-estimée
Décommissionner ou remplacer par un service
VM éteintes, réplicas et outillage retirés ; annuaire, fichiers ou progiciels vers un service managé ou un SaaS. Toujours à traiter en premier : cela réduit l'assiette de toutes les autres voies.
- À modéliser : coût évité, abonnement du service, migration des données
- Données décisives : dispositions de l'inventaire, feuille de route des éditeurs
- Vigilance : un périmètre sorti en SaaS ne figure ni dans le coût de ne rien faire ni dans la cible
Rétention partielle ou mixte
Certains segments restent sur site (informatique industrielle, sites distants, appliances, Unix), le reste suit une autre voie.
- À modéliser : coûts non évitables conservés à l'identique dans tous les scénarios, coûts fixes répartis sur une assiette plus petite
- Données décisives : segments où la cible coûte plus que l'existant alloué, contraintes de latence et de conformité
- Tient en général : petits sites amortis, segments peu rentables à déplacer
- Vigilance : coûts fixes résiduels à réaffecter, double outillage d'exploitation durable
Les destinations citées sont des exemples, comparées comme scénarios sur les mêmes critères. Déjà chiffrées en mission : une migration vers le cloud public et une solution HCI hébergée sur instances bare metal ; Proxmox, OpenShift Virtualization, les offres VMware hébergées et les clouds souverains sont comparés comme scénarios, sans chiffrage de mission à ce jour. L'hyperviseur alternatif sur site est chiffré sur un modèle générique, pas encore éprouvé en mission.
D'abord financière, puis qualitative
La lecture se fait sur ces critères, avec vos équipes ; les critères qualitatifs et leur poids sont fixés avec vous au cadrage. Un segment où la cible coûte plus que l'existant alloué est présenté comme tel : rétention, consolidation ou décision de simplification hors TCO.
| Critère | Comment nous le mesurons | Lecture |
|---|---|---|
| Économie en régime établi | Coût annuel de la voie une fois la transition terminée, comparé à la trajectoire « ne rien faire » | Robustesse de la cible |
| Économie nette sur l'horizon et VAN | Cumul des écarts de cash-flow sur 5 à 6 ans, actualisé au taux de votre direction financière | Dépend surtout de la vitesse de sortie |
| Période de retour | Première période où le cumul devient durablement positif | À confronter aux échéances des contrats |
| Robustesse | Nombre de scénarios qui restent positifs, écart entre les combinés favorable et défavorable | Une économie qui ne survit qu'au scénario favorable n'en est pas une |
| Maturité des chiffres | Part de l'économie qui repose encore sur des benchmarks plutôt que sur vos contrats | Fixe l'ordre de la demande de données |
| Calendrier | Compatibilité avec la date de renouvellement, les préavis et la capacité de migration | Conditionne la durée de la double exploitation |
| Risque de migration | Volume et complexité des VM, applications certifiées, dépendances, fenêtres de bascule | Qualitatif, critère fixé avec vous au cadrage |
| Compétences et exploitation | Écart entre les compétences en place et celles requises, outillage à remplacer | Qualitatif, critère fixé avec vous au cadrage |
| Réversibilité et dépendance | Durée d'engagement, portabilité des licences et des VM, coût de sortie | Qualitatif, critère fixé avec vous au cadrage |
| Souveraineté et conformité | Localisation des données, régime juridique du fournisseur, exigences réglementaires | Critère éliminatoire possible, à fixer dès le cadrage |
Les critères qualitatifs sont une proposition de méthode : leur liste et leur poids sont fixés avec vous au cadrage.
Un seul jeu de chiffres, plusieurs lecteurs
Inventaire consolidé
Une ligne par machine (sources, caractéristiques, disposition, cible, coûts) et l'entonnoir inventaire total, actif, en périmètre.
Coût complet de l'existant
Par plateforme, par application et par machine, avec la trajectoire « ne rien faire » sur l'horizon.
Modèle paramétrable
Recalculable dans votre tableur, avec ses scénarios figés, son tableau de réconciliation et le registre des hypothèses classées par impact sur l'économie.
Restitution au format attendu
Par votre comité et par le fournisseur cloud, alimentée par vos coûts réels et non par des hypothèses par défaut.
Note DSI et DAF
La décision en quelques pages, avec la demande de données de deux pages et les hypothèses qui restent à lever.
Modèle sur vos coûts réels
Une itération courte remplace les benchmarks par vos factures et contrats, lors d'un atelier avec vos achats et votre contrôle de gestion : scénario de base et scénario de négociation.
En option : un volet coût complet avec les coûts de personnel, la négociation fournisseur, le suivi des économies par vague après la décision.
Ce que fait KeeFinops, ce que font vos équipes
| Sujet | KeeFinops | Vos équipes |
|---|---|---|
| Cadrage | Propose les scénarios et la demande de données | Un sponsor côté DSI et un côté direction financière, un responsable par source, la liste des applications et des contraintes |
| Collecte | Contrôle, complète et signale les trous | Exports d'inventaire, contrats, factures, en l'état |
| Réduction de l'assiette | Analyse l'usage et chiffre le right-sizing | Les responsables d'application valident |
| Modélisation | Construit le TCO et documente chaque hypothèse | Valident les hypothèses métier : criticité, regroupement en vagues |
| Comparaison | Chiffre les issues au même niveau | Valident criticité, contraintes et fenêtres de bascule |
| Restitution | Présente la note et le business case | Le comité décide |
| Après la décision | Suivi des économies par vague et exécution accompagnée, en option | Pilotent la migration avec l'intégrateur |
Ce qui fausse une comparaison
- Comparer les alternatives à un statu quo non optimisé : toutes gagnent sur le papier.
- Un inventaire ancien de plusieurs mois : des machines ont pu être créées ou retirées depuis, et les machines éteintes et les templates restent à confirmer.
- Des comptages d'hôtes, de cœurs et de machines qui divergent entre outils : il faut les rapprocher, jamais les additionner.
- Chiffrer le renouvellement à partir d'une synthèse publique ou d'une règle de licence non vérifiée, au lieu du devis réel, ou compter les cœurs licenciables sans appliquer les minimums par processeur et les autres minimums du contrat, ou sans retirer d'abord les VM éteintes et les réplicas inutiles.
- Des licences possédées valorisées au prix d'abonnement, ou des bases embarquées dans un progiciel comptées en licence directe.
- Des estimations tierces qui ne licencient pas SQL Server, comparent des générations d'instances ou des régions différentes, ou incluent parfois le personnel.
- Des disques HCI et locaux comptés une seconde fois en stockage, ou un stockage valorisé sur le provisionné au lieu de l'utilisé.
- Une cible à l'identique ou à la demande, souvent plus chère que l'existant : sans right-sizing, engagement et familles adaptées, une migration massive ne se justifie pas ; de même, un engagement facturé 24/7 appliqué à des environnements hors production éteints la nuit et le week-end, pour lesquels le paiement à l'usage est souvent moins cher.
- Un engagement long signé sur l'hyperviseur pendant la migration, sur un parc appelé à décroître : mieux vaut négocier un an ou une extension transitoire. Sur bare metal cloud, les licences de l'hyperviseur peuvent dépasser le coût de l'infrastructure en engagement long.
- Une double exploitation qui pèse plus que la migration elle-même, sous-estimée si le refresh matériel n'est pas gelé dans les segments en migration ou si le décommissionnement glisse ; la conversion, la requalification des applications, la formation et l'outillage compatible (sauvegarde, supervision, reprise) sont souvent sous-estimés eux aussi.
- Des segments peu rentables à déplacer (petits sites amortis, infrastructures déjà payées), à présenter comme une décision de rétention ou de simplification, pas comme un gain de TCO ; leurs coûts non évitables, comme le réseau local des sites conservés, figurent à l'identique dans toutes les voies.
- Une ligne de coût annotée ou exclue sans explication dans un extrait : à clarifier avec son auteur, car elle peut inverser une rubrique.
Questions fréquentes
Combien de temps faut-il ?
En général 6 à 8 semaines pour une première décision argumentée, selon la taille du parc et la disponibilité des données, puis 3 à 4 semaines pour remplacer les benchmarks par vos factures et contrats. La durée exacte se fixe au cadrage.
Que faites-vous des crédits de migration proposés par le fournisseur ?
Ils figurent en lignes distinctes, à faire confirmer par le fournisseur, et le scénario sans crédits est toujours montré : un business case qui ne tient que grâce aux crédits n'en est pas un.
Votre moteur lit-il VMware ?
Non. Le moteur KeeFinops lit les clouds publics ; pour VMware, l'outil est le modèle de coût complet de mission, alimenté par RVTools, vos contrats et vos factures.
Comparez-vous aussi Proxmox, OpenShift Virtualization et les clouds souverains ?
Oui, comme scénarios de comparaison, sur les mêmes critères que les autres issues : licences, matériel, compétences, coût de migration, et la souveraineté peut devenir un critère éliminatoire fixé dès le cadrage. Seules une migration vers le cloud public et une solution HCI hébergée sur instances bare metal ont déjà été chiffrées en mission ; Proxmox, OpenShift Virtualization, les offres VMware hébergées et les clouds souverains n'ont pas encore de chiffrage de mission.
Votre devis VMware mérite un second avis
Trente minutes pour cadrer le périmètre, la taille du parc et l'échéance de décision.