Migrer d'AWS vers un cloud européen

La migration d'AWS vers un cloud européen est devenue une question stratégique pour les entreprises françaises. Souveraineté des données, maîtrise des coûts, conformité réglementaire, indépendance technologique : les motivations sont nombreuses. Mais une migration mal préparée peut transformer une décision de gouvernance en risque opérationnel majeur.

La véritable question n'est pas de savoir comment déplacer ses serveurs d'AWS vers un hébergeur européen. Elle est de savoir comment conserver la maîtrise de son système d'information, de ses données et de ses opérations après le changement de fournisseur.

Une migration réussie repose sur une démarche mesurable : analyser les dépendances, définir les exigences de souveraineté, tester la compatibilité des services, sécuriser les transferts et valider les performances avant toute bascule définitive.

Voici les bonnes pratiques techniques et méthodologiques pour conduire ce projet, en particulier dans une PME ou une ETI française.

1. Comprendre ce que signifie réellement migrer vers un cloud européen

Le premier piège consiste à confondre localisation des données, souveraineté numérique et indépendance technologique.

Ces trois notions sont liées, mais elles ne sont pas équivalentes.

La localisation des données ne suffit pas

Héberger une base de données dans une région AWS située à Paris ou à Francfort permet de traiter et de stocker des données dans l'Union européenne. Cela ne répond pas, à lui seul, à toutes les questions de souveraineté.

Il faut également examiner :

• La juridiction applicable au fournisseur et les éventuelles obligations légales d'accès aux données.
• Les personnes et entités autorisées à administrer l'infrastructure.
• La localisation des équipes de support et les conditions d'accès aux environnements.
• La maîtrise des clés de chiffrement et des mécanismes d'identité.
• Les sous-traitants, les flux de données secondaires et les procédures de transfert.

Le RGPD impose notamment d'encadrer les traitements de données personnelles et les transferts éventuels hors de l'Espace économique européen. Le choix d'un hébergeur européen ne dispense donc pas l'entreprise d'une analyse de ses traitements, de ses contrats et de ses flux.

La Commission européenne a également publié en 2026 un cadre de souveraineté cloud reposant sur 48 critères répartis en huit catégories, notamment la souveraineté juridique, opérationnelle, technologique et la chaîne d'approvisionnement.

À retenir : un cloud européen doit être évalué sur des garanties vérifiables, et non sur la seule adresse de son centre de données.

AWS est-il nécessairement incompatible avec la souveraineté européenne ?

Non. La situation est plus nuancée.

AWS a annoncé la disponibilité générale de son European Sovereign Cloud en janvier 2026, avec une infrastructure européenne indépendante, conçue pour répondre à des exigences renforcées de souveraineté et de contrôle opérationnel.

Une entreprise peut donc comparer plusieurs scénarios : conserver AWS dans une région européenne, utiliser une offre cloud souveraine, migrer vers un fournisseur européen indépendant ou répartir certaines charges entre plusieurs environnements.

Le choix dépend des exigences juridiques, des services techniques nécessaires, du budget et du niveau d'autonomie recherché.

La souveraineté n'est pas une étiquette. C'est un ensemble de propriétés qu'il faut pouvoir démontrer.

2. Auditer l'existant avant de déplacer la moindre charge de travail

Une migration cloud ne commence pas par la création de machines virtuelles chez un nouvel hébergeur. Elle commence par une cartographie précise du système existant.

C'est l'étape qui permet d'éviter les interruptions de service, les coûts imprévus et les incompatibilités découvertes trop tard.

Construire un inventaire technique complet

Pour chaque application AWS, identifiez au minimum :

L'inventaire doit être complété par une cartographie des dépendances entre applications.

Une application peut sembler indépendante tout en dépendant d'une fonction Lambda, d'une file SQS, d'une politique IAM ou d'un mécanisme de chiffrement KMS. Déplacer uniquement son serveur ne suffit pas à la rendre opérationnelle.

AWS recommande précisément de commencer par la collecte des configurations, des usages et des dépendances avant de sélectionner une stratégie de migration.

Mesurer avant de dimensionner

Ne reproduisez pas automatiquement les capacités provisionnées sur AWS.

Collectez plusieurs semaines de métriques représentatives, idéalement en couvrant les pics d'activité et les cycles métier :

• CPU, mémoire et stockage réellement consommés.
• Latence des applications et des bases de données.
• Débit réseau et volumes de données transférés.
• Taux de requêtes, files d'attente et temps de traitement.
• Variations de charge et périodes de pointe.

