[Chronique] Move-to-Cloud : comment penser… l’après-projet ?

Pour le dernier article de sa série consacrée au Move-to-Cloud, notre chroniqueur Benito Diz s’intéresse à la mise en œuvre de la nouvelle production informatique de l’entreprise, au financement de la migration et aux perspectives de l’après-projet.

Nous arrivons à la fin de cette série de chroniques « tour d’horizon » sur le cloud. Après l’analyse des huit premières étapes fondamentales, il nous reste à parler d’un ultime point d’attention : l’étape clé du fonctionnement de la nouvelle production, celle-ci étant évidemment plus un point de départ qu’une conclusion. L’occasion pour moi d’aborder deux autres sujets importants, à ne pas sous-estimer : la question du financement du projet de migration d’une part, et les conséquences du move-to-cloud pour « l’après-projet ».

A lire aussi : [Chronique] Move-to-cloud : au cœur de la migration

9e étape : La nouvelle production

Une fois les applications installées ou déplacées dans le Cloud, leur remise en exploitation nécessite un appel à un tiers sachant, un infogérant, pour les gérer et les superviser.

Les contrats d’infogérance doivent évoluer et être moins chers, du fait du changement des actes à réaliser (surtout dans la partie évolution du SI à venir où une grande majorité des actes consiste à cliquer sur “créer ceci”, “créer cela” ou à lancer un script…).

Avec la migration dans le Cloud, finis le suivi de puissance électrique, les achats de matériel, la gestion de contrats de maintenance de matériels, la gestion d’infrastructures du datacenter (DCIM). Si les systèmes d’exploitation, middlewares et autres bases de données sont installés en PaaS, finis aussi l’achat de licences et la gestion des contrats de maintenance logiciels. Le modèle se simplifie.

Cela étant, de nouveaux besoins apparaissent. Il est plus que nécessaire de les gérer en continu.

Dans le Cloud, les services évoluent vite, très vite. D’où la nécessité de gérer l’obsolescence des objets et de prévoir leur évolution voire leur simplification. De nouveaux services apparaissent aussi qui simplifient les infrastructures. Ceci nécessite une couche de maintien en conditions opérationnelles spécialisée dans l’évolution des services des fournisseurs de Cloud et la mise en place de mini projets agiles et urgents permettant d’intégrer les évolutions.

Comme vu précédemment, lors de la cartographie, l’Incident Manager poursuit son travail d’analyse pour alerter si l’incidentologie des applications transportées évolue et lancer et piloter les cellules de crise en cas de besoin. Cette mission au long cours vise à valider le non-impact des évolutions réalisées, dont la fréquence ne fera que s’accentuer.

Une dernière évolution, et non des moindres, concerne la fonction FinOps, qui a comme mission d’analyser les indicateurs d’utilisation et de charge des infrastructures IaaS et PaaS déployées. Son vise à redimensionner, au long court, les ressources au juste besoin, et à réaliser au passage de substantielles économies financières. Il gère aussi le parc de ressources non utilisées (environnements de développement, de recette, de formation, de préproduction…) afin de les éteindre en cas de non-utilisation. Il est le garant de l’étiquetage des objets afin d’opérer les regroupements nécessaires.

Les procédures d’exploitation et de maintien en condition de sécurité de ce nouvel environnement doivent être ajustées.

Enfin, il faut inclure le DPO dans cette étape afin qu’elle soit conforme dès son initialisation et inclure tous les éléments vus précédemment.

Comment ce projet de migration est-il financé ?

Un tel projet apporte à court terme plusieurs axes de performance économiques.

Cette performance concerne directement les objets traités lors de cette transformation, leurs utilisations futures simplifiées, ou encore les contrats de droit d’usage ou de maintenance sont alors réétudiés. Ci-dessous une liste non exhaustive de gains potentiels au regard du processus de transformation dans le Cloud :

