[Chronique] Move-to-cloud : quels fondamentaux pour (vraiment) réussir la transformation de l’entreprise ?

Notre chroniqueur Benito Diz introduit son premier sujet d’une série de huit articles revenant sur les fondamentaux du move-to-cloud. Il revient sur les 4 grandes méthodes de migration existantes, avant de brosser le portrait d’un processus global en 9 étapes.

Depuis la migration de grands pans applicatifs dans le Cloud en 2015, avec les équipes de Veolia, nous n’avons pas connu de pléthore de migrations globales dans le Cloud. Les équipes chargées de la pérennisation du système d’information sont frileuses du fait de la méconnaissance et d’une surmédiatisation du sujet comme un processus complexe.

A lire aussi : Une migration des Data dans le cloud gouvernée et sécurisée

Il y a cependant des entreprises qui ont migré sans mettre en place les pré-requis et qui de fait se posent la question au vu de la mauvaise évolution des coûts à revenir dans leur datacenter. C’est pour cela que le move to cloud est un projet à part entière qui ne s’arrête pas juste à la migration et qui demande des engagements fermes auprès des métiers pour garder leur confiance.

Même s’il peut parfois présenter certaines contraintes, le modèle de transition vers le Cloud n’est pas complexe. Et surtout, il apporte de la valeur aussi bien aux métiers régaliens/fondamentaux de l’entreprise qu’à la filière informatique.

Migration cloud : l’enjeu des quatre méthodes

Je vous propose dans cette série d’articles de réviser les fondamentaux d’un « move to cloud » (ou Move2Cloud) qui suit la logique appliquée chez Veolia et auprès d’autres entreprises que j’ai accompagnées pour accélérer leur transformation.

La transformation digitale doit s’accélérer. Les déploiements de boîtes à outils/méthodes agile spécifiques, qui ont répondu à la nécessité de se baser sur l’expérience de terrain et de mettre le métier au cœur du processus, doivent être généralisés et passer à l’échelle de l’entreprise.

Pour cela, il est nécessaire de s’outiller pour passer de l’agile au Dev(Sec)Ops et de mettre en place les bons logiciels jusqu’à l’intégration, la mise en production… y compris pour le développement par le test…

Si cette approche est simplifiée pour les nouveaux développements, il est cependant nécessaire d’intégrer l’outil de production informatique déjà en place (Legacy) dans cette mouvance du changement. Pour cela, il existe plusieurs stratégies de migration vers le Cloud, il est souvent proposé quatre méthodes : le « lift and shift », le replatforming, le « refactoring » / cloudification et enfin, l’évolution vers les plateformes.

Le « lift and shift » consiste à déplacer les environnements d’exécution (des souches système -P2V- ou des machines virtuelles -V2V-) dans le Cloud sans autre modification. Cette méthode a pour unique intérêt économique de vider des datacenters en les virtualisant. À ce stade, un minimum de connaissance des applications peut suffire.

D’aucuns diront que le lift and shift n’est pas l’apanage d’une migration. Cependant, elle a l’avantage d’amorcer la démarche de migration vers le Cloud, d’apporter des économies rapides et de régler les problèmes de dettes techniques (en particulier sur les hyperviseurs, voire sur les systèmes embarqués sur les machines virtuelles). Comme nous le verrons ci-après, et comme le dit l’adage, il ne faut pas confondre vitesse et précipitation : un lift and shift se prépare et ce changement doit être sécurisé. En revanche, il favorise la reprise en main du patrimoine applicatif.

Le replatforming a pour objectif de transformer les infrastructures afin de les rendre compatibles avec le monde du Cloud computing. La plateforme support des applications évolue pour être modernisée. Néanmoins, les applications n’évoluent pas. Le replatforming évoque des environnements obsolètes d’un point de vue du système, des middleware ou des bases de données. Une notion qui vaut aussi pour des environnements qui seront reconstruits dans le Cloud (tels que MVS) où un émulateur sera exécuté dans le Cloud. Il existe aujourd’hui des cadres (frameworks) pour accompagner de telles transformations (idem pour AIX ou Solaris). Il s’agit de changer d’OS tout en essayant de conserver les mêmes bases de données ou middleware. Dans ces situations, il est nécessaire de maîtriser l’urbanisation des applications et la compatibilité avec les systèmes d’exploitation support à la cible, car les applications devront être réinstallées.

A lire aussi : Amadeus fait rimer Data Mesh et migration cloud

Le replatforming peut entraîner des modifications de code applicatif ou des configurations pour connecter l’application aux nouveaux services d’infrastructure proposés dans le Cloud à travers l’appel d’API, par exemple.

La Cloudification ou « refactoring » est un processus de restructuration qui a pour but d’adapter l’application au nouvel environnement afin d’utiliser tous les avantages proposés par le Cloud. Il s’agit de transformer l’application et de l’adapter aux architectures de Cloud computing pour profiter d’atouts comme l’évolutivité (scalability), l’équilibrage de charge (load balancing), la répartition des trafics… Il ne s’agit en aucun cas de faire évoluer les fonctionnalités de l’application. Elle devient alors « Cloud Ready ». La cloudification devient une agrégation d’usage de services et d’API à travers Internet. Il est alors nécessaire de positionner la DSI dans un rôle d’intégration et de mettre en place un contrôle de bout en bout pour répondre aux engagements de performances attendus (KPI) et aux besoins des métiers.

L’évolution vers les plateformes consiste à choisir une plateforme du marché pour y transférer les données. Il ne s’agit donc pas de développement comme la cloudification. Cependant, cette plateforme devra être interconnectée au système d’information existant et nécessitera donc de l’intégration. L’évolution vers les plateformes extérieures et leurs écosystèmes devrait être la cible de tout le SI qui n’est pas cœur de métier.

Quelles étapes pour transporter le Legacy dans le Cloud, apporter de l’agilité et réduire les coûts ?

Les étapes de transformation dans le Cloud concernent toute l’entreprise et doivent être à minima structurées pour mettre en place une agilité entre le métier et l’IT. Ainsi, l’entreprise bénéficie d’une meilleure efficacité dans les actions à venir. Ces transformations offrent une opportunité pour améliorer l’efficience autour du système d’information.

Cette transformation dans le Cloud, sur la base des quatre stratégies décrites ci-dessus, incarne une première étape nécessaire à une transformation digitale de l’entreprise.

Selon certains analystes, la transition ne peut être complète, car il existera toujours une partie sur site (on premise), et seuls un mode bimodal ou une solution hybride sont possibles. Cependant, cette solution ne peut être que transitoire, elle ne doit pas laisser les DSI dans cette position de l’entre-deux, qui pérennise ce genre de legacy, hormis pour des contraintes réglementaires ou sécuritaires (ce qui n’empêche pas de gérer, y compris pour le legacy resté on premise, la dette technologique).

Vers un legacy plus agile…

Pour transporter le Legacy dans le Cloud, apporter de l’agilité, de l’efficience et des réductions de coûts… un processus global en neuf étapes est essentiel pour toute entreprise. En quelques mots, celles-ci sont : la culture digitale, l’évaluation, l’équipe projet dédiée, la cartographie, le datacenter virtuel, la réversibilité, le transport des applications, les décommissions, et la nouvelle production.

Ce transport, cette migration, permet de remettre le système d’information sous contrôle et d’envisager sereinement sa deuxième transformation vers les plateformes et le Cloud ready.

Dans ma prochaine chronique, nous détaillerons donc les deux premières étapes clés de ce processus : la transformation culturelle autour du digital et l’évaluation des grandes empreintes technologiques de l’entreprise.