Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
La planification et la gouvernance appropriées sont essentielles à la modernisation. Dans cette étape, vous décidez quelle approche de modernisation appliquer et comment procéder. La planification réfléchie réduit le risque de dépassements de budget, de dépassement de portée ou d’interruptions de service pendant l’exécution.
Choisir une stratégie de modernisation
La modernisation d’une charge de travail signifie la mettre à jour pour mieux s’aligner sur les objectifs métier actuels, les normes techniques et les fonctionnalités cloud. Les trois principales stratégies (replatform, refactor et rearchitect) s'inscrivent dans un continuum de complexité et de valeur. La plupart des efforts de modernisation utilisent une combinaison de ces approches.
La clé est de faire correspondre la stratégie aux besoins spécifiques de chaque composant, compte tenu de vos objectifs, chronologie et ressources disponibles. Évitez la tentation de sur-moderniser. Bien que les nouvelles technologies soient passionnantes, chaque décision devrait être fondée sur la valeur commerciale.
| Stratégie de modernisation | Definition | Quand utiliser | Pros | Cons |
|---|---|---|---|---|
| Changement de plateforme | Déplacez des applications vers des plateformes cloud avec des modifications de code minimales (IaaS vers PaaS). | Des gains rapides avec un minimum de perturbations nécessaires. Le code actuel fonctionne, mais la charge des opérations est élevée. | Implémentation rapide. Réduit les efforts de maintenance. Améliore la fiabilité grâce à une meilleure infrastructure. | Gains de capacité limités. L’application principale reste inchangée. |
| Refactor | Modifiez le code existant pour améliorer la structure, les performances et l’optimisation du cloud tout en conservant les fonctionnalités. | La dette technique provoque des problèmes ou du code n’est pas optimisé pour le cloud. | Améliore la maintenance, les performances et la sécurité. Facilite les améliorations futures. | Nécessite des efforts et des tests importants pour les développeurs. Aucune nouvelle fonctionnalité immédiate pour les utilisateurs. |
| Rearchitect | Redéfinissez l’architecture d’application à l’aide de modèles natifs cloud (microservices, serverless, pilotés par les événements). | L’architecture actuelle limite la croissance ou l’optimisation du cloud. | Résout les problèmes fondamentaux de scalabilité. Active les services cloud avancés. Définit les bases de l’innovation à long terme. | Le plus complexe et le plus long. Coût initial et risque élevé. Nécessite des tests étendus et des opérations parallèles. |
Planifier les modernisations en phases
Essayer de moderniser une charge de travail complexe entière (ou plusieurs) en une seule opération est risquée. Décomposez l’effort en phases logiques. Le phasing vous permet de fournir une valeur incrémentielle, de réduire les risques en s’attaquant à des segments gérables et d’ajuster le cours entre les phases en fonction de ce que vous apprenez.
Divisez les modernisations en phases logiques. Déterminez comment diviser le travail. Il n’y a pas de « bonne façon » unique. Choisissez la répartition qui est logique pour votre architecture et votre structure d’équipe. L’objectif est que chaque phase est assez petite pour exécuter et tester sans complexité écrasante, mais suffisamment significative pour fournir de la valeur. Méthodes courantes pour décomposer les phases :
Méthode de division Description Example Par composant ou couche Phases distinctes en fonction des couches de charge de travail ou des limites de charge de travail Phase 1 : Migration de base de données, phase 2 : refactorisation des applications, phase 3 : modernisation de l’interface utilisateur Par priorité et complexité Organiser le travail de faible risque aux changements à haut risque Phase 1 : Services non critiques, phase 2 : logique métier principale, phase 3 : fonctionnalités orientées client Par fonction métier Phases de structure autour des limites d’application ou fonctionnelles Phase 1 : Charge de travail de la gestion des utilisateurs, Phase 2 : Traitement des paiements, Phase 3 : Services de génération de rapports Commencez par des changements à faible risque et à valeur élevée. Pour votre phase 1, choisissez quelque chose qui est réalisable et fournit une victoire tangible, mais ne met pas en danger l’entreprise si des problèmes surviennent. Par exemple, moderniser un service principal ou un outil interne au lieu du site web accessible par le client. Visez à effectuer rapidement la première phase (un mois ou deux) comme point de preuve. Le succès précoce renforce la confiance de l’équipe et le soutien des parties prenantes pour les phases suivantes.
Phases restantes de séquence par valeur et dépendances. Après la première phase, planifiez l’ordre des phases suivantes en fonction de la valeur métier et des dépendances techniques. Créez une feuille de route où chaque phase a une étendue définie et garantit que les composants critiques ont leurs éléments de prise en charge déjà modernisés ou compatibles.
- Traiter les zones sensibles. Si une charge de travail est fragile dans son état actuel, vous devrez peut-être même avoir besoin d'une « phase 0 » préliminaire pour la stabiliser en place (appliquer des correctifs urgents dans l'ancien environnement) afin qu'elle puisse être modernisée en toute sécurité lors de la phase 1.
- Tout d’abord, répondez aux prérequis : Si la modernisation de la charge de travail B dépend de la charge de travail A en cours de modernisation (ou au moins stable), faites d’abord la charge de travail A.
- Considérez la valeur métier et le risque : Vous pouvez décider d’alterner, d’effectuer une pièce à valeur élevée mais plus risquée en une phase, puis d’un élément à risque plus faible dans le prochain, pour équilibrer la charge sur l’équipe et le risque pour l’entreprise.
Définissez les critères de réussite pour chaque phase. Pour chaque phase, décidez quand elle est terminée et réussie. La définition de critères de sortie clairs permet d'éviter l'élargissement incontrôlé du périmètre d'une phase. Les critères de réussite peuvent inclure :
Type de critères de réussite Examples Objectifs techniques • Service X s’exécute sur Azure App Service et gère 20% plus de charge
• La base de données Y migre vers Azure SQL avec zéro perte de données et performances dans les 10% de la base de référence précédentePortes de qualité • Aucun bogue de sévérité 1 ouvert
• Tous les tests automatisés réussissent
• L’analyse de sécurité affiche des vulnérabilités critiques nullesContraintes de minutage et de budget • Terminer dans les trois mois et dans les 5% du budget
• Déployer pendant les fenêtres de maintenance planifiéeAdapter les plans en fonction des résultats. Après avoir terminé une phase, passez en revue les résultats et les leçons apprises. Vous pouvez constater que certaines hypothèses étaient désactivées ou que certaines tâches étaient plus faciles ou plus difficiles que prévu. Ajustez le plan pour les phases à venir en conséquence, telles que l’ajout, la combinaison ou la réorientation des phases. L’approche par phases est destinée à être flexible. Ce qui est important n’est pas d’essayer de tout faire en même temps.
Plan de gouvernance de la modernisation
La modernisation introduit souvent des modifications importantes apportées aux charges de travail critiques, il est donc nécessaire de disposer d’une gouvernance forte pour gérer les risques. La gouvernance de la modernisation implique des processus de gestion des changements, des gels et un contrôle de l’étendue :
Établissez un flux de travail d’approbation de modification formel. Définissez un processus d’approbation structuré pour toutes les modifications liées à la modernisation. Intégrez-vous à des conseils consultatifs sur les changements existants (CAB) ou créez un conseil d’examen de modernisation dédié. Attribuez une autorité d’approbation en fonction de la catégorie de modification et documentez le flux de travail complet dans votre plan de projet. Pour plus d’informations, consultez Gérer les modifications.
Verrouiller les modifications si nécessaire. Juste avant et pendant les événements de déploiement majeurs, suspendez d'autres modifications apportées à ces charges de travail. Un gel des modifications signifie qu’aucune autre modification non liée n’est apportée à ces charges de travail dans le prospect et pendant le déploiement. Il stabilise l’environnement de sorte que vous n’atteignez pas une cible mobile. Communiquez la fenêtre de gel à toutes les équipes pertinentes.
Évitez l'élargissement d'étendue (scope creep). Le glissement de portée est un défi majeur dans les projets de modernisation. Exiger toute modification proposée de l’étendue de modernisation acceptée pour passer par une étape d’évaluation et d’approbation. La plupart des demandes doivent être différées, sauf si elles sont cruciales. Formulez un « non, pas maintenant » face aux demandes de travail supplémentaires à l'aide d'un processus structuré. Maintenez un backlog d’idées agréables à avoir qui se présentent, ce qui peut alimenter un projet d’innovation futur une fois la modernisation actuelle terminée. Les parties prenantes devraient savoir que leur idée n’est pas perdue.
Définir votre stratégie de déploiement
Une décision d’exécution cruciale consiste à déployer les composants modernisés en production. Il existe deux stratégies principales. Dans un déploiement sur place, vous mettez à niveau l’installation existante (comme la rénovation d’une maison pendant que vous y habitez). Dans un déploiement parallèle, vous créez une nouvelle configuration en même temps (comme construire une nouvelle maison, puis vous déplacer). Choisissez la stratégie qui correspond au niveau de modification et de tolérance aux risques pour chaque phase ou charge de travail. Souvent, chaque phase de modernisation peut utiliser une stratégie différente. Par exemple, vous pouvez choisir sur place pour la phase 1 (s’il s’agit d’une modification mineure) et parallèle pour la phase 2 (si celle-ci implique une révision majeure de la base de données).
Utilisez le déploiement sur place pour les changements réversibles et à faible risque. Le déploiement sur place introduit des modifications directement dans l’environnement de production actuel, peut-être pendant une fenêtre de maintenance. Cette stratégie réduit la surcharge de l’infrastructure, mais augmente le risque de temps d’arrêt. Utilisez le déploiement sur place uniquement lorsque les modifications sont petites, isolées et facilement réversibles. Les exemples incluent des mises à jour de code mineures ou des modifications de schéma qui peuvent être restaurées rapidement à l’aide du contrôle de code source ou des sauvegardes.
Utilisez le déploiement parallèle pour les modifications complexes ou à haut risque. Dans ce modèle, vous configurez un nouvel environnement pour la charge de travail modernisée alors que l’ancienne charge de travail s’exécute toujours. Les données sont synchronisées (par le biais de processus de réplication ou de migration) afin que, lorsqu’elles sont prêtes, vous pouvez passer de l’ancien au nouvel environnement. Utiliser pour les changements complexes ou à haut risque où les temps d’arrêt doivent être minimes. Si vous effectuez une migration majeure de base de données ou une réarchitecture qui implique une nouvelle infrastructure, le mode parallèle est généralement recommandé. En outre, si la charge de travail est critique de mission et ne peut tolérer plus de quelques minutes de temps d’arrêt, il est nécessaire d'utiliser un système parallèle (avec réplication et transition rapide).
Strategy Description Quand utiliser Pros Cons Déploiement sur place Déployer des modifications directement dans l’environnement de production actuel Petites modifications réversibles avec des fenêtres de maintenance acceptables Aucune infrastructure en double, déploiement plus rapide Risque plus élevé, nécessite une interruption, un retour en arrière plus lent Déploiement parallèle Exécuter un nouvel environnement en même temps que la charge de travail existante pendant la transition Modifications complexes, charges de travail critiques nécessitant un temps d’arrêt minimal Déploiement plus sûr, temps d’arrêt quasi nul, secours immédiat Coûts d’infrastructure en double, synchronisation de données complexes, effort de désactivation
Planifier l’atténuation des risques de modernisation
Même avec la meilleure planification et le test, tous les changements ne vont pas parfaitement. La modernisation implique souvent des modifications complexes, et il existe toujours un risque qu’un déploiement puisse introduire un problème, ou quelque chose se comporte de façon inattendue en production. Une équipe bien préparée se distingue par un plan de retour en arrière solide pour chaque changement ou phase.
Utilisez des techniques de déploiement progressif. Si la plateforme le permet, effectuez des mises en production progressives (mises en production avec contrôle de validité) ou un transfert graduel du trafic vers les parties modernisées de l'application. Par exemple, déployez la nouvelle version en même temps que l’ancienne et envoyez initialement seulement 5% d’utilisateurs lors de la surveillance. Cette approche peut intercepter les problèmes alors que la plupart des utilisateurs ne sont pas affectés. Si les métriques semblent bonnes, augmentez à 50%, puis 100%. En cas d'échec, revenez rapidement à 0 % de nouveau code (rollback).
Créez des procédures de rollback pour chaque modification majeure. Pour chaque changement ou livrable majeur, rédigez une procédure de retour en arrière étape par étape. Répertoriez clairement chaque action pour annuler la modification, qui est responsable de chaque étape et combien de temps cela prendra. Après la restauration, indiquez les vérifications qui permettent de confirmer que tout est revenu à la normale.
Automatisez les rétrogradations lorsque c'est possible. Les scripts de restauration automatisée ou l’infrastructure en tant que code peuvent rendre la récupération rapide et fiable. Utilisez des outils d’infrastructure en tant que code (Terraform, modèle ARM, Bicep) pour redéployer les états corrects connus. Les déploiements bleu-vert ou canary autorisent intrinsèquement le « basculement » vers la version précédente si nécessaire. Testez ces mécanismes en phase de préproduction. L’objectif est de convertir l'effort manuel, réalisé à 3 heures du matin lors d'un incident, en une action automatisée par script. Écrivez les étapes de rollback en même temps que les étapes de déploiement, afin qu’il soit facile d’effectuer un rollback.
Avoir un support disponible pendant et après le déploiement. Planifiez les déploiements pendant les périodes à faible trafic (week-ends ou nuit) si possible, mais assurez-vous que les experts pertinents sont disponibles. Ne le faites pas quand les membres clés de l’équipe sont en vacances. Disposez d’une période de support étendue (hypercare) juste après le déploiement avec les développeurs et les opérations en veille pour détecter les problèmes au début. Pour les mises en service importantes, certaines organisations mettent en place un système de surveillance de type « salle de crise » pendant 24 à 48 heures après la mise en service.
Sécuriser l’approbation des parties prenantes
Jusqu’à ce stade, nous nous sommes concentrés sur la planification technique. Il est tout aussi important d'obtenir l'adhésion des parties prenantes, tant de la direction commerciale que de la direction technique. La modernisation nécessite souvent un investissement important, de sorte que vous devez présenter un cas convaincant et maintenir les parties prenantes engagées tout au long du processus.
Adaptez la proposition de valeur à chaque public. Différentes parties prenantes s’intéressent aux différents résultats. Personnalisez votre messagerie :
- Les équipes techniques hiérarchisent l’efficacité opérationnelle : maintenance réduite, temps de fonctionnement amélioré et moins d’escalades.
- Les chefs d’entreprise se concentrent sur les résultats : délai de commercialisation plus rapide, expérience client améliorée et économies de coûts.
Documentez un plan structuré avec des jalons. Les parties prenantes sont plus à l’aise s’ils voient une feuille de route claire. Présentez les phases que vous avez planifiées, comme indiqué précédemment, et ce que chacun doit réaliser, avec une chronologie approximative. Mettez l’accent sur les premières victoires, telles que « Dans les 6 semaines, nous voulons moderniser le composant X et améliorer ses performances d’ici 20%».
Quantifier la valeur de modernisation. Préparez des métriques avant et après et des améliorations cibles. Voici quelques exemples de métriques et de plages d’améliorations classiques (basées sur les benchmarks du secteur) :
Category Exemples de métriques Plage de valeurs classique Réduction des coûts Infrastructure, maintenance, licences d'exploitation Économies annuelles de 20 à 40% Gains de productivité Fréquence de déploiement, temps de résolution Amélioration de 50 à 80% Atténuation des risques Temps d’arrêt évité, incidents de sécurité Évitement de coûts entre 100 000 $ et plus de 1 million $ Revenue Délai de commercialisation plus rapide, rétention des clients 10-25% accélération des revenus Résolvez les risques liés au projet. Identifiez les défis potentiels et démontrez la préparation grâce à des stratégies d’atténuation spécifiques. Les risques courants incluent la réplication des données, la dégradation des performances et les problèmes d’intégration. Présentez des solutions telles que des procédures de restauration automatisées, des protocoles de test complets et une disponibilité de consultation d’experts. La discussion transparente sur les risques renforce la confiance des parties prenantes en matière de leadership de projet et de planification.
Maintenir une cadence de communication régulière. Signalez la progression par rapport aux critères de réussite définis, mettez en évidence les livrables terminés et communiquez les jalons à venir. Demandez activement des commentaires et répondez aux préoccupations pour maintenir le soutien tout au long du processus de modernisation.