Migration d’application vers le cloud

Migrer une application vers le cloud n'est pas déplacer un serveur : c'est décider, pour chaque brique applicative, entre la déplacer telle quelle, l'adapter, la réécrire, la remplacer ou ne rien faire, et ces décisions engagent votre budget, votre conformité et votre dette technique pour des années. Ce guide francophone va plus loin que les pages génériques des éditeurs : arbre de décision 6R appliqué par type d'application, comparatif neutre Azure contre AWS, FinOps de migration, conformité RGPD, HDS et DORA, timeline et budget réels en France. L'objectif : que vous décidiez en connaissance de cause, et que ce qui est construit vous appartienne vraiment.

Qu'est-ce que la migration d'une application vers le cloud ?

La migration d'application vers le cloud consiste à transférer une application, son code, ses composants d'exécution et souvent ses données, depuis un environnement existant (datacenter sur site, hébergeur traditionnel, ancien cloud) vers une plateforme cloud comme Microsoft Azure ou AWS. L'enjeu n'est pas seulement de « faire tourner » l'application ailleurs : c'est de la faire bénéficier de l'élasticité, des services managés et du modèle économique du cloud, sans casser ce qui fonctionne.

Il faut distinguer trois objets souvent confondus :

• La migration d'application porte sur la charge de travail applicative elle-même : le serveur web, le serveur d'application, les traitements métier, les API. C'est le cœur du sujet de cette page.
• La migration de données porte sur les bases de données et les volumes de fichiers que l'application manipule. Elle est généralement couplée à la migration applicative, mais obéit à ses propres contraintes (volumétrie, cohérence, fenêtre de bascule, réplication).
• La migration d'infrastructure porte sur les serveurs, le réseau, le stockage : le « plancher » sur lequel reposent les applications. On parle alors plutôt de migration de serveurs ou de migration VMware.

À retenir : une migration applicative réussie ne se juge pas au fait que « ça démarre dans le cloud », mais au fait que l'application est plus disponible, plus économique à exploiter, conforme et exempte de dette technique inutile. Déplacer un problème dans le cloud ne le résout pas : il le rend souvent plus cher.

Dans la pratique, une migration applicative s'inscrit dans une démarche plus large de migration cloud d'entreprise, qui couvre la stratégie, la fondation (landing zone), la sécurité, le FinOps et l'exploitation. Cette page traite spécifiquement de la couche applicative.

Les 6R (et 7R) de la migration cloud

Le modèle des 6R (parfois étendu à 7R) est le cadre de référence pour décider, application par application, de la stratégie de migration. Il vient des travaux de Gartner et a été popularisé par AWS. Chaque « R » est une trajectoire différente, avec son coût, son délai et son niveau de risque propres. La compétence d'architecte consiste à appliquer le bon « R » à la bonne application, et non à imposer une stratégie unique à tout le parc.

| Stratégie | En clair | Effort / Coût | Délai | Risque | Bénéfice cloud | |---|---|---|---|---|---| | Rehost (lift-and-shift) | Déplacer tel quel, sans modifier le code | Faible | Court | Faible technique, élevé sur le coût final | Faible | | Replatform (lift-tinker-shift) | Déplacer avec quelques optimisations (base managée, conteneur) | Moyen | Moyen | Moyen | Moyen | | Refactor / Rearchitect | Réécrire pour tirer parti du cloud (microservices, serverless) | Élevé | Long | Élevé | Élevé | | Repurchase | Remplacer par une solution SaaS | Variable | Court à moyen | Moyen (reprise de données) | Élevé | | Retire | Décommissionner ce qui ne sert plus | Faible | Court | Faible | Suppression de coût | | Retain | Conserver sur site / ne pas migrer maintenant | Nul | — | Faible | Aucun (volontaire) | | Relocate | Déplacer un hyperviseur entier sans conversion (ex. VMware) | Faible | Court | Faible | Faible à moyen |

Rehost (lift-and-shift)

Le rehost déplace l'application telle quelle, généralement de machine virtuelle à machine virtuelle, sans toucher au code. C'est la trajectoire la plus rapide et la moins risquée techniquement. Elle convient quand le temps presse (fin de bail datacenter, fin de support matériel) ou quand l'application n'a pas vocation à évoluer.

Son piège majeur est financier : une VM sur site est un coût fixe déjà amorti ; la même VM dans le cloud, allumée 24/7 et surdimensionnée, génère une facture mensuelle qui peut dépasser le coût d'origine. Un lift-and-shift brut, sans rightsizing ni engagement, est la première cause d'explosion de la facture cloud après migration.

La mécanique d'un rehost au niveau infrastructure (réplication de la machine virtuelle, agentless ou avec agent, bascule, fenêtre d'arrêt) relève de la couche serveur, pas de la couche applicative. Elle est détaillée sur notre page migration de serveurs (rehost) vers le cloud. Au niveau d'une application, le rehost reste avant tout une décision de portefeuille (le « R » par défaut quand le temps presse) et non une fin en soi.

Replatform (lift-tinker-shift)

Le replatform déplace l'application en remplaçant quelques composants par des services managés, sans réécrire la logique métier. Exemples typiques : migrer une base de données SQL Server vers Azure SQL Database ou Amazon RDS, conteneuriser une application sans en changer l'architecture, remplacer un serveur de messages auto-hébergé par un service managé. C'est souvent le meilleur rapport effort/bénéfice : on gagne en disponibilité et en exploitation déléguée pour un effort modéré.

Refactor / Rearchitect

Le refactor réécrit tout ou partie de l'application pour exploiter pleinement le cloud : découpage d'un monolithe en microservices, passage en serverless (Azure Functions, AWS Lambda), conteneurisation orchestrée par Kubernetes (AKS sur Azure, EKS sur AWS). C'est la trajectoire la plus coûteuse et la plus longue, mais la seule qui débloque l'agilité, la scalabilité fine et la réduction durable du coût unitaire. On la réserve aux applications stratégiques, à fort trafic ou en évolution constante.

