Le Well-Architected Framework adapté à OUTSCALE

Ce que vous allez apprendre

Ce qu’est le Well-Architected Framework et pourquoi il s’applique à OUTSCALE.
Les 6 piliers AWS WAF — OpEx, Security, Reliability, Performance, Cost, Sustainability.
Le 7ᵉ pilier Souveraineté, spécifique au cloud souverain, sans équivalent chez AWS.
Comment chaque page de la formation est taguée par pilier et comment lire la formation transversalement.

Qu’est-ce que le Well-Architected Framework

Le Well-Architected Framework (WAF) est un cadre de qualité pour l’architecture cloud, popularisé par AWS depuis 2015 et adopté ensuite par Microsoft Azure, Google Cloud et IBM Cloud. Il propose un vocabulaire commun pour parler de qualité d’architecture, sous forme de piliers (5 à l’origine, 6 depuis l’ajout de Sustainability en 2021), avec pour chaque pilier des questions clés, des bonnes pratiques et des antipatterns.

Le vocabulaire WAF est directement transférable à OUTSCALE parce que l’environnement Outscale partage les mêmes primitives techniques que les hyperscalers : instances de calcul, VPC, IAM, stockage objet S3-compatible, Kubernetes managé, load balancers. Adopter le vocabulaire WAF dans cette formation offre trois bénéfices :

Repère cognitif partagé — un lecteur familier d’AWS retrouve les piliers, les questions, les antipatterns. Il transpose ses réflexes plutôt que d’apprendre un nouveau formalisme.
Clé de voûte pour l’audit — un audit de posture cloud, manuel ou outillé, peut classer ses contrôles par pilier. La formation se prête à cette lecture par grammaire commune.
Lecture transverse — taguer chaque page par piliers permet une lecture verticale (par sujet : réseau, stockage, IAM…) et une lecture horizontale (par pilier : sécurité, fiabilité…).

Les 6 piliers du Well-Architected appliqués à OUTSCALE

Voici la grille des 6 piliers AWS WAF, traduite dans le contexte OUTSCALE.

Pilier 1 — Operational Excellence (Excellence opérationnelle)

Le pilier OpEx couvre tout ce qui touche à la conduite quotidienne d’une infrastructure cloud : observabilité, runbooks, gestion du changement, GitOps, métriques DORA.

Sur OUTSCALE, ce pilier se traduit en tagging discipliné (env, project, owner, cost-center), observabilité, runbooks versionnés en Git, et pipeline IaC qui sert de mécanisme de changement contrôlé.

Question clé : « Comment savez-vous ce qui se passe dans votre infrastructure, et comment réagissez-vous quand quelque chose va mal ? »

Pilier 2 — Security (Sécurité)

Le pilier Security couvre l’identité et les accès (EIM), le réseau (Net, security groups, isolation), le chiffrement (at-rest et in-transit), la gestion des secrets, la journalisation des appels API (OMS), et la conformité réglementaire.

Sur OUTSCALE, ce pilier prend une dimension supplémentaire grâce à la qualification SecNumCloud 3.2 sur la région cloudgouv-eu-west-1 — qui pré-couvre une partie significative des exigences de sécurité, à condition de l’utiliser correctement (le SecNumCloud d’Outscale ne dispense pas le client de configurer son EIM, son réseau et ses sauvegardes selon les bonnes pratiques).

Question clé : « Comment vous assurez-vous que seules les identités autorisées peuvent accéder à vos ressources, et comment détectez-vous toute anomalie ? »

Pilier 3 — Reliability (Fiabilité)

Le pilier Reliability 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 comme moyen de prouver la résilience plutôt que de la déclarer.

Sur OUTSCALE, la mécanique multi-AZ se déploie au niveau Net + Subnets ; les EIP flottantes offrent un mécanisme de bascule réseau ; OOS sert de cible d’archivage pour les sauvegardes long terme avec règle 3-2-1.

Question clé : « Que se passe-t-il si vous perdez 50 % de votre infrastructure d’un coup, et combien de temps mettez-vous à revenir en marche ? »

Pilier 4 — Performance Efficiency (Performance)

Le pilier Performance couvre le sizing des instances, les IOPS des volumes, la latence inter-AZ, les caches, le CDN quand c’est pertinent, et le choix entre types d’instances selon le profil de charge.

Sur OUTSCALE, les gammes TINA (tinav4, tinav5, tinav6 — versions à confirmer au moment de l’écriture des guides détaillés) offrent un éventail aligné sur les usages classiques (général, mémoire, calcul, GPU). Les volumes BSU se déclinent en plusieurs types selon les IOPS visées.

Question clé : « Avez-vous mesuré le besoin réel de vos applications avant de dimensionner, et comment ajustez-vous quand le profil change ? »

Pilier 5 — Cost Optimization (Optimisation des coûts)

Le pilier Cost couvre le right-sizing, le lifecycle OOS, les instances éphémères, le reporting, le tagging à fin de répartition, et plus largement la discipline FinOps (qui dépasse le strict cadre Well-Architected mais s’y articule).

Sur OUTSCALE, le pilier Cost se matérialise notamment via Karpenter sur OKS (un provider Outscale est maintenu par la communauté), les lifecycle policies sur OOS, et le tagging discipliné qui permet de répartir les coûts par projet ou par équipe.

Question clé : « Payez-vous pour ce que vous consommez réellement, et comment savez-vous où va l’argent ? »

Pilier 6 — Sustainability (Durabilité)

Le pilier Sustainability, ajouté par AWS en 2021, couvre l’empreinte environnementale d’une architecture cloud : right-sizing comme levier vert, lifecycle agressif sur le stockage froid, choix d’instances efficaces, placement géographique dans une région à faible intensité carbone.

