Cloud Adoption Frameworks (CAF) : AWS, Azure, Google comparés

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 ? ». Ces trois cadres sont des options sur un même axe, celui du vocabulaire de pilotage : cette leçon les compare, sépare ce qui est réellement utile de ce qui relève du re-marketing, et défend une opinion : choisir un seul cadre comme référence commune est efficace, mais il ne faut pas en faire une religion. La réalité d'une migration ne suit jamais le diagramme du fournisseur.

Ce que vous allez apprendre

• Les 3 frameworks majeurs : AWS CAF, Azure CAF, Google Cloud Adoption Framework
• Les 6 perspectives AWS et les 7 phases Azure
• Comment choisir un cadre, et pourquoi un seul suffit
• Ce qui est utile vs marketing dans chaque framework
• Où se situe la zone d'atterrissage (landing zone) dans ces cadres
• Une séquence d'adoption type, de l'évaluation à l'optimisation

Prérequis : avoir lu la leçon sur les stratégies de migration 6R / 7R, dont la première phase d'adoption reprend la classification, et connaître les modèles de déploiement. La zone d'atterrissage (la plateforme préconfigurée sur laquelle les équipes arrivent) est enseignée dans la leçon Organiser ses comptes cloud et sa hiérarchie ; il suffit d'en retenir ici la définition en une phrase.

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é le découvre 6 mois après, 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

L'AWS CAF structure l'adoption en 6 perspectives transverses, chacune avec ses propres pratiques et capabilities.

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. Zone d'atterrissage (la plateforme préconfigurée sur laquelle les équipes arrivent, détaillée dans la leçon sur les comptes et la hiérarchie), 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

À cette structure transverse s'ajoute un flux d'adoption en 4 phases :

1. Envision : identifier la vision business cloud.
2. Align : aligner les équipes et identifier les capabilities à développer.
3. Launch : exécuter des projets pilotes.
4. Scale : passer à l'échelle sur l'ensemble de l'organisation.

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, 7 phases

Le Azure CAF adopte une approche par phases, avec 7 grandes phases (Strategy, Plan, Ready, Adopt, Govern, Secure, Manage), les phases opérationnelles (Govern, Secure, Manage) s'exécutant en parallèle pendant l'exploitation (documentation Microsoft Learn, relevée le 12 octobre 2026).

Les 7 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 : préparer l'organisation (personnes, processus, technologie) à l'adoption d'Azure : compétences nécessaires, roadmap, budget. La rationalisation des workloads existants (qui migre, qui reste, qui se retire), selon les stratégies 6R/7R (rehost, replatform, refactor, etc., détaillées dans la leçon dédiée), se conduit avec le volet Migrate de la phase Adopt.

3. Ready : préparer l'environnement Azure. Déployer la zone d'atterrissage (réseaux, identity, gouvernance), former les équipes, mettre en place les outils. Cette phase est technique mais préalable à toute migration.

4. Adopt : migrer, moderniser et construire des workloads. Trois volets dans la documentation Microsoft : Migrate (migrer les apps existantes via 6R/7R), Modernize (améliorer les workloads existants) et Cloud-native (construire de nouvelles apps).

5. Govern, 6. Secure et 7. Manage : gouverner, protéger et exploiter en continu. Ces phases ne sont jamais terminées, elles durent toute la vie de l'adoption cloud.

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 zone d'atterrissage est particulièrement bien formalisé chez Azure (voir la section 5).

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

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

Là où AWS raisonne par perspectives et Azure par phases, Google organise son cadre autour de quatre thèmes évalués en continu, pas franchis une fois pour toutes. Les deux premiers (Learn, Lead) touchent l'humain et la gouvernance, les deux suivants (Scale, Secure) l'industrialisation et la posture de sécurité. On ne « termine » aucun de ces thèmes : on progresse en maturité sur chacun, ce que mesure la section suivante.

• 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é

Tactical : usage cloud opportuniste, projets isolés, peu de gouvernance. Première adoption.

Strategic : adoption planifiée, fondations et gouvernance posées (la zone d'atterrissage s'y rattache dans cette lecture). Phase intermédiaire.

