Le Volet 5 est la pièce maîtresse du recueil de bonnes pratiques OUTSCALE : les 7 piliers Well-Architected appliqués au cloud souverain français — les 6 piliers AWS WAF (Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, 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 volet sert de grille de référence pour évaluer une architecture OUTSCALE, justifier un choix technique, ou préparer un audit interne ou externe.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Comment chaque pilier se traduit sur OUTSCALE — services concernés, patterns concrets, antipatterns observés.
- Les questions clés à poser sur une architecture OUTSCALE pour mesurer sa posture, pilier par pilier.
- Les checklists Definition of Done actionnables qui permettent de valider la conformité d'un environnement.
- Les ADR types (Architecture Decision Records) qui structurent une décision défendable et auditable.
- Les points d'audit qui permettent de mesurer la conformité par pilier sur un compte réel via
oapi-cli. - L'articulation entre les piliers — comment prioriser quand les contraintes se contredisent (par exemple Performance vs Cost, Sovereignty vs Performance).
Pourquoi adopter une grille Well-Architected sur OUTSCALE
Section intitulée « Pourquoi adopter une grille Well-Architected sur OUTSCALE »Le Well-Architected Framework d'AWS, popularisé depuis 2015, est devenu la grille de référence pour évaluer une architecture cloud, indépendamment du fournisseur. Sur OUTSCALE, l'adopter présente quatre bénéfices opérationnels :
- Vocabulaire commun — les architectes, les RSSI et les FinOps qui ont travaillé sur AWS, Azure ou GCP retrouvent immédiatement leurs repères. Cette continuité accélère l'onboarding et la transférabilité des compétences.
- Critères de revue — un point de revue technique ou un comité d'architecture s'appuie sur une grille reconnue. Les arbitrages se font en termes de pilier impacté, pas en termes d'opinion.
- Conformité documentée — les checklists et les ADR types fournissent la trace nécessaire à un audit interne (ISO 27001, SecNumCloud) ou externe (commissaire aux comptes pour les organisations soumises à CSRD ou DORA).
- Priorisation explicite — quand toutes les améliorations possibles sont mises sur la même grille, les arbitrages deviennent visibles : on choisit délibérément Performance contre Cost, ou Cost contre Sustainability, et la décision est documentée.
Le Well-Architected n'est pas un module en bout de course, c'est une grammaire qui structure la pratique en continu. Sur ce recueil, chaque page des volets 1 à 4 est taguée par les piliers concernés via le champ wafPillars du frontmatter. Le Volet 5 agrège ces tags pour offrir une lecture transverse par sujet de qualité.
Pourquoi 7 piliers et pas 6
Section intitulée « Pourquoi 7 piliers et pas 6 »Le Well-Architected Framework d'AWS propose 6 piliers couvrant les dimensions classiques d'une architecture cloud : opérations, sécurité, fiabilité, performance, coût, durabilité. Ce recueil 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 physique des données, juridiction applicable au fournisseur, réversibilité maîtrisée, lock-in technologique aux APIs propriétaires.
Le 7ᵉ pilier traite des mécanismes (lois extraterritoriales applicables, formats d'export ouverts, dépendances aux APIs spécifiques), 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. Sans ce pilier, une architecture peut être parfaitement conforme aux 6 piliers AWS et rester juridiquement vulnérable à une coupure unilatérale ou à une demande extraterritoriale d'accès aux données. C'est précisément ce que le pilier Sovereignty adresse.
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 (les pages sont actuellement publiées en brouillon, à challenger sur des cas réels avant figement).
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, post-mortems sans blâme. Sur OUTSCALE, il s'articule autour d'OMS pour le traçage des appels API (audit, équivalent CloudTrail) via la méthode ReadApiLogs, d'une stack Prometheus / Grafana / Loki ou d'un OpenTelemetry collector pour les métriques applicatives, et du pipeline IaC (Terraform + Packer + Ansible) comme mécanisme de changement contrôlé. Une infrastructure mal opérée subit en moyenne plus d'incidents évitables qu'une infrastructure équivalente bien opérée.
Security
Section intitulée « Security »Le pilier qui couvre l'identité (EIM), le réseau (Net, security groups, isolation), le chiffrement at-rest et in-transit, 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, le pilier 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. La sécurité n'est jamais le résultat d'une seule mesure mais d'une défense en profondeur appliquée sur toutes les couches.
Reliability
Section intitulée « Reliability »Le pilier qui couvre la multi-AZ, les objectifs RTO / RPO différenciés par criticité, les sauvegardes selon la règle 3-2-1, le plan de reprise versionné en Git, les patterns de résilience applicative (circuit breaker, retry with backoff, bulkhead, timeout) et le chaos engineering. Sur OUTSCALE, la mécanique multi-AZ Net + Subnets, les snapshots BSU et l'export OOS dans un compte d'audit séparé sont les briques de base. Une architecture revendiquée comme résiliente sans test de bascule réelle reste un postulat — le chaos engineering est la seule preuve.
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 applicatifs, et le choix entre types d'instances selon le profil de charge mesuré. Sur OUTSCALE, les gammes TINA au format tinavW.cXrYpZ offrent un éventail aligné sur les usages classiques, complété par les fGPU pour l'IA et le calcul intensif. La règle pragmatique : démarrer petit, mesurer, ajuster sur la base de métriques réelles plutôt que de surdimensionner par confort.
Cost Optimization
Section intitulée « Cost Optimization »Le pilier qui couvre le right-sizing trimestriel, le lifecycle OOS, le tagging à fin de répartition (cost-center, project) et plus largement la discipline FinOps. Sur OUTSCALE, le right-sizing TINA ajusté à la consommation réelle, les lifecycle policies OOS (suppression différée via Expiration — pas de transition entre classes chez Outscale) et le suivi mensuel via l'API ReadConsumptionAccount (paramètres FromDate / ToDate / ShowPrice / ShowResourceDetails) sont les leviers principaux. Sur un parc mal entretenu, le right-sizing libère typiquement 15 à 30 % du budget compute.
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, l'API native ReadCO2EmissionAccount retourne une estimation des émissions en kg CO₂e sur les régions eu-west-2 et cloudgouv-eu-west-1, avec une rétention de 36 mois depuis janvier 2024. Le suivi régulier des émissions est une obligation de reporting pour les organisations soumises à la directive CSRD.
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 ouverts, test annuel) et le lock-in technologique (engagement aux APIs propriétaires vs aux standards OCI, S3-compatible, Kubernetes upstream). Sur OUTSCALE, la région cloudgouv-eu-west-1 qualifiée SecNumCloud 3.2 par l'ANSSI depuis décembre 2023 est la brique principale du pilier Sovereignty.
Comment articuler les 7 piliers entre eux
Section intitulée « Comment articuler les 7 piliers entre eux »Les 7 piliers ne sont pas indépendants. Certains se renforcent mutuellement, d'autres entrent en tension. Comprendre ces articulations évite les faux compromis et oriente les arbitrages.
Cost et Sustainability se renforcent. Le right-sizing libère du budget ET des émissions évitées. La lifecycle OOS supprime des objets inutiles ET du stockage allocataire d'énergie. Sur ces deux piliers, la même action sert les deux objectifs — le cas le plus rare où on n'arbitre pas.
Security et Operational Excellence se renforcent. La journalisation OMS sert à la fois la traçabilité (Security) et le post-mortem (OpEx). Le tagging structuré sert à la fois la conformité (Security) et la refacturation (OpEx). L'IaC comme porte d'entrée unique sert à la fois la sécurité (changements tracés) et l'opération (changements reproductibles).
Performance et Cost entrent en tension. Une instance TINA p1 est plus performante mais plus chère qu'une p3. Un volume io1 est plus rapide mais plus cher qu'un gp2. L'arbitrage se fait sur la base d'une mesure (la performance attendue est-elle nécessaire ?) et d'un SLA (quelle perte de revenu une latence anormale entraîne-t-elle ?).
Reliability et Cost entrent en tension. Une architecture multi-région active-active a un coût significatif (typiquement 30 à 50 % de surcoût) mais offre la meilleure protection contre la défaillance d'une région entière. L'arbitrage se fait sur la base de l'analyse de risque : la probabilité de défaillance multipliée par l'impact métier dépasse-t-elle le coût de la résilience ?
Sovereignty et Performance peuvent entrer en tension. La région cloudgouv-eu-west-1 qualifiée SecNumCloud peut avoir des contraintes opérationnelles spécifiques. Pour les workloads sans exigence SecNumCloud, la région commerciale eu-west-2 reste pertinente.
Sovereignty et Reliability se renforcent dans le scope européen. Une architecture qui respecte le pilier Sovereignty (résidence européenne, juridiction maîtrisée) bénéficie aussi d'une réduction du risque géopolitique sur la continuité du service. La doctrine Cloud au centre et NIS 2 alignent ces deux piliers pour le secteur public et les OSE.
Méthode de revue Well-Architected sur OUTSCALE
Section intitulée « Méthode de revue Well-Architected sur OUTSCALE »Une revue WAF se mène en quatre étapes successives :
- Cadrer le périmètre — quel système est revu (une application, un projet, un compte entier) ? Quels environnements (production seulement, ou prod + staging) ?
- Parcourir les questions clés par pilier — pour chaque pilier, lire les questions clés de la page dédiée et noter la réponse (oui / partiellement / non / non applicable). Documenter les justifications quand la réponse est « partiellement » ou « non ».
- Évaluer la posture — pour chaque pilier, calculer un score simple (par exemple sur 10) reflétant le niveau de maturité. Un pilier où plus de 50 % des questions reçoivent « non » est en posture fragile.
- Prioriser les actions correctives — sur la base de la matrice criticité × effort, identifier les 3 à 5 actions à mener dans le trimestre suivant. Documenter chacune comme un ADR.
Cette revue se conduit chaque trimestre sur les périmètres critiques, annuellement sur les périmètres standards. La discipline régulière prime sur la profondeur d'une revue exceptionnelle qui ne se reproduit jamais.
Comment chaque page de pilier est structurée
Section intitulée « Comment chaque page de pilier est structurée »Les 7 pages de pilier suivent la même structure pour faciliter la consultation et la consolidation des résultats d'audit :
- Le pilier en deux phrases — définition courte et périmètre.
- Les questions clés — 5 à 10 questions qu'une architecture doit pouvoir répondre.
- Application sur OUTSCALE — services concernés, patterns concrets validés, antipatterns observés.
- Checklist Definition of Done — items vérifiables qui valident la conformité du pilier.
- ADR types — 2 modèles d'Architecture Decision Records prêts à adapter.
- Points d'audit correspondants — commandes
oapi-cliou contrôles à mener sur un compte réel. - Antipatterns à éviter — récits d'erreurs observées, pour reconnaître et désamorcer.
- À retenir — 5 à 8 points clés à retenir après lecture.
FAQ — Questions fréquentes
Section intitulée « FAQ — Questions fréquentes »Pourquoi un 7ᵉ pilier Souveraineté absent du WAF AWS ?
Section intitulée « Pourquoi un 7ᵉ pilier Souveraineté absent du WAF AWS ? »Le Well-Architected Framework AWS a été conçu par Amazon pour ses clients hyperscaler. Les enjeux de souveraineté juridique (Cloud Act, FISA), de réversibilité face à un fournisseur dominant, et de lock-in technologique aux APIs propriétaires ne sont pas adressés explicitement dans le WAF AWS. Sur OUTSCALE comme sur les autres clouds souverains européens, ces enjeux deviennent structurants et méritent un pilier dédié. Le 7ᵉ pilier Sovereignty traite ces mécanismes de manière neutre et factuelle, sans argument commercial.
Comment se positionne OUTSCALE par rapport au WAF AWS ?
Section intitulée « Comment se positionne OUTSCALE par rapport au WAF AWS ? »OUTSCALE est compatible AWS sur un grand nombre d'opérations API, ce qui permet de réutiliser les outils standards (aws-cli, SDK boto3, Terraform AWS provider). Cette compatibilité couvre la transférabilité des compétences : un architecte qui maîtrise AWS retrouve ses repères sur OUTSCALE. Le WAF AWS s'applique donc largement, à l'ajout du 7ᵉ pilier près. Les 6 piliers AWS se traduisent directement avec quelques spécificités OUTSCALE : OMS plutôt que CloudTrail pour l'audit API, format TINA tinavW.cXrYpZ plutôt que les tailles AWS pour le sizing, et lifecycle OOS limité à Expiration (pas de transition entre classes).
Quelle région OUTSCALE choisir pour un workload soumis à NIS 2 ou à la doctrine Cloud au centre ?
Section intitulée « Quelle région OUTSCALE choisir pour un workload soumis à NIS 2 ou à la doctrine Cloud au centre ? »Pour un workload couvert par la doctrine Cloud au centre (administrations françaises, données sensibles publiques) ou par les obligations NIS 2 sur les OSE, la région à privilégier est cloudgouv-eu-west-1 qualifiée SecNumCloud 3.2 par l'ANSSI depuis décembre 2023. La région commerciale eu-west-2 (qualifiée HDS et ISO 27001) reste adaptée pour les workloads soumis au RGPD avec besoin de localisation française mais sans exigence SecNumCloud.
Comment mesurer son empreinte carbone sur OUTSCALE ?
Section intitulée « Comment mesurer son empreinte carbone sur OUTSCALE ? »OUTSCALE expose l'API native ReadCO2EmissionAccount qui retourne une estimation des émissions en kg CO₂e par mois, par catégorie de service (compute, etc.) et par facteur (electricity, etc.). Les données couvrent les régions eu-west-2 et cloudgouv-eu-west-1 depuis janvier 2024, avec une rétention de 36 mois. La pratique consiste à automatiser un appel mensuel et à alimenter un dashboard de suivi longitudinal, intégré au reporting RSE / CSRD annuel.
Comment industrialiser un audit Well-Architected sur OUTSCALE ?
Section intitulée « Comment industrialiser un audit Well-Architected sur OUTSCALE ? »L'industrialisation passe par trois étapes : (1) scripter les points d'audit de chaque pilier sous forme d'appels oapi-cli (ReadAccessKeys, ReadVms, ReadVolumes, ReadSnapshots, ReadConsumptionAccount, ReadCO2EmissionAccount…) ; (2) agréger les résultats dans un dashboard, croisé avec les tags pour ventiler par projet ; (3) réviser périodiquement les checklists Definition of Done de chaque pilier pour ajuster aux évolutions de l'API et des bonnes pratiques. Une page d'audit consolidé est en construction dans ce volet.
Comment articuler SecNumCloud, HDS et le pilier Security ?
Section intitulée « Comment articuler SecNumCloud, HDS et le pilier Security ? »SecNumCloud 3.2 est un référentiel de qualification ANSSI couvrant la sécurité technique et organisationnelle d'un fournisseur cloud (plus de 360 critères). HDS (Hébergement de Données de Santé) est une certification française spécifique au secteur santé. Le pilier Security du Well-Architected couvre les contrôles côté client (EIM, chiffrement, segmentation, journalisation). Les trois sont complémentaires : SecNumCloud et HDS qualifient la posture du fournisseur, le pilier Security trace ce qui reste à la charge du client. Une architecture conforme aux trois est en posture solide ; une architecture conforme uniquement à SecNumCloud/HDS sans contrôles client n'est pas réputée sécurisée.
À retenir
Section intitulée « À retenir »- 7 piliers — les 6 AWS WAF (Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability) plus le pilier Sovereignty spécifique au cloud souverain.
- Chaque pilier dispose de sa page dédiée avec questions clés, checklist, ADR types et points d'audit sur
oapi-cli. - Lecture transverse — les pages du recueil sont taguées via
wafPillars; le Volet 5 agrège ces tags par sujet de qualité. - Articulation entre piliers — Cost et Sustainability se renforcent ; Performance et Cost entrent en tension ; Sovereignty et Reliability convergent sur le scope européen.
- Méthode de revue — cadrer le périmètre, parcourir les questions, évaluer la posture, prioriser les actions ; trimestriellement sur les périmètres critiques.
- Le pilier Sovereignty traite des mécanismes (résidence, juridiction, réversibilité, lock-in), pas d'arguments commerciaux. Il complète, ne remplace pas.
- L'audit de posture matérialise cette grille en contrôles vérifiables sur un compte réel. Une page consolidée d'audit est en construction.