Alliancy

[Chronique] Move-to-cloud : quelles compétences pour une équipe projet dédiée ?

Benito Diz

Notre chroniqueur Benito Diz poursuit son travail d’analyse des étapes clés du move-to-cloud, avec une 3e article qui s’intéresse à la forme que doit prendre dans une organisation l’équipe projet dédiée à cette transformation.

Dans ma précédente chronique, j’ai décrit les deux premières étapes clés du Move-to-cloud que sont la culture digitale et l’évaluation. Mais au-delà de ces bases, cette transformation ne peut se réaliser qu’en mode projet avec une équipe dédiée. Pour réussir, elle devra faire appel aux sachants de chaque métier de l’IT. C’est la 3e étape clé.

Avant toute chose, il faudra identifier un patron, un leader chargé de la stratégie et du pilotage global de la migration.

Dans cette équipe Projet, hormis les fonctions traditionnelles de pilotage, certaines nouvelles ou renouvelées ont leur importance :

La reprise en main des flux est primordiale. Par conséquent, l’installation d’un bus de données ou d’une API/Gateway favorisent la reprise en main des derniers de façon sécurisée et centralisée. L’accès aux flux repasse alors sous contrôle avec des autorisations gérées en fonction de profils prédéfinis.

Le bus de données autorise la mise en place de Web Services ou d’APIs présentant des demi-interfaces (côté client/Application et côté service). Chaque demi-interface peut alors évoluer de manière indépendante et seul un traitement au sein du bus de données devra aménager ce changement.

Une migration vers le Cloud rime aussi avec une meilleure maîtrise des coûts par une facturation (ou refacturation) à l’usage, éventuellement jusqu’à la seconde ou à l’objet traité, ou encore à l’action traitée.

Une vérification et une optimisation de cette tarification grâce aux outils proposés s’imposent de façon récurrente, jusqu’à établir la bonne adéquation entre l’infrastructure mise en place et son utilisation.

Le rôle du FinOps sera alors d’alerter les développeurs (Dev) ou la production (Ops) de la mauvaise adéquation de la configuration au regard de l’usage qui en est fait. Ce dernier devra disposer du droit de changement des configurations vis-à-vis de ces deux populations.

La pertinence de cette fonction est avérée dès le début de la migration où les architectes ont souvent pour défaut d’installer dans le Cloud des configurations identiques en puissance aux configurations sur site, ou avec des contraintes de sécurisation de la donnée ou de mise à l’échelle fournies de base dans le Cloud, alors que ces dernières sont surdimensionnées du fait de la limite imposée par les constructeurs dans l’Ancien Monde.

Au vu de la simplicité d’évolution des configurations, des duplications d’environnements complexes pour les environnements de recettes, de tests, de préproduction, de formations, ou encore pour faire des proofs of concepts (prototypages dynamiques), cette fonction devient essentielle pour décommissionner, voire détruire, ces environnements pour la plupart éphémères.

À l’instar de la cartographie des applications et des flux dans un processus de transformation dans le Cloud, l’état de fonctionnement de ces applications révèle toute son importance dans ce contexte. L’Incident Manager s’impose alors pour dresser un état des lieux précis des applications avant migration.

Cet état des lieux sera réalisé avec les équipes de la DSI et les métiers afin d’obtenir le ressenti de l’utilisateur, indispensable référent pour valider le bon fonctionnement de l’application post-migration.

La réurbanisation des infrastructures support des applications métiers nécessite obligatoirement une compétence réseau et sécurité afin de construire au mieux, dans les environnements IaaS et PaaS, un socle cohérent et viable dans l’optique d’obtenir une qualité de service de bout en bout.

Lors de cette réurbanisation, avec l’architecte Cloud, tous les nouveaux services autoporteurs de fonctions de sécurité et de réseaux devront être revus.

Cette évolution majeure nécessite des compétences pour redéfinir (et non adapter) les règles de transferts de flux, ainsi que la sécurité de ces derniers ou de l’accès aux services publiés.

À l’occasion de cette réurbanisation, l’architecte Cloud devra disposer d’une appétence à la solution Cloud choisie. Ce rôle étant primordial pour la construction des nouvelles infrastructures destinées aux applications.

La reprise en main de la donnée est l’un des piliers de la migration vers le Cloud. L’ingénieur des données (data engineer) accompagne les équipes pour choisir les solutions de traitement et de sécurisation de la donnée sur toutes les couches. Il est spécialisé sur les problématiques de croisement et de gestion des données à large échelle en utilisant des outils du Cloud et des techniques bien particulières. Il est aussi proche des métiers et capable d’utiliser les frameworks de calcul massivement parallèle pour gérer les gros volumes de données.

Le DPO (Data Protection officer) doit être impliqué à tous les stades du projet afin d’y intégrer son expertise et d’encadrer globalement la transformation pour qu’elle reste conforme à la réglementation en matière de protection des données.

A lire aussi : Move-to-cloud : quels fondamentaux pour (vraiment) réussir la transformation de l’entreprise ?

Exemple de construction d’équipe :

Fort d’une telle équipe dédiée, l’entreprise pourra ensuite se concentrer sur un autre sujet structurant, celui de l’inventaire et de la cartographie. J’y reviendrais plus en détail dans ma prochaine chronique, en janvier 2023.

Quitter la version mobile