Stratégie de migration vers le cloud : la méthode des 7R expliquée

Une stratégie de migration vers le cloud ne se résume pas à « on passe sur AWS » ou « on passe sur Azure ». Derrière cette décision, il y a des dizaines d’applications, chacune avec son âge, ses dépendances, ses données et sa valeur pour le métier. La méthode des 7R sert précisément à traiter ces applications une par une, avec un vocabulaire partagé entre la DSI, la direction financière et les équipes techniques.

Cet article explique comment l’utiliser concrètement : quand migrer, comment cartographier l’existant, ce que recouvre chacun des 7R, comment construire le plan de migration et ce qu’il faut prévoir côté coûts. Pour une vue d’ensemble de nos sujets, voir notre page conseil cloud AWS et Azure.

Pourquoi migrer vers le cloud (et pourquoi pas tout de suite)

Les déclencheurs

Dans la pratique, une migration démarre rarement par conviction abstraite. Elle est déclenchée par un événement :

• Une échéance d’hébergement : fin de contrat d’infogérance ou de datacenter, renouvellement de baies, salle serveur à remettre aux normes.
• Une hausse de coûts de virtualisation : depuis le rachat de VMware par Broadcom, beaucoup d’entreprises réexaminent leur plateforme de virtualisation et leurs licences.
• L’obsolescence : systèmes d’exploitation ou bases de données en fin de support, matériel vieillissant, compétences rares pour maintenir l’existant.
• De nouveaux besoins : élasticité pour des pics de charge, services managés, ou accès aux services d’IA générative proposés par les fournisseurs cloud.

Les mauvaises raisons

La plus fréquente : « le cloud coûte moins cher ». Ce n’est pas vrai par défaut. Une application déplacée telle quelle, dimensionnée comme sur site et allumée en permanence, peut coûter plus cher dans le cloud qu’avant. Les économies viennent de l’architecture (services managés, élasticité, arrêt des environnements inutiles) et d’une gouvernance des coûts dès le premier jour. Autre mauvaise raison : migrer parce que « tout le monde le fait », sans avoir identifié ce que l’on veut gagner. Sans objectif explicite, il est impossible d’arbitrer entre les 7R.

Étape 1 : cartographier son SI avant de choisir

Inventaire applicatif et dépendances

On ne choisit pas une stratégie pour une application que l’on connaît mal. L’inventaire doit recenser, pour chaque application : les serveurs et bases associés, les flux entrants et sortants, les dépendances vers d’autres applications, les volumes de données, l’utilisation réelle (CPU, mémoire, trafic) et les responsables métier et technique.

Des outils aident à collecter ces données. Côté Microsoft, Azure Migrate propose la découverte (avec ou sans agent), l’évaluation de la compatibilité et l’estimation des coûts cible. Côté AWS, attention à un changement récent : AWS Migration Hub et Application Discovery Service ne sont plus ouverts aux nouveaux clients depuis le 7 novembre 2025, et AWS oriente désormais vers AWS Transform pour la planification et l’exécution des migrations. Si vous lisez des guides plus anciens, vérifiez donc l’outillage recommandé.

Classer les applications

Une fois l’inventaire fait, chaque application est classée selon trois axes :

• Criticité métier : que se passe-t-il si elle est indisponible une heure, une journée ?
• Nature des données : données personnelles (RGPD), données de santé (hébergement HDS obligatoire), données soumises à des exigences de résidence.
• Complexité technique : dépendances, technologies anciennes, matériel spécifique, mainframe ou Unix non x86.

Ce classement fait déjà émerger des candidats évidents : des applications simples et peu critiques pour les premières vagues, des applications sensibles qui demanderont une étude dédiée.

Les 7R de la migration cloud

La documentation AWS (Prescriptive Guidance) décrit sept stratégies, que l’on retrouve sous d’autres noms chez Microsoft.

Rehost (lift and shift)

L’application est déplacée vers le cloud sans modification. C’est l’option la plus rapide, adaptée aux migrations de volume, notamment quand une échéance d’hébergement approche. Elle ne génère pas d’optimisation en soi, mais une application déjà dans le cloud est plus facile à moderniser ensuite.

Relocate

Des serveurs, souvent en grand nombre, sont transférés d’une plateforme sur site vers la version cloud de cette même plateforme, ou des ressources sont déplacées vers un autre compte, une autre région ou un autre réseau virtuel. Pas de nouveau matériel, pas de réécriture, pas de changement d’exploitation : c’est la façon la plus rapide d’opérer dans le cloud, sans impact sur l’architecture.

Replatform

Surnommé « lift, tinker and shift » : on déplace l’application en apportant des optimisations ciblées. Exemples cités par AWS : passer une base SQL Server sur Amazon RDS, conteneuriser une application sans toucher au code, passer de Windows à Linux, ou adopter des processeurs Graviton. C’est souvent le meilleur compromis effort/bénéfice.

