Une revue Well-Architected n'est pas un questionnaire
La plupart des revues Well-Architected qui n'aboutissent à rien partagent le même schéma : quelqu'un ouvre l'AWS Well-Architected Tool, enchaîne 60 questions en deux heures avec un seul architecte dans la salle, exporte le PDF et le range dans un SharePoint. Six mois plus tard, rien n'a bougé et l'exercice est perçu comme de la conformité décorative.
Une revue qui produit de la valeur est un audit animé : basé sur des preuves, multi-rôles, borné dans le temps et — surtout — qui se termine par un plan de remédiation chiffré, doté d'un propriétaire et planifié. Les questions du framework sont une checklist de couverture, pas le livrable. Ce que vous produisez, c'est un document de décision pour ceux qui financent et exploitent le workload.
Cadrage : un workload, pas « le compte AWS »
L'unité de revue est un workload : un ensemble de composants qui délivrent une valeur métier, avec un propriétaire identifiable et un rayon d'impact défini. « Notre patrimoine AWS » n'est pas un workload. « L'API de commande client et ses bases de données, en prod et pré-prod » en est un.
Avant de poser le moindre atelier dans les agendas, il faut figer :
- Le périmètre : comptes, régions, VPC, dépôts de code, pipelines, dépendances SaaS tierces.
- Le contexte métier : criticité, objectifs RTO/RPO, contraintes réglementaires (DORA, NIS2, PCI DSS, HDS), saisonnalité du trafic.
- Les lentilles : la lentille Well-Architected de base, plus Serverless, SaaS, Data Analytics, Machine Learning ou une lentille personnalisée encodant vos propres standards de plateforme.
- Les participants : l'architecte du workload, un SRE/exploitant, un développeur qui livre dessus toutes les semaines, un référent sécurité et idéalement le product owner. Oublier la voix de l'exploitation est le moyen le plus rapide d'obtenir un score de maturité fictif.
Le déroulé de l'atelier, étape par étape
Sur un workload de taille moyenne, comptez trois semaines de bout en bout. Tout comprimer sur une journée est possible, mais produit des constats superficiels.
| Phase | Timing | Qui | Sortie |
|---|---|---|---|
| Lancement & cadrage | J-15, 1h | Architecte, PO, animateur | Définition du workload, lentilles, liste des participants |
| Collecte de preuves | J-14 à J-3 | Animateur + équipe plateforme | Schémas, dépôts IaC, exports Trusted Advisor / Security Hub / Compute Optimizer, historique d'incidents, décomposition des coûts |
| Pré-remplissage | J-2, 2h | Animateur | Réponses factuelles pré-rédigées, liste des points ouverts |
| Atelier | J0, 2 × 3h | Panel complet | Réponses validées, risques identifiés, quick wins |
| Consolidation | J+3 | Animateur | Rapport, registre des risques, feuille de route de remédiation |
| Restitution | J+7, 1h30 | Panel + direction technique | Plan arbitré et financé |
Le pré-remplissage est ce qui distingue un vrai animateur d'un preneur de notes. Des questions comme « avez-vous des déploiements automatisés ? » ou « vos sauvegardes sont-elles testées ? » doivent arriver en séance déjà répondues, preuves à l'appui, pour que le groupe consacre son temps aux sujets réellement discutables : les arbitrages, la dette technique assumée, les désaccords entre dev et ops sur ce qui se passe vraiment en production.
Animer les six piliers sans endormir la salle
Six piliers en six heures, cela fait une cinquantaine de minutes chacun — et ils n'intéressent pas tout le monde de la même façon. Quelques règles d'animation qui fonctionnent :
- Commencer par l'Excellence opérationnelle, pas par la Sécurité. On échauffe la salle sur du concret (runbooks, déploiements, astreinte) et on fait émerger le modèle d'exploitation réel, qui éclaire ensuite tous les autres piliers.
- Demander des preuves, pas des opinions. « On supervise tout » devient « montrez-moi l'alerte qui s'est déclenchée au dernier incident et qui l'a acquittée ».
- Limiter les débats à trois minutes et parquer le reste. Un parking à 15 sujets est un bon signe, pas un échec.
- Séparer le risque de la solution. L'atelier identifie les écarts ; la conception des remédiations se fait après, avec les bonnes personnes. Sinon vous passez 40 minutes à arbitrer Aurora contre RDS Multi-AZ et vous n'atteignez jamais le pilier Développement durable.
Utilisez honnêtement la classification de risque de l'outil. Un High Risk Issue (HRI) doit signifier « ceci peut provoquer une panne majeure, une fuite de données ou une dérive budgétaire dans les 12 mois ». Si tout est HRI, plus rien ne l'est.
Les livrables d'un audit d'architecture AWS
Le PDF exporté du Well-Architected Tool est une matière première, pas un livrable. Voici le paquet sur lequel les équipes agissent réellement :
| Livrable | Contenu | Audience |
|---|---|---|
| Synthèse exécutive (3–5 slides) | Maturité par pilier, top 5 des risques en langage métier, budget et charge nécessaires | CTO, direction technique |
| Schéma d'architecture cible | État actuel et état cible, écarts surlignés | Architectes, tech leads |
| Registre des risques | Une ligne par écart : pilier, question, description, impact, probabilité, sévérité, propriétaire | Gouvernance architecture & sécurité |
| Plan de remédiation | Vagues, dépendances, estimations, critère d'acceptation par item | Équipes de delivery, PMO |
| Annexe technique | Exports des outils, extraits IaC, preuves de configuration, captures | Auditeurs, prochain réviseur |
| Jalon (milestone) dans le WA Tool | État figé des réponses à la date de revue | Tous, pour la revue suivante |
Gardez le registre des risques exploitable par une machine. Un tableur ou un fichier YAML versionné dans le dépôt du workload vaut mieux qu'un paragraphe dans un document Word : il se diffe, s'importe dans Jira et se réévalue à la revue suivante.
- id: REL-03
pilier: Fiabilité
question: Comment sauvegardez-vous vos données ?
constat: Sauvegardes automatiques RDS activées (7 jours) mais restauration
jamais testée ; pas de copie cross-région pour un RTO de 4h.
severite: haute
impact: RTO intenable en cas d'incident régional ; risque de pénalité contractuelle.
remediation:
- Activer les sauvegardes automatiques cross-région vers eu-west-3
- Ajouter un exercice de restauration trimestriel au runbook d'astreinte
- Alerter si l'âge de la dernière sauvegarde > 26h (EventBridge + SNS)
charge: M
proprietaire: equipe-paiements
vague: 1
acceptation: Exercice de restauration documenté, RTO mesuré < 4h
Transformer les écarts en plan de remédiation qui survit au backlog
L'échec classique : une liste de 47 recommandations remise à une équipe qui n'a aucune capacité disponible. La priorisation doit être explicite et défendable. Une matrice impact/effort fonctionne bien, avec trois vagues :
- Vague 1 — 0 à 30 jours : sévérité haute, effort faible. Activer MFA delete, refermer un security group ouvert sur 0.0.0.0/0, activer GuardDuty dans toutes les régions, poser une alarme budgétaire. C'est cette vague qui finance la crédibilité de tout l'exercice.
- Vague 2 — 1 à 3 mois : chantiers structurants nécessitant conception et tests. Multi-AZ, segmentation réseau, alerting basé sur des SLO, remplacement des utilisateurs IAM à clés longues par une fédération OIDC dans la CI.
- Vague 3 — 3 à 12 mois : items exigeant un changement d'architecture ou un arbitrage budgétaire. Migration vers un service managé, découpage d'un monolithe, mise en place d'une landing zone multi-comptes.
Deux règles non négociables. D'abord, chaque item a un propriétaire unique et nommé — une équipe, pas une personne susceptible de partir. Ensuite, chaque item a un critère d'acceptation observable : « exercice de restauration exécuté et documenté », pas « améliorer les sauvegardes ». Une remédiation non vérifiable sera déclarée faite sans l'être.
Autant que possible, la remédiation doit atterrir dans l'Infrastructure as Code et, mieux encore, dans une politique qui empêche la régression. Refermer un security group est une tâche ; ajouter une Service Control Policy ou une règle OPA/Conftest dans le pipeline est une correction.
Outillage : automatiser la moitié factuelle
Environ la moitié des questions Well-Architected se répondent avec de la donnée plutôt qu'avec de la mémoire. Collectez les preuves avant l'atelier :
- AWS Trusted Advisor — intégré nativement au WA Tool, il rattache ses contrôles aux questions concernées.
- AWS Security Hub avec les standards AWS Foundational Security Best Practices et CIS pour le pilier Sécurité.
- AWS Compute Optimizer et Cost Explorer (rightsizing, couverture Savings Plans, dépense non taguée) pour l'Optimisation des coûts.
- Prowler ou Steampipe pour un scan open source plus profond, multi-comptes.
- AWS Resilience Hub pour confronter les RTO/RPO déclarés à l'architecture réelle.
- Les lentilles personnalisées pour encoder vos propres standards de plateforme (tags obligatoires, régions autorisées, socle de logs) et les passer en revue au même titre que les questions AWS.
L'API du WA Tool permet de scripter les parties ingrates : création du workload, application d'un modèle de revue, export du rapport dans votre dépôt de documentation.
aws wellarchitected create-workload \
--workload-name "api-commande-prod" \
--description "API de commande client" \
--environment PRODUCTION \
--aws-regions eu-west-1 eu-west-3 \
--lenses wellarchitected serverless \
--review-owner "equipe-plateforme@example.com"
# Lister les points à haut risque restants après l'atelier
aws wellarchitected list-lens-review-improvements \
--workload-id $WID --lens-alias wellarchitected \
--query 'ImprovementSummaries[?Risk==`HIGH`].[QuestionTitle,ImprovementPlanUrl]' \
--output table
# Archiver le rapport validé
aws wellarchitected get-lens-review-report \
--workload-id $WID --lens-alias wellarchitected \
--query Base64String --output text | base64 -d > revue-2025T2.pdf
Installer une cadence plutôt qu'un événement
La valeur d'une revue Well-Architected ne se cumule que si elle se répète. Créez un jalon dans l'outil à la fin de chaque revue : vous obtenez alors un différentiel entre deux dates, bien plus convaincant pour une direction qu'un score absolu. Une cadence tenable : une revue complète annuelle par workload critique, un re-scoring léger trimestriel, et une revue déclenchée par tout changement d'architecture majeur ou incident sérieux.
Injectez les items de remédiation dans le backlog de delivery normal, avec le même format de ticket que les fonctionnalités, et réservez une capacité fixe — 10 à 20 % d'un sprint — à la dette d'architecture. Les items qui vivent dans un tableur « plan d'audit » séparé ne sont jamais traités.
Les erreurs qui reviennent le plus souvent
- Vouloir tout auditer d'un coup. Trois workloads revus sérieusement valent mieux que quinze survolés.
- La revue auto-congratulante. Si l'équipe anime sa propre revue sans contradiction externe, le score sera flatteur. Faites intervenir quelqu'un d'une autre équipe ou un consultant externe.
- Le rapport sans propriétaire. Une recommandation sans équipe nommée ni date cible est un vœu.
- Négliger Développement durable et Excellence opérationnelle. Souvent expédiés en fin de journée, ce sont pourtant les piliers où se cachent les gains les moins chers.
- Confondre le score de l'outil et la réalité. Le nombre de HRI ouvre une conversation, ce n'est pas un KPI à optimiser.
Bien menée, une revue Well-Architected est l'un des exercices de réduction de risque les moins coûteux sur AWS : quelques jours d'animation, un vocabulaire partagé entre dev, ops et sécurité, et un plan priorisé qui évite que le même incident se produise une troisième fois.