Construire son Business case de migration cloud
Publié le 20/05/2019
Article rédigé par Reda Benbelaid & Hugues Marlin
Vecteur d’agilité et de flexibilité dans la gestion des ressources IT, le cloud séduit de plus en plus avec une offre qui se diversifie et permet une réponse à quasiment tous les besoins IT. La preuve, le marché des solutions de cloud computing en entreprise est en croissance de près de 25% en France en 2018. Fort d’un contexte de transformation digitale, les DSI des entreprises sont amenées à changer leurs modes de fonctionnement au profit de solutions plus souples. Les solutions telles que les services à la demande du cloud sont une réponse à cet objectif. Néanmoins migrer vers un cloud externe - même partiellement, est une décision qui doit faire l’objet d’une réflexion amont, prenant en compte l’état de l’existant et les enjeux stratégiques de l’entreprise.
Dans cet article, nous allons aborder tous les points à étudier : éléments clés, outils et points d’attention pour mener à bien un projet de transition cloud ainsi que les leviers d’optimisations technologiques sur lesquels se reposer.
Etape 1 - Du TCO au Business case
La genèse d’un projet cloud se compose des coûts de l’existant pour la constitution d’une baseline (ou référentiel). Parmi les grandes familles de coûts, doivent être distingués : les infrastructures (coûts des équipements et logiciels, notamment pour les serveurs, le stockage, et le réseau...), les outils nécessaires à leur gestion et maintien en condition opérationnelle, les coûts de main d’œuvre (internes ou assistance externe), et enfin l’ensemble des coûts de pilotage liés à la gouvernance du SI. En ce qui concerne les coûts de main d’œuvre, nous conseillons de suivre principalement les domaines d’administration des serveurs, des infrastructures virtualisées, du stockage, du réseau et des fonctions support. A moyen terme, il est délicat de prévoir des baisses de charges sur ces fonctions une fois dans le cloud si l’automatisation n’est pas pleinement maîtrisée. En matière d’infrastructure, l’identification d’un périmètre applicatif et des assets qui y sont rattachés permettent une première estimation du coût total de possession actuel et celle de sa projection dans le cloud d’arrivée. Dès la phase de cadrage, établir un inventaire de tous les services non-éligibles à la transformation cloud permet de déterminer ce que l’on ne peut inclure dans les projets de migration. Certaines applications doivent ainsi rester en local pour des raisons de contraintes légales, ou pour des besoins d’audits propres à la législation d’un pays. Certains services difficilement automatisables ou non compatibles avec l’offre des fournisseurs seront non éligibles à la transformation cloud (systèmes, infrastructures, et applications legacy…) Des éléments jusqu’alors présents dans le référentiel n’apparaissent plus directement dans le business case cloud, comme par exemple : les mises à niveau et remplacement de matériel ou certaines licences que les fournisseurs cloud incluent dans les souscriptions de service. Cependant, d’autres viennent s’ajouter au cloud : connexion réseau ou achat de licences spécifiques. Les fournisseurs cloud facturent également les flux de données vers l’extérieur, vers des sauvegardes ou entre les régions. Techniquement il est difficile d’évaluer le coût de ces transferts qu’il faudra estimer. Attention, ils peuvent représenter jusqu’à un quart de la facture totale des infrastructures cloud.Etape 2 : La transformation
Une fois l’estimation financière du Business case, il est important de se projeter et de quantifier les coûts des étapes de transformation. A commencer par les besoins en formation et en accompagnement du changement pour les équipes administrant ou utilisant le cloud, et ce en fonction des compétences déjà en place. Cet accompagnement est crucial, il permet de s’assurer de la connaissance et du bon usage de ces nouveaux services cloud par les partie prenantes (personnes en charge du développement et des infrastructures principalement). Il conduit ces parties prenantes à mieux collaborer aux changements de fonctionnement et de distribution des responsabilités que le projet implique (par exemple : devops, test as a service, self-service, paiement à l’usage pour les équipes de dev). Le projet de migration nécessite souvent l’acquisition et l’intégration de nouveaux outils comme par exemple des outils de discovery, de cloud Platform Management, d’automatisation, de packaging et de déploiement. Ces coûts doivent être valorisés et être inclus dans le modèle. Enfin, la transformation doit être aussi considérée d’un point de vue applicatif. Parfois, pour limiter l’effort de transformation des applications, les DSI tendent à les migrer en l’état. Pourtant, un projet de transformation cloud nécessite souvent des évolutions des plateformes applicatives ou de la chaîne d’intégration afin de profiter des fonctionnalités du cloud ou de s’adapter aux solutions des fournisseurs. Il est donc important de fixer le périmètre de la transformation dès la phase de cadrage. Mais également de quantifier l’effort de transformation en identifiant les besoins de refontes applicatives. Cela aura un impact sur le dispositif projet à déployer et sur les interlocuteurs à embarquer sur le projet.Aller plus loin : L’optimisation financière
La finalité d’une migration cloud ne doit pas être celle de réaliser une migration à l’identique vers un acteur tiers. Ce serait passer à côté de l’intérêt majeur d’une migration : la réalisation de synergies sur les plans technologiques et économiques. Dès la genèse du projet, il est important d’établir une architecture cible offrant des services standardisés. Les acteurs majeurs du marché proposent un ensemble d’outils et d’accompagnement pour l’élaboration d’un plan de migration et la définition de l’infrastructure cible. Voici quelques leviers d’optimisation souvent conseillés :- La connaissance des offres de services des fournisseurs
- Self-service pour adapter sa consommation de ressources
- Pay as you go pour adapter sa facturation
- L’élasticité pour gérer les fluctuations