AWS Well-Architected Framework : Le pilier Reliability, ou comment concevoir l'échec

Publié le 9 octobre 2025 par Mathieu Roger

Introduction : La fiabilité n’est pas l’absence de panne

Dans le monde idéal, nos systèmes ne tombent jamais en panne. Dans le monde réel, tout tombe en panne. Les disques durs crashent, les réseaux saturent, les datacenters prennent feu, les bugs se glissent dans le code, les humains font des erreurs.

Le pilier Reliability du AWS Well-Architected Framework part de cette réalité brutale mais incontournable : l’échec est inévitable. La question n’est pas “comment éviter les pannes ?” mais “comment continuer à fonctionner malgré les pannes ?”.

Un système fiable n’est pas celui qui ne tombe jamais. C’est celui qui retombe toujours sur ses pieds, rapidement, automatiquement, et sans impact perceptible pour les utilisateurs.

Cette approche change radicalement la manière dont nous concevons les architectures. Au lieu de chercher la perfection (impossible), nous construisons la résilience (atteignable).

Qu’est-ce que le pilier Reliability ?

Définition et périmètre

Le pilier Reliability définit la capacité d’un système à :

Encaisser les défaillances : Tolérer les pannes de composants sans interruption de service
Se rétablir rapidement : Restaurer automatiquement les fonctionnalités après un incident
S’adapter dynamiquement : Ajuster les ressources en fonction de la demande
Tenir ses promesses : Respecter les SLA et les engagements de disponibilité

La fiabilité couvre cinq domaines de conception :

Foundations : Les limites et quotas de service, la topologie réseau
Workload Architecture : Architecture distribuée et découplée
Change Management : Gestion des changements avec validation
Failure Management : Anticipation et réponse aux défaillances
Monitoring : Observabilité et détection proactive

Les métriques de la fiabilité

La fiabilité se mesure avec des indicateurs précis :

Availability (Disponibilité) : Pourcentage de temps où le service est opérationnel
- 99.9% = 43 minutes d’indisponibilité par mois
- 99.99% = 4.3 minutes par mois
- 99.999% = 26 secondes par mois
MTBF (Mean Time Between Failures) : Temps moyen entre deux pannes
MTTR (Mean Time To Recovery) : Temps moyen pour restaurer le service
RTO (Recovery Time Objective) : Temps maximum acceptable d’interruption
RPO (Recovery Point Objective) : Perte de données maximum acceptable

Exemple concret : Si votre RTO est de 1 heure et votre RPO de 15 minutes, cela signifie qu’en cas de désastre, vous devez pouvoir restaurer le service en moins d'1 heure, avec au maximum 15 minutes de transactions perdues.

Les fondations de la fiabilité

1. Concevoir pour l’échec : Design for Failure

Le principe fondamental de la fiabilité est d’assumer que tout peut échouer et de concevoir en conséquence.

Composants qui peuvent échouer :

Serveurs (panne matérielle, crash système)
Disques durs (corruption, défaillance)
Réseau (saturation, routeur HS)
Base de données (corruption, deadlock)
Load balancer (surcharge, bug)
Datacenter entier (incendie, inondation, coupure électrique)
Zone de disponibilité AWS (rare mais possible)
Région AWS (extrêmement rare mais prévu)

Stratégies de résilience :

Redondance : Aucun composant unique ne doit être critique (No Single Point of Failure - SPOF)

Plusieurs instances applicatives
Plusieurs bases de données (réplication)
Plusieurs zones de disponibilité
Plusieurs régions (pour les workloads critiques)

Graceful Degradation : Dégrader le service plutôt que de tout couper

Mode dégradé avec fonctionnalités réduites
Cache statique en cas de panne du backend
Queues pour absorber les pics de charge

Circuit Breaker : Couper les dépendances défaillantes

Timeout rapide sur les appels externes
Retry avec backoff exponentiel
Fail fast plutôt que d’attendre indéfiniment

Bulkhead Pattern : Isoler les composants pour limiter la propagation des pannes

Pools de connexions séparés
Ressources dédiées par tenant/client
Quotas et throttling

2. Architecture Multi-AZ et Multi-Region

AWS organise son infrastructure en Régions et Zones de Disponibilité (AZ) pour permettre la haute disponibilité.

Zones de Disponibilité (AZ) :

Datacenters physiquement séparés (plusieurs kilomètres)
Alimentation et réseau indépendants
Latence réseau ultra-faible entre AZ d’une même région (<2ms)
Au minimum 3 AZ par région AWS