Repurchase, Retire, Retain

• Repurchase : abandonner une application développée en interne au profit d'une solution SaaS du marché (un CRM maison remplacé par Salesforce ou Dynamics 365). Pertinent quand l'application ne constitue pas un avantage concurrentiel. Le vrai travail est la reprise et la migration des données.
• Retire : identifier ce qui ne sert plus. Sur la plupart des parcs, 10 à 20 % des applications inventoriées sont des candidats au décommissionnement. C'est du coût et du risque supprimés gratuitement.
• Retain : décider, en conscience, de ne pas migrer maintenant. Certaines applications (forte latence matérielle, fin de vie proche, contrainte réglementaire) ont vocation à rester sur site ou à attendre. Le « R » le plus mature est parfois de ne rien faire.

Relocate, le 7e R

Le relocate déplace un environnement de virtualisation entier (typiquement un cluster VMware) vers le cloud sans convertir les machines une à une (via VMware Cloud on AWS ou Azure VMware Solution). Utile pour évacuer un datacenter vite, en conservant les outils VMware existants, avant une modernisation ultérieure. Voir nos pages dédiées à la migration VMware vers Azure et à la migration VMware vers AWS.

Arbre de décision 6R par type d'application

C'est ici que la plupart des contenus s'arrêtent à la théorie. Voici comment le modèle s'applique concrètement, par type d'application réelle. Les coûts et délais ci-dessous sont des ordres de grandeur indicatifs, à affiner par diagnostic, jamais des prix fermes.

ERP (SAP, Sage, Dynamics on-premise)

Un ERP est critique, fortement couplé et souvent éditeur-dépendant. La trajectoire dépend de l'éditeur :

• Repurchase vers la version SaaS de l'éditeur (S/4HANA Cloud, Business Central) si elle existe et couvre vos processus.
• Rehost / Replatform vers des VM cloud certifiées par l'éditeur si vous gardez la version actuelle.
• Refactor rarement pertinent sur un ERP : le code appartient à l'éditeur.

Ordre de grandeur : projet long (plusieurs mois), risque élevé, à ne jamais traiter en big-bang. La fenêtre de bascule et le plan de rollback sont déterminants.

Application métier .NET ou Java legacy

C'est le cas le plus fréquent en France. Une application développée en interne, monolithique, en .NET Framework ou Java, qui tourne depuis des années :

• Replatform est souvent le meilleur point d'équilibre : conteneuriser, externaliser la base vers une instance managée, sans réécrire la logique. Effort moyen, gain réel.
• Refactor si l'application est stratégique et bride le métier : découpage progressif, par le pattern « strangler fig » (on remplace le monolithe morceau par morceau).
• Rehost seulement comme étape transitoire, jamais comme cible définitive sur un monolithe non optimisé.

Lifter un monolithe legacy non optimisé est l'erreur la plus coûteuse du marché : vous payez du cloud au prix fort sans aucun bénéfice cloud.

Base de données

Une base de données se traite à part de l'application qui la consomme :

• Replatform vers une base managée (Azure SQL Database, Amazon RDS ou Aurora) supprime l'administration serveur et améliore la disponibilité.
• Outils dédiés : AWS Database Migration Service (DMS) et Azure Database Migration Service permettent une migration à chaud avec réplication continue, pour minimiser la fenêtre d'arrêt.
• Le risque clé est la cohérence des données et la fenêtre de bascule (voir la section bascule à chaud / à froid plus bas).

Application stateless (web, API)

Une application sans état (serveur web sans session locale, API REST) est la candidate idéale au cloud moderne :

