Le devis d'une migration cloud chiffre le travail du prestataire. Il chiffre rarement le reste : la période où l'ancien et le nouvel environnement tournent ensemble, le temps de vos équipes pendant les vagues de bascule, les licences à revoir, les contrats du datacenter qui ne s'arrêtent pas le jour où la dernière application part. C'est ce reste qui fait dériver les budgets, parce que personne ne l'a inscrit nulle part.
Cet article dresse la liste de ce que coûte vraiment un basculement vers le cloud, et répond à la question que l'on pose trop tard : qui porte chacun de ces coûts.
Ce qui fait le prix d'une migration
Le coût d'une migration dépend du nombre d'applications et de leur couplage bien plus que de la taille de l'infrastructure. Cent serveurs qui hébergent des applications indépendantes se migrent plus facilement que vingt serveurs qui partagent une base de données, des flux de fichiers et des tâches planifiées que plus personne ne documente.
La trajectoire choisie pour chaque application pèse ensuite. Le rehébergement à l'identique est la voie la plus rapide, et la moins chère à exécuter. La replateforme, qui passe la base ou le stockage sur des services managés, demande plus de travail mais supprime une part de l'exploitation. Le refactoring coûte le plus, et ne se justifie que pour les applications qui ont encore une longue vie devant elles. Une migration cloud bien préparée chiffre ces trajectoires application par application, pas en bloc.
Les six postes qui n'apparaissent pas dans le devis
La double exploitation. Une bascule progressive fait tourner la source et la cible en parallèle, le temps de déplacer le trafic par étapes et de garder un retour arrière possible. C'est la bonne méthode, et elle a un prix : pendant des semaines, vous payez les deux. Ce coût doit être budgété, pas découvert.
Le temps de vos équipes. Même confiée à un prestataire, une migration mobilise vos développeurs et vos responsables d'application : inventaire des dépendances, tests de recette, validation de chaque vague. Pendant ce temps, les évolutions des applications concernées sont gelées. C'est souvent le poste le plus lourd, et le seul que personne ne facture.
Les licences. Certaines licences logicielles ne se transfèrent pas dans le cloud aux mêmes conditions, d'autres changent de modèle. Le sujet se règle avant la bascule, avec les contrats sous les yeux, et non à la première facture.
Le transfert des données. Les volumes à déplacer, les liaisons réseau temporaires, les services de réplication pendant la transition : ce poste se mesure avant, pas après.
La sortie du datacenter. Location des baies, contrats de maintenance du matériel, liaisons opérateur : ces engagements ont des préavis. Une migration qui se termine en avance sur des contrats qui courent encore coûte deux fois. Le calendrier de bascule doit être construit avec le calendrier des résiliations.
La facture d'après. Un rehébergement à l'identique coûte souvent plus cher que le datacenter d'origine. Les économies viennent ensuite, quand le dimensionnement est ajusté, que les environnements hors production s'éteignent la nuit et que les services managés remplacent des machines maintenues à la main. Tant que ce travail n'est pas fait, la facture cloud reste au-dessus du budget, ce que nous détaillons dans la question du budget cloud au sixième mois.
Qui porte quoi
La question n'est pas seulement de savoir combien, mais qui paie et qui assume le risque.
Le prestataire porte le travail chiffré : l'audit, la trajectoire, les fondations cloud, l'exécution des bascules. Exigez que son devis distingue ces étapes, et qu'il dise ce qui est au forfait et ce qui est en régie.
Le fournisseur cloud peut porter une partie de l'effort. Le programme AWS MAP, par exemple, prend en charge une part de l'évaluation et de la bascule depuis un datacenter ; d'autres fournisseurs ont des dispositifs comparables. Ces financements se préparent en amont : ils couvrent une partie du coût, jamais la totalité, et ils supposent un périmètre et un calendrier engagés.
Votre direction informatique porte la double exploitation, le temps des équipes et la décision de bascule. Ce sont des coûts internes, et c'est pour cela qu'ils disparaissent des tableaux.
Votre direction financière porte la sortie du datacenter et le changement de nature de la dépense : un investissement amorti devient une consommation mensuelle qui bouge. Elle doit le savoir avant le premier mois, pas le découvrir au troisième.
Les métiers portent le gel des évolutions pendant les vagues. Ils doivent l'avoir accepté avant le lancement.
Un dernier rôle ne se partage pas : un responsable unique de la migration, qui tient les trajectoires, l'ordre des vagues, le plan de données et les critères de bascule. Sans lui, chaque équipe migre à sa façon, et le coût des incohérences s'ajoute à tous les autres.
- Partir d'un inventaire réel, applications, dépendances et contrats compris, plutôt que d'une liste de serveurs.
- Chiffrer une trajectoire par application, et le coût d'exploitation cible dans le cloud à côté du coût actuel.
- Inscrire la double exploitation sur la durée prévue des vagues, avec une marge.
- Valoriser le temps interne, même s'il n'est pas facturé : c'est lui qui décale le calendrier.
- Aligner bascules et résiliations, pour ne pas payer un datacenter vide.
- Prévoir l'optimisation des coûts dès le premier mois après la bascule, comme une étape de la migration et non comme un projet ultérieur.
Par où commencer
Un audit cloud gratuit pose l'inventaire et la première estimation des trajectoires. Pour un parc encore hébergé sur site, notre page dédiée à la migration d'un datacenter vers le cloud décrit la méthode. Et si la question est ce que coûtera l'exploitation une fois la bascule faite, la page sur le coût de l'infogérance détaille les modes de facturation.