Architecture Multi-AZ (haute disponibilité) :

┌────────────────────────────────────┐
│         Région AWS (eu-west-1)     │
│                                    │
│  ┌───────────┐     ┌───────────┐   │
│  │    AZ-A   │     │    AZ-B   │   │
│  │           │     │           │   │
│  │  App      │     │  App      │   │
│  │  RDS      │────▶│  RDS      │   │
│  │  (Master) │     │  (Standby)│   │
│  └───────────┘     └───────────┘   │
│        │                 │         │
│        └──────┬──────────┘         │
│               ▼                    │
│         Load Balancer              │
└────────────────────────────────────┘

Services AWS naturellement Multi-AZ :

Elastic Load Balancing (ALB, NLB)
RDS Multi-AZ (réplication synchrone)
Aurora (réplication dans 3 AZ minimum)
EFS (stockage distribué automatiquement)
S3 (réplication automatique dans minimum 3 AZ)

Architecture Multi-Region (disaster recovery) :

Pour les workloads critiques, déployer dans plusieurs régions géographiques :

┌─────────────────┐         ┌─────────────────┐
│  eu-west-1      │         │  us-east-1      │
│  (Paris)        │◀───────▶│  (Virginie)     │
│                 │         │                 │
│  Active         │         │  Standby        │
│  ou Active      │         │  ou Active      │
└─────────────────┘         └─────────────────┘

Patterns Multi-Region :

Active-Passive : Une région primaire, une région de secours
Active-Active : Trafic réparti sur plusieurs régions
Pilot Light : Infrastructure minimale dans la région de secours
Warm Standby : Infrastructure dimensionnée mais pas au maximum

Services pour le Multi-Region :

Route 53 avec health checks et failover DNS
Aurora Global Database (réplication cross-region <1s)
DynamoDB Global Tables (réplication automatique)
S3 Cross-Region Replication
CloudFront pour la distribution de contenu globale

3. Auto-scaling et élasticité

Un système fiable doit s’adapter automatiquement à la charge, sans intervention humaine.

Principes de l’auto-scaling :

Scale Out : Ajouter des instances quand la charge augmente
Scale In : Retirer des instances quand la charge diminue
Scale Up/Down : Changer la taille des instances (moins recommandé)

Services AWS pour l’auto-scaling :

EC2 Auto Scaling :

# Exemple de configuration
Min: 2    # Minimum pour la haute disponibilité
Desired: 4
Max: 10   # Limite pour maîtriser les coûts

Métriques de scaling:
- CPU > 70% → Scale Out
- CPU < 30% → Scale In
- Requests/Target > 1000 → Scale Out
- Queue Length > 100 → Scale Out

Application Auto Scaling : Pour ECS, Lambda, DynamoDB, etc.

Predictive Scaling : ML pour anticiper les variations de charge

Target Tracking : Maintenir une métrique cible (ex: 50% CPU)

Exemple concret : E-commerce avec pics le Black Friday

Configuration normale : 10 instances
Black Friday : auto-scale jusqu’à 100 instances
Nuit : scale down à 3 instances
Coût optimisé, performance garantie

Bonnes pratiques :

Toujours avoir minimum 2 instances (même en période creuse)
Déployer dans minimum 2 AZ
Warm-up period pour les nouvelles instances
Cooldown period pour éviter le flapping
Tester le scaling avec des load tests

4. Gestion de l’état et découplage

Un des ennemis de la fiabilité est l’état partagé (stateful architecture). Plus les composants sont couplés, plus la propagation des pannes est rapide.

Architecture stateless :

❌ Stateful (fragile):
User → Load Balancer → Instance A (session stockée en local)
                       ↓ (si crash, session perdue)

✅ Stateless (résilient):
User → Load Balancer → Instance A, B, C (interchangeables)
                       ↓
                   ElastiCache/DynamoDB (session externalisée)

Patterns de découplage :

1. Message Queues (Asynchrone) :

Producteur → SQS Queue → Consommateur
             (buffer)     (traitement indépendant)

Avantages :

Absorption des pics de charge
Retry automatique en cas d’échec
Pas de perte de messages (durabilité)
Scaling indépendant producteur/consommateur

2. Event-Driven Architecture :

Service A → EventBridge → Lambda 1
                        → Lambda 2
                        → Lambda 3
           (découplage total)