Ces mesures constituent une référence de performance, ou baseline.

Sans cette référence, il sera difficile de déterminer si le nouvel environnement est réellement équivalent, plus coûteux ou moins performant.

Règle opérationnelle : aucune charge de travail critique ne devrait être migrée sans propriétaire métier identifié, cartographie de ses dépendances et critères de réussite mesurables.

3. Choisir la bonne stratégie de migration : les 7 R

Toutes les applications ne doivent pas être migrées de la même façon.

Le cadre de migration AWS distingue sept stratégies couramment appelées les « 7 R » : Retire, Retain, Rehost, Relocate, Repurchase, Replatform et Refactor.

Pour une PME, une migration progressive est souvent plus réaliste qu'une réécriture générale.

Une application web monolithique exécutée sur EC2 peut être candidate au rehost. Une application reposant massivement sur Lambda, DynamoDB et des événements AWS nécessitera probablement davantage de refonte ou de remplacement de services.

L'objectif n'est pas de moderniser chaque application à tout prix. Il est de choisir, pour chaque charge, le niveau de transformation qui répond aux objectifs métier et au budget.

4. Concevoir une architecture portable sans tomber dans le piège du « cloud agnostique »

La portabilité est l'un des objectifs les plus importants d'une migration vers un cloud européen. Mais elle est souvent mal comprise.

Une architecture portable n'est pas une architecture qui peut être déplacée instantanément vers n'importe quel fournisseur. C'est une architecture dont les dépendances sont connues, maîtrisées et remplaçables à un coût acceptable.

Privilégier les standards ouverts aux dépendances propriétaires non maîtrisées

Pour les nouvelles briques ou les composants à moderniser, privilégiez autant que possible :

• Les conteneurs OCI pour empaqueter les applications.
• Kubernetes lorsque l'orchestration distribuée est justifiée par les besoins réels.
• PostgreSQL ou d'autres bases de données relationnelles standards lorsque le modèle de données le permet.
• OpenTelemetry pour la collecte et la transmission des traces, métriques et journaux.
• Terraform ou OpenTofu, avec des modules maintenus et des configurations adaptées à chaque fournisseur.
• Des API documentées, versionnées et indépendantes du fournisseur lorsque cela est pertinent.

Ces choix peuvent réduire le coût d'une migration future et faciliter les tests.

Cependant, Kubernetes ne garantit pas à lui seul la portabilité d'une application. Les volumes persistants, les load balancers, la gestion des secrets, le réseau, les politiques de sécurité et les services managés restent susceptibles de créer des dépendances spécifiques.

De même, une infrastructure as code commune ne rend pas deux fournisseurs techniquement identiques. Les ressources, les permissions et les mécanismes de réseau doivent être adaptés et validés.

Traiter les services managés AWS comme des dépendances architecturales

Les services managés apportent de la valeur : ils réduisent la charge opérationnelle et permettent aux équipes de se concentrer sur le produit.

Mais certains services AWS n'ont pas d'équivalent strictement compatible chez un fournisseur européen.

Prenons trois exemples :

Un stockage compatible S3 n'est pas nécessairement un remplacement transparent de S3.

Il faut tester les bibliothèques clientes, les opérations multipart, les règles de cycle de vie, les permissions, les performances et les mécanismes de notification.

Pour chaque service propriétaire, documentez trois éléments : sa fonction métier, les alternatives disponibles et le coût estimé de son remplacement.

Éviter la sur-ingénierie du multicloud

Maintenir simultanément plusieurs clouds peut réduire certaines dépendances, mais augmente également la complexité des opérations, les compétences nécessaires, les coûts de réseau et les surfaces d'attaque.

Une PME n'a pas nécessairement intérêt à exploiter deux environnements de production actifs.

Une architecture modulaire, des sauvegardes indépendantes et une procédure d'export testée peuvent offrir un niveau d'autonomie suffisant sans imposer une infrastructure multicloud permanente.

Le bon objectif est la réversibilité démontrable, pas la multiplication des plateformes.

5. Sécuriser les données : la migration est un projet de sécurité à part entière

Le transfert des données représente souvent la phase la plus sensible d'une migration.

Une base de données peut contenir des données personnelles, des informations commerciales confidentielles, des secrets d'authentification ou des données soumises à des obligations contractuelles.

La sécurité doit être conçue avant le premier transfert.

