AWS Well-Architected Review

Une revue AWS Well-Architected n'est ni un audit punitif, ni un exercice de conformité de façade : c'est une conversation structurée entre vos équipes et un architecte expérimenté, destinée à révéler les risques cachés de votre architecture avant qu'ils ne deviennent des incidents, des factures incontrôlées ou des reproches du régulateur. Cette page détaille tout : les 6 piliers, l'outil gratuit d'AWS, le déroulé réel d'un atelier, les fameux crédits de 5 000 $, et, ce qu'aucune page française ne fait, l'articulation avec le droit français (RGPD, DORA, HDS, NIS2).

Qu'est-ce qu'une revue AWS Well-Architected ?

Une revue AWS Well-Architected (Well-Architected Framework Review, ou WAFR) est l'évaluation méthodique d'une charge de travail (un workload) hébergée sur Amazon Web Services, menée à l'aune du Well-Architected Framework publié par AWS. Concrètement, on confronte votre architecture réelle à une grille de questions structurées autour de six piliers : excellence opérationnelle, sécurité, fiabilité, efficacité des performances, optimisation des coûts et développement durable.

Il faut distinguer deux notions que l'on confond souvent.

• Le Well-Architected Framework est le référentiel : un corpus de bonnes pratiques, de principes de conception et de questions, maintenu par AWS et enrichi en continu depuis 2015. C'est la « règle » à laquelle on se mesure.
• La revue (WAFR) est l'action : l'exercice concret par lequel on applique ce référentiel à un workload donné, à un instant donné, pour produire une liste de risques priorisés et un plan d'amélioration.

Autrement dit, le Framework est le livre de recettes ; la revue est le repas que l'on cuisine, et que l'on goûte ensemble pour décider quoi corriger.

À retenir. Le Framework décrit ce qu'est une « bonne » architecture cloud. La revue mesure l'écart entre cet idéal et votre réalité, puis transforme cet écart en décisions concrètes : ce qu'on corrige cette semaine, ce qui peut attendre, et ce qui relève d'un choix assumé.

Cette démarche s'inscrit dans la famille plus large de l'audit d'infrastructure cloud : la WAFR en est la déclinaison normée par AWS, focalisée sur un workload précis plutôt que sur l'ensemble du parc.

Une revue n'est pas un audit

C'est le malentendu le plus répandu, et il bloque beaucoup d'équipes. Un audit cherche un verdict de conformité : conforme ou non conforme, validé ou recalé, avec une logique de contrôle et, parfois, de sanction. Une revue Well-Architected, elle, est une conversation constructive et sans blâme.

| | Revue Well-Architected | Audit classique | |---|---|---| | Posture | Coopérative, pédagogique | Vérification, contrôle | | Finalité | Identifier des risques et s'améliorer | Statuer sur une conformité | | Ton | Sans blâme, exploratoire | Binaire (conforme / non conforme) | | Durée | Heures à quelques jours | Jours à semaines | | Livrable | Risques priorisés + plan d'action | Rapport de conformité, écarts | | Cadence | Récurrente, par jalon | Ponctuelle, déclenchée |

La revue est un processus léger. Pour un workload bien cadré, l'atelier de questionnement se compte en heures, pas en jours. On ne cherche pas à prendre vos équipes en défaut ; on cherche à mettre en lumière les angles morts que tout le monde finit par accumuler quand on construit vite. C'est précisément ce qui la rend efficace : sans posture défensive, les équipes parlent vraiment de ce qui les inquiète.

Cela ne dispense pas, par ailleurs, d'un véritable audit de sécurité cloud ou d'un audit de conformité cloud lorsque le contexte (incident, certification, exigence client) l'exige. La revue éclaire ; l'audit atteste.

Les 6 piliers du Well-Architected Framework en détail

Les six piliers structurent toute la démarche. Pour chacun, voici ce que la revue examine, les risques élevés (High Risk Issues) que l'on rencontre le plus souvent, et les services AWS mobilisés pour les corriger.

1. Excellence opérationnelle

Ce pilier interroge votre capacité à exploiter et faire évoluer vos charges de travail dans la durée : comment vous déployez, comment vous observez, comment vous réagissez aux événements, comment vous capitalisez sur les incidents.

Questions fondamentales : Comment déterminez-vous les priorités ? Comment structurez-vous votre organisation pour soutenir vos objectifs ? Comment concevez-vous vos workloads pour comprendre leur état ? Comment réduisez-vous les défauts et facilitez-vous la correction ?

HRI typiques : déploiements manuels et non reproductibles ; absence de supervision centralisée ; aucune procédure d'astreinte formalisée ; runbooks inexistants ou obsolètes.

