Déplacer ou reconstruire : les deux réponses sont bonnes — pour des questions différentes. Voici comment poser la bonne question.

Un directeur technique fait face à cette décision : son contrat datacenter expire dans six mois. Il doit migrer vers le cloud. La question n’est pas si — c’est comment. Doit-il prendre ses applications telles quelles et les déplacer ? Les réécrire pour tirer parti du cloud natif ? Faire quelque chose entre les deux ? Chaque chemin a ses partisans, ses coûts cachés et ses conditions de réussite. Ce guide démêle les trois grandes stratégies, les données qui permettent de choisir, et les pièges que personne ne mentionne dans les argumentaires commerciaux.

1. Pourquoi la question n’est pas « laquelle est la meilleure ? »

La plupart des débats sur la migration cloud se structurent comme un match : lift-and-shift contre refactoring. C’est le mauvais cadrage. Ces stratégies ne s’excluent pas — elles répondent à des contextes différents, des contraintes différentes, et des applications différentes.

La vraie question est : pour chaque application du portefeuille, quelle est la stratégie qui maximise la valeur dans les contraintes de temps, de budget et de compétences disponibles ? La plupart des organisations qui migrent vers le cloud finissent par utiliser les trois stratégies — parfois sur le même projet, selon la criticité de chaque composant.

Le chiffre qui recadre le débat Les entreprises qui modernisent leurs applications pendant la migration obtiennent 40% de ROI supplémentaire par rapport aux approches lift-and-shift. Mais le lift-and-shift se réalise 3 fois plus vite. Ces deux chiffres sont tous les deux vrais — et illustrent parfaitement pourquoi la question n’est pas laquelle choisir, mais quand.

2. Les trois stratégies : définitions et réalités

Le framework des « 6 R » d’AWS (Rehost, Replatform, Refactor, Repurchase, Retire, Retain) est la référence du secteur. En pratique, trois stratégies concentrent l’essentiel des décisions.

Stratégie 1  —  Rehost — le lift-and-shift Vous prenez l’application telle qu’elle est — code, configuration, dépendances — et vous la déplacez vers une infrastructure cloud sans la modifier. C’est littéralement “soulever et déplacer”. Sur AWS, cela signifie typiquement migrer vos VMs vers EC2, vos bases de données vers RDS, votre stockage vers S3, en reproduisant la même architecture. Les outils comme AWS Application Migration Service automatisent une grande partie du processus. Le résultat : vous êtes dans le cloud, mais vous ne tirez pas encore pleinement parti de ses capacités. Vous payez souvent autant — voire plus — qu’on-premise, parce que les applications n’ont pas été optimisées pour un environnement élastique.

Stratégie 2  —  Replatform — le lift-and-reshape Vous déplacez l’application en apportant des ajustements ciblés pour tirer parti de services cloud managés, sans réécrire le code métier. L’exemple classique : vous remplacez votre base de données PostgreSQL auto-gérée sur VM par Amazon RDS for PostgreSQL — même moteur, mais plus de gestion de patches, de sauvegardes ou de haute disponibilité à gérer manuellement. Ou vous passez de Tomcat sur VM à AWS Elastic Beanstalk pour automatiser le déploiement. Le gain est réel sans la complexité et le coût d’un refactoring complet. C’est souvent le bon compromis pour les applications stables avec une longue durée de vie.

Stratégie 3  —  Refactor / Re-architect — reconstruire pour le cloud natif Vous repensez l’architecture de l’application pour exploiter pleinement le cloud : microservices, containers (EKS), serverless (Lambda), event-driven. C’est la stratégie qui génère le plus de valeur à long terme — scalabilité, résilience, vélocité de déploiement — mais aussi la plus coûteuse, la plus risquée et la plus longue. Elle demande des compétences DevOps avancées et une connaissance profonde du domaine métier. À ne pas entreprendre sans raison business claire.

3. La comparaison honnête

Voici les données réelles, sans les arguments commerciaux de chaque camp.

Critère	Rehost (lift-and-shift)	Replatform	Refactor / Re-architect
Vitesse de migration	Rapide — semaines à quelques mois	Modérée — 1 à 6 mois selon la complexité	Lente — 6 mois à plusieurs années
Coût initial	Faible à modéré	Modéré	Élevé
Coût cloud post-migration	Souvent 40% plus élevé que prévu faute d’optimisation	Réduit grâce aux services managés	Optimisé — autoscaling, serverless, pay-per-use
ROI à long terme	Moindre — 40% inférieur à la modernisation	Bon compromis	Maximal — mais horizon 2-3 ans minimum
Risque technique	Faible — peu de changement de code	Modéré — ajustements ciblés	Élevé — réécriture partielle ou complète
Compétences requises	Infrastructure, outils de migration AWS	Cloud + connaissance applicative	DevOps avancé, architecture cloud native
Quand c’est pertinent	Urgence, fin de contrat datacenter, première étape d’une migration progressive	Applications stables avec opportunités de services managés	Applications stratégiques avec besoin fort d’évolutivité

