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 (Mailgun), 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 ;
• Sauvegarde hors-site quotidienne chez un fournisseur distinct (Backblaze B2, région UE) : archive chiffrée en AES-256 avant l'envoi, déchiffrée et relue à chaque exécution pour vérifier qu'elle est restaurable, conservée 30 jours. Elle permet de tout restaurer même si l'accès à Supabase est perdu ;
• 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 mensuel et automatisé : la dernière archive est téléchargée, déchiffrée et restaurée dans une base PostgreSQL jetable, puis les lignes sont comptées. Le résultat, réussite comme échec, remonte dans la supervision de l'espace d'administration.

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 Mailgun (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 : Michel Boyer, Président — direction@mibsoft.fr
• RSSI : fonction assurée par la direction — security@mibsoft.fr
• Responsable technique : support@mibsoft.fr
• DPO : dpo@mibsoft.fr
• Signalement : par courriel à support@mibsoft.fr et depuis le panneau d'aide de l'application. Il n'existe pas d'astreinte téléphonique — les signalements sont relevés aux heures ouvrées. [Fixer la plage horaire et le délai de prise en charge annoncés]
• 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 : mensuels et automatisés, sur base jetable ;
• 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.