Microsoft Cloud Adoption Framework : phases, landing zones, limites

Le Microsoft Cloud Adoption Framework (CAF) est le cadre méthodologique que Microsoft publie pour conduire une adoption du cloud, depuis la décision stratégique jusqu’à l’exploitation. Il mélange deux choses de nature très différente : des principes d’adoption valables chez n’importe quel fournisseur, et une architecture de référence Azure très opinionnée, les Azure landing zones. Toute la difficulté consiste à distinguer l’un de l’autre, et à savoir ce qu’on achète en suivant le second.

→ Lire l’explication complète de la marmotte

Statut du CAF : documentation vivante, pas norme versionnée

Le CAF n’a pas de numéro de version. C’est un ensemble de pages sur Microsoft Learn, chacune datée de sa dernière mise à jour, réorganisé régulièrement : la liste des méthodologies a déjà changé plusieurs fois, avec une méthodologie « Organize » apparue puis absorbée, et « Migrate » et « Innovate » regroupées sous « Adopt ». Avant de citer le CAF dans un dossier d’architecture, on relève la date affichée sur chaque page invoquée. Une référence au « CAF » sans date ne désigne rien de précis.

La structure en vigueur comporte sept méthodologies : Strategy, Plan, Ready, Adopt, Govern, Secure, Manage. S’y ajoutent des « scénarios » (IA, analytique à grande échelle, hybride et multicloud, SAP, etc.) qui déclinent ces méthodologies par type de charge. Les quatre premières se déroulent dans l’ordre. Les trois dernières s’appliquent en continu, dès la première zone d’atterrissage.

Le schéma montre le point que la frise officielle tend à masquer : Govern, Secure et Manage alimentent Ready et Adopt dès le début. Les reporter « après la migration » revient à construire la plateforme, à la remplir, puis à découvrir qu’on doit la refaire.

Ce que chaque méthodologie demande vraiment

Strategy. Écrire pourquoi on migre, en résultats mesurables : sortie d’un centre de données à une échéance de bail, élasticité d’une charge saisonnière, accès à des services managés. Livrable réel : un document qui permet à la direction de dire non à un projet. Une stratégie qui tient sur une slide intitulée « Cloud First » n’est pas une stratégie, c’est un fond d’écran.

Plan. Inventorier le patrimoine numérique et décider, application par application, de son sort. Les catégories classiques : réhéberger (rehost), refactoriser, réarchitecturer, reconstruire, remplacer par un SaaS (Software as a Service), conserver, retirer. Le livrable qui manque le plus souvent est le plan de compétences : une équipe qui n’a jamais opéré de réseau défini par logiciel ni de RBAC (Role-Based Access Control) cloud apprendra en production, sur des ressources facturées à la seconde.

Ready. Construire la zone d’atterrissage (landing zone) : l’environnement préconfiguré (hiérarchie de ressources, identité, réseau, journalisation, politiques) dans lequel les charges arrivent. C’est la méthodologie qui pèse le plus lourd techniquement, et la seule où le CAF devient un plan d’architecture plutôt qu’une méthode.

Adopt. Exécuter : migrer par vagues (évaluation, déploiement, bascule) et moderniser ou créer des applications cloud natives. La règle qui tient : une vague ne démarre que si la zone d’atterrissage cible existe déjà, avec ses garde-fous actifs.

Govern. Définir les règles (régions autorisées, chiffrement, étiquetage, budgets), les traduire en contrôles automatisés et mesurer les écarts. La gouvernance qui reste dans un document PDF ne gouverne que le lecteur du PDF.

Secure. Aligner la posture de sécurité sur un modèle Zero Trust : identité comme périmètre principal, moindre privilège, segmentation, détection et réponse. Le CAF y oriente vers les produits Microsoft (Defender for Cloud, Sentinel), ce qui est cohérent avec le document et ne constitue pas une obligation.

Manage. Établir le socle d’exploitation : supervision, gestion des correctifs, sauvegarde, continuité, gestion des incidents. Le CAF y fixe des niveaux de service par criticité de charge, ce qui oblige enfin à attribuer une criticité à chaque charge.

Principes généraux d’adoption contre spécificités Azure

La valeur du CAF se lit en séparant deux couches. La première se transpose à AWS, Google Cloud ou un cloud souverain. La seconde n’existe que sur Azure.

Principe général (transposable)	Implémentation propre à Azure
Hiérarchie de rattachement des ressources pour hériter des règles	Management groups, abonnements, groupes de ressources
Séparer plateforme partagée et charges applicatives	Abonnements « Platform » (Identity, Management, Connectivity) et « Landing zones »
Garde-fous techniques appliqués avant le déploiement	Azure Policy (effets Deny, Audit, DeployIfNotExists, Modify)
Annuaire d’identité central, privilèges juste à temps	Microsoft Entra ID, PIM (Privileged Identity Management)
Réseau en étoile avec point d’inspection central	Hub-and-spoke ou Azure Virtual WAN, Azure Firewall
Journalisation centralisée hors de portée des charges	Log Analytics dans l’abonnement Management
Distribution industrialisée des abonnements	Subscription vending via IaC (Infrastructure as Code)