Le piège du lift-and-shift qu’on ne voit qu’après Les migrations pures lift-and-shift génèrent en moyenne 40% de coûts cloud supplémentaires par rapport aux estimations initiales dans les 12 premiers mois. La raison principale : les applications on-premise sont souvent surdimensionnées (on provisionne pour les pics), alors que le cloud facture à l’usage. Sans optimisation, vous payez la même chose — mais sans le datacenter. Et 25% des organisations ont déjà rapatrié des workloads du cloud vers l’on-premise, principalement pour des raisons de coûts non maîtrisés.

4. Le cadre de décision : comment choisir pour chaque application

Il n’existe pas de réponse universelle. Il existe un processus d’évaluation que vous appliquez à chaque application de votre portefeuille. Voici les quatre questions à poser.

Question 1 — Quelle est la criticité et la durée de vie prévue de cette application ?

Une application en fin de vie dans 18 mois ne mérite pas un refactoring de 12 mois. Une application stratégique qui supportera votre croissance pendant 10 ans mérite qu’on investisse pour la rendre cloud native. La durée de vie prévue est le premier filtre. Les applications en fin de vie → retire ou repurchase (SaaS). Les applications à longue durée de vie et haute criticité → refactor. Le reste → rehost ou replatform.

Question 2 — Quelle est l’urgence de la migration ?

Si votre contrat datacenter expire dans quatre mois, vous n’avez pas le temps de refactoriser. Le rehost est alors la seule option réaliste — et ce n’est pas une mauvaise décision dans ce contexte, c’est une décision contrainte par le temps. Le lift-and-shift n’est pas une erreur — c’est souvent la bonne première étape d’une transformation progressive. On migre d’abord, on optimise ensuite.

Question 3 — Quelles compétences sont disponibles en interne ?

Le refactoring demande des compétences DevOps avancées, une culture CI/CD mature, et une connaissance profonde de l’application à refactoriser. Entreprendre un refactoring sans ces compétences, c’est s’exposer à des délais multipliés et des coûts incontrôlés. Si l’équipe n’est pas encore prête, commencer par un replatform progressif pendant que les compétences se construisent est une approche réaliste.

Question 4 — Quel est le niveau de dette technique actuelle ?

Une application monolithique écrite en 2008, sans tests, avec des dépendances opaques, sera extrêmement difficile à refactoriser. Le coût et le risque sont proportionnels au niveau de dette technique. Dans ce cas, un rehost suivi d’un remplacement progressif par une solution moderne est souvent plus sage qu’une tentative de modernisation d’un code difficile à maîtriser.

Situation	Stratégie recommandée
Fin de contrat datacenter imminente (< 6 mois)	Rehost — migrer rapidement, optimiser ensuite
Application stable, longue durée de vie, pas stratégique	Replatform — services managés sans réécriture
Application critique, forte croissance prévue, équipe DevOps mature	Refactor — investir pour la scalabilité et la vélocité
Application peu utilisée, fonctionnalités disponibles en SaaS	Repurchase — remplacer par une solution SaaS
Application obsolète, remplacée bientôt	Retire — ne pas migrer ce qui va disparaître
Application avec contrainte réglementaire forte (résidence des données)	Retain + replatform — garder on-premise partiellement, optimiser le reste

5. La migration progressive : la vraie stratégie gagnante

Ce qu’on observe dans les migrations réussies, c’est rarement l’application d’une seule stratégie à tout le portefeuille. C’est une approche progressive : rehost d’abord pour sortir du datacenter, optimiser ensuite application par application.

Cette séquence a plusieurs avantages. Elle réduit le risque en évitant de tout changer en même temps. Elle génère des quick wins qui maintiennent l’adhésion des équipes et des dirigeants. Elle permet à l’équipe de monter en compétences sur le cloud avant de s’attaquer aux refactorisations les plus complexes. Et elle permet de financer la modernisation grâce aux économies réalisées sur les premières applications optimisées.

Comment Netflix a migré — et pourquoi ça prend du tempsNetflix est souvent cité comme l’exemple de la migration cloud réussie. Ce qu’on oublie de mentionner : la migration a pris 7 ans (2008-2016) et a impliqué une réécriture progressive de quasiment toute l’infrastructure. La leçon n’est pas “il faut tout refactoriser” — c’est “une migration réussie est un processus continu, pas un projet avec une date de fin”.

Le modèle opérationnel qui fonctionne ressemble à ceci : commencer par un inventaire de toutes les applications avec leur criticité, leur âge, leur dette technique et leur durée de vie prévue. Appliquer une stratégie par application. Migrer d’abord les applications les plus simples pour apprendre et accumuler de l’expérience. Utiliser les résultats de ces premières migrations pour calibrer les estimations des suivantes.

6. Ce que les chiffres ne disent pas

