Qu'est-ce que le modèle 6R en migration cloud et pourquoi l'utiliser
Le modèle 6R est un cadre de classification fondamental dans les stratégies de migration cloud. Développé par AWS, il propose six approches distinctes pour transformer chaque application lors du passage vers le cloud, plutôt que d'appliquer une seule méthode à toutes les ressources. Chaque application, base de données ou service métier possède un profil technique et des contraintes métier différentes : certains sont critiques et doivent migrer vite, d'autres sont obsolètes ou redondants, certains tirent un grand bénéfice d'une refonte en microservices tandis que d'autres fonctionnent mieux en l'état. Le modèle 6R reconnaît cette réalité et vous aide à prendre la bonne décision pour chaque cas, minimisant les risques et les surcoûts. Sans ce cadre, les équipes tâtonnent, commencent à migrer une app de manière trop ambitieuse (refactor quand rehost aurait suffi), puis la découragent face à la complexité, ou à l'inverse refont tous les chemins à l'identique dans AWS sans capitaliser sur les avantages du cloud. L'assessment infrastructure cloud préalable révèle justement les caractéristiques techniques et métier de chaque application (dépendances, charge, criticité, dette technique) qui alimentent cette classification 6R. Vous êtes alors armé pour construire une roadmap claire : savoir lesquelles migrer en premier, lesquelles arrêter, lesquelles refondre profondément, et lesquelles garder en l'état temporairement. Cela accélère la transition et réduit les coûts imprévisibles.
Rehost : migrer comme-est vers AWS en lift-and-shift
Le Rehost, souvent appelé lift-and-shift, est la stratégie la plus rapide et la moins invasive : vous prenez l'application, la machine virtuelle, la base de données, et vous les migrez vers AWS identiques à eux-mêmes. Aucune refonte d'architecture, aucune réécriture de code. Cette approche convient parfaitement quand vous avez une application stable et performante en on-premise, que vous voulez migrer vite pour réduire le datacenter ou diminuer rapidement les coûts d'exploitation, et que vous n'avez pas de raison technique ou métier urgente de la transformer. Typiquement : un système ERP mature qui fonctionne bien, une base de données Oracle établie, une application métier interne sans évolutions prévues à court terme. Le temps de migration est compté en semaines, pas en mois. Les risques techniques sont mineurs car vous ne touchez pas au code. Les défis sont plutôt opérationnels : dimensionner correctement l'instance EC2 équivalente, configurer la sécurité réseau (VPC, security groups), planifier le cutover et les tests de validation. Un rehost mal exécuté peut coûter cher en cloud (vous gardez des instances surdimensionnées héritage) parce que vous n'avez pas ajusté les ressources à la réalité cloud. C'est pourquoi l'assessment infrastructure cloud détecte ces cas : il identifie les applications où rehost convient vraiment, distingue les charges réelles des provisions on-premise héritées, et vous aide à dimensionner correctement dès la migration. Le rehost n'est pas une « non-stratégie » : c'est un choix pragmatique pour les 40-50 % d'une infrastructure typique où la transformation n'apporte pas assez de valeur métier pour justifier l'effort.
Replatform : adapter l'infrastructure sans refondre l'application
Le Replatform est un intermédiaire intelligent entre rehost et refactor. L'idée est de conserver l'application et son code métier en grande partie, mais de moderniser sa couche infrastructure en tirant parti des services managés d'AWS. Par exemple : vous avez une application Java monolithique qui tourne sur un serveur Tomcat and Oracle on-premise. Au lieu de la laisser sur EC2 telle quelle (rehost), vous la migrez sur AWS Elastic Beanstalk qui gère l'infrastructure, les mises à jour et l'auto-scaling pour vous. Ou vous remplacez votre base de données Oracle auto-managée par Amazon RDS, qui offre backup automatique, haute disponibilité, et performance optimisée sans que vous n'ayez à vous soucier de la maintenance. Vous faites peut-être aussi un petit refactoring sur les services critiques (authentification, logging) pour les intégrer aux outils AWS natifs (IAM, CloudWatch). Le code applicatif métier, lui, reste essentiellement intact. Les bénéfices sont directs et mesurables : moins d'effort opérationnel post-migration (pas de patch OS à appliquer manuellement, pas de backup à orchestrer), coûts rééduits car les services managés éliminent les surcoûts de gestion on-premise, et flexibilité accrue (l'auto-scaling vous économise des ressources inutilisées). Le Replatform court une durée de migration de quelques semaines à 2-3 mois selon la complexité. Il convient aux applications stratégiques ou critiques qui valent l'effort de modernisation légère, mais qui ne justifient pas une refonte totale. C'est souvent le bon compromis quand vous migrez un système qui marche bien mais dont la couche infrastructure vieillit ou consomme trop de ressources.
Refactor : moderniser l'architecture pour exploiter le cloud-native
Le Refactor (aussi appelé rearchitect) est la stratégie la plus ambitieuse : vous repensez l'application pour la rendre cloud-native. Cela signifie la découper en microservices, la rendre stateless, la déployer en conteneurs sur ECS ou EKS, utiliser des services AWS serverless (Lambda, DynamoDB, SNS/SQS) à la place de bases de données centrales, implémenter l'auto-scaling granulaire et la résilience au niveau applicatif. Une refonte cloud-native bien faite offre des bénéfices énormes : scalabilité quasi-illimitée, réduction drastique des coûts en liant les ressources consommées à la demande réelle, déploiements plus rapides et fréquents, résilience naturelle. Mais c'est aussi l'option la plus coûteuse et la plus longue. Compter 4-9 mois pour une application complexe, rewrite de code significatif, nouvelles méthodologies (CI/CD, Infrastructure-as-Code, observabilité cloud-native), et apprentissage des équipes. Le Refactor convient quand l'application est stratégique pour la croissance métier, quand sa charge varie fortement (le cloud-native excelle à ça), quand votre équipe peut absorber la courbe d'apprentissage, ou quand la dette technique on-premise entrave tellement l'évolution métier que seule une refonte la libère vraiment. C'est rarement le premier mouvement d'une migration : beaucoup d'organisations refactorisent 5-15 % de leur portefeuille, souvent les applications ou services nouveaux ou prioritaires, après avoir stabilisé les rehost et replatform. Une stratégie de migration vers AWS bien construite séquence les efforts pour dégager les équipes et du budget pour les refactors progressifs.
Repurchase : remplacer l'application par un SaaS
Le Repurchase signifie abandonner l'application existante pour adopter un logiciel SaaS prêt à l'emploi qui remplit le même besoin métier. Par exemple : vous avez construit une application interne de gestion de congés en 2010, elle marche mais vous la maintenez, la patchez, la déployez vous-mêmes. Le Repurchase dirait : « Arrêtons de la maintenir, adoptons Workday ou Monday.com ou un outil SaaS niche, dans le cloud, pas besoin d'infrastructure ». Ou vous avez un vieux système d'emailing propriétaire : remplacez-le par Sendgrid ou AWS SES. Cette approche fait disparaître d'un coup une dette technique et l'effort de maintenance, vous gagnez la maturité et les mises à jour du fournisseur SaaS, et souvent vous payez moins que ce que coûte la maintenance interne plus l'infrastructure. Les défis sont différents : intégration avec les autres systèmes (APIs, webhooks), migration des données et adaptation des workflows métier à la logique du SaaS (pas toujours un 1:1). Le Repurchase convient quand l'application est métier standard (pas de différenciation compétitive), quand le SaaS du marché couvre 80 % de vos besoins, quand vous êtes prêt à accepter une contrainte métier pour gagner en opérationalité, ou quand le coût du SaaS est compétitif avec la maintenance interne plus l'infrastructure cloud. Attention : ne pas tout repurchase sous prétexte que c'est plus simple. Les applications qui font votre différence compétitive, celles hyper-spécialisées à votre métier, celles intégrées profondément à votre écosystème unique, doivent rester en interne (refactor ou rehost/replatform).
Retire : arrêter les applications obsolètes ou redondantes
Le Retire est souvent la décision la plus difficile mais la plus payante : identifier les applications que vous n'utilisez plus, ou qui sont redondantes parce qu'une autre application fait le même travail mieux, et les arrêter. Beaucoup d'organisations découvrent qu'elles traînent 10-30 % d'applications zombies qui coûtent en infrastructure, maintenance, sécurité (patches, audits) et cognitive overhead (l'équipe IT doit les connaître, les surveiller, maintenir le support). Lors d'une migration, c'est le moment parfait pour faire le ménage : vous aviez cette vieille appli de reporting qu'on n'utilise plus ? Arrêtez-la. Vous aviez deux systèmes de gestion documentaire différents parce qu'un département l'avait déployé en isolation ? Consolidez vers un seul, arrêtez l'autre. Le Retire économise de l'argent (coûts infrastructure), réduit la complexité opérationnelle (moins de systèmes à surveiller, patcher, auditer), et libère des équipes pour des travaux à valeur ajoutée. L'assessment infrastructure cloud identifie typiquement ces candidats : peu d'utilisateurs, coûts disproportionnés, peu ou pas de dépendances critiques (sinon arrêt serait risqué). Avant de retirer, toujours vérifier qu'il n'y a pas de dépendances cachées, que les données critiques sont archivées ou migrées, et que les utilisateurs acceptent la transition. Un retire bien fait peut économiser 15-20 % du budget IT sans perdre une seule capacité métier.
Retain : maintenir en on-premise ce qui ne migre pas
Le Retain signifie garder temporairement ou définitivement une application en on-premise, voire ne pas la migrer du tout. C'est une décision pragmatique : l'application est très coûteuse ou risquée à migrer, elle n'est pas prioritaire métier, ou vous n'avez pas encore la capacité à la transformer. Par exemple : une grosse base de données proprietaire avec des dépendances complexes, un système temps-réel ultra-critique avec des jeux de performance étroits, ou une appli maison avec peu de documentation et des risques de régression élevés. Le Retain n'est pas un « non-choix » : c'est une décision informée basée sur le ratio risque/bénéfice. Beaucoup d'organisations, après une première vague de migration réussie, gardent intentionnellement 10-20 % du portefeuille on-premise (ou du moins la gardent quelques années de plus) pour diversifier les risques et étaler les efforts. Le piège du Retain est de laisser cette couche on-premise s'éterniser sans plan d'action. L'idéal est de programmer le retain sur une durée définie (« on garde cette app 2 ans de plus, puis on réévalue ») et d'inclure un plan de modernisation à moyen terme (dans 2 ans, on va la refactor ou la repurchase). Autrement dit, le Retain n'est jamais un « jamais » : c'est un « pas maintenant, mais avec un horizon clair ». Une bonne stratégie de migration vers AWS intègre les retenus, les priorise dans la feuille de route, et les réévalue régulièrement à mesure que les capacités et priorités métier évoluent.
Comment décider : critères et matrice de sélection des 6R
Choisir le bon 6R pour une application requiert d'évaluer plusieurs critères croisés. L'assessment infrastructure cloud préalable collecte ces données, mais voici comment les interpréter. D'abord, la criticité métier : les applications très critiques pour la continuité opérationnelle doivent migrer vite et sûrement (rehost ou replatform sont plus sûrs que refactor) ou ne pas migrer du tout (retain). Les applications non-critiques peuvent prendre plus de risques (refactor). Deuxième critère, la complexité technique et la dette technique : une application avec beaucoup de dépendances, du code hérité, peu de documentation, est plus risquée à refactor. Elle candidate pour rehost ou replatform. Une appli bien architecturée, testée, documentée, peut supporter une refonte. Troisième, la variabilité de charge : si votre application a des pics saisonniers ou des pics imprévisibles (e-commerce en Black Friday, plateforme B2B avec montées en charge soudaines), le refactor en cloud-native excelle. Rehost ou replatform ne vous en donne pas le bénéfice. Quatrième, l'alignement métier : une app qui fait votre différence compétitive justifie un refactor pour la moderniser. Une app standard ou commoditisée candidate pour repurchase SaaS. Cinquième, la maturité de l'équipe : refactor demande des compétences cloud-native (Kubernetes, Lambda, serverless patterns). Si votre équipe ne les a pas, un refactor devient un projet à fort risque. Sixième, le coût : rehost est le moins cher en ingénierie, refactor le plus cher. Repurchase peut être cher en budget SaaS mais moins en ingénierie. Septième, le timing : si vous êtes pressé, rehost ou repurchase, pas refactor. Une approche simple est de construire une matrice : chaque application en ligne, ses caractéristiques (criticité, complexité, charge, alignement métier, coûts) en colonnes, et vous colorez cell par cell selon le degré (critique vs non-critique, complexe vs simple, etc.). Le pattern de couleurs pointe naturellement vers les 6R candidats. L'évaluation n'est jamais absolue : c'est un guide pour la conversation entre l'équipe IT, la métier, et vos partenaires d'ingénierie pour arbitrer en connaissance de cause.
Intégrer les 6R dans votre stratégie et roadmap de migration
Une fois que vous avez classifié votre portefeuille d'applications selon les 6R, l'étape suivante est de construire votre stratégie de migration vers AWS pour ordonner et séquencer. Vous ne pouvez pas tout faire à la fois : vous avez une bande passante limitée (équipes, budget, fenêtres de maintenance, risque opérationnel). L'ordre de migration dépend de plusieurs facteurs. D'abord, démarrez par les applications rehost simples et non-critiques. Elles vous donnent une victoire rapide, vous rôdez les processus de migration (automation, validation, rollback), vous montrez de la valeur métier et entraînez vos équipes. Ensuite, montez en complexité : replatform les applications stratégiques. À ce stade, vous avez du feedback des premiers rehost, vous commencez à affiner votre infrastructure AWS, vos patterns de sécurité, de networking. Ensuite viennent les refactor et repurchase : plus d'effort, plus de risque, mais vous avez l'expérience et la confiance pour les mener. En dernier, les retain et retire peuvent être traités au fil de l'eau : retire les app zombies dès que vous les identifiez (pas besoin d'attendre), et réévaluez les retain chaque trimestre pour en décaler de nouveaux vers la migration si leur criticité change. Cette séquence n'est pas gravée : selon votre contexte (urgence métier, contraintes réglementaires, disponibilité des équipes), vous pouvez resynchroniser. Mais globalement, commencer simple et accélérer progressivement minimise les risques et maximise l'apprentissage. Une bonne stratégie de migration planifie aussi les dépendances entre applications : si l'app A dépend de l'app B, migrez B avant A. Sinon vous compliquiez les tests et risquez les régressions. C'est un travail de planification qui s'appuie sur l'assessment infrastructure cloud pour construire le graphe de dépendances exact. Enfin, ne sous-estimez pas le gain de communiquer régulièrement la roadmap aux équipes, métier et direction. La migration est un projet long (12-36 mois pour une infrastructure moyenne), visible, avec impacts sur le quotidien des utilisateurs. La transparence et la victoires rapides maintiennent l'élan et la confiance.