Le découpage est opératoire : un document d’architecture multicloud reprend la colonne de gauche comme exigences et réserve la colonne de droite à l’annexe Azure. Il ne suffit pas de remplacer « management group » par « organizational unit » pour obtenir une architecture AWS, les modèles d’héritage diffèrent (une politique de contrôle de service AWS restreint les permissions, une Azure Policy évalue la configuration des ressources).

Azure landing zones : la hiérarchie qui porte la sécurité

L’architecture de référence Azure landing zone (ALZ) couvre huit zones de conception : facturation et tenant Entra, identité et accès, organisation des ressources, réseau et connectivité, sécurité, gestion, gouvernance, automatisation de la plateforme. Son cœur est la hiérarchie de management groups, qui détermine l’héritage du RBAC et des politiques.

Il faut y lire que la hiérarchie se découpe par archétype de charge, pas par organigramme. Un management group par direction métier semble naturel et devient ingérable à la première réorganisation, car déplacer un abonnement change toutes les politiques héritées d’un coup. Azure limite par ailleurs la profondeur à six niveaux sous la racine (hors racine et abonnement) : une hiérarchie qui calque l’organigramme y bute vite.

L’abonnement est l’unité d’isolation : limites de quotas, frontière de facturation, périmètre RBAC. La règle ALZ est une charge, un ou plusieurs abonnements par environnement. Partager un abonnement entre deux applications partage leurs quotas, leurs administrateurs et leurs incidents.

La topologie réseau de référence place un hub dans l’abonnement Connectivity, et chaque abonnement applicatif en spoke appairé ; il faut y regarder le fait que le trafic entre spokes passe obligatoirement par le pare-feu du hub, l’appairage n’étant pas transitif.

Les routes définies par l’utilisateur forcent ce passage. Une seule table de routage oubliée sur un sous-réseau suffit à faire sortir une charge Corp directement vers Internet, sans que rien ne casse visiblement.

Mise en œuvre : prérequis et choix d’outillage

Avant toute zone d’atterrissage, il faut :

un tenant Microsoft Entra ID dédié, avec au moins deux comptes d’urgence (break-glass) exclus de l’accès conditionnel et surveillés ;
un accord de facturation (Enterprise Agreement ou Microsoft Customer Agreement) permettant la création programmatique d’abonnements, sans laquelle le subscription vending est impossible ;
un plan d’adressage IP non chevauchant avec le réseau sur site, réservé pour plusieurs années ;
un dépôt de code et un pipeline CI/CD (Continuous Integration / Continuous Deployment) dont l’identité s’authentifie par fédération OIDC (OpenID Connect), sans secret client stocké.

Trois voies de déploiement existent : l’accélérateur du portail, Bicep et Terraform. Microsoft oriente désormais les déploiements par code vers les modules Azure Verified Modules ; avant de démarrer, on vérifie sur la documentation lequel des modules historiques reste maintenu. La recommandation est sans ambiguïté : IaC dès le premier jour, portail jamais. L’accélérateur du portail produit une plateforme correcte et impossible à reproduire, ce qui a son charme jusqu’à la première dérive.

Exemple : poser un garde-fou de région sans casser l’existant

L’exemple illustre la séquence qui évite la panne classique, à savoir l’effet Deny assigné d’emblée sur un périmètre déjà peuplé. On crée un management group, puis on assigne la politique intégrée « Allowed locations » en mode non contraignant pour mesurer les écarts.

# Créer le management group "lz-corp" sous le groupe "lz-landingzones"
az account management-group create \
  --name lz-corp \
  --display-name "Corp" \
  --parent lz-landingzones

# Assigner la politique intégrée "Allowed locations"
# (définition e56962a6-4747-49cd-b67b-bf8b01975c4c)
# DoNotEnforce : la conformité est évaluée, rien n'est bloqué
az policy assignment create \
  --name allowed-locations \
  --scope /providers/Microsoft.Management/managementGroups/lz-corp \
  --policy e56962a6-4747-49cd-b67b-bf8b01975c4c \
  --params '{"listOfAllowedLocations":{"value":["francecentral","westeurope"]}}' \
  --enforcement-mode DoNotEnforce

# Lire l'état de conformité une fois l'évaluation terminée
az policy state summarize \
  --management-group lz-corp

