Comment savoir si une architecture cloud est bien conçue ? La réponse industrielle s’appuie depuis 2015 sur le Well-Architected Framework d’AWS, devenu standard de fait — Azure et Google Cloud ont publié leurs équivalents quasi-identiques. Le cadre repose sur 6 piliers complémentaires : excellence opérationnelle, sécurité, fiabilité, efficacité des performances, optimisation des coûts, et durabilité (ajouté en 2021). Cette page détaille chaque pilier avec ses questions clés et ses anti-patterns, présente les frameworks AWS / Azure / GCP, et introduit le récent EU Cloud Sovereignty Framework d’octobre 2025 qui couvre la dimension souveraineté.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- L’origine et l’évolution du Well-Architected Framework AWS depuis 2015
- Les 6 piliers détaillés avec leurs questions clés et anti-patterns
- Les équivalents Azure Well-Architected et Google Cloud Architecture Framework
- Les ressources d’architecture chez les fournisseurs souverains européens
- Le nouveau EU Cloud Sovereignty Framework d’octobre 2025
Prérequis : avoir compris la grille XaaS et les modèles de déploiement. Si besoin, lisez d’abord IaaS, PaaS, SaaS, FaaS, CaaS.
1. Origine et évolution du Well-Architected Framework
Section intitulée « 1. Origine et évolution du Well-Architected Framework »AWS a publié le Well-Architected Framework en 2015 pour formaliser les bonnes pratiques observées chez les architectes les plus matures de sa base utilisateurs. Le cadre initial reposait sur 5 piliers : excellence opérationnelle, sécurité, fiabilité, efficacité des performances, et optimisation des coûts. Le sixième pilier — Sustainability — a été ajouté en décembre 2021 sous la pression croissante des enjeux RSE et du calcul d’empreinte carbone.
Le framework a été massivement adopté par l’industrie pour trois raisons : il est gratuit et public (white papers téléchargeables), il offre un outil intégré (Well-Architected Tool) qui permet d’évaluer une architecture, et il s’est imposé comme vocabulaire commun entre architectes, même hors AWS.
Microsoft a publié son Azure Well-Architected Framework en 2020 avec 5 piliers identiques à l’origine, Sustainability ajouté ensuite. Google Cloud a publié son Architecture Framework en 2022 avec 6 piliers identiques. IBM a publié son propre Well-Architected Framework. Cette convergence n’est pas un hasard — les bonnes pratiques d’architecture cloud sont universelles.
2. Les 6 piliers Well-Architected en détail
Section intitulée « 2. Les 6 piliers Well-Architected en détail »Pilier 1 — Operational Excellence (Excellence opérationnelle)
Section intitulée « Pilier 1 — Operational Excellence (Excellence opérationnelle) »Définition : capacité à exécuter et superviser des systèmes pour livrer de la valeur métier, et à améliorer continuellement les processus et les procédures.
Deux questions à se poser :
- Comment déterminez-vous ce qu’est la priorité quand un incident survient à 2h du matin, et est-ce documenté dans un runbook que l’astreinte peut suivre sans appeler le tech lead ?
- À quelle fréquence vos déploiements sont-ils automatisés, testés et rollback-ables sans intervention manuelle ?
Anti-pattern : déploiements manuels en production, runbooks dans la tête de la personne d’astreinte, pas de post-mortem après les incidents — l’organisation reproduit les mêmes erreurs faute d’apprentissage formalisé.
Pilier 2 — Security (Sécurité)
Section intitulée « Pilier 2 — Security (Sécurité) »Définition : capacité à protéger les données, les systèmes et les actifs en s’appuyant sur les technologies cloud pour améliorer la posture de sécurité.
Deux questions à se poser :
- Comment identifiez-vous les utilisateurs qui accèdent à vos ressources, et leurs permissions sont-elles minimales au sens du least privilege ?
- Comment détectez-vous les incidents de sécurité et combien de temps faut-il pour qu’une compromission devienne visible dans vos dashboards ?
Anti-pattern : compte root partagé entre développeurs, security groups ouverts à 0.0.0.0/0, pas de chiffrement at-rest sur les données sensibles, logs CloudTrail désactivés. Voir Responsabilité partagée pour le détail.
Pilier 3 — Reliability (Fiabilité)
Section intitulée « Pilier 3 — Reliability (Fiabilité) »Définition : capacité d’un système à exécuter sa fonction prévue correctement et de manière cohérente, malgré les pannes attendues.
Deux questions à se poser :
- Quelle est la conséquence d’une panne d’AZ sur votre service ? Les utilisateurs voient-ils quelque chose ou est-ce transparent ?
- À quelle fréquence testez-vous votre plan de DR en grandeur réelle, et combien de temps avez-vous mesuré pour la bascule ?
Anti-pattern : architecture mono-AZ « parce que c’est plus simple », backups qui ne sont jamais testés en restauration, runbook de DR qui demande un mot de passe que l’astreinte n’a pas. Voir Résilience cloud : HA, DR, chaos engineering.
Pilier 4 — Performance Efficiency (Efficacité des performances)
Section intitulée « Pilier 4 — Performance Efficiency (Efficacité des performances) »Définition : capacité à utiliser les ressources informatiques efficacement pour répondre aux exigences du système et maintenir cette efficacité quand la demande évolue.
Deux questions à se poser :
- Comment mesurez-vous la performance perçue par vos utilisateurs, et savez-vous distinguer le p50 du p99 ?
- Vos ressources sont-elles dimensionnées correctement ou avez-vous des instances tournant à 5 % de CPU 24/7 par habitude héritée de l’on-prem ?
Anti-pattern : monitoring qui ne mesure que le CPU et la RAM côté infrastructure, jamais la latence applicative côté utilisateur. Sur-dimensionnement systématique « au cas où ». Pas de benchmark réel avant de scale-up.
Pilier 5 — Cost Optimization (Optimisation des coûts)
Section intitulée « Pilier 5 — Cost Optimization (Optimisation des coûts) »Définition : capacité à exécuter les systèmes en livrant de la valeur métier au coût le plus bas.
Deux questions à se poser :
- Connaissez-vous la répartition de votre facture par projet, par équipe, par environnement (dev / staging / prod) ?
- Quel est le ratio de votre consommation entre on-demand, Reserved/Savings Plans, et Spot ?
Anti-pattern : 100 % on-demand par défaut (perte de 30–50 % d’économies), ressources de dev jamais arrêtées la nuit, NAT Gateway provisionnée par AZ sans audit de besoin, snapshots cumulatifs sans politique de rétention. Voir Pay-as-you-go : modèles tarifaires.
Pilier 6 — Sustainability (Durabilité environnementale)
Section intitulée « Pilier 6 — Sustainability (Durabilité environnementale) »Définition : capacité à minimiser l’impact environnemental des charges de travail cloud, en optimisant l’utilisation des ressources et en privilégiant les régions à faible empreinte carbone.
Deux questions à se poser :
- Connaissez-vous le mix énergétique de la région où tournent vos workloads ? La région française est à ~50 g CO₂/kWh, la région polonaise à ~700 g.
- Vos workloads non urgents (batch, ML training) sont-ils schedulés sur des régions à bas carbone quand c’est possible ?
Anti-pattern : déploiement par défaut dans us-east-1 AWS sans réflexion énergétique, instances tournant 24/7 alors que l’usage est de 8h–20h, données froides conservées en Standard au lieu de Glacier. Voir Green cloud et sustainability.
3. Comparaison AWS vs Azure vs GCP
Section intitulée « 3. Comparaison AWS vs Azure vs GCP »Les trois frameworks couvrent essentiellement les mêmes territoires avec un vocabulaire légèrement différent.
| Pilier | AWS Well-Architected | Azure Well-Architected | Google Cloud Architecture Framework |
|---|---|---|---|
| 1. Excellence opérationnelle | Operational Excellence | Operational Excellence | Operational Excellence |
| 2. Sécurité | Security | Security | Security, privacy, and compliance |
| 3. Fiabilité | Reliability | Reliability | Reliability |
| 4. Performance | Performance Efficiency | Performance Efficiency | Performance optimization |
| 5. Coût | Cost Optimization | Cost Optimization | Cost optimization |
| 6. Durabilité | Sustainability | Sustainability | Sustainability |
Les divergences sont marginales — typiquement la granularité des questions, l’outillage associé, et l’intégration native avec les services du fournisseur. Le vocabulaire est universel, ce qui permet à un architecte de raisonner indépendamment du fournisseur. Les trois frameworks proposent un outil interactif (AWS Well-Architected Tool, Azure Well-Architected Review, Google Cloud Architecture Framework Review) qui guide une évaluation pilier par pilier.
4. Les ressources d’architecture chez les fournisseurs souverains européens
Section intitulée « 4. Les ressources d’architecture chez les fournisseurs souverains européens »Les fournisseurs cloud souverains européens proposent des ressources d’architecture sous des formats variés — guides techniques, services de consulting, centres de ressources. Voici un panorama factuel des ressources publiques en 2026, utiles pour un architecte qui démarre sur ces fournisseurs.
Outscale publie des Technical Guides dans sa documentation officielle, qui couvrent les bonnes pratiques de haute disponibilité, sécurité, et conformité SecNumCloud. Le programme Outscale Cloud Practice propose un accompagnement par des Solutions Architects pour les déploiements complexes.
OVHcloud a ouvert un Architecture Centre qui regroupe guides, icônes, références d’architecture et toolbox pour architectes. La communication officielle annonce un framework foundationnel couvrant sustainability, automation et scalabilité, en cours de développement.
Scaleway propose un service Architecture Review délivré par ses Solutions Architects, ainsi que des ressources de blog publiques détaillées sur les patterns d’architecture cloud-native.
Cloud Temple, Cegedim Cloud et autres fournisseurs souverains spécialisés proposent un accompagnement sur mesure adapté aux exigences de leurs segments (santé, défense, secteur public).
Comment utiliser ces ressources avec un framework existant
Section intitulée « Comment utiliser ces ressources avec un framework existant »Le vocabulaire des 6 piliers Well-Architected est universel et transposable. Pour structurer une revue d’architecture sur un cloud souverain, on peut emprunter la grille AWS / Azure / GCP et l’appliquer aux services équivalents du fournisseur souverain choisi. Les concepts (Operational Excellence, Security, Reliability, Performance, Cost, Sustainability) restent valables indépendamment du fournisseur.
Le récent EU Cloud Sovereignty Framework (cf. section suivante) apporte une dimension complémentaire que les WAF des hyperscalers n’avaient pas : la souveraineté juridique et opérationnelle.
5. EU Cloud Sovereignty Framework — la nouvelle pièce d’octobre 2025
Section intitulée « 5. EU Cloud Sovereignty Framework — la nouvelle pièce d’octobre 2025 »Le 20 octobre 2025, la Commission européenne a publié le Cloud Sovereignty Framework, premier référentiel européen d’évaluation de la souveraineté d’une solution cloud. Ce n’est pas un Well-Architected Framework au sens AWS — il complète plutôt qu’il ne remplace.
Structure du framework
Section intitulée « Structure du framework »Le framework définit 8 objectifs de souveraineté cloud, chacun gradé sur 5 niveaux (de 0 à 4) appelés SEAL (Sovereignty Effectiveness Assurance Level). Une architecture peut donc être évaluée objectivement sur chaque dimension, plutôt que d’être qualifiée binairement « souveraine » ou « non souveraine ».
Le framework s’inspire de trois sources convergentes :
- Le Trusted Cloud framework du CIGREF français.
- La stratégie Cloud de Confiance et la qualification SecNumCloud de l’ANSSI.
- L’initiative allemande Souveräner Cloud.
Il intègre par construction les exigences réglementaires européennes : NIS2, DORA, CSRD.
Pourquoi c’est complémentaire au WAF
Section intitulée « Pourquoi c’est complémentaire au WAF »Les Well-Architected Frameworks AWS / Azure / GCP traitent l’excellence d’architecture technique : performance, fiabilité, coûts, sécurité opérationnelle. Le Cloud Sovereignty Framework européen traite la souveraineté juridique et opérationnelle : juridiction du fournisseur, contrôle effectif des données, indépendance technologique, immunité aux lois extraterritoriales.
Les deux dimensions sont distinctes mais complémentaires. Une architecture peut être excellente côté WAF mais faible côté Sovereignty Framework (par exemple AWS sur des données réglementées européennes). Une architecture peut être excellente côté Sovereignty mais immature côté WAF (par exemple un déploiement souverain sans monitoring SLO/SLI). La pratique mature consiste à faire les deux revues sur les workloads sensibles.
Pour le détail du sujet souveraineté, voir Souveraineté technologique de la stack.
6. Comment utiliser ces frameworks au quotidien
Section intitulée « 6. Comment utiliser ces frameworks au quotidien »Les frameworks ne sont pas des livres à lire une fois — ce sont des outils opérationnels qui s’utilisent sur 4 moments distincts de la vie d’une architecture.
Lors du design initial
Section intitulée « Lors du design initial »Avant la première ligne de Terraform, organisez une session design d’une journée où vous parcourez les 6 piliers WAF avec l’équipe. Pour chaque pilier, identifiez 2–3 décisions structurantes. Documentez les choix dans un Architecture Decision Record (ADR) versionné dans Git. Cette session prend 4 à 6 heures pour une architecture moyenne et économise des semaines de retravail à 6 mois.
Si l’architecture cible un cloud souverain et traite des données réglementées, ajouter une session SEAL sur les 8 objectifs du Cloud Sovereignty Framework dans la même journée.
Lors d’une revue pré-production
Section intitulée « Lors d’une revue pré-production »Avant la mise en production, organiser une revue Well-Architected avec un architecte non impliqué dans le design initial. AWS Well-Architected Tool, Azure Advisor et GCP Active Assist permettent de générer un rapport automatique sur les 6 piliers chez ces fournisseurs. Ce rapport est un point de départ — l’humain doit ensuite prioriser les findings selon le risque métier réel.
Sur cloud souverain sans outil intégré, faire la revue avec un template de questionnaire maison ou emprunté aux frameworks publics. C’est moins industriel mais tout à fait viable.
Lors d’un incident
Section intitulée « Lors d’un incident »Quand un incident survient, le framework aide à classer la cause racine sur le pilier concerné. « Cette panne est due à Reliability (mono-AZ) » est plus actionnable que « on a eu une panne ». L’incident devient une opportunité d’apprentissage qui renforce le pilier identifié. Couplé avec les post-mortems blameless, c’est une arme contre la répétition des erreurs.
Lors d’un audit annuel
Section intitulée « Lors d’un audit annuel »Une fois par an minimum, faire une revue complète Well-Architected sur l’ensemble des architectures critiques. C’est l’occasion de mesurer l’évolution depuis la dernière revue, de prioriser les chantiers de l’année à venir, et de calibrer le budget cloud selon les besoins identifiés. Sans cette discipline annuelle, le framework devient un classeur poussiéreux que personne n’ouvre.
7. Comment utiliser le framework selon le contexte
Section intitulée « 7. Comment utiliser le framework selon le contexte »Le framework n’impose pas une pondération uniforme des 6 piliers — chaque organisation calibre ses priorités selon son métier, ses contraintes et son cycle de vie. Voici comment les piliers se priorisent typiquement selon le contexte.
Démarrage et phase startup : les piliers Cost Optimization et Performance Efficiency sont prioritaires. Sustainability et Reliability sont à un niveau de base, à renforcer quand le produit a trouvé sa traction. Ne pas sur-investir en HA multi-région tant qu’on n’a pas validé le marché.
Croissance et scale-up : la priorité bascule sur Reliability et Operational Excellence. Les pannes ont désormais un coût business mesurable, l’organisation doit industrialiser ses pratiques opérationnelles.
Secteur réglementé (banque, santé, administration) : Security et Reliability dominent quoi qu’il en coûte. Les contraintes réglementaires et les exigences de SLA contractuels imposent des architectures multi-AZ, multi-région, audit-ready dès le J1.
Maturité et CSRD : à partir des engagements RSE et de la pression de la directive CSRD européenne, Sustainability prend de l’importance. Cf. Green cloud et sustainability pour le détail.
À retenir
Section intitulée « À retenir »- Le Well-Architected Framework d’AWS (2015) est devenu le standard de l’architecture cloud, repris quasi-identique par Azure, Google et IBM.
- 6 piliers universels : Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability.
- Chaque pilier contient des questions structurantes et des anti-patterns identifiés par l’industrie.
- Les souverains européens (Outscale, OVHcloud, Scaleway, Cloud Temple) n’ont pas publié d’équivalent formel — Technical Guides, Architecture Centre, Architecture Review existent mais ne forment pas de cadre unifié.
- Le EU Cloud Sovereignty Framework d’octobre 2025 complète les WAF en couvrant la souveraineté juridique et opérationnelle (8 objectifs, niveaux SEAL 0–4).
- Les framework s’utilisent à 4 moments : design initial, revue pré-prod, post-mortem d’incident, audit annuel.
- Le vocabulaire est l’apport principal des frameworks — bien plus que la checklist technique.