# RTO / RPO — Objectifs de reprise après sinistre

> **Document de travail.** Brouillon commercial à relire par un avocat IT et RGPD avant signature. Aucune valeur contractuelle en l'état.
>
> **Objectifs établis sur la base de la stack actuelle.** Les engagements contractuels RTO/RPO opposables nécessitent la signature d'un contrat dédié (typiquement un contrat Enterprise avec clause Business Continuity).

**Version** : v1 — 2026-05-24
**Référentiels** : DORA art. 11 (politique de continuité et de résilience opérationnelle numérique) + ISO 22301 (continuité d'activité).
**Éditeur** : Amir KELLOUSIDHOUM AE, SIRET 917 709 024 00017
**Contact** : [security@getscope.dev](mailto:security@getscope.dev)

---

## 1. Définitions

- **RTO (Recovery Time Objective)** : durée maximale visée entre la déclaration d'un sinistre majeur et la reprise opérationnelle du service.
- **RPO (Recovery Point Objective)** : antériorité maximale des données récupérables après un sinistre (mesure la perte de données admissible).
- **MTPD (Maximum Tolerable Period of Disruption)** : durée d'interruption au-delà de laquelle l'activité du Client devient sérieusement compromise. À déterminer conjointement avec le Client.

## 2. Objectifs visés

| Métrique | Objectif | Périmètre | Statut |
|---|---|---|---|
| **RTO** | **4 heures** en heures ouvrées France (lundi-vendredi 9h-18h CET) | Service applicatif Scope dans son ensemble | Objectif visé, non contractuel |
| **RPO** | **24 heures** maximum | Données client (Postgres + Storage) | Objectif visé, non contractuel |
| **RTO hors heures ouvrées** | Best effort, typiquement 12h | Service applicatif | Non engagé |
| **MTPD** | À définir par contrat | Variable selon le Client | Non engagé sans contrat |

> *MTPD : à définir conjointement avec le Client lors de la contractualisation. Pour un cas d'usage cadrage projet (non critique au sens DORA art. 11 §4), l'objectif RTO 4h en heures ouvrées couvre la majorité des situations attendues. [En cours de validation juridique — version pilote, formulation susceptible d'évoluer avec un avocat IT/RGPD]*

## 3. Justification de l'objectif RTO 4h en heures ouvrées

L'objectif **RTO 4h** est justifié par la stack technique actuelle :

### 3.1 Hébergement applicatif — Railway
- **Failover automatique edge** : les fonctions serverless Railway sont réparties sur de multiples points de présence. Un POP en panne est automatiquement basculé.
- **Région EU West (Union européenne)** : les fonctions applicatives sont pinned sur EU West. En cas de panne complète de la région, basculage manuel possible vers une autre région UE.
- **Délai de bascule manuelle** : ~30 minutes (modification de la configuration Railway + redéploiement automatique).

### 3.2 Base de données — Supabase
- **Multi-AZ Dublin (`eu-west-1`)** : la base Postgres et le Storage sont répliqués sur plusieurs Availability Zones de la région.
- **Point-In-Time Recovery (PITR)** : Supabase conserve un journal de transactions permettant la restauration à n'importe quel point dans le temps des **7 derniers jours** sur le plan Pro (à activer — voir §6).
- **Délai de restauration PITR** : variable selon le volume, typiquement 1-2 heures pour une base de taille moyenne (< 10 GB).

### 3.3 Signature électronique — DocuSeal auto-hébergé
- **Railway EU West** : redondance native du fournisseur d'hébergement.
- **Backups automatiques** : Railway volumes persistants + sauvegardes Railway.

### 3.4 Sous-traitants tiers
- **OpenRouter (routeur LLM) → OpenAI + Anthropic (US, sous CCT UE)** : pas de SLA propre côté Scope. Une panne LLM amont rend le pipeline IA temporairement indisponible mais ne corrompt aucune donnée existante. L'option Enterprise UE-résident (Bedrock Paris, Mistral FR) en cours de validation roadmap héritera des SLA Bedrock / Mistral lorsqu'elle sera activée par client.
- **Stripe Dublin** : SLA 99,99 % public.
- **Resend** : SLA 99,9 % public.
- **GlitchTip** : non critique, sa panne dégrade le monitoring mais pas le service.

**Calcul cumulé** : dans le scénario le plus défavorable (panne de la région Supabase Dublin et nécessité de PITR), le RTO total reste **dans la cible 4h**, sous réserve que l'incident soit détecté dans l'heure (cf. [`./incident-response.md`](./incident-response.md)).

## 4. Justification de l'objectif RPO 24h

L'objectif **RPO 24h** est justifié par :

### 4.1 PITR Supabase
- **Rétention 7 jours** sur le plan Pro (configurable jusqu'à 28 jours sur Enterprise Supabase).
- **Restauration au point-in-time près à la seconde**.
- En cas de corruption détectée tardivement, la restauration au point antérieur à la corruption est possible dans la fenêtre des 7 derniers jours.

### 4.2 Snapshots quotidiens Supabase
- **Snapshots automatiques quotidiens** côté Supabase. Conservés 7 jours.
- **Storage** (briefs, audio, exports) répliqué automatiquement multi-AZ Dublin.

### 4.3 Implication
Dans le scénario le plus défavorable (perte totale de la base), la **perte maximale est de 24 heures** (jusqu'au dernier snapshot). Le PITR ramène généralement la perte à **moins de quelques minutes** si la détection est rapide.

## 5. Plan de continuité d'activité (PCA)

### 5.1 Détection
- **Monitoring auto** : GlitchTip + audit logs (cf. [`./incident-response.md`](./incident-response.md) §2.1).
- **Uptime check externe** : TODO — à câbler avec UptimeRobot ou Pingdom avant 1er RDV AXA (cf. [`./slo-decouverte-poc.md`](./slo-decouverte-poc.md) §6).
- **Signalement utilisateur** : email à [support@getscope.dev](mailto:support@getscope.dev).

### 5.2 Procédure de bascule

À la date du présent document, **le plan de bascule complet n'est pas formellement documenté en runbook opérationnel**. La procédure est implicite :

1. **Détection** par GlitchTip + uptime check (à câbler) + signalement.
2. **Évaluation** par le founder : nature du sinistre, ampleur, sous-système concerné.
3. **Action selon nature** :
   - **Panne Railway EU West** : redéploiement manuel sur une autre région UE Railway. Modification de la configuration Railway + push.
   - **Panne Supabase Dublin** : PITR restoration sur un nouveau projet Supabase, puis basculement de la `DATABASE_URL` côté Railway.
   - **Panne OpenRouter** : aucune action immédiate — le service reste accessible en lecture, le pipeline LLM est dégradé. Communication aux utilisateurs.
   - **Panne DocuSeal** : restoration du service depuis Railway volumes persistants + sauvegardes Railway.
4. **Communication** : email aux administrateurs + status page (à créer).
5. **Post-mortem** : cf. [`./incident-response.md`](./incident-response.md) §6.

Une procédure runbook step-by-step (`docs/runbooks/disaster-recovery.md`) est en cours de formalisation et peut être communiquée sur demande dans le cadre d'un contrat Enterprise.

### 5.3 Test de bascule annuel

**Recommandé** : exercice de test de bascule **annuel**, simulant les principaux scénarios :
- Panne Railway EU West.
- Restauration PITR Supabase d'une base test.
- Panne DocuSeal.

Le premier exercice annuel sera planifié post-design partner ; le résultat sera communiqué aux Clients qui en feront la demande dans le cadre d'un contrat Enterprise.

## 6. Site secondaire et redondance

### 6.1 Site secondaire physique
**Scope ne dispose pas de site secondaire physique en propre.** La redondance est assumée via la redondance native des fournisseurs cloud EU :

- **Railway** : edge network global + région EU West primaire, basculage manuel possible vers une autre région UE Railway.
- **Supabase** : multi-AZ Dublin (`eu-west-1`) par défaut. Replicas cross-region en option sur le plan Enterprise (non activé à ce jour).
- **DocuSeal** : Railway EU West avec volumes persistants + sauvegardes Railway.

### 6.2 Roadmap redondance Enterprise

| Niveau | Stack | Disponible quand | Coût marginal mensuel |
|---|---|---|---|
| **Phase Découverte/PoC actuelle** | Railway free + Supabase free | Maintenant | 0 € |
| **Phase PoC payant** | Railway Pro + Supabase Pro + uptime check Pingdom Pro | Sur engagement contractuel | ~150-200 € |
| **Enterprise** | Railway Enterprise + Supabase Enterprise (replicas cross-region) + monitoring externe Pro | Sur contrat Enterprise | ~1000-2000 € + Supabase à négocier |

## 7. Engagement de communication

En cas de **sinistre majeur** (RTO > 1h dépassé), Scope s'engage à :

1. **Communiquer dans l'heure** un statut initial aux administrateurs des organisations affectées via Resend.
2. **Mise à jour toutes les 2 heures** jusqu'à résolution.
3. **Post-mortem public** dans les 7 jours suivant la résolution.

Cet engagement est de **meilleurs efforts** pendant la phase Découverte/PoC. Il devient contractuel sur engagement Enterprise.

## 8. Périmètre des objectifs

| Composant | RTO visé | RPO visé | Notes |
|---|---|---|---|
| **Application Scope (web + API)** | 4h HO | 24h | Stack Railway + Supabase EU |
| **Pipeline IA (LLM)** | Best effort | N/A (pas de persistance side OpenRouter) | Dépendance OpenRouter → OpenAI + Anthropic (US, CCT UE) ; option Enterprise UE-résident Bedrock Paris / Mistral FR en validation roadmap |
| **Signature électronique DocuSeal** | 4h HO | 24h | Railway EU West + volumes persistants + sauvegardes Railway |
| **Emails transactionnels** | Best effort | N/A | Dépendance Resend |
| **Paiement Stripe** | Best effort | N/A | Dépendance Stripe (99,99% SLA public) |
| **Monitoring erreurs GlitchTip** | Best effort | N/A | Non critique, dégrade le monitoring mais pas le service |

## 9. Hypothèses et limites

Cet objectif RTO/RPO repose sur les hypothèses suivantes, dont le manquement peut conduire à un dépassement :

1. **Le founder est disponible** dans les 30 minutes suivant la détection en heures ouvrées. Indisponibilité = dépassement RTO.
2. **Les sous-traitants (Railway, Supabase) sont opérationnels** au moins partiellement. Une panne simultanée de plusieurs sous-traitants majeurs (scénario extrêmement improbable mais possible) repousse le RTO.
3. **Aucune corruption silencieuse** non détectée n'est intervenue dans la fenêtre PITR. Si une corruption datant de plus de 7 jours est découverte, le RPO devient celui du dernier snapshot exploitable (typiquement 7j).
4. **La connectivité internet du founder est opérationnelle** pour piloter le PCA.

> *Les hypothèses ci-dessus seront listées comme exclusions de SLA dans tout contrat Enterprise mentionnant des objectifs contractuels, conformément à la pratique de marché (cf. Stripe SSA, AWS SLA). [En cours de validation juridique — version pilote, formulation susceptible d'évoluer avec un avocat IT/RGPD]*

---

## Renvois utiles

- **Incident Response** : [`./incident-response.md`](./incident-response.md)
- **Exit Plan** : [`./exit-plan.md`](./exit-plan.md)
- **SLO Découverte/PoC** : [`./slo-decouverte-poc.md`](./slo-decouverte-poc.md)
- **DPA Scope** : [`./dpa-template.md`](./dpa-template.md) Annexe 2 (sauvegardes)
- **Subprocessors** : [`./subprocessors.md`](./subprocessors.md)
- **Architecture data-flow** : [`./architecture-data-flow.md`](./architecture-data-flow.md)

---

*Document `rto-rpo.md` v1 — 2026-05-24 — à relire par avocat IT/RGPD avant signature. Objectifs non contractuels, **DORA art. 11 + ISO 22301** comme référentiels.*