Chiffrer les données en transit et au repos

Les transferts doivent utiliser des protocoles sécurisés, tels que TLS correctement configuré, et des canaux privés ou restreints lorsque cela est adapté à l'architecture.

Les données stockées doivent être chiffrées au repos, y compris les sauvegardes et les copies temporaires.

Il est essentiel de distinguer le chiffrement de la maîtrise des clés.

Une organisation peut chiffrer ses données tout en dépendant du fournisseur pour l'administration des clés. Si les exigences de souveraineté imposent une maîtrise renforcée, la gestion des clés doit être examinée séparément : propriété, administration, rotation, récupération, révocation et séparation des rôles.

Les clés ne doivent jamais être exportées ou partagées sans procédure formalisée.

Appliquer le principe du moindre privilège

Le compte ou le rôle utilisé pour migrer les données ne doit disposer que des autorisations strictement nécessaires.

Il faut notamment :

1. Créer des identités de migration dédiées et temporaires.
2. Restreindre les accès aux ressources et aux plages horaires nécessaires.
3. Séparer les droits d'administration, de transfert et de validation.
4. Journaliser les opérations sensibles.
5. Révoquer les accès temporaires après la migration.

L'authentification multifacteur, la rotation des secrets et la surveillance des activités privilégiées doivent être intégrées au dispositif.

Les recommandations de sécurité d'ENISA destinées aux PME insistent sur l'adaptation des contrôles au niveau de risque et sur l'évaluation des garanties du fournisseur. Elles constituent un point de départ utile pour formaliser les exigences de sécurité d'un projet cloud.

Prévoir une sauvegarde indépendante avant toute bascule

Une migration ne doit jamais être considérée comme une sauvegarde.

Avant toute opération irréversible, vérifiez que les données peuvent être restaurées dans un environnement indépendant du système source.

Les bonnes pratiques comprennent :

• Une copie de sauvegarde cohérente et vérifiée.
• Des sauvegardes protégées contre la suppression ou l'altération non autorisée.
• Une séparation des identifiants d'administration des sauvegardes.
• Un test de restauration réel, pas uniquement un contrôle de présence des fichiers.
• Une procédure de conservation et de suppression des copies temporaires.

Le test décisif est simple : l'entreprise peut-elle restaurer son application et ses données sans dépendre du fournisseur qu'elle est en train de quitter ?

Si la réponse n'est pas démontrée, la migration n'est pas encore réversible.

6. Migrer les bases de données sans perdre de transactions

La migration des bases de données est généralement plus complexe qu'un simple transfert de fichiers.

Le volume de données, les écritures continues, les contraintes d'intégrité et les différences entre moteurs peuvent rendre une bascule directe risquée.

Choisir entre migration à froid et réplication continue

Deux grandes approches sont possibles.

Migration à froid : l'application est arrêtée, une copie cohérente est réalisée, puis les données sont restaurées chez le nouveau fournisseur. Cette approche convient aux systèmes disposant d'une fenêtre d'interruption acceptable.

Migration avec réplication continue : les données initiales sont copiées, puis les modifications sont répliquées au fil de l'eau jusqu'à la bascule. Cette méthode réduit l'interruption, mais nécessite un contrôle rigoureux du retard de réplication et de la cohérence.

Dans le cas d'une base PostgreSQL, par exemple, la réplication logique peut faciliter certains scénarios de migration, sous réserve de vérifier les versions, les extensions, les séquences, les objets non répliqués et les contraintes spécifiques.

Une réplication réussie ne signifie pas automatiquement que les deux environnements sont fonctionnellement identiques.

Définir une procédure de bascule contrôlée

Une procédure de migration de base de données doit définir à l'avance :

• Le moment de gel des écritures ou le mécanisme de synchronisation finale.
• Le niveau de retard de réplication acceptable.
• La méthode de vérification des données.
• Le responsable autorisé à valider la bascule.
• Les critères d'arrêt et les conditions de retour arrière.

Les contrôles doivent couvrir les nombres d'enregistrements, les sommes de contrôle lorsque pertinentes, les contraintes d'intégrité et des requêtes métier représentatives.

Une simple comparaison du volume des bases ne suffit pas.

Exemple : pour un système de facturation, il faut vérifier non seulement le nombre de factures, mais aussi les montants, les statuts de paiement, les relations entre factures et clients et l'absence de doublons.

La validation doit porter sur les propriétés métier qui garantissent que l'application reste correcte après migration.

