Presque toutes les migrations cloud démarrent avec un slide qui annonce « 30 % d'économies ». Dix-huit mois plus tard, la direction financière regarde une facture cloud supérieure au coût de l'ancien datacenter et personne n'arrive à expliquer où le business case a dérapé. Le problème vient rarement du cloud lui-même : il vient du modèle. Un calcul de TCO et de ROI crédible n'est pas un exercice de tableur réalisé une fois pour débloquer un budget, c'est un artefact d'ingénierie que l'on versionne, que l'on challenge et que l'on remesure.
Pourquoi la plupart des business cases cloud sont faux
Trois erreurs systématiques reviennent lorsqu'on audite un dossier de migration :
- Une baseline on-premise incomplète. On compte l'amortissement du matériel, mais pas la surface au sol, l'énergie, le temps de l'équipe stockage, le site de secours utilisé à 5 % ou les régularisations de licences.
- Une cible cloud chiffrée en lift-and-shift iso-périmètre. On dimensionne les VM cloud sur les specs crête de serveurs physiques achetés il y a cinq ans, puis on s'étonne du résultat. Évidemment : on paie au tarif à la demande une machine taillée pour le pic de 2019.
- Des coûts de migration traités comme une variable d'ajustement. Équipes projet, double run, transfert de données, remédiation applicative, formation et baisse de productivité pendant la bascule peuvent dominer la première année.
Une quatrième erreur, plus subtile : ne compter que des coûts. Une migration à coût constant qui fait passer le lead time de six semaines à deux jours a un ROI énorme — il n'apparaît simplement pas sur la ligne infrastructure.
Construire une baseline on-premise défendable
La baseline doit couvrir un cycle économique complet, typiquement cinq ans, car c'est l'horizon de renouvellement du matériel que l'on évite. Plus court, cela flatte le statu quo. À inclure :
| Catégorie | Ce qu'il faut compter | Oubli fréquent |
|---|---|---|
| Matériel compute & stockage | Amortissement, contrats de maintenance, capacité de réserve | Le sur-provisionnement (souvent 50 à 70 % d'inutilisé) |
| Datacenter | Baies, énergie, climatisation, sécurité physique | Refacturations internes qui masquent le coût réel |
| Réseau | Liens WAN, load balancers, firewalls, MPLS | Liens qui disparaissent après migration |
| Licences | Hyperviseur, OS, bases de données, sauvegarde, supervision | Licences au socket dont le modèle change en cloud |
| Ressources humaines | Exploitation, patching, incidents matériels, capacity planning | Temps perdu par les équipes applicatives à attendre un environnement |
| Risque & continuité | Site de secours, assurance, coût d'indisponibilité | Le coût d'une heure d'interruption, chiffré |
Le chiffre pour lequel il faut se battre, c'est le taux d'utilisation réel. Extrayez-le de vCenter, de Prometheus ou de l'API de l'hyperviseur sur au moins 90 jours : p95 CPU et mémoire par workload, pas des moyennes. Ce jeu de données conditionne à la fois la crédibilité de la baseline et le rightsizing de la cible.
Modéliser le coût cible dans le cloud
Modélisez la cible sous forme de scénarios, pas d'un chiffre unique. Au minimum : rehost à l'identique, rehost avec rightsizing et engagements, replatform (bases managées, conteneurs, serverless là où c'est pertinent). Présentez les trois : c'est la comparaison qui rend la recommandation crédible.
Les lignes régulièrement oubliées côté cloud :
- Egress et trafic inter-AZ. Des microservices bavards répartis sur plusieurs zones génèrent un coût récurrent bien réel. Les acteurs européens souverains ont souvent des conditions d'egress plus favorables que les hyperscalers : à modéliser explicitement si vous comparez OVHcloud ou Scaleway à AWS ou Azure.
- L'observabilité. L'ingestion de logs et de métriques facturée au Go peut devenir l'un des premiers postes d'une plateforme verbeuse. Budgétez-la dès le départ.
- Sauvegardes, snapshots et réplication cross-région. Peu cher au Go, cher à l'échelle de la rétention.
- Le support, généralement un pourcentage de la dépense.
- La prime du managé. Un PostgreSQL managé coûte plus cher qu'une VM avec PostgreSQL — et remplace une partie de la charge d'un DBA. Modélisez les deux côtés de l'arbitrage.
- Les environnements hors production. C'est là que l'élasticité paie le plus : modélisez l'extinction planifiée et comptez l'économie.
Côté économies, soyez explicite sur les leviers que vous vous engagez réellement à actionner : rightsizing sur p95 mesuré, Savings Plans ou instances réservées sur le socle stable, Spot pour le batch et la CI, tiering de stockage, extinction du hors-production en dehors des heures ouvrées. Un business case qui suppose des engagements sans nommer le responsable de leur achat relève de la fiction.
Les coûts de migration : la colonne que personne n'aime
Ce sont eux qui rendent la première année négative et qui donnent du sens au délai de retour sur investissement :
- Discovery et cartographie des dépendances
- Effort de remédiation et de refactoring applicatif, par vague
- Double run : les deux environnements vivants, parfois plusieurs mois
- Transfert et réplication initiale des données
- Construction de la landing zone : réseau, IAM, IaC, CI/CD, observabilité
- Formation, certifications, prestations externes
- Décommissionnement, sortie d'actifs — et coût contractuel de sortie des baux ou contrats d'hébergement
Ce dernier point est décisif. S'il reste trois ans de contrat datacenter non résiliable, les économies ne commencent pas à la migration mais à la fin du contrat. Modélisez-le honnêtement : la migration peut rester justifiée sur des critères d'agilité.
Du TCO au ROI : l'arithmétique qui convainc une DAF
Le TCO est une comparaison de coûts. Le ROI est une décision d'investissement. La finance attendra une valeur actuelle nette, un taux de rentabilité interne et un délai de récupération, avec actualisation des flux au coût du capital de l'entreprise.
# Chiffres purement illustratifs — à remplacer par les vôtres
TAUX_ACTUALISATION = 0.08
# Année 0 = investissement migration, années 1-5 = bénéfice net annuel
# (coût on-prem évité - coût de run cloud - contrats résiduels)
flux = [-1_800_000, 250_000, 620_000, 760_000, 790_000, 810_000]
def van(taux, flux):
return sum(cf / (1 + taux) ** t for t, cf in enumerate(flux))
def tri(flux, bas=-0.9, haut=3.0):
for _ in range(200):
milieu = (bas + haut) / 2
if van(milieu, flux) > 0:
bas = milieu
else:
haut = milieu
return (bas + haut) / 2
def payback(flux):
cumul = 0.0
for annee, cf in enumerate(flux):
precedent = cumul
cumul += cf
if precedent < 0 <= cumul:
return annee - 1 + abs(precedent) / cf
return None
print(f"VAN : {van(TAUX_ACTUALISATION, flux):,.0f}")
print(f"TRI : {tri(flux):.1%}")
print(f"Payback : {payback(flux):.1f} ans")
Exécutez ce calcul comme une analyse de sensibilité, pas comme une estimation ponctuelle. Faites varier trois paramètres : le rightsizing réellement capté (quelle part de l'économie théorique vous obtenez vraiment), la croissance des workloads et le glissement du projet. Si la VAN reste positive avec la moitié du rightsizing et six mois de retard, votre dossier est robuste. Si elle ne tient que dans le scénario optimiste, vous avez un argumentaire commercial.
La valeur que personne ne met dans le tableur
Le coût d'infrastructure est la partie la moins intéressante d'un business case cloud. Les composantes qui dominent généralement la VAN sont plus difficiles à quantifier mais bien réelles :
- Le time to market. Un provisionnement d'environnement qui passe de semaines à minutes : mesurez-le avec le lead time DORA avant/après.
- Le capex évité et le risque de capacité. Plus d'achat pour un pic qui n'arrivera peut-être jamais.
- La disponibilité. Multi-AZ et bascule automatisée face à un PRA mono-site jamais testé de bout en bout.
- Le recentrage des équipes. Des heures réaffectées du firmware vers le produit.
- La conformité. Pour des données régulées ou sensibles, un fournisseur européen ou qualifié SecNumCloud peut supprimer une charge d'audit entière — ou, à l'inverse, ajouter des contraintes à chiffrer.
Quantifiez ces éléments de façon conservatrice et écrivez l'hypothèse en clair à côté du chiffre. Une DAF acceptera « nous supposons que 20 % des 3 ETP affectés à la maintenance matérielle sont redéployés » bien plus facilement qu'un multiplicateur de productivité non justifié.
Mesurer le ROI après la migration
Un business case que personne ne vérifie ne vaut rien. Mettez en place dès la première vague :
- Une politique de tagging et de showback appliquée dans l'IaC — application, environnement, centre de coût, propriétaire. Une ressource non taguée doit faire échouer le pipeline, pas générer un mail trimestriel.
- Une métrique d'unit economics — coût par commande, par client, par 1000 appels d'API. La dépense absolue croît avec l'activité ; seul le coût unitaire est un signal d'efficacité honnête.
- Une revue d'écart trimestrielle entre le réalisé et le modèle, avec explication écrite des différences.
- La couverture et l'utilisation des engagements suivies comme un KPI avec un responsable nommé.
En pratique, l'écart entre économies modélisées et économies réelles vient presque toujours des mêmes endroits : rightsizing jamais exécuté après le lift-and-shift, hors-production laissé allumé 24/7, volumes et snapshots orphelins, ingestion de logs non budgétée. Les quatre sont détectables en un mois après la bascule si la plateforme est correctement instrumentée.
Une approche pragmatique
Construisez le modèle en trois passes. Une estimation d'ordre de grandeur en deux semaines pour décider si la question mérite d'être posée. Un modèle détaillé par vague une fois les données de discovery disponibles, avec scénarios et sensibilité. Puis un modèle vivant, mis à jour chaque trimestre avec la consommation réelle, qui devient votre référentiel FinOps plutôt qu'un document archivé après le comité.
Le livrable qui compte n'est pas le pourcentage d'économies. C'est un modèle dont les hypothèses sont explicites, testables et portées par quelqu'un — un modèle qui vous dira, six mois plus tard, si vous êtes dans la trajectoire et quel levier actionner si ce n'est pas le cas.