• Replatform en conteneurs sur AKS / EKS, ou Refactor en serverless si la charge est intermittente.
• Effort faible à moyen, risque faible, bénéfice élevé (scalabilité automatique, paiement à l'usage).
• C'est souvent par là qu'on commence une migration, pour engranger des succès rapides.

Application remplaçable par un SaaS

Messagerie, gestion documentaire, CRM, paie, outils internes secondaires :

• Repurchase vers une solution SaaS éprouvée. Inutile de migrer et maintenir ce que le marché propose mieux et moins cher.
• Le projet devient un projet de reprise de données et de conduite du changement, pas un projet d'infrastructure.

Le bon réflexe : aucune migration sérieuse n'applique une seule stratégie. Un parc réel se répartit entre plusieurs « R ». L'analyse de portefeuille (quelle application reçoit quel « R ») est le livrable le plus structurant, et celui qui conditionne le budget total.

Modèles de cloud cible : public, privé, hybride, multicloud

Avant de choisir comment migrer, il faut choisir vers quoi migrer.

• Cloud public : ressources mutualisées et opérées par un fournisseur (Azure, AWS, Google Cloud). Élasticité maximale, paiement à l'usage, pas d'investissement matériel. C'est la cible par défaut de la majorité des migrations.
• Cloud privé : infrastructure dédiée à une seule organisation, hébergée sur site ou chez un tiers. Justifié par des contraintes réglementaires fortes ou une souveraineté stricte.
• Cloud hybride : combinaison maîtrisée de cloud public et de ressources sur site, reliées par un réseau sécurisé. Fréquent en phase de transition, ou pour garder certaines données ultra-sensibles à demeure.
• Multicloud : usage de plusieurs clouds publics en parallèle. Apporte de la résilience et limite la dépendance à un fournisseur, mais multiplie la complexité et les compétences requises. À choisir pour de bonnes raisons, pas par réflexe.

Le choix relève de l'architecture autant que de la stratégie : il engage la souveraineté des données, le coût et la complexité d'exploitation. C'est typiquement un sujet de conseil en architecture et de gouvernance cloud.

Modèles de service : IaaS, PaaS, SaaS, CaaS

Le modèle de service détermine ce que vous gérez et ce que le fournisseur gère. C'est directement lié au modèle de responsabilité partagée (voir plus bas).

• IaaS (Infrastructure as a Service) : le fournisseur opère le matériel, la virtualisation et le réseau ; vous gérez l'OS, les middlewares et l'application. C'est la cible naturelle d'un rehost (VM dans le cloud).
• PaaS (Platform as a Service) : le fournisseur opère aussi le runtime, le système d'exploitation et le scaling ; vous ne gérez que votre code et vos données (App Service, bases managées, fonctions). C'est la cible d'un replatform ou d'un refactor.
• SaaS (Software as a Service) : application complète opérée par un éditeur, consommée par abonnement. C'est la cible d'un repurchase.
• CaaS (Containers as a Service) : exécution de conteneurs orchestrés (AKS, EKS, ECS). Modèle intermédiaire qui combine portabilité et services managés, central dans la modernisation applicative.

La règle générale : plus on monte vers le PaaS/SaaS, moins on gère d'infrastructure et plus on bénéficie du cloud, au prix d'une adaptation applicative plus forte. Le bon arbitrage se fait application par application.

Les bénéfices d'une migration applicative bien menée

Une migration n'est pas une fin en soi : elle doit servir des objectifs mesurables.

• Scalabilité : adapter automatiquement les ressources à la charge réelle, sans surinvestir « au cas où ». Un pic de trafic n'impose plus d'acheter du matériel à l'avance.
• Réduction du TCO : sous condition de FinOps (rightsizing, engagements, extinction hors usage), le coût total de possession baisse. Sans cette discipline, il peut au contraire augmenter, d'où l'importance du business case.
• Agilité : déployer plus souvent et plus vite grâce au DevOps et à l'IaC. Les organisations matures observent une fréquence de déploiement très supérieure après modernisation.
• Résilience et disponibilité : redondance multi-zones, sauvegardes managées, PRA outillé. On vise une disponibilité plus élevée et constatée, sans jamais la promettre comme garantie absolue.
• Sécurité : services de sécurité natifs, posture mesurée en continu (Microsoft Defender for Cloud, AWS Security Hub), chiffrement par défaut. À condition d'être configurés correctement : le cloud n'est pas sécurisé « par magie ».

Honnêteté sur le TCO : ces bénéfices ne sont pas automatiques. Ils découlent d'une migration conçue pour les obtenir. Un lift-and-shift brut livre rarement ces gains. C'est la raison d'être de l'analyse de portefeuille et du FinOps en amont.

Les étapes d'une migration cloud réussie

Une migration applicative suit une démarche éprouvée. Sauter une étape, c'est accumuler le risque pour plus tard.

1. Évaluation et découverte (assessment)

On inventorie le parc applicatif : technologies, versions, criticité, coûts actuels, contraintes réglementaires. Les outils d'Application Discovery (Azure Migrate, AWS Application Discovery Service) automatisent une partie de ce recensement. Le livrable est une cartographie objective de l'existant : on ne migre bien que ce qu'on connaît précisément.

2. Cartographie des dépendances

C'est l'étape la plus souvent bâclée, et la plus dangereuse à négliger. Une application ne vit jamais seule : elle dépend de bases, de services tiers, de flux réseau, d'annuaires, de tâches planifiées. Cartographier ces dépendances évite de migrer une application en cassant ce qui la nourrit. Les outils de découverte tracent ces dépendances automatiquement à partir du trafic réseau observé.

3. Planification et roadmap

On affecte un « R » à chaque application, on les ordonne en vagues (les plus simples et les moins critiques d'abord, pour rôder l'équipe et le processus), et on construit la feuille de route alignée sur les objectifs business. C'est aussi à ce stade qu'on conçoit le business case FinOps (TCO avant/après) et qu'on dimensionne la landing zone.

4. Exécution

On migre par vagues : préparation de l'environnement cible, migration des données, bascule applicative, tests de non-régression, mise en production. Chaque vague valide le processus et réduit l'incertitude de la suivante.

5. Optimisation post-migration

La migration ne s'arrête pas à la bascule. On rightsize les ressources sur la base de l'usage réel, on active les engagements (réservations, Savings Plans), on règle la sécurité, on suit les KPIs. C'est la phase qui transforme une migration « qui tourne » en migration « rentable et durable ». Elle rejoint l'optimisation des coûts cloud.

La landing zone : la fondation avant la migration

Migrer des applications dans un cloud non gouverné, c'est construire sur du sable. La landing zone (zone d'atterrissage) est l'environnement cloud préconfiguré (identité, réseau, sécurité, supervision, gouvernance, FinOps) qui accueille vos applications dans un cadre maîtrisé dès le premier déploiement.

• Sur Azure, elle repose sur le Cloud Adoption Framework (CAF) et l'architecture de référence Azure Landing Zone. Voir notre guide dédié à la landing zone Azure.
• Sur AWS, elle s'appuie sur Control Tower et le Landing Zone Accelerator, cadrés par le Well-Architected Framework et ses six piliers. Voir notre guide landing zone AWS.

Sans landing zone, chaque application migrée crée ses propres réseaux, ses propres accès, ses propres règles. Et l'ensemble dérive en quelques mois vers l'ingouvernable. Poser la fondation d'abord, migrer ensuite : c'est l'ordre qui évite le chantier de rattrapage. C'est aussi ce qui permet d'imposer, par construction, la conformité et le contrôle des coûts.

Conformité française et européenne : RGPD, HDS, DORA, souveraineté

C'est la lacune systématique de tout le SERP francophone : les contenus traduits des éditeurs ignorent le cadre réglementaire français. Une migration applicative sérieuse en France l'intègre dès la conception.

RGPD : responsable de traitement et sous-traitant