7. Préparer la continuité d'activité et le plan de retour arrière

Le succès d'une migration ne se mesure pas uniquement au fait que le nouveau serveur démarre.

Il se mesure à la capacité de l'entreprise à continuer de fonctionner, à respecter ses engagements et à restaurer son service en cas d'incident.

Définir deux indicateurs avant le projet

Le RTO (Recovery Time Objective) est la durée maximale d'interruption acceptable pour un service.

Le RPO (Recovery Point Objective) correspond à la quantité maximale de données que l'entreprise accepte de perdre, exprimée en durée.

Ces objectifs doivent être définis par application, en fonction de l'impact métier.

Une application interne non critique peut accepter plusieurs heures d'interruption. Une plateforme transactionnelle peut nécessiter des objectifs nettement plus stricts.

Ces exigences déterminent les choix d'architecture, de réplication, de sauvegarde et de bascule.

Construire un véritable plan de retour arrière

Le plan de retour arrière doit préciser les conditions qui déclenchent un abandon de la migration, les responsabilités et les opérations à effectuer.

Il doit notamment répondre aux questions suivantes :

• Que se passe-t-il si les performances du nouvel environnement sont insuffisantes ?
• Comment revenir à l'ancien système si les données ont déjà été modifiées ?
• Comment éviter les écritures divergentes entre les deux environnements ?
• Qui autorise le retour arrière ?
• Combien de temps le système AWS restera-t-il disponible après la bascule ?

Le point le plus délicat est la divergence des données. Dès que la nouvelle plateforme accepte des écritures, un retour vers AWS peut nécessiter une réplication inverse ou une procédure de réconciliation.

Il ne faut donc jamais présenter le retour arrière comme un simple changement DNS.

AWS structure ses propres migrations autour des phases d'évaluation, de préparation, puis de migration et de modernisation. Cette logique progressive, appliquée avec des critères de validation et des contrôles opérationnels, reste pertinente pour une migration vers un autre fournisseur.

8. Calculer le coût réel : le prix du serveur n'est qu'une partie de l'équation

Une migration vers un cloud européen n'est pas automatiquement moins chère qu'une exploitation sur AWS.

Comparer uniquement le prix mensuel d'une machine virtuelle donne une vision incomplète du coût total de possession (TCO, Total Cost of Ownership).

Une analyse financière sérieuse doit intégrer au moins cinq catégories de coûts.

Les cinq composantes du coût de migration

1. Infrastructure : calcul, stockage, bases de données, réseau, sauvegardes, licences et support.
2. Transfert des données : frais de sortie AWS, bande passante, transferts intermédiaires, stockage temporaire et éventuels frais d'importation.
3. Transformation technique : adaptation des applications, remplacement des services managés, tests et développement.
4. Exploitation humaine : formation, administration, astreintes, supervision et montée en compétence des équipes.
5. Coût de transition et de risque : double exploitation temporaire, interruptions possibles, validation réglementaire et maintien du plan de secours.

Le calcul doit être effectué sur une période cohérente, par exemple trois ans, en comparant plusieurs scénarios : maintien sur AWS, migration vers un fournisseur européen et architecture hybride.

Le coût du cloud doit être rapporté à une unité métier pertinente : coût par transaction, utilisateur actif, dossier traité ou volume de calcul utile.

Une infrastructure moins chère à capacité nominale peut devenir plus coûteuse si elle exige davantage d'administration ou ne fournit pas les services managés nécessaires.

À l'inverse, une migration peut avoir une justification économique même si l'infrastructure seule coûte davantage, lorsque les gains de maîtrise des données, de conformité ou de réduction des risques sont valorisés dans le modèle financier.

La bonne décision financière repose sur un TCO documenté, et non sur une comparaison de tarifs affichés.

9. Exécuter la migration par étapes : la méthode recommandée pour une PME

Pour limiter les risques, une PME ou une ETI devrait privilégier une migration par lots fonctionnels, avec des critères de validation définis avant chaque étape.

Voici une séquence opérationnelle applicable à un projet de migration AWS vers un cloud européen.

Feuille de route de migration

1. Étape 1 — Évaluer et décider
   Inventorier les charges, cartographier les dépendances, classifier les données et définir les exigences de souveraineté, de sécurité et de performance.
2. Étape 2 — Sélectionner le fournisseur
   Comparer les services disponibles, les garanties contractuelles, la localisation, les mécanismes d'accès, les coûts et les conditions de sortie.
