BCP · DR — Continuité d'activité et reprise sur sinistre

Version : 1.0 · Date : 2026-04-22 · Propriétaire : CTO · Approbateurs : CEO + CISO + COO.

Aligné ISO 22301 (Continuité d’activité) + ISO 27031 (préparation TIC à la continuité) + GDPR art. 32 + BCT circulaire 2017-08.

---

1. Portée

Ce plan couvre :

• Le service SaaS VitaKYC hébergé sur AWS Frankfurt (zone primaire) + Paris ou Dublin (zone secondaire).
• Les déploiements on-premise chez clients (avec adaptations documentées côté client).
• Les services critiques : authentification, KYC workflow, AML screening, TCR generation, back-office, documentation publique.

Hors périmètre : les opérations purement internes non liées à la production du service (CRM, site marketing hors doc, outils RH).

2. Objectifs de continuité (RTO / RPO)

Service	RTO (temps de reprise)	RPO (perte max)	Criticité
API publique /v1/kyc/*	30 min	5 min	P0
API publique /v1/aml/*	30 min	5 min	P0
API publique /v1/tcr/*	60 min	5 min	P1
Back-office agent	30 min	5 min	P0
Form Designer (édition)	2 h	1 h	P2
Webhooks delivery	1 h	5 min (avec retry 7 jours)	P1
Docs publique docs.vitakyc...	4 h	24 h	P3
Analytics, dashboards	4 h	24 h	P3

Classement criticité :

• P0 : service métier en temps réel, impact client immédiat.
• P1 : service métier différé, impact délai.
• P2 : configuration, impact projet.
• P3 : lecture seule, impact minime.

3. Architecture de résilience

3.1 Topologie multi-région (SaaS)

Principes :

• Active-passive au MVP (coût), active-active cible V2.
• Réplication asynchrone PostgreSQL cross-région (MRR ~ 1-2 s).
• S3 Cross Region Replication activée pour tous les buckets P2+.
• MirrorMaker 2 pour les topics Kafka métier critiques (audit, events).

3.2 Multi-AZ (par défaut même en primaire)

• EKS nodes répartis sur 3 AZ.
• RDS PostgreSQL Multi-AZ synchrone (RPO = 0 pour failover intra-région).
• MSK 3 brokers, 3 AZ.
• ALB cross-AZ.

3.3 Backup strategy

Ressource	Méthode	Fréquence	Rétention
PostgreSQL	PITR (transaction logs) + full RDS snapshots	PITR continu + full quotidien	35 jours PITR + 1 an full archivé
S3 / MinIO	Versioning + Object Lock Compliance	Continu	10 ans (Object Lock)
Keycloak	Export config + DB	Quotidien	90 jours
Vault	Snapshots chiffrés	Toutes les 4 h	30 jours
Secrets (HashiCorp Vault)	Export Sealed Secrets chiffré	Quotidien	90 jours (hors-site)
Configurations (Git)	Git remote backup	À chaque push	Illimité (GitLab + miroir)

Test de restauration : mensuel minimum sur un env éphémère dédié. Preuve de restauration avec RTO/RPO mesurés archivée dans le registre conformité.

4. Scénarios de sinistre et réponses

Scénario 1 · Défaillance AZ simple (AWS eu-central-1a tombe)

Probabilité : Moyenne · Impact : Faible (transparence utilisateur).

Réponse : automatique via Multi-AZ. Les pods K8s rescheduled sur les autres AZ ; RDS Multi-AZ bascule automatique (< 60 s) ; MSK continue avec 2 brokers restants.

RTO : < 2 min · RPO : 0.

Scénario 2 · Défaillance région primaire complète (eu-central-1 indisponible)

Probabilité : Basse · Impact : Majeur.

Réponse : failover manuel (approbation CTO + CEO) vers région secondaire Paris.

Procédure détaillée :

T+0     · Alerte PagerDuty "region down"
T+2min  · Incident Commander désigné, channel #inc-region-failure
T+5min  · Validation CTO + CEO du failover
T+10min · Promotion du read replica en primary (RDS)
T+12min · Mise à jour Route 53 weighted records → secondaire
T+15min · Redéploiement K8s apps sur cluster secondaire via ArgoCD
T+20min · Validation santé services (healthchecks, smoke tests)
T+25min · Notification clients + statut page
T+30min · RTO atteint — service partiellement restauré
T+60min · Verification fonctionnelle complète (workflows KYC end-to-end)

RTO : 30 min · RPO : 1-2 min (lag réplication).

Dégradation temporaire : TCR generation et webhook delivery mis en file d’attente ; traités dans les 60 min post-failover.

Scénario 3 · Corruption DB (bug applicatif, erreur humaine, attaque ransomware)

Probabilité : Basse · Impact : Élevé.

Réponse : PITR (Point In Time Recovery) vers instant précédant la corruption.

Procédure :

1. Containment : geler toutes les écritures sur la DB affectée (read-only mode).
2. Analyse : identifier l’instant T-corruption précis via logs d’audit WORM (horodatage + hash chain).
3. Décision : restaurer jusqu’à T-corruption ? autre option ?
4. Restauration : RDS PITR vers une nouvelle instance (préserve l’originale pour forensics).
5. Rebascule : DNS interne → nouvelle instance.
6. Replay : les événements Kafka après T-corruption peuvent être rejoués (retention Kafka = 7 j).

RTO : 1-2 h selon volume · RPO : < 1 min si PITR dispo.

Scénario 4 · Attaque ransomware sur l’infra

Réponse : activation plan de crise.

1. Containment immédiat : isoler les pods compromis, couper le trafic externe.
2. Forensics : snapshot intégral, mandater CERT externe (partenariat préalable : Orange Cyberdefense, Thales…).
3. Ne pas payer la rançon (décision DG + juridique).
4. Restauration from clean backup (Object Lock empêche altération).
5. Notification CNIL/INPDP sous 72 h (cf. Playbook 3 data breach).
6. Communication clients : transparence mesurée, calendrier de restauration.

RTO : variable selon ampleur, viser 24 h · RPO : 4-24 h selon dernière snapshot saine.

Scénario 5 · Indisponibilité prolongée d’un fournisseur tiers critique

Exemples : ComplyAdvantage down, DGI IDES unreachable, AWS global outage.

Réponse :

• AML provider : bascule sur fournisseur secondaire (Dow Jones) pré-configuré avec ACL délibérément restreintes.
• DGI IDES : fichier FATCA XML stocké en file ; retry avec backoff exponentiel ; alerte compliance officer tenant si > 4 h.
• Core banking (chez tenant on-prem) : pas de fallback direct, notification tenant.
• AWS global : mode dégradé si possible, communication transparente.

Scénario 6 · Incident on-prem chez un tenant

Particularité : ce n’est pas sous notre contrôle direct, mais notre support doit être activable.

Support fourni :

• Runbooks remis au tenant (adaptés à son environnement).
• Astreinte étendue (option payante Enterprise) pour intervention sur le service VitaKYC.
• Dossier de MEP contenant topologie, credentials, endpoints : fourni au tenant, conservé chiffré côté tenant.
• Bundle de restauration air-gap : image OCI + Helm chart + migrations SQL + runbooks sur support amovible signé (cf. ADR-012).

5. Runbooks opérationnels

Les runbooks détaillés des 10 incidents les plus critiques sont maintenus dans Runbooks on-call. Les runbooks spécifiques BCP/DR supplémentaires :

• RB-BCP-001 Failover région cross-AZ (procédure ci-dessus §4 scénario 2)
• RB-BCP-002 Restauration PostgreSQL PITR
• RB-BCP-003 Restauration S3 / MinIO avec Object Lock
• RB-BCP-004 Réhydratation cluster EKS depuis zéro via GitOps
• RB-BCP-005 Rotation d’urgence des secrets (compromission Vault)
• RB-BCP-006 Procédure activation bundle air-gap on-prem

6. Tests de continuité

Test	Fréquence	Responsable	Livrable
Restauration DB	Mensuel	SRE	Rapport RTO/RPO mesurés
Failover AZ (chaos)	Trimestriel	SRE	Rapport + post-mortem
Failover région cross-région	Semestriel	CTO + SRE	Rapport d’exercice + amélioration continue
Restauration bundle air-gap	Annuel	SRE + client pilote	Rapport + mise à jour procédure
Simulation breach ransomware	Annuel	CISO + consultant externe	Rapport + plan d’action
Exercice de table (comité crise)	Annuel	CEO + CISO + CTO + DPO + légal	Retour d’expérience

7. Gouvernance et communication de crise

7.1 Cellule de crise

Activée en cas d’incident majeur (SEV-1, risque public).

Composition : CEO (lead), CTO, CISO, DPO, Compliance Officer, Communications Lead (externe si besoin), Légal, Customer Success Lead.

7.2 Canaux

• Interne : channel Slack #crisis privé à la cellule + #all-hands pour communication employés.
• Clients tenants : email CSM + status page public status.vitakyc.io.
• Personnes concernées (breach) : email direct selon données contact dispo + affichage banneur produit.
• Régulateur : CNIL, INPDP, BCT via DPO.
• Presse / public : communiqué validé DG + juridique uniquement.

7.3 Check-list de communication de crise

• Factuel, pas de spéculation
• Timeline horodatée
• Impact précis (nb clients, catégories de données, durée)
• Mesures déjà prises + en cours
• Canal d’information pour suivi
• Coordonnées DPO
• Traduit FR + AR (pour clients MENA) + EN

8. Dépendances externes critiques à surveiller

Dépendance	Criticité	Mitigation
AWS (hyperscaler)	Critique	Multi-région + option GCP Paris pour V2
Cloudflare (CDN + WAF)	Élevée	Origin direct fallback + option Akamai en V2
ComplyAdvantage / Dow Jones	Élevée	Double sourcing contractuel
DocuSign / Yousign / TunTrust	Moyenne	Module SES natif + fallback manuel
DGI IDES (Tunisie)	Moyenne	Queue + retry + alerte client
RNE Tunisie	Moyenne	Fallback documentaire (capture + OCR)
GitLab (déploiement)	Moyenne	Git miroir GitHub + option runner auto-hosted
ANCE (certificats)	Moyenne	Plan renouvellement 60 j, multi-CA

9. Maintenance et évolution

• Revue annuelle de ce plan (prochaine 2027-04-22).
• Mise à jour à chaque changement d’architecture majeur (ajout région, changement DB, etc.).
• Intégration retex après chaque incident SEV-1/2.
• Approbation DG requise pour toute modification majeure.

---

Annexe — Coûts estimés

Poste	Coût mensuel indicatif	Notes
Région secondaire (standby warm)	~+40 % du coût primaire	Cluster sous-dimensionné activable en urgence
RDS cross-région read replica	+20 %	Synchronisation async
S3 Cross Region Replication	+~25 % stockage + transfert	Négligeable sur volumes MVP
MirrorMaker 2 (Kafka)	+~15 %	Optionnel, activé sur topics critiques
Exercices BCP (consultants externes)	~5 k€/an	Pen-test annuel + simulation ransomware
Temps engineering	~15 j/an SRE	Tests + runbooks + revues

Budget BCP/DR annuel indicatif : ~15-20 % du coût cloud global. À calibrer finement en V1.

---

Plan approuvé par CEO + CTO + CISO · prochain exercice complet de failover région programmé pour 2026-07.