Remédiations AWS : automatisation via Infrastructure as Code (CloudFormation ou Terraform), CI/CD avec CodePipeline ou GitLab/GitHub Actions, observabilité avec Amazon CloudWatch et AWS X-Ray, automatisation des réponses avec Systems Manager. Notre conviction d'intermédiaire indépendant : l'excellence opérationnelle commence par le code d'infrastructure versionné, et ce code doit vivre dans vos dépôts, pas ceux d'un prestataire.

2. Sécurité

Ce pilier couvre la protection des données, des systèmes et des actifs : gestion des identités, traçabilité, protection en transit et au repos, détection et réponse aux incidents.

Questions fondamentales : Comment gérez-vous les identités pour les humains et les machines ? Comment détectez-vous les événements de sécurité ? Comment protégez-vous vos données au repos et en transit ? Comment respectez-vous le modèle de responsabilité partagée ?

HRI typiques : comptes IAM avec privilèges excessifs ou clés d'accès statiques ; absence de MFA sur les comptes sensibles ; journalisation CloudTrail désactivée ou non centralisée ; données non chiffrées ; aucun cloisonnement entre environnements.

Remédiations AWS : AWS Control Tower et AWS Organizations pour structurer une landing zone multi-comptes, IAM Identity Center pour l'accès fédéré sans clés statiques, GuardDuty et Security Hub pour la détection, KMS pour le chiffrement, CloudTrail centralisé pour la traçabilité. Pour les charges Kubernetes, le durcissement RBAC et les network policies relèvent d'un audit Kubernetes dédié.

3. Fiabilité

Ce pilier mesure la capacité d'un workload à fonctionner correctement et à récupérer après une défaillance : gestion de la charge, conception résiliente, reprise après sinistre.

Questions fondamentales : Comment gérez-vous les quotas de service et les contraintes ? Comment concevez-vous votre réseau pour la résilience ? Comment concevez-vous pour résister aux défaillances de composants ? Comment planifiez-vous la reprise (RTO / RPO) ?

HRI typiques : architecture mono-AZ sans redondance ; aucune sauvegarde testée ; absence de plan de reprise ; dépendances à un composant unique (single point of failure) ; quotas de service jamais surveillés.

Remédiations AWS : déploiement Multi-AZ pour les bases (RDS, ElastiCache) et les charges applicatives, AWS Backup avec restaurations testées, Auto Scaling, Route 53 pour le basculement, architectures multi-régions pour les charges critiques. La fiabilité se vérifie en testant la panne, pas en l'espérant : une sauvegarde jamais restaurée n'est pas une sauvegarde. Ces enjeux rejoignent ceux qu'abordent les prestataires de notre réseau sur une infrastructure cloud instable.

4. Efficacité des performances

Ce pilier évalue l'usage efficient des ressources de calcul, de stockage et de réseau pour répondre à la demande, et la capacité à maintenir cette efficience quand la demande et les technologies évoluent.

Questions fondamentales : Comment sélectionnez-vous les ressources les mieux adaptées (calcul, stockage, base de données, réseau) ? Comment surveillez-vous les performances ? Comment arbitrez-vous pour améliorer l'efficience ?

