Entre les risques à anticiper, les délais serrés et la maîtrise financière d’une migration cloud, généralement stratégique pour l’entreprise, chaque étape du projet doit être orchestrée avec précision pour faire face aux nombreux défis techniques et enjeux de sécurité.
Cet article a pour but de présenter une méthodologie structurée, reproductible et pragmatique, afin de garantir une migration réussie.
Au démarrage d’un projet, il est primordial de bien cadrer le besoin et de comprendre les enjeux associés à une migration cloud. Cette phase de planification est la clé de voûte du projet et déterminera inévitablement son succès ou son échec.
En démarrant cette étape par la « Découverte » (Discovery en anglais), ou encore « Evaluation » (Assessment) de l’infrastructure actuelle, on pourra mieux définir :
Cette phase permettra également de déterminer le niveau d’accompagnement externe nécessaire sur les migrations et post-migrations, si des formations aux utilisateurs ou exploitants sont à prévoir.
Les responsables métiers des applications migrées doivent être acteurs du projet pour que leurs besoins soient correctement pris en compte dans la planification.
Bien identifier et inventorier l’ensemble des applications, les différents assets, les contraintes et spécificités techniques de chaque métier, leurs dépendances. Tous ces éléments doivent être détaillés au maximum, afin de limiter les oublis et les impacts durant la migration et sur la nouvelle plateforme en production.
Le chef de projet doit s’assurer lors de cette phase que :
On peut notamment s’appuyer sur le diagramme de Gantt pour définir et suivre ses jalons, et utiliser des solutions de gestion documentaire centralisées telles que Confluence d’Atlassian ou SharePoint de Microsoft.
Lire aussi : Quelle stratégie migration cloud choisir ? L’exemple des 7R
Une fois la planification réalisée et le projet bien cadré, il est nécessaire d’organiser méthodiquement la nouvelle infrastructure et les équipes qui œuvreront.
De quels éléments aurons-nous besoin pour traiter les tâches définies en amont ? D’architectes cloud / réseaux, de responsables métier, d’un RSSI ou de son représentant, de développeurs / ingénieurs. Les rôles de chacun doivent être clairement définis pour éviter les zones d’ombre ou les doublons.
Une gouvernance de la nouvelle plateforme doit être mise en place et connue, partagée à chaque acteur.
L’établissement d’une Landing Zone (littéralement, zone d’atterrissage) permet d’établir un cadre d’adoption du cloud, elle définira notamment :
On peut évoquer les services cloud comme AWS IAM/Identity Center (ou juste IAM chez Google) et Azure Active Directory pour gérer les identités, rôles et droits d’accès aux ressources, notamment via l’utilisation de RBAC (Role Base Access Control).
Les outils collaboratifs tels que Teams de Microsoft, Slack de Salesforce ou Zoom permettront aux différents acteurs de communiquer régulièrement et efficacement sur les avancées de chacun.
Ça y est, les actions sont lancées, l’infrastructure cible est en cours d’édification et les premiers lots de migration démarrent. On privilégiera des premières migrations d’application moins critiques et/ou hors production, afin de s’assurer que les performances et fonctionnalités des environnements cibles soient bien celles attendues, et de corriger, d’améliorer l’infrastructure au fil des étapes.
Le chef de projet doit maintenir une communication constante de l’avancée du projet et s’assurer que les problèmes et risques rencontrés soient traités et maîtrisés. Les indicateurs de performance (KPI) permettront de suivre régulièrement et efficacement l’évolution du projet, les coûts, les incidents rencontrés, le taux ou le nombre d’assets migrés et surtout le respect du planning.
On peut utiliser des outils comme PowerBI ou Grafana pour générer des Dashboards ou rapports, et ainsi visualiser les données associées à l’avancée du projet de façon personnalisée et interactive.
Penser à consulter les anciens comptes rendus d’incident dans l’ITSM de l’entreprise et à détailler synthétiquement les problèmes rencontrés pour capitaliser sur les échecs et les succès.
Pour standardiser et automatiser au maximum les différents déploiements qui constitueront l’infrastructure cible, on recommande l’utilisation de pipelines Azure, GitLab (CI/CD), Jenkins, Ansible et autres outils DevOps. Ils permettront de contrôler de manière efficace l’intégration et le développement des nouvelles applications et éléments d’infrastructure.
Ce qui peut faire la différence entre une bascule réussie et un retour arrière lors de la migration, c’est la quantité et la qualité des tests réalisés en amont. En effet, plus l’environnement cible aura fait l’objet de tests de performance et de montées en charge, moins il y aura de risques que les performances soient différentes de celles attendues, une fois les charges de travail migrées.
Les tests permettront également de s’assurer que l’ensemble des éléments de l’infrastructure cible communiquent correctement entre eux, notamment en termes de flux et de droits d’accès. On s’assurera également que les standards de sécurité définis soient respectés concernant les applications et les données migrées.
Les responsables métiers devraient également être consultés dans le cadre des tests, pour s’assurer que les données et fonctionnalités cibles restent inchangées, avec des performances qui seront supérieures ou à minima équivalentes à l’infrastructure source. Les équipes métiers pourront ainsi remonter toute anomie et permettre d’éventuels ajustements de l’infrastructure, avant de prévoir la mise en production finale.
Il est fortement recommandé d’établir une stratégie de tests de validation, afin que les rapports de tests soient consultables par l’ensemble des parties prenantes.
Des applications Web telles que LoadRunner ou Apache JMeter peuvent s’avérer très efficaces pour réaliser des tests de montées en charge et évaluer l’infrastructure cible. Pour détecter les éventuelles vulnérabilités et auditer la nouvelle plateforme, on privilégiera l’utilisation de solutions de sécurité complètes comme Intruder, Orqa, Nessus ou Qualys.
L’ensemble des tests prévus ont été réalisés, les performances cibles sont bien celles attendues. Il est temps de prévoir la bascule finale (du lot).
Afin de minimiser les interruptions de service (s’il y en a), le chef de projet doit établir des chronogrammes estimatifs au plus juste de la réalité (basés sur les tests effectués en amont). Ils permettront d’estimer les durées totales d’intervention, et devront également inclure les actions du plan de retour arrière, si cela devait s’avérer nécessaire.
Un plan détaillé de ce retour arrière devra être défini et au mieux testé avant la mise en production.
Idéalement, le transfert des compétences aura été réalisé avant la bascule finale, pour que les équipes métiers et d’exploitation aient été formées à travailler sur la nouvelle plateforme.
On privilégiera également de configurer au mieux les outils de supervision, afin d’assurer une surveillance optimale de l’infrastructure avant et après migration.
Cette supervision (à l’aide d’outils comme CloudWatch, Prometheus, Grafana, Zabbix…) permettra également de recueillir des données d’utilisation et des métriques de performance qui seront bien utiles pour valider l’efficience de la migration avec les métiers.
Une fois la migration terminée, il est difficile, mais nécessaire, de rester concentré sur la bonne clôture du projet. Les actions finales permettront une transition douce et efficace vers les équipes de production et métier, qui utiliseront et gèreront la nouvelle infrastructure, tout en poursuivant son amélioration continue.
Dans un objectif d’évaluation, on appréciera l’élaboration d’un bilan du projet, qui reprendra succinctement les différentes étapes passées et mentionnera les difficultés rencontrées, les succès ainsi que les pistes d’amélioration pour les prochaines migrations.
L’organisation d’une session de retour d’expérience avec les différentes parties prenantes permettra de recueillir la satisfaction des parties prenantes, de consolider, d’améliorer les bonnes pratiques à tenir par la suite et d’alimenter ce bilan.
On s’assurera que l’ensemble des documents liés au projet aient bien été centralisés et sauvegardés, afin d’en conserver les enseignements, d’en assurer le support de la solution et des processus associés.
Une migration vers le cloud est une transformation organisationnelle et stratégique qui peut s’avérer être un défi majeur pour les entreprises. Bien sûr, aucun projet ne se ressemble, car il existe autant d’environnements et de solutions cloud que d’applications. Cependant, en adoptant une gestion de projet structurée et méthodique et en alignant IT et métiers, il est possible d’assurer la réussite de son projet de migration et de tirer pleinement parti des opportunités offertes par le cloud dans une économie où la réactivité et l’innovation technologique font la différence.