Refactor / ré-architecturer

L’architecture est modifiée pour tirer pleinement parti des services cloud natifs (serverless, conteneurs, services managés). Ce choix est justifié par un fort besoin métier : monolithe qui freine les évolutions, application impossible à faire évoluer, exigences de montée en charge. AWS le décrit comme la stratégie la plus complexe et la plus coûteuse, et recommande de l’éviter pendant les migrations de grande ampleur pour moderniser plutôt une fois la migration terminée.

Repurchase (passer au SaaS)

Aussi appelé « drop and shop » : l’application est remplacée par un produit du marché, souvent en SaaS. Pertinent pour les fonctions standard (messagerie, RH, CRM). Le travail ne disparaît pas : migration des données, intégration à l’annuaire d’entreprise, formation des utilisateurs, vérification de la sécurité et de la conformité de l’éditeur.

Retire

L’application est décommissionnée ou archivée. L’inventaire révèle presque toujours des applications sans utilisateurs ou sans valeur métier. AWS cite des signaux comme l’absence de connexion entrante sur les 90 derniers jours ou une utilisation CPU et mémoire très faible. Chaque application retirée, c’est du coût et du risque de sécurité en moins.

Retain

L’application reste où elle est, pour le moment : exigence de résidence des données, dépendance à un matériel spécifique (machines d’atelier), mise à niveau récente, mainframe nécessitant une étude approfondie, ou attente d’une version SaaS de l’éditeur. Retain n’est pas un échec : c’est une décision documentée, à revoir plus tard.

Tableau comparatif : effort, délai, gain, risque

Stratégie	Effort	Délai	Gain à court terme	Risque principal
Retire	Faible	Court	Suppression de coûts et de risques	Supprimer une application encore utilisée
Retain	Nul à court terme	Sans objet	Aucun	Repousser indéfiniment une décision
Rehost	Faible à moyen	Court	Sortie rapide du datacenter	Reproduire dans le cloud un surdimensionnement coûteux
Relocate	Faible	Court	Continuité d’exploitation	Rester dépendant de la plateforme de virtualisation
Repurchase	Moyen	Moyen	Moins d’infrastructure à gérer	Migration des données, dépendance à l’éditeur
Replatform	Moyen	Moyen	Services managés, coûts d’exploitation réduits	Dérive vers un refactor non prévu
Refactor	Élevé	Long	Agilité, scalabilité, coûts optimisés à terme	Dépassement de budget et de délai

6R ou 7R : d’où vient la différence ?

En 2011, Gartner décrit cinq stratégies de migration (les « 5R »). En 2016, Stephen Orban, alors chez AWS, publie « 6 Strategies for Migrating Applications to the Cloud » qui s’appuie sur ces 5R et les étend à six. Relocate a été ajouté plus tard, ce qui donne les 7R utilisés aujourd’hui dans la documentation AWS. Les deux grilles décrivent la même logique ; les 7R distinguent simplement le cas spécifique du transfert d’une plateforme virtualisée.

Construire le plan de migration

Vagues de migration et applications pilotes

On ne migre pas tout en même temps. Le plan regroupe les applications en vagues, en respectant leurs dépendances (une application et sa base migrent ensemble). La première vague sert de pilote : quelques applications peu critiques mais représentatives, pour roder les outils, les procédures de bascule et de retour arrière, et la coordination avec les métiers. Chaque vague suivante bénéficie des enseignements de la précédente.

Le socle d’abord : identité, réseau, sécurité

Avant la première application, il faut un socle (souvent appelé landing zone) : organisation des comptes ou abonnements, gestion des identités et des accès, réseau et connectivité avec le site, journalisation centralisée, règles de sécurité et de conformité. C’est ce socle qui évite que chaque équipe crée ses propres règles. Nous détaillons ces sujets dans notre approche de sécurité et gouvernance du cloud.

Infrastructure as Code dès le premier jour

Le socle et les environnements cibles doivent être décrits en code (Terraform, OpenTofu, ou les outils natifs). Bénéfices directs : des environnements reproductibles, des changements relus et tracés, une documentation vivante et une réversibilité facilitée. Rattraper l’Infrastructure as Code après la migration coûte beaucoup plus cher. Voir notre accompagnement Terraform et Infrastructure as Code.

Combien coûte une migration et comment la financer

Les postes de coût

Il n’existe pas de coût moyen fiable : tout dépend de votre inventaire et des stratégies retenues. Les postes à chiffrer sont toujours les mêmes :

