Well-Architected Review : ce qu'un audit révèle vraiment, retour de terrain

« On est plutôt bien architecturés, on suit les bonnes pratiques AWS. » C’est à peu près la phrase d’ouverture de 9 audits sur 10 chez Distribuée. Puis on lance une Well-Architected Review (WAR), et deux heures plus tard, l’équipe technique a une liste de 8 à 12 problèmes qu’elle ne soupçonnait pas. Ce n’est pas un jugement sur l’équipe — c’est le format même de l’exercice qui fait remonter des angles morts qu’un audit de code ou une revue Terraform ne voit jamais.

Cet article décrit ce qu’on trouve vraiment en mission, comment fonctionne le programme de financement AWS qui peut couvrir une partie du coût, et la méthode pour transformer les résultats en plan d’action plutôt qu’en rapport qui prend la poussière.

Ce qu’est une Well-Architected Review, en deux minutes

Le Well-Architected Framework AWS repose sur 6 piliers : Excellence opérationnelle, Sécurité, Fiabilité, Performance, Optimisation des coûts, Développement durable. L’AWS Well-Architected Tool (gratuit, dans la console) fait passer un workload à travers une série de questions par pilier, et classe chaque écart identifié en deux niveaux de sévérité :

• HRI (High Risk Issue) : un choix architectural qui peut avoir un impact significatif — perte de données, panne prolongée, fuite de sécurité, dérapage budgétaire
• MRI (Medium Risk Issue) : un écart réel mais moins critique à court terme

La session elle-même est pensée pour être légère : AWS la décrit comme “une conversation, pas un audit”, qui doit prendre des heures et non des jours. En pratique, une review complète — préparation, sessions sur les 6 piliers, priorisation des HRI, plan d’amélioration initial — s’étale sur 2 à 4 semaines calendaires, pour quelques jours de travail effectif.

Ce qu’on trouve vraiment, retour de terrain

Sur les premières reviews d’un compte, la moyenne constatée est de 5 à 12 High Risk Issues — et c’est cohérent avec ce qu’on observe en mission chez des PME de 20 à 150 personnes qui pensaient avoir « fait le ménage ». Les plus fréquents, par ordre de récurrence :

• MFA absent ou partiel sur le root account — souvent le compte root n’a même pas de MFA matériel, juste un mot de passe stocké dans un gestionnaire partagé
• Base de données sans backup automatisé testé — le backup existe, mais personne n’a jamais fait un restore réel pour vérifier qu’il fonctionne
• Service stateful en single-AZ — la base de données ou le cache Redis tourne sur une seule zone de disponibilité, invisible tant qu’il n’y a pas d’incident
• Bucket S3 avec accès public non intentionnel — souvent un bucket de logs ou d’assets créé vite fait, jamais revu
• Aucun test de reprise après sinistre documenté — le plan existe sur le papier, jamais exécuté

Le point commun : ce sont des risques invisibles en usage normal. Ils ne cassent rien au quotidien, donc personne ne les priorise — jusqu’à l’incident qui les rend visibles au pire moment.

Le financement AWS : jusqu’à 5 000 $ de crédits

Point sous-exploité par la plupart des PME : AWS finance une partie de la remédiation via le AWS Well-Architected Partner Program. Le mécanisme, tel qu’il fonctionne aujourd’hui :

1. Un partenaire AWS habilité (comme Distribuée) mène la review avec vous sur l’AWS Well-Architected Tool
2. Les HRI identifiés sont documentés dans un plan de remédiation
3. Une fois 45 % des HRI corrigés, l’entreprise devient éligible à un Service Credit Voucher de 5 000 $, applicable sur la facture AWS suivante

Ce n’est pas automatique — la demande passe par le AWS Partner Funding Portal, et le partenaire doit avoir le programme actif. Mais pour une PME qui va de toute façon corriger ces écarts (MFA, backups, chiffrement), c’est un financement direct de la remédiation qu’on voit rarement mobilisé faute d’être connu.

La méthode qui évite le rapport qui prend la poussière

Le vrai risque d’une WAR n’est pas de ne rien trouver — c’est de trouver 40 items, produire un rapport PDF, et voir 35 d’entre eux ne jamais être traités. Trois règles qu’on applique en mission :

Prioriser Sécurité et Fiabilité en premier. Les HRI de ces deux piliers représentent le risque le plus concret à court terme (perte de données, incident de sécurité). Performance, coûts et durabilité viennent après — sauf si un HRI coût dépasse un seuil qui justifie une action immédiate.

Traiter les HRI en semaines, pas en trimestres. Un HRI type MFA absent se corrige en une heure. Le classer dans un backlog trimestriel revient à accepter le risque sans le dire.

Rejouer la review tous les 12 à 18 mois, pas une fois pour la forme. L’architecture bouge — nouveaux services, nouvelles équipes, nouvelle dette. Une WAR figée en 2024 ne dit plus rien de l’état réel du compte en 2026.

Ce que l’outil ne remplace pas

Le Well-Architected Tool guide la conversation, mais il ne connaît ni votre contexte métier ni vos contraintes réelles. Deux limites qu’on voit systématiquement :

• Les réponses auto-déclarées sont optimistes. Sans preuve technique (capture d’écran, export Config, requête CLI), une équipe répond “oui, on chiffre tout” sans avoir vérifié le dernier bucket créé il y a trois mois.
• Les lenses spécialisées ne sont pas activées par défaut. AWS propose des lenses pour SaaS, serverless, IA/ML, IoT — pertinentes selon votre stack, mais il faut les ajouter explicitement à la review.

C’est pour ça qu’on mène les WAR en mission avec vérification technique en parallèle des réponses déclaratives — comptes AWS, IAM Credential Report, Config Rules — plutôt qu’un simple questionnaire coché en réunion.

Conclusion

Une Well-Architected Review n’est pas un exercice de conformité de plus. C’est le moyen le plus rapide de faire remonter les 5 à 12 risques qu’une équipe technique compétente ne voit plus, parce qu’ils sont devenus invisibles à force d’habitude. Ajoutez le financement AWS disponible sur la remédiation, et le coût d’opportunité de ne pas la faire dépasse largement celui de la faire.

Pour aller plus loin sur la mise en musique des contrôles techniques qui en découlent, notre article sur la préparation d’un audit SOC2 sur AWS détaille l’automatisation via Security Hub, GuardDuty et AWS Config.

Si vous voulez savoir ce qu’une Well-Architected Review révélerait sur votre compte, c’est le point de départ de notre Audit DevSecOps — comptez une demi-journée de session, un plan d’amélioration priorisé en sortie.