Plan de sortie DORA : documenter et tester la réversibilité d'un SaaS
Votre client bancaire vous demande votre « exit strategy », votre plan de réversibilité ou la durée de votre période de transition. Voici ce que le règlement exige réellement, ce qui relève de votre client et ce qui relève de vous, et comment le prouver par un exercice.
Pour chaque service TIC qui soutient une fonction critique ou importante, DORA impose à l'entité financière une stratégie de sortie documentée, suffisamment testée et revue périodiquement (article 28, paragraphe 8), et un contrat qui prévoit une période de transition obligatoire (article 30, paragraphe 3, point f). L'éditeur SaaS n'écrit pas la stratégie de son client, mais il en fournit la matière : un export complet, des formats documentés, des délais mesurés et une assistance définie. La preuve la plus solide est un exercice de sortie réellement exécuté, avec un rapport daté.
Ce que DORA exige exactement
Quatre dispositions encadrent la sortie d'un prestataire TIC. Elles s'adressent à l'entité financière, mais chacune suppose une contribution de votre part.
- Article 28, paragraphe 8. Pour les services soutenant des fonctions critiques ou importantes, l'entité doit avoir des stratégies de sortie qui tiennent compte d'une défaillance du prestataire, d'une dégradation du service, d'une perturbation ou d'une résiliation. La sortie doit pouvoir se faire sans perturber l'activité, sans dégrader la conformité réglementaire et sans nuire au service rendu aux clients. Les plans de sortie doivent être complets, documentés, suffisamment testés et réexaminés périodiquement. L'entité doit aussi identifier des solutions de remplacement et des plans de transition.
- Article 30, paragraphe 3, point f. Le contrat doit prévoir une période de transition adéquate et obligatoire, pendant laquelle le prestataire continue à fournir le service, le temps de migrer vers un autre prestataire ou vers une solution interne adaptée à la complexité du service.
- Article 30, paragraphe 2, point d. Pour tous les contrats, l'accès, la récupération et la restitution des données dans un format facilement accessible doivent être garantis, y compris en cas d'insolvabilité, d'arrêt d'activité ou de fin de contrat.
- Règlement délégué (UE) 2024/1773, article 10. La politique de l'entité doit prévoir un plan de sortie documenté pour chaque contrat concerné, testé et revu périodiquement. Il doit couvrir les interruptions imprévues et persistantes, une prestation défaillante et une résiliation inattendue. Il doit être réaliste, faisable, fondé sur des scénarios plausibles, et comporter un calendrier de mise en œuvre compatible avec les clauses de sortie du contrat.
Le règlement ne fixe ni la durée de la période de transition, ni la fréquence des tests, ni un format de données. Ces points se négocient dans le contrat, et c'est précisément là que des chiffres mesurés vous donnent l'avantage.
Le règlement (UE) 2023/2854 sur les données (Data Act) encadre aussi, depuis le 12 septembre 2025, le changement de fournisseur de services de traitement de données, dont le SaaS : préavis maximal, période de transition, suppression progressive des frais de changement. Ses articles 23 à 31 peuvent s'ajouter aux exigences DORA. Faites vérifier leur application à vos contrats par votre juriste.
Stratégie de sortie, plan de sortie, réversibilité : qui fait quoi
Les trois termes circulent indifféremment dans les questionnaires. Ils ne désignent pas la même chose, et ne relèvent pas de la même partie.
| Élément | Qui en est responsable | Ce que l'éditeur apporte |
|---|---|---|
| Stratégie de sortie | L'entité financière (article 28, paragraphe 8) | Les informations pour évaluer la faisabilité et la durée d'une sortie |
| Plan de sortie par contrat | L'entité financière (règlement délégué 2024/1773, article 10) | Le déroulé technique de l'export et de la transition, avec des durées mesurées |
| Clause de transition | Les deux parties, dans le contrat (article 30, paragraphe 3, point f) | Une durée réaliste et le contenu précis de l'assistance |
| Restitution des données | L'éditeur, au titre du contrat (article 30, paragraphe 2, point d) | Une procédure d'export, des formats documentés, un export déjà réalisé |
| Test de la sortie | L'entité doit tester son plan ; elle a besoin de vous pour le faire | Un exercice de sortie exécuté et un rapport daté |
Ce que l'éditeur doit documenter
Un plan de réversibilité utile répond à une question simple : si le client part demain, que reçoit-il, sous quelle forme, en combien de temps, et avec quelle aide ? La liste ci-dessous sert de trame.
- Périmètre des données. Données métier, pièces jointes et fichiers, historiques, journaux d'audit, paramétrage, utilisateurs et droits. Indiquez ce qui est exclu, et pourquoi.
- Formats. Par exemple CSV ou JSON pour les tables, fichiers d'origine pour les pièces jointes, dump SQL si pertinent. Joignez le schéma et un dictionnaire des champs : un export illisible sans votre code n'est pas une restitution.
- Canal de remise. API d'export, export en masse, dépôt sur un stockage objet ou un serveur SFTP du client.
- Intégrité et confidentialité. Chiffrement en transit, empreintes de contrôle (SHA-256) et comptages par table fournis avec l'export.
- Délais. Délai de mise à disposition de l'export complet, mesuré sur un volume réaliste, et durée proposée pour la période de transition.
- Assistance de transition. Ce qui est inclus (exports intermédiaires, réponses techniques, maintien du service), son coût, fixé à l'avance, et l'interlocuteur.
- Sous-traitants concernés. Les fournisseurs qui détiennent une partie des données, sauvegardes comprises, et la façon dont leurs copies sont restituées ou supprimées.
- Suppression. Délai de suppression après la fin de la transition, sauvegardes incluses, et attestation remise au client.
Conduire un exercice de sortie
Un plan non testé reste une hypothèse. L'exercice consiste à exécuter la sortie pour de vrai, sur des données représentatives, sans toucher à la production du client.
- Choisir le périmètre. Un client volontaire ou un environnement qui reproduit un client réel en volume et en diversité de données. Fixez à l'avance les critères de réussite : complétude, exploitabilité, durée.
- Déclencher l'export par le canal prévu au contrat. Pas par une requête ad hoc d'un développeur. Chronométrez de la demande à la mise à disposition.
- Vérifier la complétude. Comparez les comptages par table et par type d'objet entre la source et l'export, contrôlez les pièces jointes et les empreintes.
- Vérifier l'exploitabilité. Réimportez l'export dans un environnement neutre, par exemple une base PostgreSQL vierge, à l'aide de la seule documentation fournie. Si l'équipe qui réimporte a besoin de poser des questions, notez-les : ce sont des manques de la documentation.
- Mesurer et consigner les écarts. Durées réelles, volumes, anomalies, données manquantes ou mal formées, corrections apportées en cours d'exercice.
- Tester la suppression, si le périmètre le permet. Sur un environnement de test, vérifiez que les données disparaissent aussi des sauvegardes au terme du délai annoncé.
Ce que contient le rapport d'exercice
Le rapport est la pièce que votre client joindra à son propre dossier. Il doit être lisible par un responsable des risques qui n'a pas assisté à l'exercice.
| Rubrique | Contenu |
|---|---|
| Identification | Date, version du service, environnement, participants, référence du contrat ou du plan de sortie testé |
| Périmètre | Données incluses et exclues, volume en lignes, fichiers et gigaoctets |
| Déroulé | Étapes horodatées, du déclenchement à la remise |
| Résultats mesurés | Durée de l'export, durée du réimport, taux de complétude par table, empreintes vérifiées |
| Écarts | Anomalies constatées, gravité, correction apportée ou date prévue |
| Conclusion | Critères de réussite atteints ou non, durée de transition réaliste qui en découle |
| Annexes | Schéma des données, dictionnaire, extraits de journaux, procédure utilisée |
Les erreurs les plus fréquentes
- Une clause de réversibilité qui renvoie à « un export dans un format standard » sans jamais avoir produit cet export.
- Un export qui contient les tables mais pas les pièces jointes, ou l'inverse.
- Une période de transition fixée au hasard, plus courte que le temps réellement nécessaire pour exporter et vérifier les données.
- Des copies de données oubliées chez un sous-traitant ou dans les sauvegardes.
- Un exercice réalisé une fois, il y a trois ans, sur une version du produit qui n'existe plus.
La sortie est souvent la question qui bloque un questionnaire DORA. Notre guide sur le questionnaire DORA fournisseur recense les autres questions types et la preuve qui répond à chacune.
Un exercice de sortie, exécuté et documenté pour vous. L'offre Complet de Reprisa (4 900 € HT) comprend l'export complet et vérifié des données d'un client, le test de restauration et les réponses rédigées au questionnaire de votre client. Le re-test annuel (1 500 € HT) rejoue l'exercice chaque année.
Voir l'offre DORAQuestions fréquentes
La stratégie de sortie DORA est-elle à la charge du fournisseur ?
Non. Le règlement impose la stratégie et les plans de sortie à l'entité financière (article 28, paragraphe 8). Mais l'entité ne peut ni les écrire ni les tester sans vous : elle a besoin de connaître vos formats, vos délais et votre assistance, et le contrat doit prévoir une période de transition (article 30, paragraphe 3, point f).
Quelle durée prévoir pour la période de transition ?
DORA ne fixe pas de durée : elle doit être adéquate et adaptée à la complexité du service. La seule base défendable est une durée déduite d'un exercice réel, en ajoutant le temps de migration de votre client. Si le Data Act s'applique à votre contrat, il impose ses propres plafonds, à faire vérifier par votre juriste.
Faut-il tester le plan de sortie chaque année ?
Le règlement demande des plans « suffisamment testés » et réexaminés périodiquement, sans fixer de fréquence. En pratique, de nombreux établissements demandent un test daté de moins d'un an, ou un nouveau test après un changement important du produit ou de l'architecture.
Quel format d'export DORA impose-t-il ?
Aucun format précis. L'article 30, paragraphe 2, point d, exige une restitution dans un format facilement accessible. Des formats ouverts et documentés, comme CSV ou JSON avec un schéma et un dictionnaire des champs, permettent de le démontrer.
Un exercice de sortie sur des données de test suffit-il ?
Il prouve que la procédure fonctionne, mais pas qu'elle tient la volumétrie d'un client réel. Le plus convaincant est un jeu de données représentatif en volume et en diversité, ou l'export d'un client volontaire dans un environnement isolé.
Peut-on facturer l'assistance à la réversibilité ?
DORA impose que l'assistance en cas d'incident soit gratuite ou à coût fixé à l'avance. Pour la sortie, il ne fixe pas de prix, mais votre client doit pouvoir l'anticiper dans son plan. Le Data Act encadre par ailleurs les frais de changement de fournisseur et prévoit leur suppression à partir du 12 janvier 2027 : à vérifier pour vos contrats.
Sources
- Règlement (UE) 2022/2554 (DORA), articles 28 et 30 — EUR-Lex, Journal officiel L 333 du 27.12.2022.
- Règlement délégué (UE) 2024/1773, article 10 — sortie et résiliation des accords contractuels — EUR-Lex.
- Règlement (UE) 2023/2854 (Data Act), chapitre VI — changement de services de traitement de données — EUR-Lex.
- ACPR — FAQ du webinaire DORA du 23 janvier 2026 — publiée le 20 mars 2026.
Textes consultés le 3 novembre 2026. En cas de divergence, seule la version publiée au Journal officiel de l'Union européenne fait foi.