• Lors de la cartographie des applications : La revue des applications et la (re)validation des usages de ces dernières avec le métier permettront d’en arrêter certaines et de décommissionner toutes les infrastructures support.
• Lors de la mise en place d’un outil moderne de gestion des flux : L’installation d’un outil moderne et central de gestion des flux permettra de se débarrasser de toutes les solutions et infrastructures installées au fil du temps.
• Lors de la mise en place d’une version optimum des environnements hors production : Duplication, arrêt et démarrage à la demande des infrastructures autre que production, duplications d’environnement de production deviendront des actes récurrents, simples et optimisés. Tous les développeurs se plaignent à longueur de temps des environnements non conformes à la production. Les scripts mis en place pour dupliquer, anonymiser et démarrer de nouveaux environnements éphémères permettront, là encore, des gains substantiels.
• Lors de la migration des environnements vers une solution IaaS : Historiquement, lors de l’achat du matériel, il y avait un minimum structurel (par construction ou par l’usage lié aux contrats-cadres négociés avec certaines configurations) dans la puissance de calcul proposée, dans la mémoire mise à disposition et dans l’espace disque fourni. Ces trois axes ne se gèrent plus de la même manière (avec des modélisations prédéfinies), mais selon l’usage réel. De fait, toutes les configurations sont diminuées une fois transportées dans le Cloud.
• Lors de la migration des environnements vers des solutions PaaS : La migration de certaines solutions en mode PaaS, en mode managé, permet l’arrêt des contrats de maintenance associés, nécessaires dans des versions installées « on premise» ou en mode IaaS. L’arrêt des contrats de maintenance souvent très onéreux n’est pas à confondre avec les contrats d’assistance des éditeurs, qui eux sont toujours nécessaires.
• Lors de la revue des contrats d’infogérance des applications et des environnements dans le Cloud: Une fois la transformation réalisée, certains actes d’infogérance n’existent plus ou sont simplifiés à l’extrême. L’installation d’un serveur, d’un système ou d’une base de données qui suivait un processus détaillé disparaît ou se limite à quelques clics sur le portail du fournisseur de Cloud. Autre évolution pour l’infogérant : le changement des services de supervision. La supervision dite de couches basses étant réalisée par les fournisseurs des solutions Cloud, l’infogérant dispose de base de toutes les données. Il se doit alors d’apporter une réelle valeur ajoutée, en proposant de la supervision applicative sur des points de fonctions par exemple.
• Lors de l’arrêt ou la redéfinition des contrats d’hébergement et/ou de maintenance de matériel : La transformation dans le Cloud entraîne la désertification des datacenters et l’arrêt des infrastructures. Tous les contrats associés à ces services devront être revus ou dénoncés au regard de leurs constructions et des leurs règles de gestion.
• Lors de la renégociation des contrats de tierce maintenance applicative : L’apport du Cloud apporte une simplification de gestion des environnements, ce qui simplifie l’accessibilité et la mise en place de ces derniers. Simplification donc du travail des tiers mainteneurs quant à l’accès et à la gestion des environnements. C’est pourquoi il s’avère nécessaire de revisiter les contrats liant l’entreprise à ces sociétés.
• Ultérieurement, lors de l’usage de ce nouvel outil par la DSI : Tous les processus d’intégration et d’exploitation gérés par la DSI seront simplifiés et optimisés. Une transformation primordiale devra être opérée auprès des opérationnels pour les faire évoluer vers le monde du « Software defined everything». Le nouveau travail des opérationnels passera obligatoirement par le scripting des infrastructures. Les temps de mise en place de nouvelles infrastructures seront considérablement diminués. Et le type de consommation de ces dernières évoluera également.

Tous ces gains contribueront à un retour sur investissement (ROI) rapide et à abaisser les coûts de fonctionnement de manière significative.

Et après le projet ?

Une fois le projet réalisé, l’entreprise dispose d’une infrastructure plus efficiente, plus évolutive : plus agile !

Pour utiliser pleinement ce nouvel outil industriel, il convient désormais de faire évoluer la DSI, la filière informatique et la relation avec les métiers afin que le tout soit plus agile, plus efficace. Cette évolution entraînera automatiquement une diminution des temps de livraison, des optimisations de coûts, de l’intégration, et la mise en place de livraisons ou de tests en continu…

Il ne faut pas tomber dans le biais que ferait croire que cette migration serait suffisante. En effet, certains métiers pourraient trouver que le nouveau souffle donné à leurs applications grâce au move to cloud serait suffisant et qu’il ne serait pas la peine d’aller plus loin. Ceci est une erreur à ne pas faire, il faut continuer à optimiser et à transformer l’existant pour proposer de nouveaux services qui apporteront de valeur aux métiers et s’engager sur la réduction des coûts au regard de la valeur ajoutée (que ce soient des gains sur les infrastructures virtuelles, sur l’exploitation, sur la supervision de la solution ou encore sur les ressources nécessaires à son maintien en conditions opérationnelles). Le Finops et l’incident Manager ont ici un rôle primordial à jouer.

Avec les nouveaux outils, avec de nouvelles organisations et avec des méthodologies telles que DevOps, la DSI revient au centre de la transformation de l’entreprise et évolue vers une direction concentrée sur les technologies avec pour préoccupation majeure et permanente la valeur ajoutée pour les métiers. La DSI devient un métier à part entière, promoteur et support aux autres métiers de l’entreprise.