L’évaluation d’une nouvelle assignation n’est pas instantanée : il faut attendre la fin du cycle avant de lire un rapport. Une fois les ressources non conformes traitées ou exemptées, on repasse l’assignation en --enforcement-mode Default. Deux pièges : les politiques DeployIfNotExists et Modify exigent une identité managée dotée du rôle adéquat sur le périmètre, et elles ne corrigent pas les ressources existantes sans tâche de remédiation explicite.

Surface d’attaque d’une plateforme bâtie sur le CAF

Une zone d’atterrissage concentre le pouvoir. C’est son intérêt, et c’est la cible.

Identité du pipeline de plateforme. Elle détient en général Owner sur la racine intermédiaire. Sa compromission équivaut à celle de toute la plateforme. Contre-mesures : fédération OIDC restreinte à une branche protégée et un environnement approuvé, revue obligatoire des modifications, aucun secret client.
Élévation d’accès à la racine. Un administrateur global Entra peut s’octroyer User Access Administrator sur la racine de tout le tenant Azure. Contre-mesures : rôles Entra privilégiés en juste à temps via PIM, alerte sur l’opération d’élévation, revue des rôles assignés au Tenant Root Group (qui devrait être vide).
Héritage RBAC. Un rôle assigné sur un management group descend sur tous les abonnements en dessous. Une assignation Contributor posée « temporairement » en haut de la hiérarchie dure plus longtemps que la plupart des contrats de prestataires.
Exemptions de politique. Le droit de créer une exemption vaut droit de désactiver un garde-fou. On le réserve à l’équipe plateforme, avec date d’expiration systématique.
Contournement réseau. Un spoke qui obtient une IP publique ou un point de terminaison public sur un service PaaS (Platform as a Service) sort du chemin d’inspection. Contre-mesures : politiques Deny sur Corp, points de terminaison privés, DNS (Domain Name System) privé centralisé dans Connectivity.
Journalisation sous contrôle de la charge. Si les journaux restent dans l’abonnement applicatif, l’attaquant qui le compromet les efface. Les paramètres de diagnostic doivent pointer vers l’abonnement Management, avec RBAC séparé ; la page sur la journalisation d’audit immuable détaille cette séparation d’autorité.

Ce que le CAF ne garantit pas

Le CAF n’est ni une norme, ni une certification, ni une garantie de sécurité. Aucun organisme n’audite la conformité au CAF, et aucun texte réglementaire n’y renvoie. Une plateforme « alignée CAF » est une plateforme qui ressemble à un schéma de Microsoft, ce qui n’engage personne d’autre que l’auteur du schéma.

Les tableaux de conformité réglementaire de Defender for Cloud mappent des politiques Azure sur des référentiels : ce sont des indicateurs techniques, pas une attestation. La conformité à la directive NIS 2 (directive (UE) 2022/2555) ou au règlement DORA (Digital Operational Resilience Act, règlement (UE) 2022/2554) exige de la gouvernance, de la gestion des risques et des preuves que le CAF ne produit pas ; les pages NIS 2 et DORA décrivent ces obligations, et ce que vérifie un auditeur ne se limite pas à un écran vert.

Le CAF ne garantit pas non plus la réversibilité. Il décrit une adoption Azure ; la sortie d’Azure n’y figure qu’à la marge. La réversibilité doit venir du contrat, traité dans les clauses de sécurité fournisseur, et de l’analyse de risque tiers. Il ne remplace pas davantage une analyse de risque : les politiques ALZ par défaut traitent des risques génériques, pas ceux identifiés par une démarche EBIOS RM.

CAF, Well-Architected Framework, TOGAF et COBIT

Le Well-Architected Framework (WAF, à ne pas confondre avec le Web Application Firewall) évalue une charge de travail selon cinq piliers : fiabilité, sécurité, optimisation des coûts, excellence opérationnelle, efficacité des performances. Le CAF traite le patrimoine et l’organisation. Le partage tient en une ligne : le CAF construit la plateforme sur laquelle les charges arrivent, le WAF juge chaque charge qui y arrive. Utiliser le WAF sans zone d’atterrissage produit des applications excellentes dans une plateforme anarchique ; l’inverse produit une plateforme impeccable remplie d’applications fragiles. Le cadre homonyme d’Amazon, l’AWS Well-Architected Framework, joue le même rôle avec six piliers au lieu de cinq : on ne se ruine pas en noms chez les hyperscalers.

TOGAF opère un cran au-dessus : il structure l’architecture d’entreprise, dont le cloud n’est qu’une architecture de transition. Le CAF se range naturellement dans les phases de planification de migration de l’ADM (Architecture Development Method). COBIT 2019 fournit les objectifs de gouvernance et la répartition des responsabilités ; la méthodologie Govern du CAF en est une déclinaison opérationnelle restreinte à Azure. Le CAF n’est donc pas un concurrent de ces cadres, c’est un manuel d’implémentation pour un fournisseur.

Coût d’exploitation et position à retenir

