Construire son Business case de migration cloud

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

L’externalisation de certaines fonctions (sauvegardes, load balancing, outils SaaS…) permet de libérer une charge pour les équipes tout en continuant de proposer des services à haute valeur ajoutée pour leurs clients. Cela implique une veille permanente pour suivre, et intégrer les fréquentes évolutions des offres des fournisseurs cloud.

• Self-service pour adapter sa consommation de ressources

A tout moment, la possibilité de choisir ou de modifier les paramètres techniques permet d’ajuster au mieux les ressources affectées aux projets. Les besoins en stockage peuvent également être optimisés en adaptant la classe du stockage des données.

• Pay as you go pour adapter sa facturation

Les fournisseurs de services cloud s’accordent généralement sur une facturation à l’usage avec une tarification dégressive selon les volumes ou les durées. En suivant l’usage, c’est une meilleure maîtrise des coûts et de l’utilisation des ressources qui est en jeu.

• L’élasticité pour gérer les fluctuations

Lorsque la périodicité (ou la saisonnalité parfois) de l’activité justifie une fluctuation plus ou moins importante des besoins en ressources, il est plus facile de demander plus de puissance que de devoir investir dans du matériel supplémentaire.

Cela peut dans un premier temps, nécessiter des ajustements sur les architectures techniques et applicatives, mais le retrait dynamique de ressources temporairement inutiles est une source d’économies à envisager.

Le projet de transformation n’a pas nécessairement pour objectif de mettre en place toutes ces optimisations, mais de déployer les dispositifs de contrôles et d’améliorations continues qui pourront les permettre. Les revues et mises à jour périodiques des consommations en ressources d’infrastructure orientent les décisions stratégiques à prendre concernant le plan capacitaire et les variations à anticiper.

Il y aura toujours des modernisations d’applications et actualisations des infrastructures. Dans un cloud optimisé, nous gagnons en souplesse et ces opérations deviennent plus faciles à réaliser, même avec une fréquence plus élevée. C’est par cette souplesse, qu’il faut envisager les premiers bénéfices du cloud. Ensuite avec la maturité, l’automatisation permettra de débloquer la DSI en l’allégeant partiellement d’une charge opérationnelle (RUN & BUILD) et lui permettre de consacrer plus de temps pour des sujets axés sur le THINK et le développement d’offres de services favorables à l’innovation.

Quel meilleur moyen d’innover que d’expérimenter ? Les acteurs « pure-players » du cloud proposent la possibilité de réaliser des PoC en mode « bac à sable » sans coûts additionnels.

Article rédigé par Reda Benbelaid & Hugues Marlin