Rehost et replatform : deux stratégies opposées sur le continuum migration-transformation
Rehost et replatform se situent aux deux extrémités d'un spectre migratoire au sein du cadre 6R. Le rehost, aussi appelé lift-and-shift, consiste à déplacer une application telle quelle depuis l'infrastructure on-premises vers AWS sans modification fonctionnelle ni architecture. On installe le système d'exploitation, les dépendances et l'application sur une instance EC2 (ou conteneur) AWS, en respectant au plus proche la configuration source. Le replatform, souvent appelé lift-and-optimize ou refonte légère, va un cran plus loin : on migre l'application, mais on la prépare pour le cloud en levant certaines dépendances, en l'adaptant à des services AWS gérés (par exemple, remplacer une base de données auto-hébergée par Amazon RDS, ou une file d'attente maison par SQS), et en optimisant légèrement l'architecture pour réduire les coûts opérationnels à terme. Rehost privilégie la rapidité et la réduction du risque immédiat ; replatform ajoute une phase d'optimisation qui réduit la dette technique et la facture AWS à long terme, mais prend plus de temps et implique des changements logiciels. Aucune des deux n'entraîne une réécriture majeure (c'est le rôle du refactor) ni un changement de produit (repurchase) ; elles restent dans la philosophie du « garder ce qu'on a et l'adapter au cloud ».
Rehost : migrer en deux semaines, accepter la facture cloud à venir
Le modèle rehost est le plus rapide et le moins risqué à court terme. Une application monolithique on-premises peut être migrée vers une instance EC2 en quelques jours à quelques semaines, selon sa taille et ses dépendances externes. Aucune modification de code n'est nécessaire ; il suffit de reproduire l'environnement d'exécution sur le cloud. Les délais courts signifient que le ROI apparaît immédiatement : vous cesserez de payer le serveur physique, amortissez rapidement la licence AWS, et l'équipe technique peut passer aux chantiers suivants. Le risque de régression fonctionnelle est minimal, puisque rien ne change côté applicatif. Cet avantage est précieux pour les migrations d'urgence (fin de contrat de maintenance d'une infrastructure vieillissante, décommissionnement forcé d'un data center) où le temps prime sur la perfection architecturale. Cependant, le rehost n'optimise rien pour AWS. Une application migrée en lift-and-shift continuera souvent à consommer des ressources généreuses (processeurs, mémoire, stockage) comparables à ce qu'elle utilisait on-premises, où le coût marginal d'une ressource supplémentaire était dilué dans un budget capex fixe. Sur AWS, cet excès se traduit par une facture mensuelle gonflée, avec peu de levier pour la réduire sans refonte logicielle. À titre d'exemple, une base de données auto-hébergée sur un serveur physique, même surprovisionnée, ne coûte que l'électricité et la maintenance du serveur ; déplacée telle quelle sur une instance EC2 optimisée pour calcul (au lieu d'un service RDS) sur AWS, elle continue de consommer à l'identique, sans profiter des réductions de coûts ou de la haute disponibilité que RDS aurait apportées pour un effort d'adaptation raisonnablement faible. Le rehost doit donc être choisi quand le timing est critique, que l'application en question n'est pas un gros consommateur de ressources ou que l'équipe technique est trop surchargée pour envisager une refonte, même légère.
Replatform : trois à quatre semaines pour réduire les coûts de 30 à 50 % à terme
Le replatform dépasse le lift-and-shift en ajoutant une phase de légère refonte adaptée au cloud AWS. Au lieu de simplement déplacer l'application, on en profite pour identifier et remplacer les composants qu'AWS peut gérer plus efficacement. Les bases de données auto-hébergées deviennent RDS ou DynamoDB selon le schéma ; les systèmes de files d'attente maison deviennent SQS ou Kinesis ; les serveurs d'application figés passent à des conteneurs ECR-ECS pour une meilleure scalabilité. Ces adaptations sont généralement peu risquées car elles ne touchent pas à la logique métier de l'application, juste à son infrastructure technique. Cette approche coûte plus de temps d'ingénierie en amont (recettage d'une semaine ou deux en plus), mais elle produit trois bénéfices dès la semaine suivant le déploiement : réduction immédiate de la facture AWS (un moteur de base de données optimisé par RDS peut coûter 40 à 50 % moins cher qu'une instance EC2 qui tourne le même moteur 24 heures sur 24), réduction de la charge opérationnelle d'administration technique (AWS gère les patches, sauvegardes, failover), et une base saine pour les optimisations futures (scaling automatique, reservation instances pour réduire le coûts variables, etc.). Le replatform est donc le modèle de prédilection pour les migrations « normales » où le temps ne manque pas totalement, mais où on veut éviter une réécriture majeure qui aurait un ROI moins clair et des risques de régression plus élevés. Il convient particulièrement bien aux applications monolithiques de 10 à 20 ans qui ont accumulé de la dette technique on-premises mais dont le cœur métier reste solide et utile. Une banque qui migrate une application de gestion de prêts écrite en Java il y a 15 ans sur un serveur on-premises passera typiquement par replatform : elle adaptera la base de données Oracle auto-hébergée pour en faire un RDS Oracle, mais n'ajoutera pas de microservices ou d'API REST puisque ce n'était pas le cœur du projet.
Critères pour choisir rehost ou replatform selon le profil de l'application
Le choix entre rehost et replatform dépend de quatre critères principaux : l'urgence de la migration, le profil de consommation de ressources, le niveau de dette technique architecturale, et la capacité d'ingénierie disponible. Premièrement, si la migration doit être achevée en moins de quatre semaines (fin urgente d'un contrat data center, fin de support d'une base de données ancienne), rehost s'impose. Deuxièmement, si l'application est peu exigeante en ressources (site web statique, petit portail d'administration interne, batch de nuit qui consomme peu), le surcoût AWS du lift-and-shift restera marginal, et rehost peut être acceptable. Troisièmement, si l'application inclut des briques techniquement lourdes et inefficaces à maintenir (un système de cache maison écrit en C des années 1990, une base de données auto-répliquée sans failover automatique, une architecture n-tiers avec trop de saut réseau), replatform sera rentable : adapter ces briques à des services AWS gérés paiera vite la semaine supplémentaire d'ingénierie. Quatrièmement, si votre équipe tech est saturée et ne peut libérer que trois développeurs pour trois semaines, rehost sera plus réaliste qu'un replatform qui exigerait plus de bande passante. Inversement, si vous avez un peu de respiration calendaire, une application qui consomme massivement du calcul ou du stockage, et une équipe capable de passer deux-trois semaines à l'optimisation, replatform délivrera un meilleur coût total de possession après six mois. Une matrice simple aide à arbitrer : si le score d'urgence est 9 ou 10 sur 10 et le coût mensuel de l'app est < 5 000 euros, rehost ; si l'urgence est 5 ou moins et le coût mensuel dépasse 10 000 euros avec des composants identifiables comme inefficaces, replatform.
Pièges communs et comment les éviter lors du choix rehost vs replatform
Le piège le plus fréquent est de choisir rehost par manque de temps initial, puis de subir une facture AWS beaucoup plus lourde que prévu pendant un an, ce qui impose une refonte rétroactive plus difficile qu'une optimisation d'entrée. Une application qui aurait pu passer en replatform en deux semaines supplémentaires doit ensuite être revisitée alors qu'elle est en production et que les raccords avec les autres systèmes se sont durcis. Le coût de cette refonte tardive est souvent supérieur au coût d'opportunité d'une optimisation d'emblée. Pour éviter ce piège, évaluez à l'amont le coût mensuel AWS estimé en scénario rehost (demandez à AWS un devis ou simulez sur la calculatrice tarifaire) et comparez-le à vos objectifs de coût cloud. Si la projection annuelle dépasse vos budgets de 50 %, l'investissement dans replatform sera plus intéressant. Un second piège est de négliger les dépendances externes lorsqu'on opte pour rehost. Une application on-premises peut s'appuyer sur des connexions synchrones vers d'autres systèmes, des authentifications LDAP propres au data center, ou des chemins réseau prévisibles d'une latence très basse. Basculée en lift-and-shift sur AWS, elle peut subir des latences inattendues ou des timeouts si ces dépendances n'ont pas été refactorisées. Replatform force à revisiter ces dépendances (adapter l'authentification en Cognito ou OAuth, découpler les appels synchrones en files de messages), ce qui réduit le risque d'une mauvaise surprise post-migration. Un dernier piège : la confusion entre replatform et refactor. Replatform, c'est adapter l'application aux services AWS gérés sans toucher à la logique métier. Refactor, c'est réécrire des portions de l'application pour tirer pleinement parti du cloud (microservices, sans serveur, etc.). Si vos sponsors ou votre backlog promettent une « refonte dans le cloud », ce n'est pas du replatform, c'est du refactor, et cela dépasse la portée et les délais d'une simple migration 6R.
Cas d'usage concrets : quand rehost et quand replatform gagnent
Prenons trois exemples concrets pour illustrer le choix. Cas 1 : une petite startup fintech a une application de gestion de portefeuille écrite en Python, qui tourne sur un serveur on-premises loué 800 euros par mois. Urgence moyenne (contrat renouvelle dans deux mois), équipe de deux ingénieurs. Estimation rehost : deux semaines pour faire l'audit et la migration, coût AWS estimé à 900 euros par mois (peu optimisé). Estimation replatform : trois semaines supplémentaires pour adapter la base de données Postgres en RDS et refactoriser les connexions, réduction estimée à 600 euros par mois. Calcul : l'investissement d'une semaine de deux ingénieurs (80 heures) pour économiser 300 euros par mois vaut la peine au-delà de 8 mois. La réponse est replatform. Cas 2 : un grand assureur doit migrer immédiatement un batch Legacy-COBOL qui tourne un rapport annuel le dernier jour de l'année fiscale. Le report d'une semaine serait un désastre réglementaire. L'app consomme 5 000 euros par mois en serveur. Rehost : déployer le batch sur une machine EC2 avec même RAM et CPU en deux semaines, migration de la donnée. Le batch tourne en novembre et décembre, puis l'équipe pourra l'optimiser ultérieurement quand il n'y a pas urgence. Réponse : rehost maintenant, replatform en Q2 si profitable. Cas 3 : une PME de e-commerce a une application de gestion de magasin écrite en Java avec une base MySQL auto-répliquée, un cache Redis au-dedans, une file d'attente de commandes en-house. Pas d'urgence extrême, équipe de quatre développeurs, facture serveur on-premises de 15 000 euros par mois. La base de données, le cache et la queue pourraient passer à des services AWS gérés. Rehost coûterait 18 000 euros par mois sur AWS (non optimisé). Replatform, une vingtaine de jours de développement, réduirait à 9 000 euros par mois. L'équipe peut se dégager cette bande passante. Réponse : replatform, car le ROI est évident et réalisable.
Rehost et replatform dans le cadre plus large du modèle 6R
Rehost et replatform ne sont que deux facettes du cadre 6R complet. Les six stratégies (Rehost, Replatform, Refactor, Repurchase, Retire, Retain) couvrent l'ensemble des décisions possibles lors d'une migration cloud. Beaucoup d'organisations ne choisissent pas un seul modèle pour tout leur portefeuille : elles combinaient typiquement rehost pour les applications urgentes ou héritées peu critiques, replatform pour les briques métier de taille modérée, refactor pour les nouveaux services critiques, repurchase pour les applications génériques (ERP, CRM, suite bureautique) qu'un SaaS peut couvrir moins cher, retire pour les applications obsolètes, et retain pour les systèmes trop complexes ou liés à du matériel spécialisé qui resteront on-premises ou dans un cloud privé. Une matrice de sélection 6R aide à classifier rapidement chaque application de votre portefeuille selon ces six critères (coût, risque, délai, capacité d'ingénierie nécessaire, dépendances). Si une application ressort candidat rehost ou replatform, cet article approfondit ce choix. Si elle vous semble plutôt refactor ou repurchase, c'est qu'elle sort du périmètre rehost/replatform : elle exige soit une réécriture, soit un changement de produit. L'important est de ne pas laisser une décision de rehost ou replatform être imposée par une fausse urgence ; revisiter la matrice 6R avec les parties prenantes (métier, finance, technique) pour vous assurer que vous ne ratiez pas une opportunité de repurchase ou retire qui aurait un meilleur ROI.
Ressources pour affiner votre décision : dépendances, blocages et étapes suivantes
Avant de verrouiller un choix rehost ou replatform, identifiez les dépendances et blocages techniques qui pourraient influer sur ce choix. Les dépendances (connexions vers d'autres systèmes, authentifications partagées, chemins réseau spécifiques, licences) doivent être listées car elles peuvent rendre rehost plus lent et plus risqué si elles exigent des modifications de configuration. Les blocages (impossibilité de modifier l'app pour des raisons réglementaires, dépendance envers un tiers qui ne peut pas mener la migration, contraintes de performance qui interdisent une refonte même légère) peuvent exclure replatform et forcer rehost. Un diagnostic approfondi des dépendances et blocages avant de choisir peut vous épargner des semaines de rework post-migration. Une fois rehost ou replatform sélectionné, les étapes immédiatement suivantes sont un plan de migration chiffré (délais, ressources, coûts), une stratégie de cutover (big bang ou migration progressive), et un plan de recettage de deux à trois jours avant le go-live. Ces sujets relèvent du chantier de migration lui-même plutôt que du choix stratégique ; si cet article a clarifié pour vous pourquoi vous choisissiez rehost ou replatform, les étapes pratiques suivantes suivront naturellement de ce choix.