Lors d'une migration, vous restez responsable de traitement au sens du RGPD. Le fournisseur cloud (Azure, AWS) agit comme sous-traitant, encadré par l'article 28 : il faut un contrat de sous-traitance, des garanties sur la localisation des données et la maîtrise des transferts hors UE. Concrètement, la migration doit fixer les régions de déploiement (régions françaises ou européennes), le chiffrement et la journalisation des accès, pour rendre la conformité explicite et auditable. C'est un sujet central de conformité cloud.

HDS : données de santé

Si l'application traite des données de santé, l'hébergement doit s'appuyer sur un hébergeur certifié HDS (Hébergeur de Données de Santé) et sur des services éligibles. Point essentiel à ne jamais travestir : la certification HDS vise l'hébergeur, pas votre configuration ni votre prestataire. Azure et AWS disposent d'offres éligibles ; l'architecture doit s'y conformer. Voir nos enjeux par secteur santé.

DORA : finance et assurance

Le règlement DORA (Digital Operational Resilience Act) impose aux acteurs financiers et assurantiels une résilience opérationnelle numérique : tests de résilience, gestion du risque lié aux prestataires tiers (dont les fournisseurs cloud), et réversibilité. Une migration applicative dans ce secteur doit intégrer ces exigences dès la roadmap. Voir nos enjeux par secteur finance.

SecNumCloud et souveraineté

Pour les organisations soumises à des exigences de souveraineté fortes (secteur public, opérateurs sensibles), la qualification SecNumCloud de l'ANSSI et les offres de cloud souverain entrent en jeu. Le choix de la cible (cloud public hyperscaler, offre souveraine, hybride) doit être tranché en fonction de la sensibilité réelle des données, pas par défaut. Voir nos enjeux par secteur public.

Pourquoi c'est décisif : la conformité n'est pas une couche qu'on ajoute après la migration. Migrer des données de santé sur une région non éligible, ou ignorer DORA dans la finance, oblige à tout refaire, au prix fort. La conformité se conçoit en amont, dans la landing zone et l'analyse de portefeuille.

FinOps de migration : éviter l'explosion de la facture

Le piège le plus coûteux d'une migration n'est pas technique : c'est financier. Une discipline FinOps appliquée avant et pendant la migration est ce qui sépare une migration rentable d'une facture qui dérape.

Le business case avant/après

Avant de migrer, on modélise le TCO (coût total de possession) on-premise actuel (matériel amorti, énergie, maintenance, licences, personnel) et on le compare au TCO cloud cible. Cette comparaison honnête est ce qui justifie (ou non) chaque trajectoire. Un rehost brut affiche souvent un TCO cloud supérieur au on-premise : c'est ce que le business case révèle, et ce qui pousse vers le replatform ou le rightsizing.

| Poste | On-premise | Cloud (bien optimisé) | |---|---|---| | Matériel / serveurs | CAPEX amorti, renouvellement cyclique | Aucun (OPEX) | | Énergie, datacenter | Coût fixe récurrent | Inclus dans le service | | Dimensionnement | Surdimensionné « au cas où » | Rightsizé sur l'usage réel | | Charges stables | Coût fixe | Réservations / Savings Plans | | Charges intermittentes | Coût fixe permanent | Paiement à l'usage / Spot | | Disponibilité | Investissement matériel | Redondance native |

Le piège du lift-and-shift

Lifter une VM surdimensionnée, allumée 24/7, à la demande, sans engagement : c'est le scénario qui multiplie la facture. Les leviers FinOps post-migration corrigent cela :

• Rightsizing : ajuster la taille des ressources à la consommation réelle observée, souvent moitié moindre que le dimensionnement on-premise.
• Réservations et Savings Plans : engager les charges stables et prévisibles sur 1 ou 3 ans réduit fortement le coût horaire (Reserved Instances, Savings Plans sur Azure et AWS).
• Spot / instances ponctuelles (AWS) : pour les charges interruptibles, batch et tolérantes aux coupures.
• Extinction hors usage : éteindre les environnements de test et de développement la nuit et le week-end.
• Coûts d'egress : anticiper les frais de transfert sortant de données, souvent oubliés, qui peuvent peser lourd sur des applications fortement échangeuses de données.

En tant que membre de la FinOps Foundation, nous intégrons ces leviers dès l'analyse de portefeuille, pas après coup. Pour un environnement déjà migré et dérivé, le chantier relève de l'optimisation des coûts cloud ou d'un audit FinOps.

Azure ou AWS pour migrer ses applications ? Un comparatif neutre

Tous les contenus de référence sur ce sujet sont publiés par un éditeur, donc orientés. En tant qu'intermédiaire indépendant, non lié à un éditeur, nous proposons un comparatif honnête des outils et services de migration. La conclusion utile : les deux clouds permettent d'excellentes migrations ; le choix tient davantage à votre existant, vos compétences et vos contraintes qu'à une supériorité intrinsèque.

| Domaine | Microsoft Azure | AWS | |---|---|---| | Découverte & évaluation | Azure Migrate (discovery, assessment, dépendances) | Application Discovery Service, Migration Evaluator | | Migration de serveurs/VM | Azure Migrate: Server Migration | AWS Application Migration Service (MGN) | | Migration de bases | Azure Database Migration Service | AWS Database Migration Service (DMS) | | Programme cadré & financement | Azure Migrate and Modernize | Migration Acceleration Program (MAP) | | Fondation / landing zone | Cloud Adoption Framework, Azure Landing Zone | Control Tower, Landing Zone Accelerator | | Cadre de qualité | Azure Well-Architected Framework | Well-Architected Framework (6 piliers) | | Conteneurs managés | AKS | EKS, ECS | | Serverless | Azure Functions | AWS Lambda | | Identité | Microsoft Entra ID | IAM Identity Center | | Posture de sécurité | Microsoft Defender for Cloud | AWS Security Hub | | Coûts | Azure Cost Management | AWS Cost Explorer | | Engagements | Reserved Instances, Savings Plans | Reserved Instances, Savings Plans, Spot | | IaC natif | Bicep (+ Terraform) | CloudFormation (+ Terraform) |

Quand pencher vers Azure : parc fortement Microsoft (Windows Server, SQL Server, Active Directory, Microsoft 365), licences existantes valorisables (Azure Hybrid Benefit), intégration Entra ID native.

Quand pencher vers AWS : maturité DevOps avancée, besoin de la palette de services la plus large, charges cloud-native déjà présentes, multicloud assumé.

Dans les deux cas, Terraform permet de décrire l'infrastructure de façon portable et de limiter la dépendance à un fournisseur. C'est un sujet de fond traité avec notre architecte Azure et les experts AWS de notre réseau.

Notre position d'indépendant : nous n'avons aucun intérêt à vous orienter vers un cloud plutôt que l'autre : nous ne sommes pas revendeurs. Le choix se fait sur vos critères, pas sur notre marge. C'est l'avantage structurel d'un intermédiaire indépendant que les éditeurs ne peuvent pas offrir.

Sécurité by-design pendant la migration

La sécurité ne se rajoute pas après la bascule : elle se conçoit pendant la migration, sans quoi vous migrez aussi vos vulnérabilités.

• Modèle de responsabilité partagée : le fournisseur sécurise le cloud (matériel, réseau physique, hyperviseur) ; vous sécurisez ce qui est dans le cloud (OS, application, données, accès). Migrer ne transfère pas votre part de responsabilité au fournisseur : il faut la couvrir explicitement.
• IAM et identité : appliquer le moindre privilège via Entra ID (Azure) ou IAM Identity Center (AWS), des rôles plutôt que des comptes individuels, l'authentification multifacteur et l'activation à la demande des droits sensibles.
• Chiffrement : chiffrer les données en transit (TLS) et au repos (clés gérées), par défaut, dès la migration.
• Durcissement : appliquer les CIS Benchmarks aux ressources cibles, plutôt que de migrer des configurations laxistes existantes.
• Posture continue : activer Microsoft Defender for Cloud ou AWS Security Hub pour mesurer et suivre la posture de sécurité en continu, dès la mise en production.

Cette discipline relève d'une démarche plus large de sécurisation de l'infrastructure cloud et de cybersécurité cloud. Architecte Cloud inscrit sa démarche dans le référentiel ISO 27001 et met en relation avec des prestataires disposant des certifications requises (CISSP, Azure Security Engineer).

Stratégie de bascule : big-bang ou par vagues ?

La manière de basculer en production est aussi décisive que la stratégie de migration.

• Big-bang : tout bascule en une seule fenêtre. Plus rapide, mais le risque est concentré et le rollback peut être brutal. Réservé aux applications simples, peu critiques, ou aux cas où la coexistence est impossible.
• Par vagues (phased) : on migre par lots successifs, en validant chaque vague avant la suivante. Plus long, mais le risque est étalé et maîtrisé. C'est l'approche par défaut pour un parc applicatif réel et pour toute application critique.

Migration de données : à chaud ou à froid

• À froid : on arrête l'application, on copie les données, on bascule. Simple, mais impose une fenêtre d'indisponibilité proportionnelle à la volumétrie.
• À chaud : on réplique les données en continu (via DMS, Database Migration Service) pendant que l'application reste en service, puis on bascule sur un delta minimal. Fenêtre d'arrêt réduite à quelques minutes, au prix d'une mise en œuvre plus technique. Indispensable pour les applications qui ne tolèrent pas l'interruption.

Plan de rollback et tests de non-régression

Aucune bascule ne se lance sans plan de rollback documenté : la procédure exacte pour revenir à l'état antérieur si la bascule échoue, dans un délai défini. Et chaque application migrée passe une batterie de tests de non-régression (fonctionnels, de performance, de sécurité) avant validation. Migrer sans filet de retour est un pari, pas une méthode.

Le réflexe d'expert : la fenêtre de bascule se prépare comme une opération chirurgicale : répétée en pré-production, minutée, avec critères de go/no-go et plan de retour. C'est ce qui transforme un risque en non-événement.

KPIs et métriques de succès post-migration

Une migration se pilote par des indicateurs, pas par une impression. Les KPIs à suivre après bascule :

• RTO / RPO : temps de reprise et perte de données maximale tolérée, mesurés par des tests de PRA réels, pas seulement déclarés. Voir notre approche du PRA cloud.
• Disponibilité observée : le taux de disponibilité réellement constaté sur la période, et non un chiffre promis.
• Coût par application : grâce au tagging, suivre le coût mensuel imputable à chaque application, base du FinOps continu.
• DORA metrics (DevOps Research and Assessment) : fréquence de déploiement, délai de mise en production, taux d'échec des changements, temps de restauration. Elles mesurent l'agilité réelle gagnée par la modernisation.
• Dette technique résorbée : nombre de composants obsolètes décommissionnés, applications modernisées, configurations durcies.

Ces métriques relèvent ensuite d'une infogérance cloud d'entreprise qui exploite et optimise le parc dans la durée.

Outils d'évaluation et de migration

Les hyperscalers fournissent un outillage complet : découverte, évaluation, réplication, bascule. À l'échelle applicative, l'essentiel tient en une phrase : ces outils exécutent une stratégie 6R, ils ne la décident pas. Migrer vite une mauvaise architecture ne fait que produire vite une mauvaise architecture cloud. Voici les chaînes par plateforme, et où en trouver les mécaniques détaillées.