3. API Gateway avec cache :

Client → API Gateway (cache) → Backend
         (absorbe la charge)

Services AWS pour le découplage :

Amazon SQS : Queue FIFO ou standard
Amazon SNS : Pub/Sub pour notifications
Amazon EventBridge : Bus d’événements
AWS Step Functions : Orchestration de workflows
Amazon Kinesis : Streaming de données
AWS AppSync : GraphQL managé avec cache

Exemple concret : Traitement de commandes e-commerce

Commande → SQS → [Lambda: Validation]
                → [Lambda: Paiement]
                → [Lambda: Inventory]
                → [Lambda: Shipping]
                → [Lambda: Email]

Si le service de paiement est lent ou down, les autres traitements continuent. Les messages sont retraités automatiquement en cas d’échec.

5. Stratégies de backup et disaster recovery

La fiabilité inclut la capacité à restaurer après une catastrophe majeure.

Les 4 stratégies de DR (par ordre de coût/RTO croissant) :

1. Backup and Restore (RTO: heures, RPO: heures)

Backups réguliers vers S3
Restauration manuelle en cas de besoin
Moins cher mais RTO/RPO élevés
Adapté aux environnements non-critiques

2. Pilot Light (RTO: dizaines de minutes, RPO: minutes)

Infrastructure minimale dans la région de DR
Bases de données répliquées mais instances arrêtées
Scale up rapide en cas de besoin
Bon compromis coût/performance

3. Warm Standby (RTO: minutes, RPO: secondes)

Infrastructure dimensionnée mais à capacité réduite
Réplication continue des données
Scale up immédiat en cas de basculement
Plus cher mais RTO très court

4. Active-Active Multi-Region (RTO: secondes, RPO: quasi-zéro)

Infrastructure complète dans plusieurs régions
Trafic réparti activement
Basculement transparent
Le plus cher mais disponibilité maximale

Services AWS pour les backups :

AWS Backup : Solution centralisée

Backups automatisés avec rétention
Cross-region et cross-account
Policies de sauvegarde par tags
Compliance et audit trails

Snapshots EBS : Backups incrémentaux

Stockés dans S3 (11 9s de durabilité)
Copie cross-region possible
Restauration rapide

RDS Automated Backups :

Point-in-time recovery (PITR)
Rétention jusqu’à 35 jours
Snapshots manuels illimités

S3 Versioning + Lifecycle :

Versions multiples des objets
Protection contre la suppression accidentelle
Archivage automatique vers Glacier

Exemple de stratégie 3-2-1 :

3 copies des données
Sur 2 supports différents (EBS + S3)
1 copie off-site (cross-region)

Test de restauration : CRITIQUE

Tester la restauration régulièrement (minimum trimestriel)
Documenter les procédures (runbooks)
Mesurer le RTO/RPO réels (pas théoriques)
Automatiser au maximum

Anti-pattern mortel : Des backups jamais testés = pas de backups. Découvrir lors d’un désastre que les backups sont corrompus ou incomplets est un cauchemar récurrent.

Gestion des changements : déployer sans casser

Les changements (déploiements, mises à jour, reconfigurations) sont une source majeure d’incidents. Un système fiable doit pouvoir évoluer sans risque.

1. Infrastructure as Code (IaC)

L’IaC garantit la reproductibilité et la traçabilité des changements.

Avantages :

Version control (Git)
Review process (pull requests)
Rollback facile
Environnements identiques (dev/staging/prod)
Documentation as code

Outils :

AWS CloudFormation : Natif AWS, YAML/JSON
Terraform : Multi-cloud, HCL
AWS CDK : IaC en code (TypeScript, Python, Java, etc.)
Pulumi : IaC en code avec langages standards

Exemple CloudFormation :

Resources:
  WebServerGroup:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      MinSize: 2
      MaxSize: 10
      DesiredCapacity: 4
      AvailabilityZones:
        - eu-west-1a
        - eu-west-1b
        - eu-west-1c
      HealthCheckType: ELB
      HealthCheckGracePeriod: 300

2. Déploiements progressifs et canary

Ne jamais déployer en big bang sur toute la production.

Blue/Green Deployment :

┌──────────┐          ┌──────────┐
│  Blue    │          │  Green   │
│  (v1.0)  │          │  (v1.1)  │
│  100%    │  Switch  │  0%      │
└──────────┘  ──────▶ └──────────┘
                       │  100%    │

Avantages :

Rollback instantané (basculer sur l’ancien)
Test en conditions réelles
Zero downtime

Canary Deployment :

v1.0: 95% du trafic
v1.1: 5% du trafic (canary)
      ↓ (surveillance)
      Si OK: augmenter progressivement (10%, 25%, 50%, 100%)
      Si KO: rollback immédiat

Services AWS :

Elastic Beanstalk : Blue/Green et rolling deployments
ECS/EKS : Déploiements progressifs natifs
CodeDeploy : Déploiements automatisés avec canary
Lambda : Alias et versions avec traffic shifting

Metrics à surveiller pendant un déploiement :

Taux d’erreur (4xx, 5xx)
Latence (p50, p95, p99)
Throughput (requêtes/seconde)
Health checks
Logs d’erreurs

Rollback automatique : Si les métriques se dégradent → rollback immédiat sans intervention humaine.

3. Feature flags et kill switches

Les feature flags permettent de découpler déploiement et activation d’une fonctionnalité.

Avantages :

Déployer du code désactivé
Activer progressivement (par région, par % d’utilisateurs)
Désactiver instantanément en cas de problème (kill switch)
A/B testing et expérimentation

Exemple :

if feature_flags.is_enabled('new_checkout', user_id):
    return new_checkout_flow(user)
else:
    return legacy_checkout_flow(user)

En cas de problème sur le nouveau checkout → désactiver le flag en 1 clic → retour immédiat à l’ancien flow.

Services :

AWS AppConfig : Feature flags managés
LaunchDarkly, Split.io (SaaS tiers)

4. Chaos Engineering et Game Days

Tester la résilience avant qu’un incident réel ne survienne.

Chaos Engineering :

Injecter volontairement des pannes en production
Observer comment le système réagit
Identifier les faiblesses
Améliorer continuellement

Exemples de tests :

Tuer aléatoirement des instances (Chaos Monkey)
Saturer le réseau (latence, packet loss)
Crasher une AZ entière
Remplir les disques durs
Introduire des erreurs dans les API

AWS Fault Injection Simulator (FIS) :

Service managé pour le chaos engineering
Scénarios pré-définis
Safety controls (arrêt automatique si ça dérape)
Intégration avec CloudWatch pour monitoring

Game Days :

Simulation d’incident avec toute l’équipe
Scénario réaliste (ex: “la région primaire est down”)
Test des runbooks et procédures
Amélioration de la préparation

Fréquence recommandée :

Chaos Engineering : continu (automated)
Game Days : trimestriels minimum

Monitoring et observabilité pour la fiabilité

Un système dont on ne peut pas mesurer la santé n’est pas fiable.

1. Les trois piliers de l’observabilité

Métriques :

CPU, mémoire, disque, réseau (infrastructure)
Latence, throughput, taux d’erreur (application)
Queue length, age of oldest message (async)

Logs :

Événements applicatifs structurés (JSON)
Corrélation avec trace IDs
Recherche et analyse rapides

Traces distribuées :

Suivi d’une requête à travers tous les microservices
Identification des goulots d’étranglement
Debugging des problèmes de performance

2. Alerting intelligent

Principes d’un bon système d’alertes :

❌ Mauvaises pratiques :

Alertes sur des seuils arbitraires (CPU > 80%)
Trop d’alertes → fatigue → ignorer les vraies alertes
Alertes non actionnables
Pas de contexte dans l’alerte

✅ Bonnes pratiques :

Alertes sur les symptômes, pas les causes (latence utilisateur, taux d’erreur)
Anomaly detection (ML pour détecter les écarts)
Alertes avec contexte et runbook associé
Escalation automatique si pas de réponse
Synthèse des alertes corrélées

Services AWS :

CloudWatch Alarms : Alertes sur métriques
CloudWatch Anomaly Detection : Détection par ML
SNS : Notifications (email, SMS, Slack, PagerDuty)
X-Ray : Tracing distribué
CloudWatch Logs Insights : Requêtes sur les logs

Exemple d’alerte actionnable :

❌ "EC2 Instance i-abc123 CPU > 90%"
   (et alors ? c'est peut-être normal, c'est peut-être un spike temporaire)

✅ "API Latency p95 > 500ms pendant 5 minutes
    Impact: 15% des utilisateurs affectés
    Runbook: https://wiki/runbook-high-latency
    Dashboard: https://grafana/api-latency"

3. SLI, SLO, SLA : mesurer ce qui compte

SLI (Service Level Indicator) : Métrique mesurable

Latence (ex: p99 < 200ms)
Disponibilité (ex: uptime 99.9%)
Taux de réussite (ex: 99.95% de requêtes HTTP 200)

SLO (Service Level Objective) : Cible interne

“99.9% des requêtes doivent réussir”
“p95 de la latence < 300ms”
“RTO < 1 heure, RPO < 15 minutes”

SLA (Service Level Agreement) : Engagement contractuel client

“99.95% de disponibilité garantie”
Pénalités financières si non respecté

Error Budget : Marge d’erreur acceptable

Si SLO = 99.9%, error budget = 0.1% = 43 minutes/mois
Si l’error budget est consommé → freeze des déploiements, focus stabilité
Si l’error budget est préservé → on peut prendre plus de risques

Exemple concret :

SLI: Availability = (successful requests / total requests) * 100
SLO: 99.95% sur un mois glissant
Error Budget: 0.05% = 21 minutes d'indisponibilité/mois

Si on a déjà consommé 15 minutes → plus que 6 minutes restantes
→ Pas de déploiement majeur ce mois-ci
→ Focus sur la stabilité

Cas d’usage : l’impact de la fiabilité

Scénario sans fiabilité : la catastrophe évitable

J’ai observé chez un client une situation malheureusement classique :

Architecture initiale :

Application critique hébergée sur une seule instance EC2
Base de données RDS sans Multi-AZ
Pas de backup testé (backups automatiques activés mais jamais restaurés)
Déploiements manuels le vendredi soir
Monitoring basique (CloudWatch par défaut)
Pas de plan de disaster recovery

L’incident : Un samedi matin, la base de données RDS a eu une défaillance matérielle (événement rare mais pas impossible).

Conséquences en cascade :

Détection : 45 minutes (alerte non configurée)
Application complètement down (dépendance totale à la DB)
Tentative de restauration depuis backup : échec (backup corrompu, jamais testé)
Escalade vers AWS Support : 2 heures d’attente
Restauration manuelle depuis un snapshot de 24h avant
RTO réel : 6 heures
RPO réel : 24 heures de transactions perdues

Impact business :

Site e-commerce inaccessible pendant le week-end (pic de trafic)
Perte de CA estimée : 150K€
Commandes perdues : impossibles à reconstituer
Réputation : clients furieux sur les réseaux sociaux
Équipe technique : burnout et démissions

Coût total : 200K€ direct + impact réputation incalculable

Transformation avec le pilier Reliability

Sur un projet similaire, l’approche a été radicalement différente :

Architecture résiliente :

Application : Auto Scaling Group avec minimum 2 instances dans 2 AZ
Load Balancer : Application Load Balancer Multi-AZ
Base de données : RDS Multi-AZ avec réplication synchrone
Cache : ElastiCache Redis en cluster mode
Backup : AWS Backup avec tests de restauration mensuels
Monitoring : CloudWatch + X-Ray + PagerDuty
DR : Pilot Light dans une région secondaire

L’incident équivalent : Défaillance de la base de données primaire dans l’AZ-A.

Réponse automatique :

RDS détecte la panne (health check)
Basculement automatique sur le standby dans l’AZ-B (30 secondes)
DNS mis à jour automatiquement
Applications reconnectées automatiquement (retry logic)
Alertes envoyées à l’équipe (pour information, pas pour action d’urgence)

Résultat :

RTO réel : 1 minute 45 secondes
RPO réel : 0 (réplication synchrone)
Impact utilisateur : quelques requêtes en erreur pendant 30s (retry client)
Downtime perçu : quasi-zéro
Équipe : informée, analyse post-mortem le lundi, pas de stress

Coût de la résilience :

Multi-AZ RDS : +100% du coût DB (~300€/mois → 600€/mois)
Auto Scaling minimum 2 instances : +100% instances (~200€/mois → 400€/mois)
Monitoring avancé : +50€/mois
Total : +600€/mois

ROI : Un seul incident évité = 200K€ économisés. Rentabilité immédiate.

Outils et services AWS pour la Reliability

Compute et scaling

EC2 Auto Scaling : Scaling automatique des instances
ECS/EKS : Orchestration de containers avec HA
Lambda : Serverless avec scaling infini et HA native
Elastic Beanstalk : PaaS avec déploiements managés

Storage et bases de données

RDS Multi-AZ : Haute disponibilité automatique
Aurora : Réplication dans 3 AZ, failover <30s
DynamoDB : NoSQL avec réplication automatique
ElastiCache : Cache in-memory avec réplication
EFS : Stockage fichier distribué Multi-AZ
S3 : Durabilité 99.999999999% (11 9s)

Réseau et distribution

Elastic Load Balancing : ALB, NLB, GLB avec Multi-AZ
Route 53 : DNS avec health checks et failover
CloudFront : CDN global avec caching
Global Accelerator : Routing intelligent global

Backup et DR

AWS Backup : Sauvegarde centralisée et automatisée
EBS Snapshots : Backups incrémentaux
S3 Cross-Region Replication : Réplication automatique
Aurora Global Database : Multi-region avec latence <1s
DynamoDB Global Tables : Multi-region actif-actif

Monitoring et testing

CloudWatch : Métriques, logs, alarmes
X-Ray : Tracing distribué
AWS Health Dashboard : État des services AWS
AWS Fault Injection Simulator : Chaos engineering
CloudWatch Synthetics : Tests synthétiques continus

Implémentation progressive de la Reliability

Phase 1 : Éliminer les SPOF critiques (1 mois)

Actions immédiates :

Audit des Single Points of Failure :
- Identifier tous les composants uniques
- Prioriser par criticité business
- Estimer le coût de la redondance
Quick wins :
- Activer RDS Multi-AZ sur les DB critiques
- Passer en Auto Scaling Group (min 2 instances)
- Déployer un Load Balancer
- Activer les backups automatiques
- Configurer les alertes CloudWatch de base
Tests :
- Tester un failover RDS
- Tester l’auto-scaling (scale out/in)
- Tester une restauration de backup

Résultat attendu : Disponibilité passe de 99% à 99.9% (43 min → 4.3 min downtime/mois)

Phase 2 : Architecture Multi-AZ complète (3 mois)

Objectifs :

Distribuer tous les composants :
- Application dans 3 AZ minimum
- Bases de données répliquées
- Cache distribué
- Stockage sur S3/EFS (Multi-AZ natif)
Découplage :
- Introduire SQS pour les traitements asynchrones
- Externaliser les sessions (ElastiCache/DynamoDB)
- API Gateway avec cache
- EventBridge pour les événements
Monitoring avancé :
- CloudWatch Dashboards personnalisés
- X-Ray pour le tracing
- Anomaly Detection activée
- Runbooks pour chaque alerte
Chaos Engineering :
- Premier game day (simulation d’incident)
- Tests automatisés avec FIS
- Documentation des leçons apprises

Résultat attendu : Disponibilité 99.95% (21 min downtime/mois), RTO < 5 minutes

Phase 3 : Maturité et Multi-Region (6+ mois)

Évolution continue :

Disaster Recovery Multi-Region :
- Choisir la stratégie adaptée (Pilot Light, Warm Standby, Active-Active)
- Implémenter la réplication cross-region
- Automatiser le basculement
- Tester le DR trimestriellement
Optimisation :
- SLI/SLO/SLA formalisés
- Error budget tracking
- Amélioration continue du MTTR
- Priorisation data-driven
Culture :
- Postmortems blameless systématiques
- Partage des incidents et leçons apprises
- Formation continue de l’équipe
- Intégration reliability dans la roadmap produit

Résultat attendu : Disponibilité 99.99%+ (4 min downtime/mois), RTO < 1 minute

Indicateurs de succès de la Reliability

Métriques techniques

Availability : Uptime mensuel (objectif : > 99.95%)
MTBF : Temps moyen entre pannes (objectif : augmentation continue)
MTTR : Temps moyen de récupération (objectif : < 5 minutes)
Change Failure Rate : % de déploiements causant un incident (objectif : < 5%)
Deployment Frequency : Fréquence des déploiements (objectif : plusieurs/jour)

Métriques business

Customer Impact : Nombre d’utilisateurs affectés par incident
Revenue Loss : Perte de CA par incident
Customer Satisfaction : NPS, CSAT
Brand Reputation : Mentions sur réseaux sociaux

Métriques d’équipe

On-call Burden : Nombre d’alertes nocturnes (objectif : minimiser)
Toil : Temps passé en tâches manuelles répétitives (objectif : automatiser)
Burnout : Turnover, satisfaction d’équipe

Erreurs courantes et comment les éviter

Erreur #1 : “Ça n’arrive qu’aux autres”

Mythe : “On est trop petit pour qu’AWS tombe chez nous”

Réalité : Les pannes AWS sont rares mais existent. Et vos propres bugs sont beaucoup plus fréquents.

Solution : Concevoir pour l’échec dès le jour 1, même pour un MVP.

Erreur #2 : “On ajoutera la HA plus tard”

Mythe : “On verra la haute disponibilité une fois qu’on aura du trafic”

Réalité : Refactoriser une architecture monolithique en système distribué coûte 10x plus cher que de bien faire dès le départ.

Solution : Multi-AZ dès le départ, même avec peu de trafic. Le coût marginal est faible.

Erreur #3 : “Les backups, c’est suffisant”

Mythe : “J’ai activé les backups automatiques, je suis protégé”

Réalité : Des backups non testés = pas de backups. Restaurer sous pression pour la première fois = 90% d’échec.

Solution : Tests de restauration réguliers, automatisés, avec métriques de RTO/RPO réels.

Erreur #4 : “Le monitoring par défaut suffit”

Mythe : “CloudWatch est activé, je suis couvert”

Réalité : Les métriques infrastructure ne montrent pas les problèmes utilisateur (latence applicative, erreurs métier).

Solution : Monitoring applicatif avec SLI/SLO, alertes sur les symptômes, pas les causes.

Erreur #5 : “Pas besoin de Multi-Region pour nous”

Mythe : “Le Multi-Region, c’est pour Netflix, pas pour nous”

Réalité : Dépend de vos RTO/RPO. Si vous ne pouvez pas vous permettre > 1h d’indisponibilité, vous avez besoin d’une stratégie DR.

Solution : Commencer par Pilot Light (peu coûteux), évoluer vers Warm Standby si nécessaire.

Erreur #6 : “Plus de 9s = mieux”

Mythe : “Visons 99.999% de disponibilité pour tout”

Réalité : Chaque 9 supplémentaire coûte exponentiellement plus cher. 99.999% peut coûter 10x plus que 99.95%.

Solution : Aligner les SLO sur les besoins business réels, pas sur l’ego technique.

La fiabilité au-delà d’AWS : principes universels

Les principes du pilier Reliability s’appliquent à tout environnement :

Azure :

Availability Zones (équivalent AZ AWS)
Azure Site Recovery (DR)
Azure Load Balancer
Cosmos DB (globally distributed)

Google Cloud :

Multi-region deployments
Cloud Load Balancing
Cloud Spanner (global consistency)

Kubernetes :

ReplicaSets (haute disponibilité)
Horizontal Pod Autoscaler
Multi-cluster avec federation
Chaos Mesh pour chaos engineering

On-premise :

VMware vSphere HA
Clustering de bases de données
Load balancers matériels (F5, A10)
SAN avec réplication

Les fondamentaux restent identiques :

Éliminer les SPOF
Redondance et réplication
Monitoring et alerting
Tests de chaos et DR

Conclusion : La fiabilité, investissement stratégique

Le pilier Reliability du AWS Well-Architected Framework nous enseigne une leçon fondamentale : l’échec n’est pas une option, c’est une certitude. La seule question est de savoir comment nous nous y préparons.

Un système fiable ne coûte pas nécessairement beaucoup plus cher qu’un système fragile. Ce qui coûte cher, ce sont :

Les incidents non gérés
Les pannes prolongées
La perte de confiance client
Le turnover d’équipe lié au stress

Un système fiable :

Encaisse les pannes sans broncher
Se rétablit automatiquement et rapidement
S’adapte dynamiquement à la charge
Permet de dormir tranquille

Le vrai ROI de la fiabilité :

Business : Continuité d’activité, satisfaction client, réputation
Technique : Déploiements sereins, innovation sans peur
Humain : Équipes moins stressées, moins de burnout

La question n’est pas “peut-on se permettre d’investir dans la fiabilité ?”, mais “peut-on se permettre de ne pas le faire ?”

Comme le dit Werner Vogels, CTO d’Amazon : “Everything fails all the time.” À nous de construire des systèmes qui savent tomber pour mieux se relever.

Prochainement dans cette série : Le pilier Performance Efficiency du AWS Well-Architected Framework — comment optimiser les performances tout en maîtrisant les coûts.

Besoin d’un audit de fiabilité ou d’accompagnement pour sécuriser vos architectures Cloud ? Notre équipe d’experts certifiés AWS Solutions Architect est disponible. Contactez-nous.