Le ROI Cloud ne se résume pas à comparer une ancienne facture d’hébergement avec une facture Azure. Une migration peut réduire certains coûts, en déplacer d’autres, et créer de la valeur par la résilience, l’automatisation, la vitesse de livraison ou la capacité à absorber les pics.
Pour une direction informatique, la bonne question n’est donc pas “le Cloud est-il moins cher ?”. La question utile est : dans quel scénario le TCO Cloud devient-il maîtrisable, mesurable et relié à des gains métier concrets ?
Cet article propose une méthode pragmatique pour construire un business case Cloud avant migration, sans confondre économies théoriques, coûts de projet et bénéfices réellement pilotables.
ROI Cloud et TCO Cloud : deux métriques différentes
Le TCO Cloud mesure le coût complet d’un scénario sur une période donnée. Il inclut les dépenses techniques visibles, mais aussi le run, la sécurité, la supervision, la sauvegarde, le support, les licences, le réseau, le temps d’exploitation et les coûts de transition.
Le ROI Cloud mesure le retour sur investissement :
ROI = (gains cumulés - coûts de migration - coûts de run cible) / coûts engagés
Un TCO comparé peut montrer qu’un scénario Cloud coûte plus cher en euros directs, tout en restant pertinent si la migration réduit le risque d’indisponibilité, accélère les déploiements, évite un renouvellement matériel ou améliore la sécurité. À l’inverse, un scénario affiché comme économique peut devenir défavorable si l’observabilité, les sauvegardes, les environnements de test ou le trafic sortant sont sous-estimés.
Définir le périmètre du TCO actuel
Le premier travail consiste à établir le coût complet du socle existant. Sans cette base, le business case Cloud repose sur une comparaison biaisée.
Le TCO actuel doit couvrir :
- l’infrastructure : serveurs, stockage, virtualisation, réseau, sauvegarde, licences ;
- l’hébergement : énergie, locaux, infogérance, support, supervision ;
- les coûts humains : administration, astreinte, mises à jour, incidents, capacité ;
- les coûts de continuité : PRA, PCA, tests de reprise, restauration ;
- la dette technique : obsolescence, fin de support, dépendances difficiles à maintenir ;
- les coûts d’opportunité : délais de livraison, environnements indisponibles, faible automatisation.
Ce cadrage oblige à distinguer les coûts réellement évités après migration des coûts qui restent dans l’organisation. Une licence applicative, une équipe de run ou une exigence de sécurité ne disparaît pas parce que l’application change d’hébergement.
Construire le TCO Cloud cible
Le TCO Cloud cible ne doit pas être une simple estimation de calcul et de stockage. Il doit représenter un modèle d’exploitation complet.
Pour une trajectoire Azure, le chiffrage doit inclure :
- les ressources : compute, stockage, bases de données, réseau, sauvegarde, sécurité ;
- les services managés : supervision, journalisation, secrets, identité, politiques ;
- la connectivité : interconnexion, VPN, ExpressRoute si nécessaire, flux sortants ;
- les environnements : développement, test, préproduction, production ;
- les engagements éventuels : réservations, plans d’économies, licences réutilisables ;
- les coûts de run : supervision, patching, incidents, capacity planning, revues de sécurité ;
- les outils de pilotage : tags, budgets, alertes, tableaux de bord, allocation des coûts.
Un TCO Cloud fiable doit aussi modéliser plusieurs scénarios : migration minimale, modernisation partielle, adoption de services managés, ou plateforme Kubernetes lorsque le besoin de standardisation le justifie. Le scénario le plus ambitieux n’est pas toujours celui qui produit le meilleur ROI.
Les coûts de migration à ne pas oublier
Le coût du projet est souvent sous-estimé parce qu’il est traité comme un effort ponctuel. Dans un calcul de ROI Cloud, il doit être explicite.
À intégrer dans le business case :
- audit applicatif et cartographie des dépendances ;
- conception de la landing zone et des garde-fous ;
- Infrastructure as Code, CI/CD, secrets, supervision et sauvegarde ;
- tests de performance, sécurité, réversibilité et restauration ;
- conduite du changement, documentation et transfert de compétences ;
- double run temporaire entre l’ancien et le nouveau socle ;
- remédiation après migration : droits, logs, coûts, alertes, durcissement.
Le double run est particulièrement important : pendant quelques semaines ou quelques mois, l’organisation peut payer l’ancien environnement et le nouveau. Si cette période n’est pas pilotée, elle dégrade vite le ROI réel.
Traduire les gains en indicateurs mesurables
Un ROI Cloud solide ne s’appuie pas uniquement sur des promesses d’économies. Il relie les coûts à des indicateurs suivis après migration.
| Axe | Indicateur possible | Valeur recherchée |
|---|---|---|
| Coût | coût mensuel par application ou par environnement | meilleure allocation et dérives détectées plus tôt |
| Delivery | délai de création d’un environnement | moins d’attente pour les équipes produit |
| Run | temps moyen de résolution d’incident | diagnostic plus rapide avec logs, métriques et alertes utiles |
| Résilience | temps de restauration testé | reprise vérifiable, pas seulement documentée |
| Sécurité | taux de ressources conformes aux politiques | réduction des écarts et preuves plus simples |
| Gouvernance | part des coûts non taggés | responsabilisation des équipes et lecture financière fiable |
Ces indicateurs transforment le ROI Cloud en outil de pilotage. Ils évitent de déclarer la migration “réussie” le jour de la bascule alors que le vrai résultat se joue dans les mois de run.
Exemple de calcul simplifié
Prenons un exemple volontairement simple sur 36 mois.
| Élément | Scénario existant | Scénario Cloud cible |
|---|---|---|
| Infrastructure et hébergement | 420 000 € | 300 000 € |
| Exploitation et support | 240 000 € | 210 000 € |
| Sécurité, sauvegarde, supervision | 90 000 € | 120 000 € |
| Coûts de migration | 0 € | 130 000 € |
| Total 36 mois | 750 000 € | 760 000 € |
Dans ce scénario, le TCO direct ne montre pas d’économie. La migration peut pourtant rester justifiée si elle évite un renouvellement matériel, réduit les interruptions, accélère les mises en production ou permet de moderniser des applications critiques.
Le ROI devient positif seulement si ces gains sont chiffrés et suivis. Par exemple :
- réduction du risque d’indisponibilité mesurée par incidents évités ;
- baisse du temps passé sur l’administration récurrente ;
- création d’environnements en heures plutôt qu’en semaines ;
- réduction des retards projet liés à la capacité infrastructure ;
- meilleure visibilité des coûts par application et par responsable.
Sans ce travail, le business case Cloud se résume à une comparaison de factures. C’est rarement suffisant pour décider.
Méthode Doveaia : Cadrage -> Build -> Run
La méthode la plus robuste consiste à séparer décision, construction et exploitation.
1. Cadrage
Le cadrage établit le périmètre : applications candidates, dépendances, contraintes réglementaires, criticité, coûts actuels, niveau de service attendu et capacité des équipes.
À ce stade, Doveaia recommande de produire trois livrables :
- une cartographie applicative exploitable ;
- un TCO comparé par scénario ;
- une matrice de décision entre migration minimale, modernisation progressive et refonte ciblée.
2. Build
Le build transforme le scénario retenu en socle opérationnel : landing zone, réseau, identité, politiques, Infrastructure as Code, pipelines, observabilité, sauvegarde, sécurité et premiers workloads.
Le ROI se protège pendant cette phase. Chaque choix d’architecture doit être relié à une hypothèse du business case : réduire le run, améliorer la résilience, accélérer le delivery, maîtriser les coûts ou diminuer un risque.
3. Run
Le run vérifie si le ROI attendu devient réel. Les budgets, alertes, tags, tableaux de bord, revues d’incidents et revues d’architecture doivent être en place dès les premiers mois.
La gouvernance FinOps est essentielle : allocation des coûts, prévision, analyse des usages, optimisation continue et indicateurs unitaires. Sans cette discipline, le TCO Cloud dérive alors même que la migration technique est terminée.
Points de vigilance fréquents
Plusieurs erreurs reviennent dans les business cases Cloud :
- comparer un environnement actuel sous-documenté avec une cible idéalisée ;
- oublier les coûts de réseau, de logs, de sauvegarde ou de support ;
- supposer que les équipes auront immédiatement les compétences nécessaires ;
- mélanger ROI de migration et ROI de modernisation applicative ;
- compter deux fois les gains liés à l’automatisation ;
- ignorer la période de double run ;
- ne pas définir de propriétaire pour les coûts après migration.
Le ROI Cloud doit rester un document vivant. Il doit être revu après les premières bascules, puis ajusté avec les données réelles d’exploitation.
Maillage utile pour approfondir
Si votre priorité est de choisir le bon modèle de destination, commencez par notre guide Migration cloud Azure : VM, Container Apps ou AKS. Si la question porte sur la supervision et la qualité du run, lisez aussi Supervision cloud avec Azure Monitor.
Pour les organisations qui envisagent une plateforme conteneurisée, notre article Kubernetes pour l’entreprise aide à décider quand Kubernetes sert réellement la trajectoire. Vous pouvez aussi consulter notre catalogue d’offres pour cadrer un accompagnement Cloud, DevOps ou IA.
Sources utiles
- Microsoft Azure Pricing Calculator : https://azure.microsoft.com/en-us/pricing/calculator/
- Microsoft Cloud Adoption Framework, Strategy : https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/strategy/
- FinOps Framework : https://www.finops.org/framework/
- FinOps Allocation capability : https://www.finops.org/framework/capabilities/allocation/
- FinOps Forecasting capability : https://www.finops.org/framework/capabilities/forecasting/
- FinOps Unit Economics capability : https://www.finops.org/framework/capabilities/unit-economics/
Conclusion
Calculer le ROI Cloud, c’est relier une trajectoire technique à des coûts complets, des risques, des gains opérationnels et des indicateurs suivis après migration.
Un bon business case Cloud ne cherche pas à prouver que le Cloud est toujours moins cher. Il montre dans quelles conditions le TCO Cloud devient maîtrisable, comment la migration Azure sera opérée, et quels signaux permettront à la direction informatique de décider puis de piloter.