• Côté Azure, l'outillage s'articule autour d'Azure Migrate (découverte, évaluation, dépendances, bascule de serveurs), d'Azure Database Migration Service pour les bases et du programme Azure Migrate and Modernize. Le détail des mécaniques (agentless vs agent, réplication initiale/différentielle/bascule, migration de test, levier de l'Azure Hybrid Benefit) est traité sur notre page migration de serveurs vers Azure (Azure Migrate, Hybrid Benefit).
• Côté AWS, la chaîne repose sur Application Discovery Service, Application Migration Service (MGN) pour la bascule des serveurs, Database Migration Service (DMS) pour les bases et le Migration Acceleration Program (MAP). Les mécaniques détaillées et l'arbitrage de souveraineté propre à AWS sont couverts sur migration de serveurs vers AWS (MGN, souveraineté).

Pour un parc virtualisé entier, la trajectoire relève d'un outillage spécifique (HCX, AVS, EVS) : voir sortie VMware vers Azure (AVS) ou sortie VMware vers AWS (EVS). Au niveau applicatif, l'enjeu n'est pas l'outil mais l'orchestration : quelle application part dans quelle vague, avec quel « R », sous quelle contrainte de conformité : c'est la décision que cette page outille, là où les pages serveur outillent l'exécution.

Conduite du changement et montée en compétence

Une migration applicative est aussi un projet humain. Le déficit de compétences cloud est l'un des premiers obstacles cités par les organisations. Réussir suppose :

• de former les équipes aux nouveaux outils (cloud, IaC, conteneurs, supervision) avant et pendant la migration ;
• d'accompagner le changement de pratiques (DevOps, CI/CD, exploitation cloud) ;
• de transférer la connaissance plutôt que de créer une dépendance au prestataire : la documentation et le code remis font partie du livrable.

C'est un point où notre positionnement est ferme : nous rendons vos équipes autonomes. Le code IaC est versionné dans vos dépôts, les comptes sont à votre nom, la documentation vous est remise. Pas d'enfermement.

Réversibilité et anti-vendor-lock-in

Le vendor lock-in (la dépendance excessive à un fournisseur dont on ne peut plus sortir) est un risque réel d'une migration mal pensée, et une exigence réglementaire dans la finance (DORA). Nos principes pour le neutraliser :

• IaC dans vos dépôts : toute l'infrastructure est décrite en Terraform ou Bicep, versionnée dans vos dépôts Git. Vous pouvez la redéployer, la modifier, ou la confier à un autre prestataire.
• Comptes au nom du client : les abonnements et comptes cloud sont à votre nom, pas au nôtre. Vous gardez la propriété et le contrôle.
• Stratégie d'exit documentée : la manière de sortir du cloud ou de changer de fournisseur est pensée dès la conception, pas découverte au moment de partir.
• Portabilité par les conteneurs : conteneuriser une application (Kubernetes) réduit l'adhérence à un cloud précis et facilite un éventuel changement.

Notre principe : ce que les prestataires de notre réseau construisent vous appartient. La réversibilité n'est pas une option de fin de contrat, c'est une propriété de l'architecture, posée dès le premier jour.

Conteneurs, Kubernetes et IA dans la modernisation

La modernisation applicative s'appuie de plus en plus sur les conteneurs et l'orchestration Kubernetes (AKS sur Azure, EKS sur AWS). Ils apportent portabilité, scalabilité fine et déploiements reproductibles, au prix d'une complexité d'exploitation réelle qu'il ne faut pas sous-estimer. Découper un monolithe en microservices conteneurisés est l'aboutissement d'un refactor, à réserver aux applications qui le justifient.

L'automatisation et l'IA interviennent aujourd'hui dans l'assessment (analyse de dépendances, recommandation de trajectoire) et dans l'aide à la réécriture de code legacy. Ce sont des accélérateurs, pas des décisionnaires : la responsabilité de l'architecture reste humaine. Pour la dimension industrialisation, voir notre infrastructure DevOps.

Erreurs fréquentes à éviter

Les pièges que nous corrigeons le plus souvent sur le terrain (fort potentiel de coût évité) :

• Lifter un monolithe non optimisé et le laisser tel quel : vous payez du cloud au prix fort sans aucun bénéfice cloud.
• Sous-estimer les coûts d'egress et de transfert de données : un poste invisible au départ qui plombe la facture d'applications échangeuses.
• Oublier la reprise après sinistre : migrer sans PRA outillé, en croyant que « le cloud est résilient par défaut ». Il ne l'est que si on le configure.
• Migrer sans landing zone : chaque application crée ses propres règles, l'ensemble devient ingouvernable en quelques mois.
• Négliger la cartographie des dépendances : casser un flux invisible le jour de la bascule.
• Pas de plan de rollback : se retrouver sans solution de retour quand une bascule échoue.
• Ignorer la conformité en amont : migrer des données de santé sur une région non éligible, ou oublier DORA dans la finance, et devoir tout refaire.
• Sauter le FinOps post-migration : ne jamais rightsizer ni engager les charges stables, et laisser la facture filer.
• Confondre vitesse et réussite : migrer vite une mauvaise architecture produit vite une mauvaise architecture cloud.

Cas d'usage sectoriels en France

• Santé : applications manipulant des données de santé, contraintes par l'hébergement chez un partenaire certifié HDS. La trajectoire et la cible se choisissent sous cette contrainte. Voir secteur santé.
• Finance et assurance : exigences DORA de résilience, de tests et de réversibilité. La migration intègre la gestion du risque tiers dès la roadmap. Voir secteur finance.
• Industrie : applications métier legacy, souvent .NET/Java, candidates au replatform, avec des contraintes de continuité de production. Voir secteur industrie.
• Distribution : forte saisonnalité, pics de charge. La scalabilité du cloud y prend tout son sens. Voir secteur distribution.
• Secteur public : enjeux de souveraineté et de qualification SecNumCloud. Voir secteur public.
• Éditeurs SaaS : modernisation pour la scalabilité et le multitenant, souvent par refactor et conteneurisation. Voir secteur SaaS.

Combien coûte une migration d'application vers le cloud ? Durée, budget, livrables

C'est la question YMYL par excellence. Nous y répondons par une fourchette indicative, jamais par un prix ferme : annoncer un montant sans avoir audité votre contexte serait trompeur.

Durée indicative

Pour une migration applicative cadrée, le délai indicatif se situe entre 3 et 10 semaines sur un périmètre défini. Il varie selon :

• le nombre d'applications et leur criticité ;
• la stratégie retenue (un rehost est rapide, un refactor prend des mois) ;
• la bascule (par vagues étale le calendrier mais sécurise) ;
• les exigences de conformité (HDS, DORA ajoutent des étapes de validation).

Budget indicatif

La fourchette budgétaire indicative pour un projet de migration applicative se situe entre 25 000 et 100 000 €, sur devis selon le périmètre. Ordres de grandeur par taille de projet :

| Profil | Périmètre type | Stratégie dominante | Position dans la fourchette | |---|---|---|---| | PME | Quelques applications, peu de dépendances | Rehost / Replatform | Bas de fourchette | | ETI | Parc partiel, dépendances modérées, conformité | Mix Replatform / Refactor | Milieu de fourchette | | Grand compte | Vagues, applications critiques, multicloud, DORA/HDS | Mix complet 6R | Haut de fourchette, projet pluri-phasé |

Pourquoi pas de prix ferme ? Parce qu'une migration engage votre production et votre conformité, et que l'honnêteté YMYL l'exige : la même application peut relever d'un rehost à quelques milliers d'euros ou d'un refactor à plusieurs dizaines de milliers. La fourchette ci-dessus est indicative ; le devis se construit après un diagnostic qui cadre précisément le périmètre.

Livrables types

Une migration applicative accompagnée par nos soins comprend systématiquement :

• l'analyse de portefeuille (affectation d'un « R » par application, avec coût/délai/risque) ;
• la cartographie des dépendances ;
• le business case FinOps (TCO avant/après) ;
• la landing zone ou son adaptation, conforme à vos exigences réglementaires ;
• le code IaC (Terraform ou Bicep) versionné dans vos dépôts ;
• les applications migrées, testées et basculées par vagues, avec plan de rollback ;
• la documentation, le transfert de compétences et les KPIs post-migration.