Le compromis central : on gagne une architecture de référence éprouvée et déployable en jours plutôt qu’en mois ; on paie une dépendance à des choix opinionnés de Microsoft et un coût de maintenance permanent. Les politiques ALZ évoluent avec les services Azure ; une plateforme qui n’intègre pas les nouvelles versions de référence accumule une dérive comparable à celle d’un système non patché, documentée dans la page sur la dette de sécurité.

Les postes de coût réels : une équipe plateforme dédiée (identité, réseau, politiques, pipeline), l’ingestion Log Analytics qui croît avec chaque paramètre de diagnostic activé, et certains services de connectivité facturés au forfait mensuel quel que soit le trafic (pare-feu en SKU (Stock Keeping Unit) Premium, protection DDoS (Distributed Denial of Service) réseau). Ce dernier poste se dimensionne avant déploiement, l’accélérateur proposant de l’activer par défaut. Le chiffrage complet relève du coût total de possession.

La position tranchée : sur Azure, adopter la hiérarchie ALZ telle quelle, déployée par IaC, plutôt que d’inventer une structure maison. Les écarts se justifient par écrit, un par un. Cette recommandation vaut tant que l’organisation dispose d’une équipe capable de maintenir la plateforme ; sans elle, une ALZ complète devient une cathédrale sans sacristain, et un périmètre réduit (identité, journalisation, politiques de base) vaut mieux qu’un déploiement intégral abandonné. Sur un environnement multicloud, on garde les principes généraux du CAF comme exigences et on n’importe pas son vocabulaire Azure dans les autres plateformes.

Sources

Microsoft Cloud Adoption Framework for Azure, Microsoft.
Microsoft Azure Well-Architected Framework, Microsoft.
Directive (UE) 2022/2555 (NIS 2).
Règlement (UE) 2022/2554 (DORA).

🐝 Ce qui arrive si on s’en passe

Sans zone d’atterrissage préalable, chaque équipe crée ses abonnements, ses réseaux et ses administrateurs. Les plages IP se chevauchent et interdisent plus tard toute interconnexion sans renumérotation. Les rôles privilégiés s’assignent au cas par cas, et personne ne peut dire qui détient Owner où. Sans politiques héritées, une ressource déployée dans une région non autorisée ou exposée par IP publique ne déclenche aucun refus, seulement une découverte tardive. Les journaux restent dans l’abonnement qui les produit, à portée de quiconque le compromet, ce qui efface la trace au moment précis où elle sert. Reprendre l’existant coûte alors une migration de plus, cette fois de l’intérieur du cloud.

🦫 Explication de la marmotte 🍫

Quand une entreprise déplace ses programmes de ses propres ordinateurs vers les ordinateurs loués à Microsoft, elle suit souvent une méthode écrite par Microsoft. Cette méthode a sept étapes. D’abord, écrire pourquoi on change. Ensuite, faire la liste de tous les programmes et décider du sort de chacun : le déplacer tel quel, le réécrire, le remplacer ou le supprimer. Puis préparer l’espace d’accueil avant d’y mettre quoi que ce soit : qui a le droit d’entrer, comment les ordinateurs communiquent, où sont gardées les traces de ce qui se passe. Seulement après, on déplace les programmes, par petits groupes. Trois étapes tournent en permanence : fixer des règles (par exemple, interdire de stocker des données hors d’Europe) que la machine applique toute seule, protéger contre les attaques, et surveiller que tout fonctionne. Les règles sont posées sur des dossiers, et tout ce qui est rangé dedans en hérite. Si quelqu’un vole le compte qui modifie ces dossiers du haut, il contrôle tout. Si on oublie une règle, rien ne bloque l’erreur. Attention : suivre cette méthode ne prouve pas qu’on respecte la loi, et aucun organisme ne délivre de diplôme pour l’avoir suivie. Elle aide à construire proprement, elle ne remplace ni les contrôles, ni les preuves, ni le contrat avec le fournisseur.

Pages voisines

La citent

Microsoft Cloud Adoption Framework : phases, landing zones, limites

Elle cite

: les deux pages se citent l’une l’autre.

Microsoft Cloud Adoption Framework : phases, landing zones, limites

Microsoft Cloud Adoption Framework : phases, landing zones, limites

Statut du CAF : documentation vivante, pas norme versionnée

Ce que chaque méthodologie demande vraiment

Principes généraux d’adoption contre spécificités Azure

Azure landing zones : la hiérarchie qui porte la sécurité

Mise en œuvre : prérequis et choix d’outillage

Exemple : poser un garde-fou de région sans casser l’existant

Surface d’attaque d’une plateforme bâtie sur le CAF

Ce que le CAF ne garantit pas

CAF, Well-Architected Framework, TOGAF et COBIT

Coût d’exploitation et position à retenir

Sources

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines