Le Volet 5 est la pièce maîtresse de la formation : les 7 piliers Well-Architected appliqués à OUTSCALE — les 6 piliers AWS WAF (Operational Excellence, Security, Reliability, Performance, Cost, Sustainability) plus un 7ᵉ pilier Souveraineté, spécifique au cloud souverain. Chaque pilier dispose de sa page dédiée avec questions clés, checklist Definition of Done, ADR types et points d’audit correspondants.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Comment chaque pilier se traduit sur OUTSCALE — services concernés, patterns, antipatterns.
- Les questions clés à poser sur une architecture OUTSCALE pour chaque pilier.
- Les checklists actionnables qui permettent de valider une posture par pilier.
- Les ADR types (Architecture Decision Records) qui structurent une décision défendable.
- Les points d’audit qui permettent de mesurer la conformité par pilier.
Pourquoi 7 piliers et pas 6
Section intitulée « Pourquoi 7 piliers et pas 6 »Le Well-Architected Framework d’AWS, popularisé depuis 2015, propose 6 piliers couvrant les dimensions classiques d’une architecture cloud : opérations, sécurité, fiabilité, performance, coût, durabilité. Cette formation ajoute un 7ᵉ pilier Souveraineté parce qu’une architecture déployée sur un cloud souverain présente des enjeux qui n’existent pas chez les hyperscalers : résidence des données, juridiction applicable, réversibilité, lock-in technologique.
Ce 7ᵉ pilier traite des mécanismes (lois applicables, formats d’export, dépendances aux APIs propriétaires), pas d’arguments commerciaux. Il s’inscrit en cohérence avec les 6 autres piliers, pas en remplacement — un audit Well-Architected complet sur OUTSCALE évalue les 7.
Les 7 piliers en bref
Section intitulée « Les 7 piliers en bref »Chaque pilier dispose de sa page de synthèse dédiée dans ce volet, à venir au fil de la production de la formation.
Operational Excellence
Section intitulée « Operational Excellence »Le pilier qui couvre la conduite quotidienne d’une infrastructure : tagging, runbooks, observabilité, GitOps, métriques DORA, gestion du changement. Sur OUTSCALE, il s’articule autour d’OMS pour le traçage des appels API (audit, équivalent CloudTrail), d’une stack Prometheus / Grafana ou d’un OTel collector pour les métriques applicatives, et du pipeline IaC comme mécanisme de changement contrôlé.
Security
Section intitulée « Security »Le pilier qui couvre l’identité (EIM), le réseau (Net, security groups, isolation), le chiffrement (at-rest natif sur BSU/OOS, in-transit via TLS), la gestion des secrets (typiquement OpenBao ou Vault, OUTSCALE n’expose pas de KMS managé natif en 2026), la journalisation des appels API (OMS) et la conformité réglementaire. Sur OUTSCALE, il prend une dimension supplémentaire grâce à la qualification SecNumCloud 3.2 sur la région cloudgouv-eu-west-1, à condition de configurer correctement la couche client.
Reliability
Section intitulée « Reliability »Le pilier qui couvre la multi-AZ, les objectifs RTO / RPO, les sauvegardes, le plan de reprise, les patterns de résilience (circuit breaker, retry with backoff, bulkhead) et le chaos engineering. Sur OUTSCALE, les EIP flottantes et la mécanique multi-AZ Net + Subnets sont les briques de base.
Performance Efficiency
Section intitulée « Performance Efficiency »Le pilier qui couvre le sizing des instances, les IOPS des volumes, la latence inter-AZ, les caches, et le choix entre types d’instances selon le profil de charge. Sur OUTSCALE, les gammes TINA offrent un éventail aligné sur les usages classiques.
Cost Optimization
Section intitulée « Cost Optimization »Le pilier qui couvre le right-sizing, le lifecycle OOS, les instances éphémères, le tagging à fin de répartition et plus largement la discipline FinOps. Sur OUTSCALE, Karpenter sur OKS et les lifecycle policies sur OOS sont les leviers principaux.
Sustainability
Section intitulée « Sustainability »Le pilier qui couvre l’empreinte environnementale d’une architecture : right-sizing comme levier vert, lifecycle agressif sur le stockage froid, choix d’instances efficaces. Sur OUTSCALE, le service Carbon Footprint lancé en novembre 2025 (intégré au Cockpit + API publique) permet de mesurer et suivre l’empreinte carbone des services cloud consommés.
Sovereignty (7ᵉ pilier — spécifique cloud souverain)
Section intitulée « Sovereignty (7ᵉ pilier — spécifique cloud souverain) »Le pilier qui couvre la résidence des données (où vivent-elles physiquement, qui peut y accéder juridiquement), la juridiction applicable (droit français et européen vs Cloud Act / FISA), la réversibilité (plan de sortie, formats d’export) et le lock-in technologique (engagement aux APIs propriétaires vs aux standards). Sur OUTSCALE, la région cloudgouv-eu-west-1 qualifiée SecNumCloud 3.2 est la brique principale du pilier Sovereignty.
Comment chaque page de pilier sera structurée
Section intitulée « Comment chaque page de pilier sera structurée »Chaque page de pilier (à venir) suivra la même structure pour faciliter la consultation :
- Le pilier en deux phrases — définition et périmètre.
- Les questions clés — 5 à 8 questions qu’une architecture doit pouvoir répondre.
- Application sur OUTSCALE — services concernés, patterns, antipatterns.
- Checklist Definition of Done — items vérifiables.
- ADR types — 2 à 3 modèles d’Architecture Decision Records.
- Points d’audit correspondants — items vérifiables sur un compte réel.
- Antipatterns à éviter — récits d’erreurs observées.
- À retenir — 5 à 8 points clés.
À retenir
Section intitulée « À retenir »- 7 piliers — les 6 AWS WAF (OpEx, Security, Reliability, Performance, Cost, Sustainability) + le pilier Souveraineté spécifique au cloud souverain.
- Chaque pilier dispose de sa page dédiée avec checklist, ADR types et points d’audit.
- Lecture transverse — les pages de ce Volet 5 agrègent les tags
wafPillarsde toute la formation. - L’audit de posture matérialise cette grille en contrôles vérifiables sur un compte réel.
- Le pilier Souveraineté traite les mécanismes (résidence, juridiction, réversibilité, lock-in), pas les arguments commerciaux.