Tout vous appartient : c'est notre principe de réversibilité.

Pourquoi confier sa migration à Architecte Cloud

Architecte Cloud est un intermédiaire indépendant qui cadre votre besoin et vous met en relation avec des prestataires d'expertise et d'infogérance sur Microsoft Azure et AWS, du conseil à l'exploitation. Sur la migration applicative, notre valeur tient en trois points :

• L'expérience : 12 ans d'expertise, plus de 120 projets accompagnés, plus de 40 clients, des prestataires qualifiés disposant des certifications Azure Solutions Architect Expert, AWS DevOps Engineer Professional, FinOps Certified Practitioner et CISSP. Microsoft Azure Solutions Partner (Infrastructure) et AWS Advanced Tier Services Partner.
• L'indépendance et la réversibilité : nous ne sommes pas revendeurs. Le comparatif Azure/AWS est honnête, le code IaC est dans vos dépôts, les comptes à votre nom, la documentation remise. Vous n'êtes jamais enfermé.
• La traduction décisionnelle : nous présentons coûts, risques et délais en langage clair, pour la DSI comme pour la direction générale. Les chiffres de performance que nous citons sont observés et constatés, jamais garantis.

Pour situer la migration applicative dans une démarche plus large, elle s'articule avec notre pilier migration cloud d'entreprise, le conseil en architecture, notre offre de migration cloud et l'ensemble de nos services. Pour reprendre la main sur un environnement déjà migré mais bancal, voir reprendre une infrastructure cloud existante.

Le diagnostic d'abord. Avant tout devis, un diagnostic en ligne cadre votre parc applicatif, vos exigences de conformité et votre niveau de maturité. C'est lui qui permet de chiffrer juste, et de n'appliquer à chaque application que la trajectoire qu'elle mérite. Vous pouvez aussi nous contacter directement pour échanger sur votre projet.

FAQ : Migration d'application vers le cloud

Qu'est-ce que la migration d'une application vers le cloud ?

C'est le transfert d'une application, son code, ses composants d'exécution et souvent ses données, depuis un environnement existant (datacenter, hébergeur traditionnel, ancien cloud) vers une plateforme cloud comme Azure ou AWS. L'objectif n'est pas seulement de la faire tourner ailleurs, mais de la rendre plus disponible, plus économique à exploiter et conforme, en exploitant l'élasticité et les services managés du cloud. Elle se distingue de la migration de données (les bases) et de la migration d'infrastructure (les serveurs).

Quelles sont les 6R (ou 7R) de la migration cloud ?

Les 6R sont six stratégies de migration : Rehost (lift-and-shift, déplacer tel quel), Replatform (déplacer avec quelques optimisations), Refactor/Rearchitect (réécrire pour le cloud), Repurchase (remplacer par un SaaS), Retire (décommissionner) et Retain (ne pas migrer). Le 7e R, Relocate, déplace un environnement de virtualisation entier (VMware) sans conversion. Une migration réelle applique plusieurs « R » selon les applications, pas une stratégie unique.

Quelle est la différence entre rehost, replatform et refactor ?

Le rehost déplace l'application sans modifier le code : rapide, peu risqué techniquement, mais sans bénéfice cloud et financièrement piégeux. Le replatform déplace en remplaçant quelques composants par des services managés (base managée, conteneur) sans réécrire la logique : souvent le meilleur rapport effort/bénéfice. Le refactor réécrit l'application pour exploiter pleinement le cloud (microservices, serverless) : coûteux et long, mais seul à débloquer agilité et scalabilité fine.

Combien de temps dure une migration d'application vers le cloud ?

Pour un périmètre cadré, le délai indicatif se situe entre 3 et 10 semaines. Il dépend du nombre d'applications, de leur criticité, de la stratégie retenue (un rehost est rapide, un refactor prend des mois), du mode de bascule (par vagues étale le calendrier) et des exigences de conformité (HDS, DORA ajoutent des validations). Le délai précis est établi après diagnostic.

