[Chronique] Move-to-Cloud : sans cartographie, pas de salut

Notre chroniqueur Benito Diz détaille la 4e étape clé du move-to-cloud dans le cadre de sa série d’articles sur la bonne réussite d’une migration pour une DSI. Au programme : l’importance de l’inventaire et de la cartographie.

Nous sommes dorénavant entrés au cœur des questionnements des entreprises en matière de move-to-cloud. Après avoir décrit dans de précédentes chroniques, les étapes clés que sont l’acculturation digitale et l’évaluation initiale, puis la constitution de l’équipe projet appropriée, il est temps de décrypter l’importance des pratiques d’inventaires et de cartographie pour la DSI.

En effet, pour transformer un système et le faire passer d’un état initial à un état cible, mieux vaut connaître le périmètre de l’état initial. Sinon, il s’avérera complexe de mettre en place un projet de transformation, et plus encore de le maîtriser et/ou de le faire évoluer.

La cartographie doit être réalisée ou mise à jour au moment de l’inventaire. Il est primordial de maîtriser les applications concernées, les flux entrants et sortants de ces dernières avec leurs origines ou leurs destinations. Sans oublier les traitements intermédiaires de ces derniers ou leurs points de passage. Il ne s’agit pas cependant de rentrer dans le constituant des flux à cette étape.

L’inventaire des applications sera complété par les documents d’architecture de ces dernières (DAT) et les dossiers d’exploitation (DEX). Leur complétude sera traitée dans le projet de transformation.

Il faudra également lister les infrastructures utilisées par chaque module composant les applications, afin de bien identifier celles qui sont partagées, et de planifier dans le projet les arrêts de ces infrastructures.

Vient ensuite le temps d’identifier les processus automatisés et ordonnancés dans les chaînes applicatives. Ils devront être cartographiés afin d’être correctement repris dans le Cloud.

Tous les contrats d’infogérance, de maintenance, d’assistance devront être inventoriés avec une analyse de leur périmètre et des engagements qu’ils portent. Ces derniers vont évoluer ou disparaître avec le « transport » dans le Cloud. Les actes à réaliser seront simplifiés pour la plupart d’entre eux.

Classifier les actifs de l’entreprise

Une fois cette cartographie réalisée, il faudra essayer -par des ratios- de calculer le coût global de l’application, afin de le présenter au métier concerné pour valider la nécessité de cette dernière. Soit elle sera considérée comme éligible au transport, soit elle sera décommissionnée.

Durant cette phase, un Incident Manager devra réaliser un examen clinique de chaque application éligible au transport dans le Cloud afin de connaître l’incidentologie de cette dernière, le portefeuille des évolutions, les périodes d’usage critiques… Ceci permettra de bien planifier le transport et de déterminer, une fois l’application migrée, les incidents relevant de la migration ou imputables à l’application.

Cette phase de cartographie doit effectivement permettre d’établir un inventaire précis des actifs de l’entreprise et d’obtenir, le cas échéant, leur niveau de classification pour formaliser les exigences et contraintes à prendre en compte dans la cible (règles d’accès à la donnée, règles de manipulation de la donnée, règles de stockage de la donnée, règles de transport de la donnée).

L’évaluation dressera un inventaire précis des données à caractère personnel traitées et leur sensibilité afin d’adapter le niveau de sécurité associé, ainsi que toutes les règles et procédures à appliquer. Cela permettra d’établir le bon niveau d’obligations des sous-traitants.

Quelques actions de base à gérer lors de la cartographie :

Les applications

• • Revoir et mettre à jour les DAT existants si nécessaire,
  • Vérifier les dossiers d’exploitation et les revoir,
  • Faire valider la cartographie et le périmètre avec les métiers (pour ne migrer que les applications vivantes et décommissionner les autres).

Les flux

• • Identifier tous les spots intermédiaires de passage,
  • Référencer les traitements des flux,
  • Pour les transporter dans l’ESB (Enterprise Service Bus) ou la solution d’API Management (Application Programming Interface) dans le Cloud et pour arrêter les infrastructures les supportant.

Les travaux automatisés

• • Pour les transporter et les centraliser sur l’ordonnanceur dans le Cloud.

Les infrastructures supportant ces applications

• • Pour décommissionner les infrastructures non utilisées.

Les besoins métiers et techniques de sécurité

• • Pour prévoir dès la cartographie un modèle cible où chaque module de l’application qui sera migré dans le Cloud sera défini dans le mode Security by Design grâce aux nouveaux services Cloud ou au nouveau datacenter virtuel qui embarquera tous les services de base nécessaires (prochaine étape),
  • Pour détecter l’opportunité de mettre en place de nouveaux modèles comme le Zero Trust, si cela est compatible avec une évolution sans changements majeurs des fonctionnalités de l’application lors de la première étape de lift and shift.

Les contrats de licences, de maintenance, d’assistance ou d’infogérance existants

• • Pour redéfinir les périmètres, les renégocier ou les arrêter au regard de l’évolution dans le Cloud.

Dans ma prochaine chronique, nous nous intéresserons à la 5e étape clé du move-to-cloud et celle-ci sera par nature plus tournées vers la technologie. Il s’agira en effet de s’interroger sur le socle technique va supporter la transition et notamment la création d’un datacenter virtuel.