HRI typiques : instances surdimensionnées « par sécurité » ; choix de service inadapté (instance EC2 là où une fonction Lambda suffirait, ou l'inverse) ; absence de cache ; stockage mal hiérarchisé.

Remédiations AWS : Compute Optimizer pour le rightsizing, recours au serverless (Lambda, Fargate) quand le profil de charge s'y prête, CloudFront pour la distribution, choix éclairé entre Amazon EKS et Amazon ECS pour les conteneurs, classes de stockage S3 adaptées au cycle de vie de la donnée.

5. Optimisation des coûts

Ce pilier traque la valeur : payer le juste prix pour ce dont vous avez réellement besoin, éliminer le gaspillage et rendre les coûts lisibles et imputables.

Questions fondamentales : Comment gouvernez-vous l'usage et la dépense ? Comment surveillez-vous l'utilisation et le coût ? Comment choisissez-vous le bon modèle de tarification ? Comment ajustez-vous l'offre à la demande ?

HRI typiques : ressources orphelines (volumes EBS détachés, IP élastiques non utilisées) ; aucun étiquetage permettant l'imputation ; tout en tarif à la demande alors que la charge est prévisible ; environnements de test allumés la nuit et le week-end.

Remédiations AWS : AWS Cost Explorer et budgets pour la visibilité, Savings Plans et Reserved Instances pour les charges stables, Spot Instances pour les charges tolérantes à l'interruption, extinction automatique hors usage, politique d'étiquetage (tagging) rigoureuse. Ce pilier est la porte d'entrée naturelle vers une démarche FinOps continue, détaillée plus bas et sur notre page optimisation des coûts cloud.

6. Développement durable

Ajouté en 2021 et trop souvent survolé, ce pilier mesure l'impact environnemental de vos charges de travail : consommation énergétique, empreinte carbone, sobriété des ressources. Il n'est pas cosmétique : il rejoint directement l'optimisation des coûts (moins de ressources gaspillées = moins de carbone et moins de facture) et devient un critère d'appel d'offres dans le secteur public et les grands comptes.

Questions fondamentales : Comment choisissez-vous vos régions en tenant compte des objectifs de durabilité ? Comment alignez-vous l'utilisation sur la demande réelle ? Comment tirez-vous parti des offres logicielles et matérielles les plus efficientes ?

HRI typiques : régions choisies sans considération de mix énergétique ; ressources surprovisionnées en permanence ; aucune politique de cycle de vie sur les données froides ; architectures qui maintiennent des ressources actives sans usage.

Remédiations AWS : choix de régions à faible intensité carbone, processeurs Graviton (ARM) plus efficients, dimensionnement au plus juste, archivage S3 Glacier pour les données froides, mutualisation des charges. Le tableau de bord Customer Carbon Footprint Tool d'AWS permet de mesurer la trajectoire.

L'AWS Well-Architected Tool : l'outil gratuit en console

AWS met à disposition le Well-Architected Tool (WA Tool), accessible gratuitement depuis la console AWS. C'est le support technique de la revue.

Son fonctionnement repose sur trois notions :

• Le workload : vous y déclarez la charge de travail à examiner (son nom, son environnement, sa région, sa criticité). Une revue porte toujours sur un workload précis, pas sur « tout le cloud ».
• Les questions fondamentales : pour chaque pilier, l'outil déroule une série de questions à choix multiples. À chaque réponse, vous cochez les bonnes pratiques déjà en place et laissez visibles celles qui manquent.
• Les milestones (jalons) : à un instant donné, vous figez l'état de la revue dans un milestone. C'est une photographie horodatée qui permet, lors des revues suivantes, de mesurer le chemin parcouru.

À mesure que vous répondez, l'outil calcule automatiquement le nombre de risques élevés (HRI) et de risques moyens (MRI) par pilier, et génère un rapport téléchargeable. C'est gratuit, c'est en libre-service, et c'est l'épine dorsale de toute la démarche, y compris quand un partenaire vous accompagne. Le WA Tool s'intègre par ailleurs avec AWS Trusted Advisor pour pré-remplir certaines vérifications automatisables.

Pourquoi un partenaire si l'outil est gratuit ? Parce que l'outil pose les questions, mais ne répond pas à votre place et n'interprète pas vos réponses. La valeur d'une revue ne tient pas à cocher des cases : elle tient à la qualité de la conversation, à la pertinence de la priorisation et à la traduction des risques en décisions business. Nous y revenons dans la section « revue autonome vs accompagnée ».

Le processus de revue en 3 phases : Prepare, Review, Improve

AWS structure la démarche en trois phases. Voici ce qui se passe réellement à chacune.

Phase 1 : Préparer (Prepare)

On délimite le périmètre : quel workload, quels piliers prioritaires (rarement les six à la même intensité), quels participants. Les bons participants sont ceux qui savent : l'architecte, un référent sécurité, un exploitant, et idéalement quelqu'un qui porte l'enjeu métier. On rassemble les schémas d'architecture, les diagrammes de flux, les éléments de coûts et les exigences de conformité applicables.

Une préparation soignée divise par deux la durée de l'atelier. C'est aussi le moment de lever une objection fréquente : non, il ne faut pas « tout documenter parfaitement » avant de commencer. Si votre cloud n'est pas documenté, la revue est justement l'occasion de reconstituer cette vue.

Phase 2 : Réviser (Review)

C'est l'atelier de questionnement. On déroule, pilier par pilier, les questions du WA Tool. Pour chaque pratique, l'animateur ne se contente pas de la réponse : il creuse. « Vous dites que les sauvegardes sont en place : quand a eu lieu la dernière restauration testée ? » « Vous chiffrez au repos, et la gestion des clés, qui y a accès ? »

À l'issue, l'outil consolide les HRI et MRI. Mais le vrai produit de cette phase est la discussion : c'est là qu'émergent les risques que personne n'avait formulés à voix haute.

Phase 3 : Améliorer (Improve)

On transforme les risques identifiés en plan de remédiation priorisé. Chaque HRI est qualifié : impact, effort, dépendances, échéance recommandée. On distingue ce qui doit être corrigé avant un go-live, ce qui relève du trimestre, ce qui est un choix assumé que l'on documente. Puis on enregistre un milestone dans le WA Tool pour graver l'état initial et pouvoir mesurer les progrès lors de la revue suivante.

L'amélioration n'est pas un événement, c'est un cycle. La revue suivante mesurera combien de HRI ont été réellement traités, ce qui, on le verra, conditionne aussi l'accès aux crédits AWS.

High Risk Issues (HRI) et plan de remédiation priorisé

Au cœur de la revue se trouve la notion de risque. Le WA Tool classe chaque écart en deux niveaux :

• High Risk Issue (HRI) : un risque élevé, susceptible d'avoir un impact significatif sur l'activité : perte de données, indisponibilité prolongée, exposition de sécurité, dérive de coûts majeure. Ce sont les priorités.
• Medium Risk Issue (MRI) : un risque modéré, à traiter mais sans urgence existentielle.

L'intérêt d'une revue accompagnée se mesure ici : un HRI brut (« absence de stratégie de reprise ») ne dit pas quoi faire. Notre travail consiste à le traduire en correctif nommé et chiffré.

| Risque élevé constaté | Correctif AWS concret | |---|---| | Privilèges IAM excessifs, clés statiques | IAM Identity Center, rôles à privilège minimal, rotation | | Multi-comptes non gouverné | AWS Control Tower / Landing Zone Accelerator | | Architecture mono-AZ | Bascule Multi-AZ (RDS, ASG, équilibrage de charge) | | Sauvegardes non testées / absentes | AWS Backup + plan de restauration testé | | Tout en tarif à la demande | Savings Plans, Reserved Instances, Spot | | Conteneurs sans contrôle d'accès | Durcissement RBAC EKS, network policies | | Aucune traçabilité | CloudTrail centralisé, Security Hub |

Le plan de remédiation n'est pas une liste à plat : il est priorisé par le couple impact/effort. On commence par les corrections à fort impact et faible effort : les « quick wins » qui rassurent les équipes et libèrent du budget pour les chantiers plus lourds.

Quand et à quelle fréquence réaliser une revue ?

Une revue n'a de sens qu'aux bons jalons du cycle de vie. Les moments les plus rentables :

• Avant un go-live d'une charge critique : on ne met pas en production une architecture dont on n'a pas mesuré les risques.
• Après un incident majeur : pour comprendre la cause profonde et éviter la récidive.
• Lors d'un changement d'échelle : nouvelle géographie, montée en charge significative, ouverture à de nouveaux usages.
• Avant ou après une migration : la revue est le complément naturel d'un projet de migration cloud d'entreprise.
• À cadence régulière : tous les 3 à 6 mois pour une charge en évolution rapide, annuellement au minimum pour une charge stable. L'architecture cloud n'est jamais figée : ce qui était bien conçu il y a un an a pu dériver.

La cadence régulière est ce qui transforme la revue d'un événement ponctuel en une discipline de gouvernance cloud.

Les AWS Well-Architected Lenses

Le Framework généraliste ne couvre pas finement tous les cas d'usage. AWS publie donc des Lenses (objectifs, ou « lentilles ») : des jeux de questions spécialisés qui viennent compléter la revue pour un domaine particulier.

Les Lenses les plus utilisées :

• Serverless Lens : pour les architectures Lambda / API Gateway / DynamoDB.
• SaaS Lens : pour les éditeurs de logiciels multi-locataires (modèles de tenant, isolation, métriques par client).
• Data Analytics Lens : pour les plateformes de données et la data.
• Machine Learning Lens : pour les charges d'IA / ML (entraînement, inférence, MLOps).
• Financial Services Industry Lens : pour les contraintes du secteur financier.
• Et d'autres : IoT, conteneurs, hybride, mainframe migration, etc.

AWS permet aussi de créer des Custom Lenses : vos propres jeux de questions, pour intégrer vos standards internes ou un référentiel réglementaire propre à votre secteur. C'est un levier puissant (et largement sous-exploité en France) pour transformer la revue en outil de gouvernance sur mesure.

Combien ça coûte, combien de temps, quels livrables ?

C'est la question que les pages françaises évitent. Voici une réponse honnête.

Ce qui est gratuit : le Well-Architected Tool, le Framework, les Lenses officielles. Vous pouvez mener une revue vous-même, sans débourser un euro de licence.

Ce qui est facturé : l'accompagnement par un partenaire (l'animation des ateliers, l'interprétation des résultats, la priorisation, le plan de remédiation chiffré, et souvent la remédiation elle-même).

Durée et budget indicatif

| Élément | Repère | |---|---| | Durée d'une revue accompagnée | 1 à 3 jours selon le périmètre | | Budget indicatif | de l'ordre de 3 000 à 7 000 €, sur devis selon le périmètre | | Atelier de questionnement seul | quelques heures par workload |

Ces montants sont indicatifs. Le coût réel dépend du nombre de workloads, des piliers et Lenses retenus, de la profondeur de remédiation souhaitée et de votre contexte réglementaire. Un seul workload bien cadré ne demande pas le même budget qu'un parc multi-comptes avec exigences DORA. Nous établissons un devis ferme sous 48 h ouvrées après un premier échange de cadrage.

Les livrables remis

À l'issue d'une revue accompagnée, vous repartez avec :

• Le rapport priorisé : la liste des HRI et MRI par pilier, lisible par la DSI comme par la direction.
• Le plan d'action / de mitigation : chaque risque traduit en correctif nommé, avec impact, effort et échéance.
• Les milestones enregistrés dans votre WA Tool, pour mesurer les progrès.
• Le cas échéant, le code d'infrastructure (Terraform) des correctifs apportés, versionné dans vos dépôts.

Notre engagement d'intermédiaire indépendant : tout vous appartient. Les comptes AWS sont à votre nom, le code IaC vit chez vous, la documentation vous est remise. Pas d'enfermement, réversibilité totale. Si vous décidez demain d'internaliser ou de changer de prestataire, vous repartez avec l'intégralité de ce qui a été construit. C'est exactement l'esprit que nous appliquons quand il faut remettre de l'ordre dans son cloud.

Les crédits AWS de 5 000 $ : conditions exactes

C'est l'un des intérêts financiers concrets d'une revue menée avec un partenaire du AWS Well-Architected Partner Program. Sous conditions, AWS accorde jusqu'à 5 000 $ de crédits de service par workload revu.

Les conditions, telles que documentées par AWS, sont précises :

• La revue doit être menée avec un partenaire qualifié au programme Well-Architected.
• Au moins 45 % des High Risk Issues identifiés lors de la revue initiale doivent être remédiés.
• La revue initiale et la remédiation doivent être documentées via des milestones dans le Well-Architected Tool (un milestone à l'état initial, un milestone après remédiation prouvant la résorption des HRI).

Autrement dit, les crédits ne récompensent pas le fait de passer la revue, mais celui d'agir sur ses résultats. C'est cohérent avec l'esprit du Framework : la revue n'a de valeur que si elle débouche sur des corrections réelles, tracées et vérifiables.

Notre posture sur les crédits. Ils sont un bonus appréciable, pas une fin en soi. Nous ne « gonflons » jamais une revue pour cocher la case des 5 000 $. La vraie valeur reste la réduction de risque ; les crédits financent une partie de l'effort de remédiation, ce qui est toujours bon à prendre.

Revue Well-Architected et conformité française : la cartographie réglementaire

C'est ici que la quasi-totalité des pages, françaises comme anglaises, s'arrête. Or pour une entreprise française, les piliers Sécurité et Fiabilité ne sont pas que des bonnes pratiques techniques : ils sont le support concret de vos obligations légales. Voici la cartographie que nous appliquons.

| Exigence réglementaire | Piliers WAFR mobilisés | Traduction concrète | |---|---|---| | RGPD (art. 28 : sous-traitant) | Sécurité | Chiffrement, traçabilité CloudTrail, localisation des données, contractualisation du rôle de sous-traitant | | DORA (finance / assurance) | Fiabilité, Excellence opérationnelle | Résilience opérationnelle, tests de reprise, gestion du risque tiers, réversibilité | | HDS (données de santé) | Sécurité, Fiabilité | Hébergement chez un partenaire certifié HDS, cloisonnement, traçabilité des accès | | NIS2 | Sécurité, Fiabilité | Gestion des risques, détection d'incident, continuité d'activité | | Démarche ISO 27001 | Sécurité, Excellence opérationnelle | SMSI, gestion documentaire, revue périodique des contrôles | | CIS Benchmarks | Sécurité | Durcissement des configurations IAM, S3, réseau, journalisation |

Quelques points de vigilance que nous portons systématiquement à l'attention de nos clients :

• Le modèle de responsabilité partagée est la clé de lecture du RGPD sur AWS : AWS sécurise le cloud (l'infrastructure), vous êtes responsable de la sécurité dans le cloud (vos données, vos configurations IAM, vos chiffrements). Vous restez responsable de traitement ; AWS est sous-traitant au sens de l'article 28.
• Pour la santé, la certification HDS vise l'hébergeur (AWS dispose d'offres éligibles via des régions et services qualifiés), jamais votre configuration ni notre structure. Une revue bien menée vérifie que votre architecture s'appuie effectivement sur le périmètre certifié.
• Pour la finance et l'assurance, DORA impose depuis 2025 une exigence forte de résilience opérationnelle et de maîtrise du risque lié aux prestataires tiers de TIC. Le pilier Fiabilité et la clause de réversibilité deviennent des obligations, pas des options.

Cette articulation entre standard technique mondial et droit français est notre marque de fabrique : une revue Well-Architected qui ignore le RGPD, DORA ou HDS reste un exercice abstrait. Pour aller plus loin, voir notre audit de conformité cloud et notre offre de cybersécurité cloud.

Revue autonome (self-service) ou accompagnée par un partenaire ?

Le WA Tool étant gratuit, la question est légitime. Voici une grille de décision honnête.

| Critère | Revue autonome | Revue accompagnée | |---|---|---| | Coût direct | Gratuit | Sur devis (3 000–7 000 € indicatif) | | Maturité d'équipe requise | Élevée (architectes confirmés) | Faible à moyenne | | Objectivité | Risque d'angle mort / autocomplaisance | Regard externe | | Priorisation des HRI | À votre charge | Apportée et chiffrée | | Crédits AWS 5 000 $ | Non éligible | Éligible (partenaire requis) | | Plan de remédiation | À construire seul | Fourni, parfois exécuté |

Faites-la en autonomie si votre équipe compte des architectes AWS confirmés, qu'elle veut un état des lieux interne rapide, et qu'elle n'a pas besoin des crédits. Faites-vous accompagner si vous cherchez un regard externe sans complaisance, une priorisation business, l'éligibilité aux crédits, ou si l'enjeu (go-live critique, contrainte réglementaire) ne tolère pas l'erreur. La maturité de votre équipe est le vrai critère, pas le budget.

Revue Well-Architected et FinOps : un cycle continu

Le pilier Optimisation des coûts est la porte d'entrée d'une démarche FinOps durable. Une revue donne une photographie à un instant T ; le FinOps installe la discipline continue qui empêche la dérive de revenir.

Concrètement, les recommandations du pilier coûts alimentent trois leviers FinOps :

• Rightsizing : ajuster en continu la taille des ressources à l'usage réel observé (Compute Optimizer, métriques CloudWatch).
• Engagements : couvrir la charge stable par des Savings Plans et Reserved Instances, et la charge élastique tolérante par du Spot.
• Étiquetage et imputation : une politique de tagging rigoureuse pour que chaque euro soit rattaché à une équipe, un produit, un client, condition de toute responsabilisation.

En nous appuyant sur des prestataires et experts qualifiés disposant des certifications requises (FinOps Certified Practitioner) et membres de la FinOps Foundation, nous inscrivons systématiquement le volet coûts de la revue dans cette boucle. Le détail figure sur nos pages optimisation des coûts cloud et audit FinOps.

Revue Well-Architected, PRA/PCA et responsabilité partagée

Le pilier Fiabilité ne se résume pas à « mettre du Multi-AZ ». Il pose les questions qui fondent un véritable PRA (plan de reprise d'activité) et un PCA (plan de continuité d'activité) :

• Quel est votre RTO (Recovery Time Objective : en combien de temps doit-on être de nouveau opérationnel) ?
• Quel est votre RPO (Recovery Point Objective : quelle perte de données maximale est tolérable) ?
• Avez-vous testé la reprise, ou seulement écrit la procédure ?

La revue confronte vos RTO/RPO affichés à la réalité de votre architecture. Trop souvent, l'écart est béant : un RTO de quatre heures revendiqué, mais des sauvegardes jamais restaurées et une architecture mono-région. Là encore, le modèle de responsabilité partagée structure l'analyse : AWS assure la disponibilité de ses zones et régions, mais c'est votre conception qui détermine la résilience effective de votre charge. Rien ne garantit la haute disponibilité d'un workload mal conçu : elle ne s'achète pas, elle se conçoit.

AWS Well-Architected face à Azure Well-Architected : le cas des parcs hybrides

Beaucoup d'organisations françaises sont multicloud ou hybrides. Microsoft propose son propre référentiel, l'Azure Well-Architected Framework, bâti sur cinq piliers (fiabilité, sécurité, optimisation des coûts, excellence opérationnelle, efficacité des performances). La logique est très proche d'AWS ; la principale différence notable est qu'Azure n'a pas, à ce jour, érigé la durabilité en sixième pilier distinct au même niveau qu'AWS.

| | AWS Well-Architected | Azure Well-Architected | |---|---|---| | Nombre de piliers | 6 (dont durabilité) | 5 | | Outil | Well-Architected Tool (console) | Recommandations via Azure Advisor / WAF | | Landing zone | Control Tower / Landing Zone Accelerator | Cloud Adoption Framework | | Crédits partenaire | Jusqu'à 5 000 $ sous conditions | Programmes Microsoft distincts |

Notre position d'intermédiaire indépendant, nous appuyant sur des prestataires experts à la fois sur AWS et sur Azure, est ici un atout : nous vous orientons vers des prestataires qui mènent les deux types de revue avec le même niveau d'exigence, sans parti pris constructeur. Pour un parc hybride, l'enjeu est de réconcilier les deux référentiels en une gouvernance unique plutôt que de raisonner en silos. C'est précisément ce que couvre notre expertise d'architecte Azure en miroir de l'AWS, et notre audit Azure dédié.

Cas d'usage sectoriels

La revue prend un sens différent selon votre métier. Quelques illustrations représentatives tirées de missions menées par les prestataires de notre réseau.

• Santé / HDS : un éditeur de logiciel de santé prépare le référencement d'un client hospitalier. La revue, ciblée Sécurité et Fiabilité, vérifie l'usage d'un hébergement chez un partenaire certifié HDS, le cloisonnement des données patients et la traçabilité des accès. Voir secteur santé.
• Finance / DORA : une fintech (ETI) doit prouver sa résilience opérationnelle. La revue documente RTO/RPO, tests de reprise et clause de réversibilité, en appui de la mise en conformité secteur finance.
• Industrie : un groupe industriel migre un MES vers AWS. La revue avant go-live sécurise l'architecture Multi-AZ et l'observabilité. Voir secteur industrie.
• SaaS / scale-up : un éditeur en hypercroissance applique la SaaS Lens pour valider l'isolation multi-locataires et maîtriser le coût par client. Voir secteur SaaS.
• Secteur public : la durabilité et la maîtrise des coûts deviennent des critères d'appel d'offres. Voir secteur public.

Erreurs fréquentes et objections

Quelques freins reviennent systématiquement. Autant les traiter franchement.

• « On est trop occupés. » L'atelier se compte en heures, pas en jours, et une bonne préparation le raccourcit. Le coût d'un incident évité dépasse de loin celui d'une demi-journée d'atelier.
• « On ne veut pas dévoiler notre architecture. » La revue est sans blâme et confidentielle. Son but n'est pas de juger, mais d'outiller votre équipe. Le code et la documentation produits restent chez vous.
• « On a déjà fait un scan Trusted Advisor. » Trusted Advisor est utile mais partiel : il automatise des vérifications, il ne mène pas la conversation structurée qui fait émerger les risques organisationnels et les choix d'architecture.
• « On l'a faite il y a deux ans. » Une revue de deux ans est périmée : l'architecture a évolué, AWS a publié de nouveaux services, le contexte réglementaire (DORA, NIS2) a changé. La revue est un cycle, pas un certificat.

Pourquoi passer par nous pour votre revue Well-Architected

Nous sommes un intermédiaire indépendant en expertise et infogérance cloud sur AWS et Azure : nous cadrons votre besoin et vous mettons en relation avec des prestataires et experts qualifiés de notre réseau, notamment AWS Partner (Advanced Tier Services) et membres du programme Well-Architected. Nos repères :

• Une expertise cloud éprouvée sur de nombreux projets Azure et AWS, portée par un réseau de prestataires reconnus.
• Des prestataires et experts qualifiés disposant des certifications requises : AWS DevOps Engineer Professional, Solutions Architect, CISSP, FinOps Certified Practitioner.
• Indépendance : conseil sans parti pris constructeur, recommandations traduites en coûts / risques / délais pour la DSI comme pour la direction.
• Réversibilité : code IaC dans vos dépôts, comptes à votre nom, documentation remise. Vous n'êtes jamais prisonnier.
• Transparence : budget indicatif annoncé, devis ferme sous 48 h ouvrées, aucun engagement caché.

Pour situer la revue dans une démarche plus large, explorez nos pages conseil en architecture, infrastructure & DevOps, l'ensemble de nos services et notre guide du cloud. Pour mieux nous connaître : à propos.

Prochaine étape. Lancez votre diagnostic en ligne ou demandez un devis via notre page contact. Premier échange de cadrage offert, devis ferme sous 48 h ouvrées.

FAQ : AWS Well-Architected Review

Qu'est-ce qu'une revue AWS Well-Architected ?

C'est l'évaluation structurée d'une charge de travail (workload) hébergée sur AWS, menée à l'aune du Well-Architected Framework et de ses six piliers. Elle confronte votre architecture réelle à un référentiel de bonnes pratiques, identifie les risques élevés (HRI) et débouche sur un plan d'amélioration priorisé. C'est une conversation constructive, pas un contrôle.

Quels sont les 6 piliers du Well-Architected Framework d'AWS ?

Excellence opérationnelle, sécurité, fiabilité, efficacité des performances, optimisation des coûts et développement durable (sustainability). Chaque pilier rassemble un jeu de questions et de bonnes pratiques. La revue les passe en revue, généralement avec une intensité variable selon vos priorités.

Une revue AWS Well-Architected est-elle un audit ?

Non. Un audit statue sur une conformité (conforme / non conforme) avec une logique de contrôle. Une revue Well-Architected est une conversation sans blâme, exploratoire et coopérative, dont la finalité est d'identifier des risques et de s'améliorer. Elle ne délivre pas de certificat ; elle produit un plan d'action.

Combien coûte une revue AWS Well-Architected ?

Le Well-Architected Tool d'AWS est gratuit : vous pouvez mener la revue vous-même sans coût de licence. Une revue accompagnée par un partenaire se situe, à titre indicatif, dans une fourchette de l'ordre de 3 000 à 7 000 €, sur devis selon le périmètre (nombre de workloads, piliers, Lenses, profondeur de remédiation et contexte réglementaire).

Comment obtenir les 5 000 $ de crédits AWS Well-Architected ?

La revue doit être menée avec un partenaire du AWS Well-Architected Partner Program. Il faut ensuite remédier à au moins 45 % des High Risk Issues identifiés, et documenter la revue initiale comme la remédiation via des milestones dans le Well-Architected Tool. Les crédits récompensent l'action sur les résultats, pas le simple passage de la revue.

À quelle fréquence faut-il réaliser une revue Well-Architected ?

Aux jalons clés (avant un go-live, après un incident, lors d'un changement d'échelle, autour d'une migration) et à cadence régulière : tous les 3 à 6 mois pour une charge en évolution rapide, au minimum une fois par an pour une charge stable. L'architecture cloud dérive avec le temps ; la revue est un cycle, pas un événement unique.

Combien de temps dure une revue AWS Well-Architected ?

L'atelier de questionnement d'un workload bien cadré se compte en heures. Une revue accompagnée complète, incluant préparation, ateliers, priorisation et plan de remédiation, s'étend généralement sur 1 à 3 jours selon le périmètre. Une bonne préparation raccourcit sensiblement la durée.

Qu'est-ce que l'AWS Well-Architected Tool ?

C'est l'outil gratuit disponible dans la console AWS qui supporte la revue. Vous y déclarez un workload, répondez aux questions fondamentales de chaque pilier, et l'outil calcule automatiquement le nombre de HRI et MRI, génère un rapport et enregistre des milestones horodatés pour mesurer les progrès dans le temps.

Que sont les High Risk Issues (HRI) dans une revue Well-Architected ?

Ce sont les risques élevés identifiés par la revue : des écarts susceptibles d'avoir un impact significatif sur l'activité (perte de données, indisponibilité, exposition de sécurité, dérive de coûts majeure). Ils constituent les priorités du plan de remédiation. Les Medium Risk Issues (MRI) sont des risques modérés, à traiter sans urgence existentielle.

Quelles sont les étapes d'une revue Well-Architected Framework ?

Trois phases : Préparer (Prepare) : cadrer le périmètre, réunir les participants et les documents ; Réviser (Review) : dérouler les questions du WA Tool en atelier et consolider les HRI/MRI ; Améliorer (Improve) : bâtir le plan de remédiation priorisé et enregistrer un milestone. Le cycle se répète aux jalons suivants.

Qu'est-ce qu'une Lens AWS Well-Architected ?

Une Lens (objectif) est un jeu de questions spécialisé qui complète la revue pour un cas d'usage précis : Serverless, SaaS, Data Analytics, Machine Learning, services financiers, etc. AWS permet aussi de créer des Custom Lenses pour intégrer vos propres standards internes ou un référentiel réglementaire propre à votre secteur.

Quelle est la différence entre le Well-Architected Framework et la revue ?

Le Framework est le référentiel : le corpus de bonnes pratiques et de questions maintenu par AWS. La revue (WAFR) est l'action d'appliquer ce référentiel à un workload donné, à un instant donné, pour produire une liste de risques priorisés et un plan d'amélioration. Le Framework est la règle ; la revue est l'exercice.

Faut-il un partenaire AWS pour réaliser une revue Well-Architected ?

Non, vous pouvez la mener en autonomie avec le WA Tool gratuit. Un partenaire devient utile (ou nécessaire) si vous cherchez un regard externe sans complaisance, une priorisation business des HRI, l'éligibilité aux crédits de 5 000 $, ou si l'enjeu réglementaire ou critique ne tolère pas l'erreur. La maturité de votre équipe est le vrai critère de décision.

Quelle est la différence entre AWS Well-Architected et Azure Well-Architected ?

Les deux référentiels partagent la même philosophie. AWS compte six piliers (dont la durabilité), Azure en compte cinq. Les outils et les notions de landing zone diffèrent (Control Tower / Landing Zone Accelerator côté AWS, Cloud Adoption Framework côté Azure). Pour un parc hybride, l'enjeu est de réconcilier les deux en une gouvernance unique, ce qu'un intermédiaire indépendant multicloud peut coordonner sans parti pris.

Comment se déroule un atelier Well-Architected Review ?

L'animateur déroule, pilier par pilier, les questions du WA Tool avec vos référents (architecte, sécurité, exploitation, métier). Pour chaque pratique, il creuse au-delà de la réponse de façade afin de faire émerger les risques réels. L'outil consolide ensuite les HRI et MRI, et l'on transforme ces risques en plan d'action priorisé, avec un milestone pour figer l'état initial.