Transformational : transformation profonde, cloud-native par défaut, organisation et processus alignés. Maturité complète.

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. Où se situe la zone d'atterrissage dans ces cadres ?

La zone d'atterrissage est la partie des trois cadres qui livre du résultat concret, et elle s'enseigne à part. Elle correspond à la perspective Platform chez AWS et à la phase Ready chez Azure ; chez Google, organisé par thèmes et niveaux de maturité, elle se situe naturellement au niveau Strategic (rapprochement fait par cette leçon : Google ne désigne pas la zone d'atterrissage comme telle). Sa définition, ses composants, les outils proposés par chaque fournisseur et le moment où la construire sont détaillés dans la leçon Organiser ses comptes cloud et sa hiérarchie.

6. Comparaison synthétique des 3 frameworks

Ce tableau met les trois cadres côte à côte pour trancher rapidement. Ne cherchez pas le « meilleur » : ils couvrent le même territoire avec des découpages différents, et le bon choix est presque toujours celui du fournisseur principal de votre organisation. Ce sont trois options d'un même choix de vocabulaire, pas trois méthodes concurrentes ; la ligne Force dit ce que chacune apporte, la ligne Faiblesse ce qu'il faut corriger en la lisant.

Aspect	AWS CAF	Azure CAF	Google CAF
Structure	6 perspectives × 4 phases	7 phases (4 séquentielles, 3 opérationnelles en parallèle)	4 thèmes × 3 niveaux maturité
Maturité du framework	Mature, beaucoup de white papers	Mature, très complet	Plus léger, moins prescriptif
Force	Découpage par perspective claire	Phases ordonnées, zone d'atterrissage détaillée	Approche par maturité pragmatique
Faiblesse	Documentation très volumineuse	Marketing Azure intégré	Moins prescriptif, peu d'exemples génériques

Glissez pour voir

7. Stratégie d'adoption pragmatique 2026

Voici une séquence d'adoption type, valable indépendamment du cadre choisi. Les durées sont des ordres de grandeur pour une grande organisation, sans mesure sourcée : calibrez-les sur un pilote.

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 de la direction (CTO, DSI), la migration échoue.

Phase 2, Zone d'atterrissage (12 à 16 semaines)

Construire la plateforme avant de migrer (voir la leçon sur les comptes et la hiérarchie) :

• 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.
• Étiquetage obligatoire par politique as code sur le plan d'infrastructure (environnement, equipe, projet), comme l'enseigne la leçon sur les garde-fous et l'étiquetage.

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 vagues, selon la règle de la leçon sur les stratégies 6R/7R : une vague est un groupe d'applications dépendantes, les vagues étant ordonnées ensuite par stratégie.
• Décommissionnement au fur et à mesure : pas de double facturation.

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

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. Quatre 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 zone d'atterrissage. Sur l'ensemble d'un CAF, la section qui apporte la valeur opérationnelle la plus directe est la zone d'atterrissage : 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 zone d'atterrissage 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 zone d'atterrissage 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 le couvrent pas de façon homogène : Microsoft rattache à son CAF une Sovereign Landing Zone (Microsoft Cloud for Sovereignty), conçue d'abord pour le secteur public, tandis qu'AWS et Google Cloud n'en documentaient pas d'équivalent rattaché à leur CAF au 12 octobre 2026. 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

• 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 : 7 phases (Strategy, Plan, Ready, Adopt, Govern, Secure, Manage).
• Google CAF : 4 thèmes × 3 niveaux de maturité (Tactical, Strategic, Transformational).
• La zone d'atterrissage est le concept le plus opérationnel, plateforme préconfigurée avec sécurité, identité, réseau, gouvernance ; elle s'enseigne dans la leçon sur les comptes et la hiérarchie.
• Séquence d'adoption type : évaluation → zone d'atterrissage → migration progressive → optimisation continue.
• Bonnes pratiques : choisir un seul cadre comme vocabulaire commun, lire avec esprit critique, concentrer l'effort opérationnel sur la zone d'atterrissage, ajouter explicitement une perspective souveraineté quand elle s'applique.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →