v1.0 Novembre 2025
DOCUMENT 10.4

Plan de Sauvegarde et Disaster Recovery

La solution de cashback nouvelle génération

24 novembre 2025
Version 1.0
1

INTRODUCTION

1.1 Objectif du Document

Ce document définit la stratégie complète de sauvegarde et de reprise après sinistre (Disaster Recovery) pour l'ensemble de l'écosystème REWAPP. Il établit les procédures permettant d'assurer la continuité des opérations et la protection des données utilisateurs, commerçants et transactionnelles.

1.2 Périmètre

Le plan couvre l'ensemble des composants de l'infrastructure REWAPP :

  • Application Mobile (données utilisateurs)
  • Site Vitrine (contenu et configurations)
  • Dashboard Admin (configurations système)
  • Dashboard Partenaire (données commerçants)
  • Backend API (microservices NestJS)
  • Bases de données (PostgreSQL, Redis)
  • Stockage fichiers (Amazon S3)
  • Services tiers (intégrations bancaires, notifications)

1.3 Criticité des Données

Matrice de Criticité des Données

Catégorie Criticité Exemples Impact Perte
Données transactionnelles CRITIQUE Points, transactions, virements Perte financière directe, atteinte à la confiance
Données utilisateurs HAUTE Profils, cartes liées, historique Non-conformité RGPD, perte clients
Données partenaires HAUTE Comptes commerçants, configurations Interruption service partenaires
Données système MOYENNE Logs, métriques, configurations Dégradation monitoring, audit difficile
Assets statiques BASSE Images, documents marketing Impact visuel, remplacement possible
2

OBJECTIFS DE RÉCUPÉRATION (RTO/RPO)

2.1 Définitions

Recovery Time Objective (RTO)

Durée maximale acceptable d'interruption de service après un incident.

Recovery Point Objective (RPO)

Perte de données maximale acceptable, mesurée en temps depuis la dernière sauvegarde.

2.2 Objectifs par Composant

Objectifs RTO/RPO par Composant

Composant RTO RPO Justification
PostgreSQL (Production) 1 heure 5 minutes Données transactionnelles critiques, Multi-AZ avec réplication
Cache Redis 15 minutes 0 (temps réel) Réplication synchrone, données volatiles acceptables
Stockage S3 30 minutes 0 (temps réel) Réplication cross-region native AWS
API Backend 30 minutes N/A Services stateless, redéploiement rapide
Application Mobile 2 heures N/A Publication stores, cache local utilisateur
Dashboards Web 1 heure N/A Rebuild automatique via CI/CD

2.3 Objectifs Globaux REWAPP

< 4h RTO Global
< 1h RPO Global
99.9% Disponibilité annuelle
< 2h MTTR
SLA Disponibilité

99.9% de disponibilité annuelle équivaut à 8h76 de downtime maximum par an.

3

STRATÉGIE DE SAUVEGARDE

3.1 Types de Sauvegardes

Types de Sauvegardes

Type Fréquence Rétention Données Concernées
Sauvegarde complète (Full) Hebdomadaire (dimanche 3h00) 12 semaines Toutes les bases de données
Sauvegarde incrémentielle Quotidienne (2h00) 30 jours Modifications depuis dernière sauvegarde
Sauvegarde continue (WAL) Temps réel 7 jours Logs de transactions PostgreSQL
Snapshots EBS Quotidien (4h00) 14 jours Volumes de données
Snapshots RDS Automatique + manuel 35 jours Instance PostgreSQL complète

3.2 Règle de Sauvegarde 3-2-1

RÈGLE 3-2-1

REWAPP applique la règle de sauvegarde 3-2-1 :

  • 3 copies des données (production + 2 sauvegardes)
  • 2 supports différents (RDS + S3)
  • 1 copie hors site (région AWS secondaire)

3.3 Politique de Rétention

Politique de Rétention

Période Type de Sauvegarde Conservation
Dernières 24 heures Point-in-Time Recovery Toutes les 5 minutes
7 derniers jours Sauvegardes quotidiennes 7 copies
4 dernières semaines Sauvegardes hebdomadaires 4 copies
12 derniers mois Sauvegardes mensuelles 12 copies
Archives légales Sauvegardes annuelles 5 ans (conformité RGPD)
4

ARCHITECTURE DE SAUVEGARDE AWS

4.1 Services AWS Utilisés

Services AWS de Sauvegarde

Service AWS Usage Sauvegarde Configuration
RDS Automated Backups Sauvegardes automatiques PostgreSQL Rétention 35 jours, fenêtre 2h00-3h00
RDS Snapshots Snapshots manuels avant opérations Chiffrement KMS, copie cross-region
S3 Versioning Versionnement objets Activé sur tous les buckets
S3 Cross-Region Replication Réplication région secondaire eu-west-1 vers eu-central-1
AWS Backup Orchestration sauvegardes centralisée Plans de sauvegarde automatisés
ElastiCache Backups Snapshots Redis Quotidien, rétention 7 jours

4.2 Architecture Multi-Région

Région Primaire : eu-west-1 (Irlande)
  • Infrastructure de production complète
  • Sauvegardes automatiques actives
  • Point-in-Time Recovery activé
Région Secondaire : eu-central-1 (Francfort)
  • Réplication S3 automatique
  • Copie snapshots RDS quotidienne
  • Infrastructure DR en standby (warm standby)

4.3 Chiffrement des Sauvegardes

CHIFFREMENT OBLIGATOIRE

Toutes les sauvegardes sont chiffrées :

  • Algorithme : AES-256
  • Gestion des clés : AWS KMS (Key Management Service)
  • Rotation automatique des clés : Annuelle
  • Accès aux clés : Restreint aux rôles IAM autorisés
5

PROCÉDURES DE SAUVEGARDE

5.1 Sauvegarde PostgreSQL (RDS)

5.1.1 Sauvegardes Automatiques

  • Fenêtre de sauvegarde : 02:00 - 03:00 UTC
  • Type : Snapshot + WAL continu
  • Stockage : Amazon S3 (géré par RDS)
  • Rétention : 35 jours
  • Point-in-Time Recovery : Activé (granularité 5 minutes)

5.1.2 Sauvegardes Manuelles (Avant Opérations Critiques)

DÉCLENCHEUR

Avant toute migration de données, mise à jour majeure ou modification de schéma.

  1. 1
    Notification équipe

    Via Slack #ops-alerts

  2. 2
    Création snapshot manuel

    Via AWS Console ou CLI

  3. 3
    Vérification intégrité

    Du snapshot créé

  4. 4
    Documentation

    Dans le registre des sauvegardes

  5. 5
    Attente confirmation

    Avant opération

5.2 Sauvegarde Redis (ElastiCache)

  • Type : Snapshot RDB
  • Fréquence : Quotidienne (04:00 UTC)
  • Rétention : 7 jours
  • Données : Sessions, cache, QR codes actifs
NOTE

Les données Redis sont considérées comme volatiles. En cas de perte, elles sont reconstituées depuis PostgreSQL ou expirées naturellement.

5.3 Sauvegarde S3

5.3.1 Configuration Versioning

Tous les buckets S3 de production ont le versioning activé :

  • rewapp-prod-assets : Images, logos partenaires
  • rewapp-prod-documents : Documents utilisateurs
  • rewapp-prod-exports : Exports de données
  • rewapp-prod-backups : Sauvegardes applicatives

5.3.2 Lifecycle Policies

Politiques de Cycle de Vie S3

Bucket Transition Glacier Expiration Versions Précédentes
rewapp-prod-assets 90 jours Jamais Suppression après 30 jours
rewapp-prod-documents 60 jours 5 ans Suppression après 90 jours
rewapp-prod-exports 30 jours 1 an Suppression après 7 jours
rewapp-prod-backups 30 jours 5 ans Conservation 1 an

5.4 Sauvegarde des Configurations

  • Infrastructure as Code : Terraform (versionné Git)
  • Secrets : Variables CapRover (backup automatique)
  • Paramètres : AWS Parameter Store (versionné)
  • Configurations applicatives : Git (GitHub)
6

PLAN DE DISASTER RECOVERY

6.1 Niveaux de Sinistre

Classification des Sinistres

Niveau Description Exemples Temps de Réponse
Niveau 1 Incident mineur - Service dégradé, données intactes Pic de charge, latence élevée < 30 minutes
Niveau 2 Incident majeur - Service indisponible partiellement Panne serveur, corruption partielle < 2 heures
Niveau 3 Sinistre critique - Perte infrastructure région Panne AWS région, cyberattaque < 4 heures
Niveau 4 Catastrophe - Perte multi-région Catastrophe naturelle majeure < 24 heures

6.2 Stratégies de Recovery par Niveau

6.2.1 Niveau 1 - Incident Mineur

Stratégie : Auto-healing et scaling automatique
  • Auto-scaling ECS pour absorber la charge
  • Health checks et redémarrage automatique des containers
  • Failover automatique vers replica RDS si nécessaire
  • Pas d'intervention manuelle requise

6.2.2 Niveau 2 - Incident Majeur

Stratégie : Basculement intra-région
  • Activation du replica RDS (Multi-AZ)
  • Redéploiement des services impactés
  • Restauration depuis dernier snapshot si nécessaire
  • Communication équipe via PagerDuty

6.2.3 Niveau 3 - Sinistre Critique

Stratégie : Basculement inter-région (Warm Standby)
  • Activation infrastructure région secondaire (eu-central-1)
  • Restauration base de données depuis réplication cross-region
  • Mise à jour DNS via Route 53 (failover automatique)
  • Communication crise aux utilisateurs

6.2.4 Niveau 4 - Catastrophe

Stratégie : Reconstruction complète
  • Déploiement infrastructure depuis Terraform
  • Restauration données depuis archives S3 Glacier
  • Reconstruction progressive des services
  • Communication étendue (média, régulateur)
7

SCÉNARIOS DE SINISTRE

7.1 Scénario 1 : Corruption Base de Données

Cause probable

Bug applicatif, erreur humaine, injection SQL

Impact : Données utilisateurs ou transactions corrompues

1. Détection

Alertes monitoring sur incohérences données

2
2. Isolation

Mise en maintenance du service impacté

3
3. Analyse

Identification du point de corruption

4
4. Restauration

Point-in-Time Recovery vers état sain

5
5. Validation

Vérification intégrité des données restaurées

6
6. Reprise

Réactivation progressive du service

1-2h RTO estimé
5 min RPO estimé (granularité PITR)

7.2 Scénario 2 : Panne Zone de Disponibilité AWS

Cause probable

Incident infrastructure AWS

Impact : Indisponibilité partielle des services

1. Détection

Health checks ALB échouent

2
2. Basculement

Automatique vers AZ secondaire (Multi-AZ)

Automatique
3
3. Scaling

Augmentation capacité dans AZ disponible

4
4. Monitoring

Surveillance performance post-basculement

5
5. Reprise

Rééquilibrage lors de restauration AZ

5-15 min RTO estimé (automatique)
0 RPO (réplication synchrone)

7.3 Scénario 3 : Cyberattaque (Ransomware)

Cause probable

Intrusion malveillante, phishing

Impact : Chiffrement malveillant des données

1. Détection

Alertes Sentry/CloudWatch sur comportement anormal

2
2. Isolation

Coupure accès réseau immédiate

URGENT
3
3. Évaluation

Identification périmètre compromis

4
4. Restauration

Depuis sauvegardes non impactées (air-gapped)

5
5. Forensics

Analyse post-incident avec équipe sécurité

6
6. Renforcement

Correction des vulnérabilités identifiées

4-8h RTO estimé
≤ 24h RPO (dernier backup sain)

7.4 Scénario 4 : Panne Région AWS Complète

Cause probable

Catastrophe naturelle, incident majeur datacenter

Impact : Indisponibilité totale région primaire

1. Détection

Route 53 health checks échouent

2
2. Activation DR

Lancement infrastructure eu-central-1

3
3. Restauration

Depuis dernière réplication cross-region

4
4. DNS

Basculement Route 53 vers région secondaire

5
5. Validation

Tests fonctionnels complets

6
6. Communication

Notification utilisateurs du basculement

2-4h RTO estimé
< 1h RPO (réplication asynchrone)
8

PROCÉDURES DE RESTAURATION

8.1 Restauration PostgreSQL

8.1.1 Point-in-Time Recovery (PITR)

Cas d'usage : Corruption données récente, erreur humaine

AWS CLI 
aws rds restore-db-instance-to-point-in-time   --source-db-instance-identifier rewapp-prod-db   --target-db-instance-identifier rewapp-prod-db-restored   --restore-time 2025-11-24T14:30:00Z

8.1.2 Restauration depuis Snapshot

Cas d'usage : Reconstruction complète, test DR

AWS CLI 
aws rds restore-db-instance-from-db-snapshot   --db-instance-identifier rewapp-prod-db-restored   --db-snapshot-identifier rewapp-prod-db-snapshot-20251124

8.2 Restauration Redis

Cas d'usage : Perte cache, corruption données session

  1. 1
    Création nouveau cluster

    Depuis snapshot disponible

  2. 2
    Mise à jour endpoint

    Dans configuration applicative

  3. 3
    Invalidation cache

    Cache applicatif

  4. 4
    Vérification

    Connectivité des services

NOTE

Les sessions utilisateurs seront invalidées, nécessitant une reconnexion.

8.3 Restauration S3

8.3.1 Restauration Version Précédente

Cas d'usage : Suppression accidentelle, modification erronée

  1. 1
    Identification

    De l'objet et version via Console S3

  2. 2
    Copie

    De la version antérieure comme version courante

  3. 3
    Suppression

    De la version corrompue (optionnel)

8.3.2 Restauration depuis Glacier

Cas d'usage : Données archivées nécessaires

  1. 1
    Initiation restauration

    Délai 3-5 heures pour Glacier Standard

  2. 2
    Attente notification

    De disponibilité

  3. 3
    Copie

    Vers bucket standard

  4. 4
    Utilisation

    Des données restaurées

8.4 Checklist de Restauration

Checklist de Restauration

Étape Action Validation Responsable
1 Évaluation de l'impact Périmètre identifié Ops Lead
2 Choix méthode restauration Méthode approuvée DBA
3 Notification équipes Slack #incident-war-room Ops Lead
4 Exécution restauration Backup restauré DBA
5 Validation technique Tests passés QA
6 Validation métier Données vérifiées Product Owner
7 Reprise service Service opérationnel Ops Lead
8 Post-mortem Rapport incident Ops Lead
9

PLAN DE CONTINUITÉ D'ACTIVITÉ

9.1 Modes Dégradés

En cas d'incident, REWAPP peut fonctionner en mode dégradé :

Modes de Fonctionnement Dégradés

Service Impacté Mode Dégradé Impact Utilisateur
Solution bancaire File d'attente transactions Détection différée des achats (< 24h)
Service virements Suspension temporaire Virements reportés (délai 2-3 semaines maintenu)
Génération QR code Désactivation temporaire Cashback commerçant indisponible
Notifications push Queue en attente Notifications différées
Dashboard partenaire Mode lecture seule Scan QR maintenu, stats différées

9.2 Communication de Crise

9.2.1 Canaux de Communication

Canaux de Communication par Audience

Audience Canal Responsable Délai
Équipe technique Slack #incident-war-room Ops Lead Immédiat
Direction Email + Téléphone CTO < 30 minutes
Partenaires premium Email dédié Account Manager < 1 heure
Utilisateurs Push notification + In-app Product Manager < 2 heures
Public Page statut + Réseaux sociaux Communication < 4 heures

9.2.2 Templates de Communication

Message Utilisateurs (Incident en cours)

Chers utilisateurs, nos services rencontrent actuellement des difficultés techniques. Nos équipes travaillent activement à la résolution. Vos points et données sont sécurisés. Nous vous tiendrons informés.

Message Utilisateurs (Résolution)

Bonne nouvelle ! Nos services sont de nouveau pleinement opérationnels. Merci de votre patience et confiance.

9.3 Équipes d'Intervention

Équipes d'Intervention

Équipe Rôle Astreinte Contact
Équipe Ops Première réponse, diagnostic 24/7 PagerDuty rotation
Équipe DBA Gestion bases de données 24/7 PagerDuty rotation
Équipe Sécurité Incidents sécurité 24/7 PagerDuty escalation
Équipe Dev Support technique approfondi Heures ouvrées Slack escalation
Direction Décisions critiques Astreinte Téléphone direct
10

TESTS ET VALIDATION

10.1 Planning des Tests

Planning des Tests DR

Type de Test Fréquence Durée Participants
Test restauration unitaire Mensuel 2 heures Ops + DBA
Test DR intra-région Trimestriel 4 heures Ops + Dev + QA
Test DR cross-region Semestriel 8 heures Toutes équipes
Exercice de crise complet Annuel 1 jour Toute l'entreprise

10.2 Procédure de Test Mensuel

Objectif : Valider la capacité de restauration des sauvegardes

  1. 1
    Sélection snapshot

    Aléatoire (< 7 jours)

  2. 2
    Restauration

    Vers instance de test

  3. 3
    Exécution tests

    Suite de tests d'intégrité

  4. 4
    Vérification

    Cohérence des données

  5. 5
    Mesure

    Du temps de restauration (RTO réel)

  6. 6
    Documentation

    Des résultats

  7. 7
    Suppression

    De l'instance de test

10.3 Procédure de Test Trimestriel DR

Objectif : Valider le basculement Multi-AZ

  1. 1
    Planification

    Avec équipes concernées (fenêtre de maintenance)

  2. 2
    Notification

    Utilisateurs si impact attendu

  3. 3
    Simulation panne

    AZ primaire (arrêt forcé instance)

  4. 4
    Observation

    Basculement automatique

  5. 5
    Validation

    Fonctionnement services

  6. 6
    Mesure

    RTO et RPO réels

  7. 7
    Retour

    À la configuration nominale

  8. 8
    Rédaction

    Rapport de test

10.4 Métriques de Succès des Tests

Métriques de Succès

Métrique Objectif Seuil Alerte
Temps de restauration PostgreSQL < 30 minutes > 45 minutes
Temps de basculement Multi-AZ < 5 minutes > 10 minutes
Temps de basculement cross-region < 4 heures > 6 heures
Intégrité des données restaurées 100% < 99.9%
Taux de succès des tests 100% < 95%
11

RÔLES ET RESPONSABILITÉS

11.1 Matrice RACI

Légende

R = Responsable | A = Approbateur | C = Consulté | I = Informé

Matrice RACI

Activité Ops Lead DBA Dev Lead CTO Product
Exécution sauvegardes A R I I -
Monitoring sauvegardes R A I I -
Restauration données I R/A I I I
Décision activation DR C C C A R
Communication crise I I I A R
Tests DR R/A R C I I
Post-mortem R R R A C

11.2 Contacts d'Urgence

Contacts d'Urgence

Rôle Nom Téléphone Email Astreinte
CTO [À définir] +33 6 XX XX XX XX cto@rewapp.fr 24/7
Ops Lead [À définir] +33 6 XX XX XX XX ops@rewapp.fr PagerDuty
DBA [À définir] +33 6 XX XX XX XX dba@rewapp.fr PagerDuty
Security Lead [À définir] +33 6 XX XX XX XX security@rewapp.fr Escalation
12

CONCLUSION

12.1 Récapitulatif des Objectifs

Le plan de sauvegarde et Disaster Recovery de REWAPP garantit :

  • Protection des données : Sauvegardes multi-niveaux avec règle 3-2-1
  • Récupération rapide : RTO < 4 heures, RPO < 1 heure
  • Résilience géographique : Réplication cross-region AWS
  • Tests réguliers : Validation mensuelle, trimestrielle et annuelle
  • Conformité : Rétention conforme RGPD (5 ans pour données légales)

12.2 Points Clés

Configuration REWAPP

Aspect Configuration REWAPP
Sauvegarde PostgreSQL Quotidienne + PITR 5 min + rétention 35 jours
Sauvegarde Redis Quotidienne + rétention 7 jours
Réplication S3 Cross-region temps réel vers eu-central-1
Chiffrement AES-256 avec AWS KMS
Architecture DR Warm Standby multi-région
RTO Global < 4 heures
RPO Global < 1 heure

12.3 Évolutions Prévues

Phase 2

Implémentation Hot Standby pour RTO < 30 minutes

2
Phase 3

Automatisation complète du basculement DR

3
Long terme

Multi-cloud pour résilience maximale

FIN DU DOCUMENT

Document 10.4 - Plan de Sauvegarde et Disaster Recovery - Version 1.0