Combien coûte une migration vers le cloud ?

La fourchette budgétaire indicative se situe entre 25 000 et 100 000 €, sur devis selon le périmètre. Une PME avec quelques applications en rehost/replatform sera en bas de fourchette ; un grand compte avec des applications critiques, du multicloud et des contraintes DORA/HDS sera en haut, sur un projet pluri-phasé. Aucun prix ferme n'est annoncé sans diagnostic : la même application peut relever d'un rehost à quelques milliers d'euros ou d'un refactor bien plus coûteux.

Quelles sont les étapes d'une migration cloud réussie ?

Cinq étapes : l'évaluation et la découverte (inventaire du parc), la cartographie des dépendances, la planification et la roadmap (affectation d'un « R » par application, vagues, business case FinOps), l'exécution (migration par vagues avec tests et bascule) et l'optimisation post-migration (rightsizing, engagements, sécurité, KPIs). La fondation (la landing zone) se pose avant l'exécution.

Quels sont les risques d'une migration vers le cloud ?

Les principaux risques sont la complexité des dépendances (casser un flux invisible), les applications legacy et monolithes mal adaptés au cloud, le déficit de compétences, les failles de sécurité si la configuration est négligée, l'indisponibilité pendant la bascule, et l'explosion de la facture après un lift-and-shift brut. Chacun se maîtrise par la méthode : cartographie, vagues, plan de rollback, sécurité by-design et FinOps.

Quelles erreurs éviter lors d'une migration cloud ?

Les plus fréquentes : lifter un monolithe non optimisé, sous-estimer les coûts d'egress, oublier la reprise après sinistre, migrer sans landing zone, négliger la cartographie des dépendances, partir sans plan de rollback, ignorer la conformité en amont et sauter le FinOps post-migration. Le fil rouge : ne jamais confondre vitesse et réussite. Migrer vite une mauvaise architecture produit vite une mauvaise architecture cloud.

Comment migrer une application legacy vers le cloud ?

Pour une application monolithique .NET ou Java, le replatform est souvent le meilleur équilibre : conteneuriser, externaliser la base vers une instance managée, sans réécrire la logique. Si l'application est stratégique et bride le métier, un refactor progressif par le pattern « strangler fig » (remplacer le monolithe morceau par morceau) est pertinent. Le rehost ne doit être qu'une étape transitoire, jamais la cible définitive d'un monolithe non optimisé.

Faut-il choisir Azure ou AWS pour migrer ses applications ?

Les deux clouds permettent d'excellentes migrations ; le choix tient à votre existant, vos compétences et vos contraintes, pas à une supériorité intrinsèque. Azure s'impose souvent sur un parc fortement Microsoft (Windows, SQL Server, Active Directory, licences valorisables). AWS séduit en contexte DevOps mature ou cloud-native. En tant qu'intermédiaire indépendant non revendeur, nous comparons honnêtement, sur vos critères. Terraform permet de limiter la dépendance à un fournisseur.

Comment garantir la conformité RGPD lors d'une migration cloud ?

Vous restez responsable de traitement, le fournisseur cloud est sous-traitant au sens de l'article 28 : un contrat de sous-traitance, la maîtrise de la localisation des données et l'encadrement des transferts hors UE sont requis. Concrètement, la migration doit fixer les régions de déploiement (françaises ou européennes), le chiffrement et la journalisation des accès, pour rendre la conformité explicite et auditable. La landing zone porte ces obligations par construction.

Qu'est-ce qu'une landing zone cloud ?

C'est l'environnement cloud préconfiguré (identité, réseau, sécurité, supervision, gouvernance, FinOps) qui accueille vos applications dans un cadre maîtrisé dès le premier déploiement. Sur Azure, elle repose sur le Cloud Adoption Framework ; sur AWS, sur Control Tower et le Landing Zone Accelerator. Migrer sans landing zone, c'est laisser chaque application créer ses propres règles, jusqu'à l'ingouvernable. Le bon ordre : poser la fondation d'abord, migrer ensuite.

Comment éviter l'explosion de la facture après la migration (FinOps) ?

En appliquant une discipline FinOps avant et pendant la migration : modéliser le TCO avant/après pour justifier chaque trajectoire, éviter le lift-and-shift brut, puis rightsizer les ressources sur l'usage réel, engager les charges stables via réservations et Savings Plans, utiliser le Spot pour les charges interruptibles, éteindre les environnements hors usage et anticiper les coûts d'egress. Sans cette discipline, la facture cloud peut dépasser le coût on-premise.

Comment éviter le vendor lock-in lors d'une migration cloud ?

En décrivant toute l'infrastructure en IaC (Terraform ou Bicep) versionné dans vos propres dépôts, en gardant les comptes cloud à votre nom, en documentant une stratégie d'exit dès la conception et en privilégiant la portabilité par les conteneurs. La réversibilité n'est pas une option de fin de contrat : c'est une propriété de l'architecture, posée dès le premier jour. C'est aussi une exigence réglementaire dans la finance (DORA).

Quels outils utiliser pour migrer ses applications ?

Sur Azure : Azure Migrate (découverte, évaluation, dépendances, migration de serveurs), Azure Database Migration Service, et le programme Azure Migrate and Modernize. Sur AWS : Application Discovery Service, Application Migration Service (MGN), Database Migration Service (DMS) et le Migration Acceleration Program (MAP). Ces outils exécutent une stratégie définie par un architecte ; ils accélèrent la migration mais ne remplacent pas la décision.

Migration cloud big-bang ou par vagues ?

Le big-bang bascule tout en une fenêtre : plus rapide, mais le risque est concentré. Il est réservé aux applications simples et peu critiques. La migration par vagues migre par lots successifs en validant chaque vague : plus longue, mais le risque est étalé et maîtrisé. C'est l'approche par défaut pour un parc réel et pour toute application critique. Dans les deux cas, un plan de rollback et des tests de non-régression sont indispensables.