1. Objectifs

Le présent document définit :

• Le Plan de Continuité d'Activité (PCA) — mesures préventives pour maintenir le service en condition opérationnelle ;
• Le Plan de Reprise d'Activité (PRA) — procédures de retour à l'état nominal après un sinistre.

2. Périmètre

Le PCA / PRA couvre :

• L'application web MIBsoft (frontend Vercel) ;
• La base de données et le stockage (Supabase Frankfurt) ;
• Les services connexes : Auth, Storage, Edge Functions, emails (Resend), paiements (Stripe) ;
• Les processus internes (support client, communication de crise).

3. Plan de Continuité d'Activité (PCA)

3.1 Haute disponibilité de l'infrastructure

• Frontend Vercel : déploiement multi-régions (Edge Network mondial), bascule automatique en cas de défaillance d'un POP ;
• Supabase : architecture managée AWS multi-AZ (zones de disponibilité multiples au sein de la région eu-central-1), redondance automatique ;
• DNS : TTL court, basculement DNS prêt en cas de migration urgente.

3.2 Sauvegardes

• Point-In-Time Recovery (PITR) Supabase : restauration à n'importe quel instant des 7 derniers jours ;
• Backups quotidiens automatiques chiffrés ;
• Snapshots stockés en cross-region sur l'infra AWS de Supabase pour résilience régionale ;
• Test de restauration trimestriel sur environnement isolé.

3.3 Monitoring et alerting

• Supervision Supabase (santé DB, latence, requêtes) ;
• Supervision Vercel (uptime, temps de réponse, erreurs 5xx) ;
• Alerting sur seuils critiques : SMS / email vers astreinte technique ;
• Page de statut publique (à mettre en place — status.mibsoft.fr).

3.4 Astreinte

• Astreinte technique 7j/7 pour les incidents P1 (service indisponible) ;
• Délai de prise en charge : 30 min en heures ouvrées, 1 h hors heures ouvrées ;
• Liste des contacts dans la section 6.

4. Plan de Reprise d'Activité (PRA)

4.1 Procédure générique de reprise

1. Détection — alerte automatique ou signalement client ;
2. Qualification — par le responsable d'astreinte (P1 à P4) ;
3. Mobilisation — cellule de crise (P1 : direction + tech, P2 : tech) ;
4. Confinement — isolement du périmètre impacté, communication initiale ;
5. Restauration — selon scénario (cf. infra) ;
6. Validation — tests fonctionnels avant remise en production ;
7. Communication — notification clients, mise à jour statut ;
8. Retour d'expérience (post-mortem) — sous 7 jours pour les P1.

4.2 Scénarios et procédures

Scénario 1 — Indisponibilité Supabase (hébergeur DB)

• Cause possible : panne AWS eu-central-1, incident Supabase global ;
• Première étape : vérifier status.supabase.com et status AWS ;
• Procédure : afficher page de maintenance frontend, communiquer aux clients via email/statut, suivre la résolution upstream ;
• RTO : dépend du fournisseur — historique : 99,9 % uptime Supabase ;
• Plan de secours envisagé à terme : migration vers projet Supabase de secours dans une autre région UE (à l'étude).

Scénario 2 — Corruption de la base de données

• Cause possible : bug applicatif, fausse manipulation, attaque ciblée ;
• Procédure :
  1. Identifier l'horodatage juste avant la corruption ;
  2. Geler les écritures (mode maintenance) ;
  3. Restaurer via PITR à T-X minutes/heures (interface Supabase) ;
  4. Vérifier l'intégrité des données ;
  5. Communiquer aux clients sur les éventuelles données perdues entre T et l'incident.
• RTO : 2-4 h ; RPO : 5 min à 24 h selon timing.

Scénario 3 — Attaque cyber (intrusion, ransomware, déni de service)

• Voir la procédure incidents détaillée ;
• Mesures immédiates : isolation (révocation tokens, rotation secrets), analyse forensique, notification CNIL si données personnelles compromises (sous 72 h) ;
• Restauration depuis backup sain ;
• Communication crise transparente avec les clients.

Scénario 4 — Indisponibilité Vercel (frontend)

• Vercel dispose d'un Edge Network multi-régions très résilient ;
• En cas d'indisponibilité globale Vercel : mise à disposition d'un domaine de secours Cloudflare Pages avec le même build (déploiement préalablement préparé), bascule DNS ;
• RTO cible : 1-2 h pour la bascule frontend.

Scénario 5 — Incendie / sinistre des locaux MIB

• Impact : limité, l'infrastructure de production est intégralement dans le cloud ;
• Conséquences : perte des postes de travail, des supports physiques ;
• Procédure : tous les collaborateurs disposent de postes portables chiffrés avec sauvegarde cloud, possibilité de télétravail immédiat depuis n'importe quel site ;
• Postes de remplacement commandés sous 48 h.

Scénario 6 — Défaillance Stripe (paiements)

• Acceptation temporaire des paiements par virement uniquement ;
• Communication aux clients ;
• Pas d'impact sur l'usage du service par les clients déjà à jour.

Scénario 7 — Défaillance Resend (emails)

• Bascule vers fournisseur de secours (configuration préalable possible : SendGrid, Postmark) ;
• Les emails critiques (reset mot de passe, factures) peuvent transiter par un secours technique sous 4 h.

5. Communication de crise

• Canal principal : email à l'administrateur de chaque centre client actif ;
• Canal complémentaire : page de statut publique (status.mibsoft.fr — à mettre en place) ;
• Template de communication initiale disponible en annexe de la procédure incidents ;
• Délai d'information : 1 h après confirmation d'un incident P1.

6. Cellule de crise — Coordonnées

• Directeur de crise : [À COMPLÉTER : nom + téléphone]
• RSSI : [À COMPLÉTER : nom + téléphone]
• Responsable technique : [À COMPLÉTER : nom + téléphone]
• DPO : dpo@mibsoft.fr
• Astreinte 24/7 : [À COMPLÉTER : numéro d'astreinte]
• Support Supabase Enterprise : selon contrat support actif
• Support Vercel : selon contrat support actif

7. Tests du PCA / PRA

Le présent plan fait l'objet de tests réguliers :

• Tests de restauration backup : trimestriels, sur environnement isolé ;
• Exercice complet PRA : annuel — simulation d'un sinistre majeur (Supabase indisponible 4 h) avec mobilisation de la cellule de crise ;
• Exercice de communication : annuel ;
• Revue documentaire : annuelle ou suite à incident significatif.

Le rapport de chaque test (synthèse anonymisée) est disponible sur demande sous NDA.

8. Améliorations continues

Chaque incident significatif donne lieu à un retour d'expérience (post-mortem) et à des actions correctives priorisées dans le backlog technique. Le suivi des actions est revu lors du comité sécurité trimestriel.