Les statistiques de migration sont trompeuses si on les lit sans contexte. Quelques réalités à garder en tête.

Les coûts post-migration sont presque toujours sous-estimés

En moyenne, les coûts cloud post-migration sont 23% plus élevés que prévu dans les 12 premiers mois, principalement à cause de problèmes de right-sizing (instances surdimensionnées) et de transferts de données non anticipés. La bonne pratique : intégrer une phase de FinOps — optimisation des coûts cloud — dans le plan de migration dès le départ, pas après le fait accompli.

Le refactoring prend deux fois plus de temps que prévu

C’est une constante dans les projets de modernisation applicative. Les estimations initiales tiennent rarement face à la réalité du code legacy. La règle empirique : doubler l’estimation initiale d’un projet de refactoring, puis travailler à réduire ce délai via des pratiques agiles et des scopes réduits.

La dette technique ne se rembourse pas en une fois

Le refactoring est souvent présenté comme le moyen de “se débarrasser de la dette technique une bonne fois pour toutes”. Ce n’est pas exact. La dette technique se gère — elle ne se liquide pas en un seul projet. Les organisations qui obtiennent les meilleurs résultats sont celles qui intègrent la modernisation dans leur cadence opérationnelle normale, pas celles qui lancent un grand projet de “transformation” tous les cinq ans.

7. Les outils AWS pour chaque stratégie

Stratégie	Services AWS recommandés	Cas d’usage
Rehost	AWS Application Migration Service (MGN), AWS Database Migration Service (DMS), AWS Server Migration Service	Migration automatisée de VMs et bases de données on-premise vers EC2 et RDS
Replatform	Amazon RDS (base de données managée), AWS Elastic Beanstalk, Amazon ECS (containers managés), Amazon ElastiCache	Remplacement de composants auto-gérés par des services managés équivalents
Refactor	Amazon EKS (Kubernetes managé), AWS Lambda (serverless), Amazon API Gateway, AWS Step Functions, Amazon EventBridge	Architecture microservices, event-driven, serverless — cloud natif complet
Repurchase	AWS Marketplace, intégrations SaaS partenaires	Remplacement d’une application custom par une solution SaaS disponible sur le marketplace
Évaluation et découverte	AWS Migration Hub, AWS Application Discovery Service	Inventaire automatique du parc applicatif et des dépendances avant de choisir la stratégie

8. Questions fréquentes

Est-ce qu’il faut choisir une seule stratégie pour toute la migration ?

Non — et c’est l’une des idées reçues les plus répandues. Une migration d’entreprise implique typiquement des dizaines ou des centaines d’applications, chacune avec son propre contexte. La bonne approche est d’évaluer chaque application individuellement et d’appliquer la stratégie adaptée. Il est parfaitement normal de rehoste 60% des applications, de replatformer 30% et de refactoriser les 10% les plus critiques — simultanément ou en séquence.

Le lift-and-shift est-il vraiment une erreur ?

Rarement. Il est souvent le bon choix dans un contexte d’urgence, pour des applications en fin de vie, ou comme première étape d’une migration progressive. L’erreur n’est pas de faire du lift-and-shift — c’est de s’y arrêter quand ce n’est pas la destination finale. Si votre objectif est d’optimiser les coûts et de tirer parti du cloud, un rehost est un point de départ, pas une conclusion.

Comment convaincre sa direction d’investir dans le refactoring plutôt que dans le lift-and-shift ?

Avec des chiffres à long terme, pas des arguments techniques. Le refactoring se justifie par son impact business : time-to-market réduit (déploiements plus fréquents), scalabilité (capacité à absorber la croissance sans sur-provisionner), et coûts optimisés à horizon 2-3 ans. Le lift-and-shift se justifie par l’urgence et la réduction du risque à court terme. Présenter les deux avec leurs horizons de retour sur investissement respectifs est plus convaincant que de défendre l’une contre l’autre.

Comment éviter la dérive des coûts post-migration ?

Trois pratiques font la différence. D’abord, intégrer le FinOps dès la phase de planning — pas après. Ensuite, définir des alertes de budget AWS Budgets et des dashboards Cost Explorer pour chaque projet dès le premier jour. Enfin, programmer une revue de right-sizing à 30 et 90 jours post-migration : les instances surdimensionnées représentent la majorité des surcoûts. Les organisations qui investissent dans l’optimisation des coûts pendant la migration économisent en moyenne 430 000 USD la première année.

Sources et références

DataStackHub — Cloud Transformation Statistics 2025-2026 — ROI refactoring vs lift-and-shift, données enterprise

NetApp — Cloud Migration Approach: Rehost, Refactor or Replatform?

Cloudelligent — Lift and Shift vs Refactor Migration — données réduction coûts et downtime AWS 2024

LuceIT — Lift & Shift, Replatform or Refactor: Cloud Migration Strategies

AWS — The 6 R’s of Cloud Migration (documentation officielle)