La migration vers le cloud reste l’un des chantiers les plus structurants pour une DSI, et l’un des plus risqués lorsqu’il est conduit sans méthode. Entre la pression des métiers pour réduire les délais de mise sur le marché, les contraintes réglementaires croissantes (NIS2, DORA, RGPD) et la complexité technique des workloads existants, les organisations accumulent des erreurs évitables : surcoûts, dettes techniques déplacées vers le cloud, incidents de sécurité post-migration et pertes de souveraineté sur les données. Cet article présente une approche structurée de la migration cloud, centrée sur la taxonomie des 7R et les points de vigilance que tout RSSI ou DSI doit intégrer avant de signer un bon de commande hyperscaler.
Pourquoi la migration cloud échoue sans taxonomie préalable
La première erreur consiste à traiter la migration cloud comme un projet technique homogène. En réalité, un parc applicatif d’entreprise regroupe des workloads aux contraintes radicalement différentes : une application de paie hébergeant des données personnelles sensibles, un outil de reporting décisionnel, une plateforme e-commerce à trafic variable et un ERP vieux de quinze ans n’appellent pas la même stratégie. Appliquer un rehosting généralisé pour tenir un calendrier revient à déplacer les problèmes sans les résoudre.
La taxonomie des 7R, popularisée par Gartner et formalisée dans la documentation officielle AWS, fournit un cadre de qualification workload par workload. Elle permet d’aligner la stratégie technique avec les objectifs métier (TCO, time-to-market, résilience, conformité) avant d’engager les ressources.
Les 7R : description et critères de sélection
Le tableau suivant synthétise les sept stratégies, leur niveau de complexité et leurs cas d’usage typiques.
| Stratégie | Description | Complexité | Cas d’usage typique |
|---|---|---|---|
| Rehost (Lift and shift) | Migration à l’identique vers des VM cloud | Faible | Applications stables, contraintes de calendrier, dette technique à traiter ensuite |
| Replatform | Ajustements ciblés sans refonte (BDD managée, load balancer cloud natif) | Moyenne | Réduction de la charge opérationnelle, amélioration de la résilience |
| Repurchase | Remplacement par un SaaS équivalent | Faible à moyenne | Messagerie, CRM, outils collaboratifs, applications standardisées |
| Refactor | Refactoring du code pour exploiter les services cloud natifs | Élevée | Applications à fort potentiel de scalabilité, microservices |
| Re-architect | Réécriture complète en architecture cloud native | Très élevée | Applications critiques nécessitant élasticité totale et résilience multi-région |
| Retain | Maintien on-premise (temporaire ou permanent) | Aucune | Workloads souverains, applications en fin de vie, coût de migration non justifié |
| Retire | Décommission de l’application | Aucune | Applications redondantes, non utilisées ou remplacées par un SaaS |
La stratégie Rehost est souvent présentée comme un point de départ avant d’évoluer vers Replatform ou Refactor. Elle est pertinente dans une approche en deux temps (migrer vite, optimiser ensuite), à condition que la phase d’optimisation soit planifiée et budgétée dès le départ. Sans cette intention explicite, le Rehost devient une dette technique déplacée vers le cloud à un coût supérieur.
Gouvernance préalable : souveraineté, conformité et qualification des hébergeurs
Avant toute décision technique, le RSSI doit qualifier les contraintes réglementaires qui pèsent sur chaque workload.
Pour les entités soumises à NIS2 ou DORA, l’hébergeur cloud doit être en mesure de répondre aux exigences de continuité, de gestion des incidents et de test de résilience. DORA impose en particulier des clauses contractuelles minimales avec les prestataires TIC critiques (article 30), incluant les droits d’audit et les obligations de notification d’incident.
Pour les données personnelles, le chapitre V du RGPD et les recommandations de la CNIL encadrent les transferts hors Union européenne. Les clauses contractuelles types (CCT) ne suffisent pas lorsque le droit du pays tiers permet un accès gouvernemental aux données : un fournisseur de droit américain reste soumis au CLOUD Act, indépendamment de la localisation physique des serveurs. Cette analyse doit précéder le choix du fournisseur.
Pour les OIV (Opérateurs d’Importance Vitale) et les administrations, l’ANSSI recommande de s’orienter vers des offres qualifiées SecNumCloud v3.2. Ce référentiel exige notamment que l’hébergeur soit immunisé contre les législations extra-européennes. La liste des offres qualifiées est publiée sur cyber.gouv.fr.
Pour les entreprises sans contrainte OIV, la qualification n’est pas obligatoire mais constitue un critère de sélection pertinent pour les workloads sensibles.
Sécurité post-migration : les vecteurs d’incident prioritaires
La migration cloud modifie le modèle de responsabilité partagée (shared responsibility model). Ce que l’hébergeur gère (sécurité “du” cloud : infrastructure physique, hyperviseur, réseau sous-jacent) ne dispense pas l’entreprise de sécuriser “dans” le cloud : configuration des services, gestion des identités, chiffrement des données, surveillance des accès.
Le MITRE ATT&CK Cloud Matrix recense les techniques d’attaque spécifiques aux environnements cloud. Les vecteurs les plus fréquents post-migration sont les suivants.
Identity and Access Management (IAM). Les droits excessifs hérités de l’on-premise constituent la première surface d’attaque : administrateurs locaux élevés en administrateurs cloud, comptes de service avec permissions globales, absence de MFA sur les comptes cloud. Le principe de moindre privilège (NIST SP 800-53, contrôle AC-6) doit être appliqué workload par workload, avec révision trimestrielle des droits.
Misconfiguration. Selon l’ENISA (Threat Landscape 2023), les erreurs de configuration restent parmi les causes principales des incidents cloud. Stockage objet mal configuré (accès public non intentionnel), règles de groupe de sécurité trop permissives, chiffrement at-rest désactivé par défaut : ces erreurs sont souvent introduites lors des phases de migration accélérée. Un outil de Cloud Security Posture Management (CSPM) doit être déployé dès la conception de la Landing Zone, avant le premier workload de production.
Gestion des secrets dans les pipelines CI/CD. La migration vers le cloud s’accompagne généralement d’une transformation DevOps. Les secrets (clés API, credentials de bases de données, certificats) mal gérés dans les pipelines représentent une exposition critique, documentée régulièrement dans les incidents de type supply-chain. Des solutions dédiées (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) doivent être intégrées dès la conception des pipelines, pas ajoutées après constat d’incident.
Pour aller plus loin sur la stratégie de sécurité multi-cloud, consultez la page /cloud/multi-cloud-strategie-exit/.
Gouvernance des coûts : intégrer la FinOps dès le projet
La dérive des coûts cloud est l’un des problèmes les plus fréquemment cités par les DSI. Elle résulte presque toujours d’un défaut de gouvernance initialisé lors de la migration, pas d’un problème de tarification hyperscaler.
La FinOps Foundation (FinOps Framework) structure la gouvernance des coûts cloud en trois phases : Inform (visibilité en temps réel sur les coûts par service, équipe et projet), Optimize (identification des ressources surdimensionnées ou inutilisées), Operate (pilotage continu avec ownership distribué).
Les prérequis à mettre en place avant la première migration de charge de production sont les suivants :
- Politique de tagging obligatoire : chaque ressource cloud doit porter au minimum un tag projet, un tag environnement (production, staging, dev), un tag centre de coût et un tag propriétaire. L’absence de tagging initial bloque toute attribution des coûts pendant des mois.
- Alertes budgétaires : seuils d’alerte à 50 %, 80 % et 100 % du budget mensuel par compte ou par projet.
- Revue mensuelle des ressources : identification et suppression des ressources orphelines (snapshots, load balancers sans cible, IP élastiques non attachées).
- Commitment-based pricing : les Reserved Instances (AWS) ou Savings Plans permettent des réductions de 30 à 60 % sur les workloads stables, à condition que la consommation ait été observée au moins 90 jours avant engagement.
Plan de migration : les phases critiques et pièges à éviter
Une migration structurée suit cinq phases, quelles que soient les stratégies 7R choisies.
Phase 1 - Découverte et qualification. Inventaire exhaustif du parc applicatif (CMDB), mesure des dépendances inter-applications, qualification des contraintes réglementaires et de souveraineté, et application de la taxonomie 7R workload par workload. Cette phase prend entre 4 et 12 semaines selon la taille du parc.
Phase 2 - Architecture de la zone d’atterrissage (Landing Zone). Conception de l’organisation des comptes cloud (multi-account strategy), des connectivités réseau (VPN, Direct Connect/ExpressRoute), du modèle IAM de référence et des outils de surveillance (SIEM, CSPM). C’est ici que se décident les choix structurants impossibles à corriger sans coût.
Phase 3 - Migration pilote. Migration d’un workload non critique pour valider les procédures, les outils et les compétences internes. La phase pilote révèle systématiquement des ajustements nécessaires sur la Landing Zone.
Phase 4 - Migration à l’échelle. Vagues de migration par lot de workloads, avec des tests de non-régression fonctionnelle et de sécurité (pentest post-migration, revue de configuration IAM et réseau) avant chaque basculement en production.
Phase 5 - Optimisation continue. Décommission des ressources on-premise libérées, optimisation des coûts (rightsizing, reserved instances), montée en maturité vers les stratégies Replatform ou Refactor pour les workloads qui le justifient.
Plusieurs erreurs reviennent systématiquement dans les migrations mal préparées. Migrer sans qualification des données personnelles expose à un risque de mise en demeure CNIL. Sous-estimer la formation des équipes cloud génère des erreurs de configuration coûteuses. Négliger le shadow IT cloud résiduel (souscriptions non gouvernées existant avant la migration officielle) laisse des surfaces d’attaque non surveillées. Reproduire l’architecture on-premise dans le cloud (VM statiques surdimensionnées) ne produit ni économies ni gains de résilience, et coûte généralement plus cher.
Pour une vue d’ensemble des ressources disponibles sur le domaine cloud, consultez la page /cloud/. Les aspects de conformité réglementaire sont traités dans le pilier /cybersecurite-entreprise/.
La migration cloud est avant tout un projet de transformation organisationnelle autant que technique. La taxonomie des 7R fournit le vocabulaire commun entre DSI, RSSI et architectes pour objectiver les choix et éviter les décisions prises sous contrainte de calendrier. La sécurité et la gouvernance financière ne sont pas des sujets à traiter après la migration : elles doivent être conçues dans la Landing Zone avant le premier workload de production.