Les Cloud Adoption Frameworks (CAF) sont les méthodologies publiées par AWS, Azure et Google pour structurer l’adoption du cloud à l’échelle de l’entreprise. Ils répondent à une question concrète : « par où commencer une migration cloud quand on est une organisation de 500+ personnes ? ». Cette page compare les 3 frameworks majeurs, identifie ce qui est réellement utile vs ce qui relève du re-marketing, présente le concept de landing zone, et défend une opinion : utiliser un seul framework comme structure de référence est efficace, mais ne pas en faire de la religion — la réalité d’une migration ne suit jamais le diagramme du fournisseur.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Les 3 frameworks majeurs : AWS CAF, Azure CAF, Google Cloud Adoption Framework
- Les 6 perspectives AWS et les 5 phases Azure
- La notion de landing zone comme socle d’adoption
- Ce qui est utile vs marketing dans chaque framework
- L’approche pragmatique en 2026
Prérequis : avoir compris les modèles de déploiement cloud. Si besoin, lisez d’abord Modèles de déploiement.
1. Pourquoi un framework d’adoption
Section intitulée « 1. Pourquoi un framework d’adoption »Migrer 200 applications d’un datacenter on-premise vers le cloud n’est pas un projet technique — c’est un projet de transformation qui implique sécurité, conformité, finance, RH, opérations, et jusqu’au juridique. Sans structure, les organisations partent dans tous les sens : l’équipe dev migre des applis avec ses outils, la sécurité découvre 6 mois plus tard, les coûts explosent parce que personne n’a posé la gouvernance financière.
Les Cloud Adoption Frameworks apportent une structure : quoi traiter, dans quel ordre, par qui, avec quels outputs. Les 3 frameworks majeurs (AWS, Azure, Google) couvrent les mêmes territoires avec des découpages différents.
2. AWS Cloud Adoption Framework — 6 perspectives
Section intitulée « 2. AWS Cloud Adoption Framework — 6 perspectives »L’AWS CAF structure l’adoption en 6 perspectives transverses, chacune avec ses propres pratiques et capabilities.
Les 6 perspectives
Section intitulée « Les 6 perspectives »Business : alignement entre stratégie business et capacités cloud. Définir les KPI métier, identifier les opportunités de transformation, prioriser les workloads selon la valeur business.
People : développement des compétences, gestion du changement, structures organisationnelles. Former les équipes, recruter ou faire monter en compétence, créer un Cloud Center of Excellence.
Governance : gestion des risques, conformité, contrôle financier. Mettre en place les politiques (security, FinOps, data residency), définir qui décide quoi.
Platform : conception et exploitation de la plateforme cloud. Landing zone, services partagés (CI/CD, monitoring, identity), architecture de référence.
Security : sécurité de bout en bout, du périmètre aux données. IAM, conformité, response aux incidents, gestion des vulnérabilités.
Operations : exploitation continue, observabilité, gestion des incidents. SLA, monitoring, runbooks, automation opérationnelle.
Les phases AWS
Section intitulée « Les phases AWS »À cette structure transverse s’ajoute un flux d’adoption en 4 phases :
- Envision : identifier la vision business cloud.
- Align : aligner les équipes et identifier les capabilities à développer.
- Launch : exécuter des projets pilotes.
- Scale : passer à l’échelle sur l’ensemble de l’organisation.
Lecture critique du AWS CAF
Section intitulée « Lecture critique du AWS CAF »Utile : les 6 perspectives forcent à ne pas oublier People et Governance, souvent négligés dans les migrations cloud purement techniques. Le découpage est cohérent et permet de bien répartir les responsabilités entre équipes.
Re-marketing : les « capabilities » détaillées dans les white papers AWS sont parfois étirées pour pousser les services AWS spécifiques. Lire les white papers en gardant un œil critique — toutes les capabilities n’exigent pas un service AWS dédié.
3. Azure Cloud Adoption Framework — 5 phases
Section intitulée « 3. Azure Cloud Adoption Framework — 5 phases »Le Azure CAF adopte une approche phaseée, avec 5 grandes étapes séquentielles.
Les 5 phases
Section intitulée « Les 5 phases »1. Strategy : définir les motivations business, les outcomes attendus, le business case. Identifier les KPI de succès. Cette phase produit un document stratégique avant tout investissement technique.
2. Plan : construire le rationalization des workloads existants (qui migre, qui reste, qui se retire). Planifier la roadmap, les compétences nécessaires, le budget. Définir les landing zones cibles.
3. Ready : préparer l’environnement Azure. Déployer les landing zones (réseaux, identity, gouvernance), former les équipes, mettre en place les outils. Cette phase est technique mais préalable à toute migration.
4. Adopt : exécuter la migration ou l’innovation. Deux sous-volets : Migrate (migrer les apps existantes via 6R/7R) et Innovate (construire de nouvelles apps cloud-native).
5. Govern + Manage : gouverner et exploiter en continu. Cette phase n’est jamais terminée — elle dure toute la vie de l’adoption cloud.
Lecture critique du Azure CAF
Section intitulée « Lecture critique du Azure CAF »Utile : la séparation claire entre Strategy (avant tout) et Adopt (pas avant que Ready soit fait) évite l’erreur classique de migrer avant d’avoir préparé la plateforme. Le concept de landing zone est particulièrement bien formalisé chez Azure (cf. section suivante).
Re-marketing : la documentation pousse vers les services Azure (Defender, Sentinel, Cost Management) à chaque chapitre. Les principes restent valables ailleurs, mais les outils nommés sont propriétaires. Lire en gardant une distance critique.
4. Google Cloud Adoption Framework
Section intitulée « 4. Google Cloud Adoption Framework »Le Google Cloud Adoption Framework est plus léger et plus orienté maturité. Il propose 4 thèmes et 3 niveaux de maturité sur chacun.
Les 4 thèmes
Section intitulée « Les 4 thèmes »- Learn : compétences et formation des équipes.
- Lead : sponsorship et gouvernance executive.
- Scale : automation et industrialisation.
- Secure : posture de sécurité.
Les 3 niveaux de maturité
Section intitulée « Les 3 niveaux de maturité »Tactical : usage cloud opportuniste, projets isolés, peu de gouvernance. Première adoption.
Strategic : adoption planifiée, landing zone en place, gouvernance posée. Phase intermédiaire.
Transformational : transformation profonde, cloud-native par défaut, organisation et processus alignés. Maturité complète.
Lecture critique du Google framework
Section intitulée « Lecture critique du Google framework »Utile : le modèle de maturité Tactical / Strategic / Transformational permet d’évaluer où on en est plutôt que de suivre une feuille de route linéaire. Cette approche est moins prescriptive et plus pragmatique pour des organisations qui ont déjà commencé.
Re-marketing : très focalisé Google Cloud, peu d’exemples génériques. Le framework reste plus marketing que les deux autres en 2026.
5. Le concept central — landing zone
Section intitulée « 5. Le concept central — landing zone »Quel que soit le framework choisi, le concept de landing zone est central et vraiment utile.
Définition
Section intitulée « Définition »Une landing zone est une plateforme cloud préconfigurée, conforme aux bonnes pratiques de sécurité, gouvernance et opérations de l’organisation. Quand une équipe veut déployer une nouvelle application, elle arrive sur la landing zone — réseaux, identity, monitoring, sécurité de base sont déjà en place.
Composants typiques d’une landing zone
Section intitulée « Composants typiques d’une landing zone »| Composant | Rôle |
|---|---|
| Multi-comptes / multi-projects | Isolation entre environnements et workloads |
| Identity centralisée | SSO, federation, RBAC unifié |
| Réseau hub-and-spoke | VPC central avec connexions vers chaque workload |
| Connectivité hybride | VPN ou Direct Connect / ExpressRoute vers on-prem |
| Logging et monitoring centralisés | Tous les logs convergent vers un compte « audit » |
| Politiques de sécurité | Service Control Policies (AWS), Azure Policies, Org Policies (GCP) |
| Gestion des coûts | Budgets, tagging obligatoire, allocation par centre de coût |
| CI/CD partagés | Pipelines réutilisables pour tous les workloads |
Implémentations par fournisseur
Section intitulée « Implémentations par fournisseur »AWS : Control Tower automatise la création de landing zones avec multi-account organizations, Service Control Policies, baseline de sécurité.
Azure : Azure Landing Zones (Enterprise-Scale) avec subscriptions hiérarchiques via management groups, Azure Policies, Hub-and-Spoke réseau.
Google Cloud : Cloud Foundation Toolkit (modules Terraform officiels) pour déployer une landing zone avec organization, folders, projects, networking.
Outscale : pas de toolkit officiel landing zone packagé en 2026 — à construire avec Terraform sur la base du outscale/outscale provider, en suivant les bonnes pratiques génériques.
Pourquoi c’est central
Section intitulée « Pourquoi c’est central »Sans landing zone, chaque équipe crée son réseau, son IAM, ses politiques — incohérence totale, sécurité défaillante, coûts non maîtrisés. Avec landing zone, toutes les équipes héritent par défaut des bonnes pratiques.
C’est le concept le plus opérationnel des frameworks d’adoption — le reste est souvent du méta-discours.
6. Comparaison synthétique des 3 frameworks
Section intitulée « 6. Comparaison synthétique des 3 frameworks »| Aspect | AWS CAF | Azure CAF | Google CAF |
|---|---|---|---|
| Structure | 6 perspectives × 4 phases | 5 phases séquentielles | 4 thèmes × 3 niveaux maturité |
| Maturité du framework | Mature, beaucoup de white papers | Mature, très complet | Plus léger, moins prescriptif |
| Landing zone | Control Tower | Azure Landing Zones | Cloud Foundation Toolkit |
| Force | Découpage par perspective claire | Phases ordonnées, landing zone détaillée | Approche par maturité pragmatique |
| Faiblesse | Documentation très volumineuse | Marketing Azure intégré | Moins prescriptif, moins exemple |
7. Stratégie d’adoption pragmatique 2026
Section intitulée « 7. Stratégie d’adoption pragmatique 2026 »Sur les transformations cloud que j’accompagne, voici l’approche que je recommande, indépendamment du framework officiellement choisi.
Phase 1 — Évaluation et stratégie (6 à 12 semaines)
Section intitulée « Phase 1 — Évaluation et stratégie (6 à 12 semaines) »Avant tout investissement technique :
- Inventaire des applications existantes (combien, quelle criticité, quelles dépendances).
- Rationalization 6R/7R : pour chaque app, décider la stratégie (cf. Stratégies de migration 6R/7R).
- Business case chiffré : TCO actuel vs TCO cloud (cf. TCO cloud vs on-premise).
- Choix du fournisseur : AWS, Azure, GCP, Outscale ou hybride selon contexte (souveraineté, écosystème).
- Sponsorship executive : sans soutien CDO/CTO, la migration échoue.
Phase 2 — Landing zone (12 à 16 semaines)
Section intitulée « Phase 2 — Landing zone (12 à 16 semaines) »Construire la plateforme avant de migrer :
- Multi-account / multi-project structure (typiquement : prod, non-prod, audit, security, network, sandbox par équipe).
- Identity centralisée (Entra ID, Okta, Identity Center) avec SSO et MFA.
- Réseau hub-and-spoke avec connectivité on-prem (Direct Connect ou VPN).
- Politiques de sécurité baseline (encryption, logging, IAM minimum).
- Logging centralisé dans un compte/projet audit, immuable.
- Tagging obligatoire par policy (CostCenter, Environment, Owner).
Phase 3 — Migration progressive (12 à 36 mois)
Section intitulée « Phase 3 — Migration progressive (12 à 36 mois) »Migrer app par app, pas en big bang :
- Pilotes sur 3 à 5 applications pour valider l’approche.
- Industrialisation : factory de migration, automatisation, runbooks.
- Migration en vague par dépendances : front-end légers d’abord, données critiques à la fin.
- Décommissionnement au fur et à mesure : pas de double facturation.
Phase 4 — Optimisation continue
Section intitulée « Phase 4 — Optimisation continue »Une fois en cloud :
- FinOps continu, audit mensuel des coûts, optimisation Reserved/Spot.
- Sécurité continue : posture management (CSPM), threat detection, audits.
- Modernisation : refactoriser les apps lift-and-shift en cloud-native progressivement.
- Gouvernance : adapter les politiques selon l’évolution.
8. Comment utiliser un Cloud Adoption Framework efficacement
Section intitulée « 8. Comment utiliser un Cloud Adoption Framework efficacement »Un CAF est un référentiel utile pour structurer une adoption cloud à grande échelle, mais sa valeur dépend de la manière dont l’organisation se l’approprie. Trois bonnes pratiques évitent les écueils les plus courants.
Choisir un seul cadre comme vocabulaire commun. Mélanger plusieurs CAF dans les présentations internes (perspectives AWS, phases Azure, niveaux de maturité Google) dilue le message et complique la coordination entre équipes. Adopter un seul cadre — souvent celui du fournisseur principal — comme référentiel commun simplifie les échanges. Le contenu des CAF est largement convergent (même découpage en stratégie, opérations, sécurité, gouvernance), donc le choix précis compte moins que la discipline collective d’utiliser le même langage.
Lire avec esprit critique. Les frameworks publiés par les fournisseurs sont rédigés en partie par leurs équipes marketing : chaque chapitre tend naturellement à citer les services maison. Une organisation qui s’approprie le cadre emprunte la structure (perspectives, phases, jalons de maturité) mais adapte le détail à son contexte (équipes, parc applicatif, contraintes réglementaires). Aucune migration ne suit littéralement les diagrammes du fournisseur, et c’est attendu.
Concentrer l’effort opérationnel sur la landing zone. Sur l’ensemble d’un CAF, la section qui apporte la valeur opérationnelle la plus directe est la landing zone : organisation des comptes, identité fédérée, réseau de référence, journalisation centralisée, garde-fous de sécurité. Investir tôt dans une landing zone solide donne à toutes les équipes un environnement standardisé sur lequel construire, et évite la prolifération de configurations divergentes. La méthodologie générale du CAF est utile comme structure mentale, mais c’est la landing zone qui livre du résultat tangible.
Adapter au critère de souveraineté quand il s’applique. Quand l’organisation a des contraintes de souveraineté (données sensibles, secteur régulé, juridiction française ou européenne exigée), les CAF des hyperscalers ne traitent pas directement ce critère. Il appartient alors à l’équipe d’ajouter une perspective souveraineté au cadre : choix du fournisseur, qualification SecNumCloud le cas échéant, gestion des clés, localisation des données — tous sujets traités dans la section Souveraineté et conformité.
À retenir
Section intitulée « À retenir »- Les CAF structurent l’adoption cloud à l’échelle de l’entreprise — utiles pour ne rien oublier.
- AWS CAF : 6 perspectives (Business, People, Governance, Platform, Security, Operations) + 4 phases.
- Azure CAF : 5 phases séquentielles (Strategy, Plan, Ready, Adopt, Govern/Manage).
- Google CAF : 4 thèmes × 3 niveaux de maturité (Tactical, Strategic, Transformational).
- Le concept de landing zone est le plus opérationnel — plateforme préconfigurée avec sécurité, identité, réseau, gouvernance.
- Approche pragmatique 2026 : évaluation → landing zone → migration progressive → optimisation continue.
- Bonnes pratiques : choisir un seul cadre comme vocabulaire commun, lire avec esprit critique, concentrer l’effort opérationnel sur la landing zone, ajouter explicitement une perspective souveraineté quand elle s’applique.