---
name: "Modèle de stratégie de sortie et de plan de sortie DORA"
version: "1.0"
updated: "2026-07-23"
source: "https://www.orbiqhq.com/fr/modeles/modele-strategie-sortie-dora"
license: "Utilisation et adaptation libres au sein de votre organisation. Attribution appréciée. Ne constitue pas un conseil juridique."
legal_basis:
  - "https://eur-lex.europa.eu/eli/reg/2022/2554/oj"          # DORA — règlement (UE) 2022/2554 (art. 28(7), 28(8), 30(3)(f))
  - "https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj"      # RTS sur la politique en matière de prestataires tiers TIC (art. 10 — plans de sortie)
---

# Modèle de stratégie de sortie et de plan de sortie DORA (lisible par machine)

Objet : documenter et maintenir des stratégies de sortie conformes à DORA et des plans de
sortie par accord pour les services TIC soutenant des fonctions critiques ou importantes
(règlement (UE) 2022/2554, article 28(8) ; règlement délégué (UE) 2024/1773 de la Commission,
article 10). Ce fichier est autonome : un agent peut construire une stratégie de sortie au
niveau de l'entité, générer un enregistrement de plan de sortie par accord contractuel dans le
périmètre, et maintenir le journal de tests et de revues à partir des définitions ci-dessous.

Règle structurelle : UN enregistrement de plan de sortie par accord contractuel soutenant une
fonction critique ou importante (RTS, art. 10) — jamais un plan générique pour l'ensemble du
parc de prestataires. Les enregistrements de plan de sortie se rattachent au registre
d'informations via `contract_ref` (voir le fichier compagnon
dora-register-of-information-starter.md).

Résultats protégés (art. 28(8)) — toute sortie doit s'achever sans :
1. perturbation des activités de l'entreprise ;
2. limitation du respect des exigences réglementaires ;
3. préjudice pour la continuité et la qualité des services fournis aux clients.

Notes juridictionnelles : la Norvège applique l'art. 28(8) tel quel (loi norvégienne DORA en
vigueur depuis le 2025-07-01, Finanstilsynet ; plans attendus réalistes et régulièrement
testés). Le Royaume-Uni n'a pas de DORA, mais la PRA SS2/21 exige une stratégie de sortie
documentée et testée par accord d'externalisation matériel, distinguant sorties sous
contrainte et sorties planifiées — l'enum `trigger_class` ci-dessous couvre les deux régimes.

---

## 1. Stratégie de sortie (niveau entité) — un enregistrement

| # | Champ | Type | Définition / règle |
|---|---|---|---|
| 1 | `entity_legal_name` | texte | Dénomination sociale enregistrée |
| 2 | `entity_lei` | texte (LEI-20) | Identifiant d'entité juridique |
| 3 | `competent_authority` | texte | ANC (ACPR, AMF, BaFin, DNB, Finanstilsynet, …) |
| 4 | `strategy_owner` | texte (rôle) | Rôle responsable, p. ex. responsable de la gestion des risques tiers |
| 5 | `approval_body` | texte | Organe de direction ou comité + date d'approbation |
| 6 | `in_scope_contract_refs` | liste de `contract_ref` | Tous les accords soutenant des fonctions critiques ou importantes (art. 3(22)) ; doit correspondre au registre d'informations |
| 7 | `risk_scenarios` | liste fixe | DOIT couvrir : `provider_failure`, `quality_deterioration`, `business_disruption`, `material_deployment_risk`, `art_28_7_termination` (art. 28(8), premier alinéa) |
| 8 | `substitutability_scale` | définition d'enum | p. ex. `easily_substitutable` / `substitutable_with_effort` / `difficult` / `not_substitutable` — à aligner sur les évaluations B_07 du RoI |
| 9 | `market_scan_cadence` | texte | Fréquence de réévaluation des alternatives par catégorie de service |
| 10 | `review_cadence` | texte | Au moins annuelle + à chaque changement significatif |
| 11 | `last_review` / `next_review` | date (ISO 8601) | Dates de revue de la stratégie |

## 2. Plan de sortie — un enregistrement PAR accord

### 2.1 Identification

| # | Champ | Type | Définition / règle |
|---|---|---|---|
| 1 | `contract_ref` | texte, unique | CLÉ PRIMAIRE — doit exister dans le registre d'informations (B_02) |
| 2 | `provider_legal_name` | texte | Prestataire tiers de services TIC |
| 3 | `provider_id` | texte | LEI ou EUID (personnes morales de l'UE) ; LEI (personnes morales de pays tiers) |
| 4 | `ict_service_type` | enum `S01`–`S19` | Liste fermée selon l'annexe III de l'ITS (UE) 2024/2956 |
| 5 | `cif_supported` | texte | Fonction critique ou importante soutenue + référence du raisonnement art. 3(22) |
| 6 | `plan_owner` | texte (rôle) | Maintient le plan |
| 7 | `activation_decision_maker` | texte (rôle/comité) | Habilité à déclencher la sortie |
| 8 | `plan_version` / `plan_date` | texte / date | Gestion de versions |

### 2.2 Déclencheurs

| # | Champ | Type | Définition / règle |
|---|---|---|---|
| 1 | `trigger_class` | enum : `planned` / `stressed` | Sous contrainte = défaillance/insolvabilité ou circonstance de l'art. 28(7) ; satisfait aussi la distinction stressed/non-stressed de la PRA SS2/21 |
| 2 | `planned_triggers` | liste de texte | p. ex. expiration du contrat sans renouvellement, réinternalisation stratégique |
| 3 | `stressed_triggers` | liste d'enum | `provider_insolvency` / `art_28_7_a_breach` / `art_28_7_b_monitoring_findings` / `art_28_7_c_ict_risk_weaknesses` / `art_28_7_d_supervisability` / `ctpp_oversight_recommendation` |
| 4 | `trigger_indicators` | liste de texte | KRI faisant remonter chaque déclencheur (nombre de manquements aux SLA, fréquence des incidents, signaux de santé financière) |

### 2.3 Solution alternative

| # | Champ | Type | Définition / règle |
|---|---|---|---|
| 1 | `alternatives_assessed` | liste de {name, assessed_date, result} | Prestataires alternatifs évalués |
| 2 | `inhouse_option` | {feasible: booléen, notes} | Évaluation de la réintégration en interne (art. 28(8), quatrième alinéa) |
| 3 | `selected_route` | enum : `alternative_provider` / `in_house` / `hybrid` | Voie de sortie retenue |
| 4 | `substitutability` | enum selon l'échelle de la stratégie | Cotation actuelle |

### 2.4 Plan de transition

| # | Champ | Type | Définition / règle |
|---|---|---|---|
| 1 | `phases` | liste ordonnée de {phase, duration, description} | Typique : préparation → migration des données → fonctionnement en parallèle → bascule → décommissionnement |
| 2 | `data_inventory` | liste de {dataset, volume, location} | Données détenues par le prestataire |
| 3 | `data_return_format` | texte | Format(s) d'export convenus — garantis contractuellement |
| 4 | `secure_transfer_method` | texte | Mécanisme + chiffrement en transit + vérification d'intégrité (« transférer de manière sûre et intègre », art. 28(8)) |
| 5 | `parallel_run_window` | texte | Durée + critères de succès |
| 6 | `rollback_criteria` | texte | Conditions de retour arrière après bascule |
| 7 | `closure_steps` | liste de texte | Confirmation de suppression, révocation des accès, mise à jour du RoI |

### 2.5 Ancrages contractuels

| # | Champ | Type | Définition / règle |
|---|---|---|---|
| 1 | `transition_period` | texte | Période de transition adéquate obligatoire selon l'art. 30(3)(f) |
| 2 | `notice_period_entity` / `notice_period_provider` | entier (jours) | Préavis de résiliation |
| 3 | `data_return_clauses` | texte | Références des clauses + formats garantis |
| 4 | `transition_assistance` | texte | Obligations d'assistance à la migration du prestataire, coûts inclus |
| 5 | `schedule_fit` | booléen | RÈGLE : le total des durées de `phases` DOIT tenir dans `transition_period` ; si faux → chantier de remédiation contractuelle, plan non exécutable |

### 2.6 Contingence, coûts, gouvernance

| # | Champ | Type | Définition / règle |
|---|---|---|---|
| 1 | `contingency_measures` | liste de texte | Mesures provisoires de continuité pendant la sortie (art. 28(8), dernier alinéa) |
| 2 | `client_impact_mitigation` | texte | Protection de la continuité/qualité des services aux clients |
| 3 | `compliance_safeguards` | texte | Reporting, continuité de la protection des données, conservation pendant la migration |
| 4 | `exit_cost_estimate` | nombre + devise | Coût unique de migration + frais d'assistance à la transition |
| 5 | `resourcing` | texte | Équipes, semaines-ETP, dépendances aux personnes clés |

## 3. Journal de tests et de revues — enregistrements en ajout seul

| # | Champ | Type | Définition / règle |
|---|---|---|---|
| 1 | `test_date` | date (ISO 8601) | |
| 2 | `contract_ref` | texte | Accord testé |
| 3 | `scenario` | enum : `unforeseen_interruption` / `persistent_interruption` / `provider_insolvency` / `quality_deterioration` / `planned_exit` / autre | RTS, art. 10 : les tests DOIVENT prendre en compte les interruptions de service imprévues et persistantes |
| 4 | `test_type` | enum : `tabletop` / `walkthrough` / `partial_data_extraction` / `restore_verification` / `full_simulation` | Accords les plus critiques : inclure de vrais tests d'extraction de données |
| 5 | `participants` | liste de texte | |
| 6 | `findings` | texte | p. ex. débit d'export inférieur à l'hypothèse |
| 7 | `remediation` | {actions, closed_date} | Mises à jour du plan qui en résultent |
| 8 | `next_test` | date | Règle de cadence : au moins un test par accord et par cycle de revue ; fréquence fondée sur le risque |

## 4. Runbook d'activation (séquence)

1. `declare` — le décideur confirme le déclencheur, déclare la sortie (planifiée/sous contrainte), consigne la décision + l'heure
2. `notify` — parties prenantes internes ; prestataire (préavis contractuel) ; autorité compétente le cas échéant ; clients selon le plan
3. `freeze` — geler les changements de périmètre ; figer un instantané des données ; revalider l'inventaire des données
4. `execute` — dérouler les phases de transition dans la fenêtre de l'art. 30(3)(f) ; activer les mesures de contingence si nécessaire
5. `verify` — données restituées au format convenu ; intégrité vérifiée ; suppression confirmée par le prestataire ; accès révoqués
6. `close` — mettre à jour le registre d'informations ; revue post-sortie ; réinjecter les enseignements dans la stratégie et les autres plans

## 5. Exemple d'enregistrement (fictif, abrégé)

```yaml
contract_ref: CTR-2024-018
provider_legal_name: CloudCore GmbH
ict_service_type: S17
cif_supported: "Traitement des paiements de détail (critique, RoI B_06.01)"
trigger_class: stressed
stressed_triggers: [provider_insolvency, art_28_7_c_ict_risk_weaknesses]
selected_route: alternative_provider   # HanseCloud AB, évalué 2026-03
phases:
  - {phase: preparation, duration: 4w}
  - {phase: data_migration, duration: 6w}   # replanifié 4w→6w après le test d'extraction du 2026-04-22
  - {phase: parallel_run, duration: 4w}
  - {phase: cutover, duration: 1w}
  - {phase: decommission, duration: 3w}
transition_period: "24 mois à compter du préavis de résiliation"
schedule_fit: true
data_return_format: "Dumps PostgreSQL + export objet compatible S3, AES-256 en transit, manifestes SHA-256"
contingency_measures: ["File d'attente de paiements en mode dégradé via site secondaire, RTO 4 h"]
last_test: {date: 2026-04-22, scenario: persistent_interruption, test_type: partial_data_extraction}
```