Test schedule

Calendrier des tests DR

Principe

Tier 2 BCMS-grade exige au moins 1 test annuel par procédure critique. Notre stratégie répartit les tests sur 4 trimestres pour éviter la saturation et garantir une couverture continue.

Chaque test produit un procès-verbal dans docs/dr/test-results/ (template templates/post-incident-report.md).

Calendrier annuel

Q1 — janvier-mars

Test : Restauration PostgreSQL PITR

• Runbook : 01-restore-postgres-pitr.md
• Environnement : pré-prod (jamais sur prod)
• Cible : restore vers target-time = NOW() - 1 hour puis pg_promote()
• Validation : smoke-after-restore.sh OK + chain Ed25519 valid
• Durée prévue : 2 heures
• Procès-verbal : docs/dr/test-results/YYYY-Q1-postgres-pitr.md

Q2 — avril-juin

Test : Restauration Vault depuis snapshot raft

• Runbook : 02-restore-vault-from-snapshot.md
• Environnement : pré-prod
• Cible : démarrer Vault from-scratch + restore snapshot J-1 + unseal Shamir
• Validation : vault status sealed=false + AppRole login OK + secrets accessibles
• Durée prévue : 1 heure
• Procès-verbal : docs/dr/test-results/YYYY-Q2-vault-restore.md

Q3 — juillet-septembre

Test : Rotation Shamir + récupération enveloppe trustee

• Runbook : 06-rotate-shamir-keys.md
• Environnement : pré-prod (rotation simulée), prod (récupération enveloppe trustee + re-scellage)
• Cible : vault operator rekey + nouvelles 5 shares + dépôt enveloppe notaire
• Validation : Vault unseal avec nouvelles shares fonctionne + procès-verbal notaire signé
• Durée prévue : 4 heures (incl. RDV notaire)
• Coût : ~50-100€ (acte simple)
• Procès-verbal : docs/dr/test-results/YYYY-Q3-shamir-rotation.md

Q4 — octobre-décembre

Test : Exercice incident complet en mode “blanc”

• Runbook : 05-recover-from-ransomware.md + tous les IR
• Environnement : env de test isolé (pas pré-prod, pas prod)
• Cible : simulation ransomware end-to-end, incl. rédaction notif CSIRT-FR + CNIL fictives
• Validation : 7 phases parcourues, MTTR < 12h, notifs rédigées en <24h fictives
• Durée prévue : 1 journée (8h consolidées)
• Procès-verbal : docs/dr/test-results/YYYY-Q4-incident-blanc.md

Tests mensuels (smoke checks)

En complément du cycle trimestriel, le 1er samedi de chaque mois :

• Restore partial artifacts : 1 client random, restore depuis backup vers env de test
• Verify chain audit log : trigger via UI, vérifier valid: true
• Verify Sentry monitor heartbeats : vérifier que tous les jobs DR ont check-in OK les 7 derniers jours

Durée : 30 minutes / mois. Procès-verbal abrégé dans docs/dr/test-results/YYYY-MM-monthly-smoke.md.

Tests automatiques quotidiens

Sans intervention humaine, les vérifications suivantes tournent en continu :

Test	Fréquence	Source
dr-verify smoke check	Daily 06:30 UTC	ofelia → dr-runner
GitLab CI dr:verify	Daily 07:00 UTC	OIDC WIF + restic check
Sentry monitor check-ins	Real-time	Backup scripts via sentry_check_in()
Audit chain integrity	Daily (worker)	audit-chain-worker.ts
Anchor signing	Daily 23:00 UTC	audit-chain-worker.ts

Échec de l’un déclenche alerte Sentry + email DR Owner immédiat.

Tests à l’occasion (ad-hoc)

Déclencheur	Test à effectuer
Mise à jour Vault majeure (X.Y → X.Y+1)	Test runbook 02 sur env de test avant déploiement prod
Mise à jour pgbackrest	Test runbook 01 sur env de test
Nouveau fournisseur S3	Test pull/push depuis dr-runner
Recrutement 1er salarié	Test transmission keyholders (si élargissement Shamir)

Engagement annuel

Volume total : 5 tests (1 mensuel × 12 mois + 4 trimestriels) = ~30 procès-verbaux/an.

Effort total : ~12-15 jours-homme/an. Tenable solo.

Reporting annuel

Synthèse annuelle dans docs/dr/test-results/YYYY-annual-summary.md :

• Liste de tous les tests exécutés
• Taux de succès / échec
• MTTR moyen mesuré
• Tests qui ont dépassé leur RTO cible (et pourquoi)
• Actions correctives mises en œuvre
• Sujets pour la roadmap N+1

À montrer en RFP client : preuve concrète de la maturité Tier 2.

Version	Date	Auteur
1.0	2026-04-26	Nicolas Schiffgens