Pourquoi une matrice de sélection 6R plutôt que des décisions au cas par cas
La plupart des migrations cloud débutent par un défi : choisir la bonne stratégie 6R pour chaque application parmi un portefeuille souvent composé de dizaines ou de centaines d'applications hétérogènes. Sans cadre structuré, ces décisions s'éternisent en comités de pilotage, chacun brandissant des argumentaires conflictuels (« c'est trop critique pour un refactor », « le SaaS coûte trop cher », « on ne peut pas la laisser on-premise »). Les mois passent, le coût d'inaction grimpe, et la migration démarre enfin sans consensus technique véritable.
Une matrice de sélection 6R résout ce problème en imposant une logique commune. Elle croise deux ou trois axes décisifs (complexité technique de l'app, valeur métier, dépendances, coût de maintenance actuel) et produit une recommandation immédiate : non pas la « meilleure » stratégie en absolu, mais la plus adaptée au profil spécifique de cette application et au contexte d'urgence de votre migration. Elle ne remplace pas le jugement métier, mais elle l'encadre et l'accélère. Plutôt que de débattre pendant deux semaines si telle application legacy doit être replatformée ou refactorisée, la matrice oriente le débat : « selon nos paramètres, c'est un refactor ; qui conteste et pourquoi ? ».
Pour une scale-up ou une ETI aux prises avec une facture AWS qui dérape ou une architecture technique hétéroclite, cette matrice devient un outil de gouvernance première. Elle aide le CTO et son équipe à construire une roadmap cohérente en jours plutôt qu'en semaines, à l'adapter à mesure que de nouvelles applications sont évaluées, et à justifier auprès du métier pourquoi telle application sera migrée d'une certaine manière.
Les deux axes principaux : complexité technique et valeur métier
Toute matrice de sélection 6R efficace repose sur deux grandes dimensions qui, à elles seules, couvrent 80 % des décisions réelles.
Le premier axe est la complexité technique de l'application. Une application complexe présente des caractéristiques comme : une architecture monolithique fortement couplée, des dépendances multiples vers d'autres systèmes ou du matériel on-premise, un code legacy peu documenté, une base de données aux millions de requêtes par jour, ou des besoins de performance critique. Une application simple, à l'inverse, est une web app stateless, un service métier isolé, une base de données de petite ou moyenne taille, peu de dépendances externes. Cette complexité technique détermine fortement le coût et le risque de la migration : un monolithe gigantesque ne s'expose pas à un refactor sans casse. Un petit service métier peut le supporter sans sourciller.
Le second axe est la valeur métier : critiques pour le fonctionnement de l'entreprise (ventes, facturation, production, contrôle qualité), ces applications méritent une migration soigneuse et maîtrisée, même si elle coûte plus cher. Les applications non critiques (outils internes, bases de documents, anciens datawarehouses partiellement exploités) peuvent supporter un risque plus élevé ou un rehost rapide, car l'impact d'une panne est contenu.
Croiser ces deux axes produit quatre quadrants clairs : complexe et critique (refactor ou rearchitect lentement et rigoureusement), complexe et non critique (repurchase ou retire si obsolète), simple et critique (replatform soigneusement, ou rehost si vraiment peu de dépendances), simple et non critique (rehost sans hésiter ou retire). Cette grille n'est jamais exhaustive (il faut souvent un troisième axe comme le coût ou la dette technique), mais elle élimine rapidement les mauvaises idées et oriente vers les trois ou quatre 6R les plus pertinents.
Construire votre matrice : critères concrets et questions-clés
Une matrice 6R pratique n'existe pas en tant que formule universelle : elle doit être calibrée à votre contexte. Pour l'assembler, commencez par recenser les critères qui discriminent vraiment vos applications.
Sur la complexité technique, posez-vous : cette application est-elle monolithique ou orientée services ? Combien d'interfaces externes, de connexions bases de données, de dépendances vers d'autres systèmes ? Quel est l'état du code (bien documenté, debt technique élevée, langage obsolète) ? Quels sont ses besoins en performance, latence, concurrence ? Si monolithe fortement accouplée + bases de données massives + dépendances legacy partout = très complexe. Si simple REST API + base PostgreSQL standard = peu complexe.
Sur la valeur métier, le classement est souvent plus politique que technique : demandez aux métiers eux-mêmes quelles applications ne peuvent pas être indisponibles ne serait-ce qu'une heure sans causer une crise (sales blocked, facturation figée, production stoppée) ? Celles-ci sont critiques. Les autres, même si elles sont utilisées tous les jours, peuvent supporter une panne de quelques heures.
Ajoutez un troisième critère si votre portefeuille l'impose : le coût actuel de la maintenance (licensing legacy, coût infra on-premise, effort de support interne). Une application complexe mais peu maintenante peut être un candidat à la retire, tandis qu'une simple mais coûteuse à maintenir justifie un repurchase SaaS.
Une fois vos axes définis, construisez un tableau simple : chaque ligne = une application, chaque colonne = un critère (complexité : faible/moyenne/haute, valeur métier : faible/critique, coût maintenance : bas/moyen/élevé). Vous pouvez le tenir dans un spreadsheet ou un outil de gestion de portefeuille cloud (AWS Migration Evaluator, Cloudscape, etc.). Remplissez-le collectivement : CTO, responsable infra, représentant métier, pour éviter le biais monophonique. Puis appliquez votre règle de décision : si complexe + critique = refactor, si simple + faible coût = rehost, etc.
Cas d'usage réels : appliquer la matrice à des profils typiques
Prenons des exemples concrets pour montrer comment la matrice fonctionne à la fois pour des applications très différentes et pour les contextes des scale-ups AWS en croissance rapide.
Premier exemple : une application de facturation legacy, écrite en COBOL il y a 20 ans, au cœur du système d'information. Complexe : oui (monolithe obèse, dépendances bases de données propriétaires, peu de docs, language obsolète). Critique : absolument (toutes les factures passent par là, panne = dégâts massifs). Recommandation matrice : refactor ou rearchitect. Pourquoi ? Parce qu'on ne peut pas faire confiance à un rehost en cloud sans maîtriser le code, et qu'on ne peut pas la laisser on-premise si elle dérape en coûts. Donc investir quelques mois dans un refactor : moderniser progressivement en services, tester minutieusement, valider chaque passe. Ou, si le refactor est jugé trop coûteux (dépendances externes trop épaisses), envisager un repurchase vers une solution SaaS de facturation, même si c'est plus cher qu'un rehost : au moins on ne porte plus la dette technique.
Deuxième exemple : une application de reporting interne, utilisée pour des tableaux de bord métier, écrite en Python modern, hébergée on-premise, peu critique (elle peut être indisponible un jour sans bloquer l'activité). Complexe : non (architecture stateless, quelques requêtes SQL simples, bien documentée, langage moderne). Recommandation matrice : rehost direct en EC2 ou conteneurisation Lambda. Pourquoi ? Aucune raison de refactoriser un code qui fonctionne. Migration simple et rapide, coûts d'infra réduits dès le départ.
Troisième exemple : une petite base de données Excel améliorée, en Access ou en VBA, utilisée par 3 personnes pour tracker les commandes clients internes. Complexe : non. Critique : non. Coût maintenance : zéro (c'est un machin bâclé en fin d'après-midi). Recommandation matrice : retire ou repurchase. Pourquoi ? Pas intéressant de migrer. Si le besoin existe vraiment, passer à une base Notion, Airtable ou Google Sheets, c'est-à-dire un repurchase SaaS quasi-gratuit. Sinon, arrêter la maintenance et laisser disparaître ce zombie applicatif.
Quatrième exemple : une application de micro-services partiels, moderne, écrite en Node.js et Go, bien conteneurisée, mais pas encore cloud-native (pas de scaling auto, pas de gestion déclarative d'infrastructure). Complexe : moyennement (déjà moderne, mais infra adhoc). Critique : oui (elle supporte la majorité des requêtes API de production). Recommandation matrice : replatform vers Kubernetes managé (EKS) ou bien refactor pour cloud-native (serverless + event-driven où pertinent). Pourquoi ? L'application est déjà partiellement cloud-ready : passer à une infra cloud-native (managed Kubernetes, IAM, autoscaling) vaut mille fois mieux qu'un rehost sur EC2 qui n'adresserait pas les vrais problèmes de scaling.
Intégrer les dépendances et blocages dans la matrice
Une matrice basée uniquement sur complexité et valeur métier donne une vision partielle. Les dépendances entre applications transforment souvent les recommandations.
Exemple : vous avez une application A (facturation) qui appelle une application B (authentification legacy). Selon la matrice brute, A = refactor (complexe + critique), B = rehost (simple + non critique, utilisée seulement par A). Mais si B est très accouplée à A et que la refactoriser à part coûte énormément, vous devrez synchroniser les deux migrations : refactor A et B en parallèle ou retarder l'une jusqu'à ce que l'autre soit stabilisée en cloud. Cela change les délais, les risques, les coûts.
Pour intégrer les dépendances, la matrice doit éviter les décisions isolées. Pendant le remplissage, annotez pour chaque application : « dépend de [App X, App Y] » et « est dépendance pour [App Z] ». Puis, avant de valider les recommandations, tracez les chemins de migration : si l'app A et l'app B doivent être refactorisées ensemble, fusionnez leurs trajectoires. Si l'app C est retire mais que l'app D en dépend encore, reportez la retire de C jusqu'à ce que D soit prête.
Certain cocons de migration AWS utilisent pour cela un diagramme de dépendances (DAG : directed acyclic graph) avant la matrice. On y voit quelles apps forment des clusters de dépendances mutuelles. On traite alors la matrice par cluster plutôt qu'app par app. Un cluster isolé peut être migré à son rythme ; un cluster critique doit être migré en bloc ou en cascade maîtrisée.
Cette étape révèle souvent des blocages cachés : « on croyait que l'app X était simple à rehost, mais en fait elle dépend de ce vieux service on-premise qu'on ne peut pas bouger avant 6 mois, donc rehost doit attendre » ou « l'app Y paraît complexe à refactoriser seule, mais si on la mige en même temps que la refonte d'infra globale, c'est en fait plus rapide ». La matrice mécanique devient alors matrice décisionnelle informée par le contexte réel.
Mettre à jour et affiner la matrice au fil de l'exécution
Une matrice de sélection 6R n'est jamais figée. À mesure qu'on migre les applications, qu'on découvre des hidden dependencies, qu'on rencontre des coûts inattendus, qu'on reçoit des retours métier, il faut l'affiner.
Dans les premières semaines de migration, les équipes techniques découvrent souvent que ce qu'on croyait « simple » ne l'était pas (hidden legacy dependencies, base de données plus volumineuse que prévu, code plus enchevêtré). La matrice initiale permet d'appliquer une heuristique rapide ; l'exécution valide ou contredit cette heuristique. Quand vous découvrez une anomalie (« l'app X qu'on pensait rehost s'avère complexe et nécessite refactor »), mettez à jour la ligne correspondante, notez la raison de l'écart, et utilisez ce feedback pour affiner les critères futurs.
De même, certaines recommandations deviennent obsolètes : vous aviez recommendé de retirer une vieille app, mais entre-temps le métier a trouvé un nouveau cas d'usage. Vous aviez chosen repurchase SaaS, mais le vendor a augmenté ses tarifs de 50 %. Vous aviez misé sur replatform, mais l'équipe découvre que refactoriser en serverless coûte finalement moins cher. Réviser la matrice en continu (par trimestre ou tous les deux mois) maintient la cohérence des décisions et montre à l'organisation que la migration est un processus adaptatif, pas un plan gravé dans le marbre.
La matrice devient ainsi un artefact de gouvernance vivant : elle documente la stratégie initiale, elle guide l'exécution, et elle capture les apprenants pour les applications futures. Quelques entreprises la publient même sur un dashboard interne, avec pour chaque app : profil, recommandation initiale, statut actuel (planifié, en cours, livré, révision), et déviation éventuelle expliquée.
Cela aide aussi au coton interne : quand quelqu'un se demande « pourquoi cette app est rehost et pas refactor ? », la réponse est documentée et justifiée, pas arbitraire.