Sur OUTSCALE, le service Carbon Footprint (lancé en novembre 2025) est intégré au Cockpit et exposé via une API publique. Il permet aux équipes IT et RSE de mesurer et suivre l’empreinte carbone estimée de leurs services cloud, dans un environnement souverain. La discipline d’architecture reste indispensable au-delà de la mesure : tout right-sizing est un gain Cost et Sustainability ; tout lifecycle OOS qui supprime ou archive des objets non lus est un double gain.

Question clé : « Avez-vous mesuré l’empreinte de votre infrastructure, et avez-vous pris les leviers de réduction à votre portée ? »

Le 7ᵉ pilier — Sovereignty (Souveraineté)

Le 7ᵉ pilier Souveraineté est la spécificité de cette formation. Il n’existe pas dans le WAF AWS, parce qu’il n’est pas pertinent pour un fournisseur soumis à juridiction américaine. Sur un cloud souverain comme OUTSCALE, il prend tout son sens.

Ce que le pilier Sovereignty couvre

Résidence des données — où vivent physiquement les données, qui peut y accéder juridiquement.
Juridiction applicable — Cloud Act américain, FISA, Patriot Act vs droit français et européen ; rôle du SecNumCloud comme isolation juridique.
Réversibilité — plan de sortie, formats d’export, dépendances aux services managés non standards.
Lock-in technologique — niveau d’engagement aux APIs propriétaires vs aux standards (OCI pour les containers, Kubernetes, Terraform comme couche d’abstraction).

Pourquoi en faire un pilier à part

Trois raisons motivent l’élévation de la souveraineté au rang de pilier :

Visibilité éditoriale — un sujet qui s’invite dans toutes les discussions cloud en France mérite un traitement frontal, pas une mention marginale.
Cohérence avec l’audit — un contrôle de posture doit pouvoir dire « cette ressource est dans cloudgouv-eu-west-1, donc sous juridiction française », ce qui demande une grille dédiée.
Lecture transverse spécifique — la souveraineté traverse Security (juridiction), Reliability (réversibilité, plan de sortie), OpEx (formats d’export documentés). Lui dédier un pilier permet d’articuler ces traversées.

Le modèle de responsabilité partagée OUTSCALE

Le Well-Architected ne dispense pas de comprendre qui est responsable de quoi entre OUTSCALE et le client. Le modèle de responsabilité partagée d’OUTSCALE suit la même logique que les hyperscalers, avec des nuances.

Ce qu’OUTSCALE prend en charge

Sécurité physique des datacenters — accès, alimentation, refroidissement.
Hyperviseur et virtualisation — TINA OS, isolation entre tenants.
Disponibilité du plan de contrôle — API OAPI, Cockpit, services managés.
Maintenance des services managés — OKS (control plane), LBU, OOS, OMS.
Conformité de l’infrastructure au référentiel SecNumCloud 3.2 sur la région cloudgouv-eu-west-1.

Ce qui reste à votre charge

Configuration EIM — utilisateurs, groupes, policies, MFA. Outscale ne sait pas si votre policy * sur * est intentionnelle.
Configuration réseau — Net, subnets, security groups. Un SG en 0.0.0.0/0 sur SSH est de votre responsabilité.
Sécurité des OMI — patches, durcissement (ANSSI BP-028), conformité applicative.
Sauvegardes des données — Outscale ne sauvegarde pas vos données pour vous. Vos snapshots BSU et vos exports OOS sont à votre charge.
Conformité applicative — RGPD, HDS, sectorielle. La conformité du fournisseur ne fait pas votre conformité.

Le modèle complet est détaillé dans la page transverse Responsabilité partagée.

Comment chaque page de la formation est taguée

Chaque page de fondation, de service ou de pratique inclut, dans son frontmatter, un champ wafPillars qui liste les piliers concernés :

---
title: "Concevoir un réseau OUTSCALE multi-AZ"
wafPillars: ["Reliability", "Security", "Performance"]
---

Le Volet 5 de la formation agrège ces tags : chaque page de pilier (Security, Reliability, etc.) liste les guides du site qui l’adressent, avec une checklist consolidée et des ADR (Architecture Decision Records) types.

Lecture transverse — comment naviguer

Cette formation peut se lire de deux manières complémentaires :

Lecture verticale (par volet) — vous suivez la progression linéaire Découvrir → Construire → Industrialiser → Services managés → Well-Architected → Audit → Capstone. C’est la lecture conseillée pour un premier parcours complet.
Lecture horizontale (par pilier) — vous arrivez avec un besoin précis (« je dois améliorer ma posture Security ») et vous parcourez toutes les pages taguées Security via la page de pilier dédiée. C’est la lecture conseillée en mode consultation.

À retenir

Le Well-Architected Framework fournit un vocabulaire commun de qualité d’architecture, transférable d’AWS à OUTSCALE grâce à la convergence des primitives techniques.
Les 6 piliers AWS WAF (OpEx, Security, Reliability, Performance, Cost, Sustainability) couvrent les dimensions classiques.
Le 7ᵉ pilier Souveraineté est la spécificité de cette formation — résidence, juridiction, réversibilité, lock-in.
Chaque page est taguée par pilier ; le Volet 5 agrège les tags pour une lecture transverse.
Le modèle de responsabilité partagée OUTSCALE est analogue à celui des hyperscalers — la conformité du fournisseur ne fait jamais votre conformité.

Prochaines étapes

Choisir son parcours selon votre profil 5 profils types et le parcours conseillé pour chacun.

Volet 5 — Well-Architected appliqué La pièce maîtresse — 7 piliers détaillés, checklists, ADR types.

Pourquoi cette formation existe Le positionnement pédagogique et le public cible.

Responsabilité partagée Le modèle qui distingue ce qu'OUTSCALE prend en charge de ce qui reste à votre charge.