• Le double run : pendant la migration, vous payez l’ancien et le nouvel environnement. Sa durée dépend directement du rythme des vagues.
• Les licences : certaines licences ne sont pas transférables dans le cloud, d’autres le sont sous conditions. C’est un poste souvent sous-estimé.
• Le travail de migration : préparation, tests, bascules, corrections.
• La montée en compétence : vos équipes vont exploiter un environnement différent. Formation et transfert de compétences sont à budgéter.
• Les coûts cible : la facture mensuelle après migration, à projeter à partir de l’utilisation réelle mesurée pendant l’inventaire.

Les programmes des fournisseurs

AWS et Microsoft proposent des programmes d’accompagnement qui peuvent réduire le coût initial :

• AWS Migration Acceleration Program (MAP), structuré en trois phases (Assess, Mobilize, Migrate & Modernize), associe méthodologie, outils, partenaires et investissements financiers. AWS ne publie pas de montants ni de critères d’éligibilité détaillés.
• Côté Microsoft, l’ancien programme Azure Migrate & Modernize est désormais présenté au sein de l’offre Azure Accelerate, qui combine accompagnement par des partenaires et financements Microsoft.

Les noms, conditions et montants de ces programmes évoluent régulièrement : vérifiez-les au moment de votre projet (informations vérifiées en octobre 2026).

Après la migration : FinOps et exploitation

Une migration réussie se mesure plusieurs mois après la bascule. Deux chantiers prennent le relais :

• La maîtrise des coûts : allocation des dépenses par application et par équipe, rightsizing, engagements d’utilisation, arrêt des environnements hors production. C’est l’objet du FinOps, que nous détaillons dans notre article FinOps : définition et leviers sur AWS et dans notre offre d’optimisation des coûts cloud.
• L’exploitation : supervision, gestion des incidents, sauvegardes testées, mises à jour, procédures documentées. Les applications rehostées sont aussi les premières candidates à une modernisation, maintenant qu’elles sont dans le cloud.

Checklist avant de lancer votre migration

• Objectifs de la migration écrits et partagés (coûts, échéance, agilité, sécurité)
• Inventaire applicatif complet, avec dépendances et utilisation réelle
• Classement par criticité, sensibilité des données et complexité
• Une stratégie 7R décidée et justifiée pour chaque application
• Socle cible conçu (identités, réseau, sécurité, journalisation) et décrit en code
• Plan de vagues avec une vague pilote et des critères de retour arrière
• Estimation du double run, des licences et de la formation
• Gouvernance des coûts prête avant la première bascule

Prochaine étape

Si vous préparez une migration et souhaitez confronter vos choix à un regard extérieur, nous pouvons vous aider à cartographier votre SI et à construire un plan réaliste, depuis notre base de Villeneuve-d’Ascq dans la métropole lilloise ou à distance. Découvrez notre accompagnement à la migration vers AWS et Azure.

[ VOS QUESTIONS ]

Questions fréquentes

Pourquoi migrer vers le cloud ?

Les bonnes raisons sont concrètes : fin de contrat d’hébergement, matériel ou logiciels en fin de support, besoin d’élasticité, accès à des services managés ou à l’IA. Le cloud n’est pas moins cher par défaut : il le devient quand l’architecture et la gouvernance des coûts sont adaptées.

Quelle est la différence entre lift and shift, replatform et refactor ?

Le lift and shift (rehost) déplace l’application sans la modifier. Le replatform apporte quelques optimisations ciblées, comme le passage à une base de données managée. Le refactor modifie l’architecture pour tirer parti des services cloud natifs : c’est l’option la plus coûteuse et la plus longue.

6R ou 7R : quelle différence ?

Les 6R ont été popularisés par AWS en 2016 à partir des 5R décrits par Gartner en 2011. AWS a ensuite ajouté Relocate, qui consiste à déplacer une plateforme virtualisée vers sa version cloud sans changer l’application. Les 7R sont la version utilisée aujourd’hui dans la documentation AWS.

Combien coûte une migration cloud ?

Il n’existe pas de prix moyen fiable : le coût dépend du nombre d’applications, des stratégies retenues, de la durée du double run, des licences et de l’effort de formation. Une estimation sérieuse part de l’inventaire applicatif et d’une projection des coûts cible, puis intègre les éventuels programmes de financement des fournisseurs.

AWS ou Azure pour migrer ?

Les deux plateformes couvrent les 7R et proposent des outils de découverte et de migration. Le choix dépend surtout de votre existant (environnement Microsoft, compétences internes, contrats), des services dont vous aurez besoin et de vos exigences de conformité. Nous restons neutres et documentons ce choix avec vous.

Sources

• AWS Prescriptive Guidance : About the migration strategies (7 Rs)
• AWS Enterprise Strategy Blog : 6 Strategies for Migrating Applications to the Cloud (Stephen Orban, 2016)
• AWS Migration Hub : availability change (fermeture aux nouveaux clients)
• AWS Migration Acceleration Program (MAP)
• Microsoft Learn : About Azure Migrate
• Microsoft Partner : Azure Accelerate et offres de migration