3. Étape 3 — Construire la zone d'accueil
   Configurer réseau, identité, chiffrement, journaux, sauvegardes, infrastructure as code et chaîne de déploiement.
4. Étape 4 — Migrer un pilote non critique
   Choisir une application représentative, tester le transfert, mesurer les performances, vérifier la restauration et documenter les écarts.
5. Étape 5 — Industrialiser par lots
   Réutiliser les procédures validées, automatiser les déploiements et migrer les applications selon leur criticité et leurs dépendances.
6. Étape 6 — Basculer et stabiliser
   Exécuter la procédure de bascule, surveiller les indicateurs métier et techniques, valider le service puis clôturer progressivement l'environnement AWS.

Le pilote est une étape déterminante. Il doit être suffisamment représentatif pour révéler les difficultés techniques, sans exposer immédiatement une activité critique.

Il doit produire des livrables réutilisables : scripts de migration, documentation d'architecture, résultats de tests, procédure de retour arrière et estimation financière actualisée.

Les six piliers du cadre AWS Well-Architected — excellence opérationnelle, sécurité, fiabilité, performance, optimisation des coûts et durabilité — fournissent également une grille structurée pour évaluer les architectures avant et après migration.

10. Les erreurs qui compromettent le plus souvent une migration cloud

Certaines erreurs peuvent être évitées dès la phase de conception.

La leçon est simple : une migration ne doit pas être pilotée uniquement par un calendrier de transfert. Elle doit être pilotée par des preuves de bon fonctionnement.

11. Conclusion : une migration réussie se mesure à l'autonomie qu'elle crée

Migrer d'AWS vers un cloud européen peut répondre à des objectifs importants de souveraineté, de gouvernance des données, de maîtrise des coûts et de résilience.

Mais le changement de fournisseur ne garantit, à lui seul, ni la sécurité, ni la conformité, ni l'indépendance technologique.

Les entreprises qui préparent cette transition doivent commencer par connaître précisément leur système, définir leurs exigences, évaluer les dépendances propriétaires et construire une stratégie de migration adaptée à chaque application.

La meilleure protection contre une migration risquée est une architecture documentée, des tests reproductibles, des responsabilités claires et une procédure de sortie réellement vérifiée.

La souveraineté numérique ne se décrète pas au moment de signer un contrat cloud. Elle se construit dans l'architecture, se vérifie dans les opérations et se démontre par la capacité à reprendre le contrôle de son système.

Pour les PME françaises, cette démarche n'exige pas nécessairement une refonte complète de l'infrastructure. Elle exige surtout une méthode rigoureuse, des arbitrages techniques explicites et une vision à long terme.

C'est précisément ce qui transforme une migration cloud en véritable projet de maîtrise technologique.

12. Questions fréquentes sur la migration AWS vers un cloud européen

Peut-on migrer une application AWS vers un cloud européen sans la réécrire ?

Oui, dans certains cas. Une application reposant principalement sur des machines virtuelles, des bases de données standards et des composants portables peut être déplacée avec des adaptations limitées. Les applications fortement dépendantes de services propriétaires AWS nécessitent généralement des modifications supplémentaires.

Combien de temps dure une migration AWS vers un cloud européen ?

La durée dépend du nombre d'applications, des volumes de données, des dépendances techniques, des exigences de disponibilité et des ressources mobilisées. Un pilote limité peut être réalisé avant un programme plus large, mais il n'existe pas de durée universelle fiable sans audit préalable.

Un hébergeur européen garantit-il automatiquement la conformité RGPD ?

Non. La conformité dépend notamment des traitements, des responsabilités contractuelles, des accès, des mesures de sécurité, des sous-traitants et des transferts de données. Le choix du fournisseur est une composante de la conformité, pas une garantie globale.

Kubernetes permet-il d'éviter le verrouillage fournisseur ?

Kubernetes facilite la portabilité de certaines applications conteneurisées. Il ne supprime pas les dépendances au stockage, au réseau, aux identités, aux services managés ou aux outils d'exploitation propres à chaque fournisseur.

Faut-il quitter AWS complètement pour gagner en souveraineté ?

Pas nécessairement. Selon les contraintes réglementaires et métier, une approche hybride, une migration ciblée ou une conservation de certaines charges sur AWS peuvent être envisagées. La décision doit être fondée sur les risques, les exigences de contrôle et le coût total.