Pourquoi la priorisation des applications est la base d'une migration réussie
La tentation est grande de migrer en parallèle ou de commencer par l'application la plus complexe, mais c'est l'inverse qui minimise les risques et accélère le projet. Une mauvaise priorisation crée des blocages en cascade (vous ne pouvez pas migrer l'application B tant que A n'est pas stabilisée sur AWS), perd du temps sur des pré-requis non identifiés, et expose vos applications critiques à des aléas documentés trop tard. Une bonne priorisation, au contraire, déverrouille les vagues successives à faible risque et construit la confiance de vos équipes à chaque étape. Chez les scale-ups et ETI qui ont confié ce travail à Stralya, cette phase de classement représente souvent la différence entre un déploiement qui traîne sur six mois (avec des crises non prévues) et un qui tenait ses jalons trimestriels. L'enjeu n'est pas de prédire l'avenir avec certitude, mais d'identifier maintenant les trois ou quatre critères qui vont vraiment compter : l'impact métier si l'app tombe, la complexité de la migration, les dépendances qui vous bloqueront si vous oubliez l'ordre. Commencer par là évite les faux départs et positionne le reste du projet sur un fondement solide.
Les trois critères essentiels pour classer vos applications
Pour construire une matrice de priorisation que vos équipes comprendront et accepteront, vous devez évaluer chaque application selon trois dimensions qui interagissent constamment.
Le premier critère est l'impact métier. Vous devez répondre honnêtement : combien de chiffre d'affaires ou de processus critiques dépendent de cette application ? Une application de back-office utilisée deux fois par mois par trois personnes n'a pas le même poids qu'un service interne qui gère les commandes en temps réel. Cet impact se mesure en trois éléments imbriqués : les utilisateurs directs touchés (combien et à quelle fréquence), les services en aval qui en dépendent (c'est-à-dire, si elle tombe, qu'est-ce d'autre qui s'arrête cascadement), et le coût métier d'une interruption d'une heure (vous pouvez parfois le trouver dans une analyse de risque existante, sinon, demandez à l'unité métier qui la gère). Les applications dites « critiques » (impact fort) ne sont généralement que 10 à 20 % de votre portefeuille informatique, mais elles concentrent 80 % de votre risque de migration.
Le second critère est la complexité technique. Certaines applications sont faciles à migrer (une application stateless, sans base de données complexe, déployée sur quelques serveurs identiques), d'autres sont des cauchemars d'interdépendances, de configurations sur mesure, de librairies obsolètes ou de données volumineuses. Pour chaque application, posez-vous : quels types d'infrastructure utilise-t-elle (serveurs, bases de données, systèmes de fichiers, services externes) ? Ces infras sont-elles standardisées ou très personnalisées ? Quel volume de données doit migrer, et à quelle fréquence change-t-il ? Avez-vous la documentation complète ou allez-vous devoir réingéniérer en chemin ? Plus une application est complexe, plus elle doit être tentée tard dans le projet, quand vos équipes ont déjà une expérience AWS et que vous avez affiné vos processus.
Le troisième critère est les dépendances entre applications. Si l'application B ne peut pas fonctionner sans que l'application A soit déjà opérationnelle (ou au moins accessible depuis le cloud), alors A doit être migrée avant B. Vous découvrirez souvent des dépendances que personne n'avait explicitement documentées : l'app B appelle une API de l'app A toutes les dix minutes, ou l'app C a besoin que l'app A soit en place pour tirer des données de synchronisation chaque nuit. Ces dépendances deviennent les contraintes de sequençage de vos vagues de migration. Ignorer cette dimension vous garantit que votre deuxième vague restera bloquée sur une dépendance non migrée, qui elle-même a des pré-requis non satisfaits.
Construire la matrice de priorisation en quatre étapes pratiques
Construire cette matrice n'exige pas de mois d'analyse. Voici comment faire en quelques semaines, avec vos propres équipes et sans consultant coûteux.
Étape 1 : dresser l'inventaire complet de vos applications. Listez chaque système qui tourne sur votre infrastructure actuelle (on-premises ou ancien cloud), en séparant clairement les applications métier, les outils internes (GitLab, Jira, bases de données de données), les middlewares (files d'attente, services d'authentification), et les services externalisés qui ne vont pas migrer. Vous devriez arriver à 30 à 150 éléments selon votre taille. Pour chacun, notez : le propriétaire métier ou technique, l'environnement actuel (serveurs, technologie, version), l'étape du cycle de vie (en production depuis combien de temps, prévu de fin de vie quand). Cet inventaire est votre vérité source pour toute la migration.
Étape 2 : évaluer l'impact métier. Vous organisez une session avec les propriétaires métier de chaque application (ou leurs représentants). Vous posez trois questions simples pour chacune : (1) Combien de personnes l'utilisent et à quelle fréquence ? (2) Si elle tombe, en combien de temps l'activité métier subit un préjudice sérieux (une heure, un jour, une semaine) ? (3) Estimez le coût métier d'un arrêt d'une heure (revenu perdu, clients fâchés, conformité menacée, etc.). Sur la base de ces réponses, vous placez chaque application dans une catégorie d'impact : critique (doit toujours être disponible), haute (arrêt d'une heure a des conséquences graves), moyenne (arrêt d'un jour acceptable) ou basse (peut être arrêtée quelques jours). Cette catégorisation prend généralement deux ou trois jours pour l'ensemble du portefeuille.
Étape 3 : évaluer la complexité technique. Vous travaillez avec votre équipe d'infrastructure et vos architectes. Pour chaque application, vous documentez : type d'infra (nombre de serveurs, base de données, stockage, outils spécialisés), taille des données (quelques Go ou pétaoctets), dépendances techniques (librairies, OS, autres systèmes internes), matérialité de la documentation (vous avez une spec complète ou vous la bricolez au départ à l'autre). Sur la base de cet audit technique, vous classez chaque application en basse, moyenne ou haute complexité. Une application Linux standard avec une base PostgreSQL est basse complexité. Une application mainframe avec 50 Go de données et une configuration propriétaire est haute complexité. Compter trois à cinq jours pour cet exercice.
Étape 4 : identifier les dépendances critiques. Vous menez une revue architecturale courte : pour chaque application, « quels autres systèmes doivent être en place ou accessibles pour que celle-ci fonctionne ? » Vous découvrirez une partie des réponses en examinant les logs (qui appelle qui), une autre en posant des questions directes aux équipes de développement. Notez ces dépendances dans un graphe simple (app A dépend de app B et C, app B dépend de app D, etc.). Cette revue prend généralement une semaine, car elle révèle souvent des dépendances inattendues qui doivent être validées.
Une fois ces quatre étapes accomplies, vous avez tous les ingrédients pour remplir une simple matrice de calcul (un tableau dans un classeur ou un outil collaboratif) : en lignes, toutes vos applications, en colonnes, les trois critères et les dépendances, et vous pouvez enfin séquencer vos vagues.
L'ordre de migration recommandé : vagues logiques et d'apprentissage
Avec vos trois critères en main, voici la logique que Stralya recommande pour ordonner vos migrations, testé sur des dizaines de projets.
Vague 1 (Validation et apprentissage) : Commencez par une ou deux applications de basse criticité et basse complexité. Ces applications servent de test grandeur réelle : vous découvrirez comment votre déploiement AWS fonctionne, quels outils et scripts vous avez réellement besoin, quel est le temps réel de cutover et de stabilisation, et vous formerez vos équipes sur les pièges. Ces applications ont peu d'impact métier si quelque chose tourne mal, donc l'apprentissage ne vous coûte rien. Elles doivent aussi être relativement indépendantes (peu ou pas de dépendances amont). La durée de cette vague est souvent un à trois mois. Beaucoup d'équipes qui ont sauté cette vague l'ont regretté tard, quand elles ont découvert des hypothèses fausses sur AWS à grande échelle.
Vague 2 (Complexité progressive) : Migrez ensuite des applications de basse à moyenne criticité mais de complexité croissante. Ce n'est plus de l'apprentissage pur, mais vous bénéficiez toujours de la tolérance à l'erreur que vous donne le faible impact métier. Vous pouvez vous permettre des rollbacks, des corrections en place, du debugging en productif. Vous affinez vos runbooks et vos scripts. C'est ici aussi que vous commencez à migrer les applications qui ont des dépendances simples (c'est-à-dire, dont les dépendances ont déjà été migrées en vague 1). Cette vague dure généralement deux à quatre mois.
Vague 3 (Applications critiques) : Seulement quand vous êtes confiants dans votre processus et que vous avez stabilisé AWS, migrez les applications de haute criticité. À ce stade, votre équipe a vu les pièges, les dépendances subtiles ont été identifiées, et votre infrastructure AWS est déjà bien comprise. Le risque est mitigé par l'apprentissage accumulé. Parce que ces applications sont critiques, vous mettez en place plus de monitoring, de rollback plans, de tests de charge. Une application critique ne peut pas tomber en apprentissage, mais elle peut être migrée avec confiance après que vous avez déjà migré les non-critiques. Cette vague dure deux à quatre mois.
Vague 4 (Queue et exotique) : Les dernières applications à migrer sont celles qui ont une haute complexité avec un impact métier moyen ou bas, ou celles dont les dépendances amont sont nombreuses. Vous les attendez jusqu'à la fin parce que, soit elles sont techniquement subtiles (vous avez eu le temps d'assembler l'expertise), soit elles dépendent de trop d'autres systèmes (qui sont enfin en place). Cette vague peut durer un à trois mois et est souvent moins stressante, puisque 80 % de votre infra est déjà stable.
Attention à une tentation courante : tenter de faire toutes les vagues en parallèle pour « aller plus vite ». Cela crée un chaos de dépendances mal résolues, d'apprentissages zéro, et d'équipes surchargées qui font des erreurs. Une séquence disciplinée de quatre ou cinq vagues dure réellement moins longtemps (et expose moins de risque) qu'une tentative de tout faire ensemble.
Pièges courants et comment les éviter
Trois erreurs reviennent régulièrement dans les priorisations mal pensées, et elles peuvent coûter cher.
Premier piège : ignorer les dépendances cachées. Une équipe pense pouvoir migrer l'application A en vague 2, mais découvre trop tard que l'application A appelle une API interne d'une application D qui n'était pas documentée, et que D était supposée migrer en vague 4. Subitement, l'équipe ne peut pas finir la vague 2. Pour éviter cela, forcez-vous à valider les dépendances découvertes avec les équipes qui les connaissent, et ajoutez une couche de vérification technique (inspectez les logs de production, tracez les appels réseau, auditez les fichiers de configuration). Une dépendance trouvée et reclassée en trois jours vaut mieux qu'une dépendance découverte en urgence pendant le cutover.
Deuxième piège : surestimer l'impact métier d'une application parce qu'elle est vieille ou semble importante. Une base de données de « données maîtres » héritée peut sembler critique, mais en vérité n'est consultée qu'une fois par semaine dans des rapports. Vous mettrez trois mois à la migrer parce que vous pensiez qu'elle était critique, alors qu'une bonne revue aurait montré qu'elle pouvait attendre. Pour éviter cela, insistez pour que l'évaluation d'impact métier soit faite par les propriétaires métier eux-mêmes, pas par le service informatique qui suppute. Une feuille de calcul partagée où chaque unité métier remplit ses trois questions d'impact crée une responsabilité et révèle les avis divergents (que vous pouvez alors résoudre en atelier).
Troisième piège : modifier la priorisation au cours du projet pour des raisons court-termistes. « L'app X n'avait pas l'air urgente, mais le directeur a changé d'avis, on la fait maintenant. » Cela introduit du chaos de dépendances (vous aviez prévu que l'app X dépendait de l'app Y, vous changez d'ordre, maintenant Y ne sera prête que dans deux mois). Établissez une priorisation ferme au démarrage, documentez les hypothèses derrière chaque choix, et réservez les reclassifications pour une revue formelle tous les trois mois, fondée sur des faits (« l'impact métier était mal estimé ») plutôt que sur l'humeur du moment. Une priorisation stable et explicitée obtient l'adhésion des équipes bien mieux qu'une qui change chaque semaine.
Valider et documenter votre priorisation avant de commencer
Une fois que vous avez construit votre matrice de priorisation et défini vos quatre vagues, ne lancez pas vos migrations immédiatement. Vous avez besoin de trois étapes de validation courtes.
Premièrement, présentez la priorisation à un comité de gouvernance (DSI, responsables métier clés, CTO). Ce comité ne revise pas chaque ligne, mais valide que les grands principes sont respectés : les applications critiques sont bien en vague 3, pas en vague 1, les dépendances les plus sensibles sont bien resolved avant leur consommateur, et les apprentissages de la vague 1 vont bien servir la vague 2. Cette revue met au jour les désaccords non résolus (un responsable métier peut contester que son application est classée moyenne alors qu'il estime qu'elle est critique) : mieux les résoudre en une heure de réunion que de découvrir le problème pendant la migration. Budgétez une réunion d'une à deux heures, et une ronde de commentaires écrite.
Deuxièmement, menez un test de dépendances rapide. Prenez les deux applications que vous minez en vague 1. Inspectez réellement leurs logs sur une semaine, listez chaque dépendance sortante (appels API, accès à la base de données partagée, etc.), et validez auprès des équipes que vous n'avez rien oublié. Ce test prend un jour ou deux mais élimine souvent les surprises qui coûtent une semaine de projet plus tard.
Troisièmement, documentez votre priorisation dans un document simple et partagé : titre, contexte métier, les trois critères d'évaluation, la matrice résultante, les quatre vagues avec leurs justifications, et les hypothèses clés (« nous supposons que la bande passante réseau sera suffisante », « nous comptons sur l'équipe de la base de données pour valider les migrations de data »). Ce document sert de contrat avec les autres équipes, et permet à quiconque se demande « pourquoi l'app X n'est pas en vague 1 ? » de trouver une réponse documentée plutôt qu'une opinion. Il prend deux à trois jours à rédiger, mais il vaut bien dix réunions d'explication ultérieures.
Une fois ces trois étapes complétées, vous avez un plan de priorisation solide, accepté par le leadership et compris par vos équipes. C'est maintenant que vous pouvez brancher le reste du projet (phases de migration, planification détaillée, allocation des ressources) sur cette fondation stable.