Résilience opérationnelle, dépendance aux tiers et désengagement contrôlé
Introduction
DORA Article 28 exige des entités financières qu’elles gèrent les risques découlant des prestataires de services ICT tiers, y compris les plateformes cloud, les fournisseurs CI/CD SaaS, les registres d’artefacts et autres services numériques critiques.
Une exigence centrale — et souvent sous-estimée — est la capacité à quitter un arrangement avec un tiers sans perturber les opérations critiques.
La stratégie de sortie n’est pas seulement une clause contractuelle.
C’est une capacité opérationnelle testée intégrée dans l’architecture, la gouvernance et la planification de reprise après sinistre.
Cet article explique :
- Ce que DORA Article 28 attend en matière de stratégies de sortie
- Comment la capacité de sortie se connecte au DR (Disaster Recovery) et au BCP (Business Continuity Planning)
- Comment tester la préparation à la sortie dans les environnements dépendants du CI/CD et du cloud
- Ce que les auditeurs et régulateurs évalueront
1. Pourquoi la stratégie de sortie est une exigence DORA fondamentale
Sous DORA, les entités financières doivent :
- Éviter un risque de concentration excessif
- Assurer la continuité des fonctions critiques
- Maintenir la capacité de résilier les contrats ICT en toute sécurité
- Empêcher le verrouillage fournisseur de compromettre la résilience
Une stratégie de sortie garantit que :
- La défaillance d’un prestataire ne paralyse pas la livraison
- La résiliation d’un contrat ne casse pas les opérations
- Un incident cyber chez un fournisseur ne se propage pas en perturbation systémique
La préparation à la sortie est donc un contrôle de résilience, pas seulement une clause d’approvisionnement.
2. Stratégie de sortie vs Disaster Recovery vs Business Continuity
Ces concepts sont liés mais distincts :
Stratégie de sortie
Désengagement contrôlé d’un prestataire tiers et transition vers une solution alternative.
Disaster Recovery (DR)
Restauration des systèmes et services après une perturbation.
Business Continuity Planning (BCP)
Maintien des fonctions métier critiques pendant et après les perturbations.
Sous DORA Article 28, la stratégie de sortie croise le DR et le BCP lorsque :
- Un fournisseur cloud devient indisponible
- Une plateforme CI/CD SaaS est compromise
- Un prestataire ICT critique fait défaut ou est sanctionné
- La résiliation d’un contrat nécessite une migration
La capacité de sortie doit donc être techniquement alignée avec les mécanismes DR et BCP.
3. Risque de sortie dans les architectures CI/CD et cloud
Les institutions financières modernes s’appuient sur :
- L’hébergement Git SaaS (GitHub, GitLab, Bitbucket)
- Les plateformes CI/CD
- Les registres d’artefacts
- Le cloud IaaS/PaaS
- Les outils de sécurité SaaS
- Les proxies de dépendances
Chacun représente un point de défaillance unique potentiel.
Les scénarios de risque de sortie incluent :
- Perte d’accès au plan de contrôle CI/CD
- Impossibilité de récupérer les configurations de pipeline
- Dépendance à des formats d’artefacts propriétaires
- Automatisation d’infrastructure verrouillée
- Perte des journaux d’audit hébergés par le fournisseur
La stratégie de sortie doit donc être intégrée dans :
- La conception architecturale
- La portabilité des données
- L’export de configuration
- Les mécanismes de sauvegarde
4. Composants essentiels d’une stratégie de sortie conforme DORA
Une stratégie de sortie robuste comprend :
4.1 Cartographie des actifs et des dépendances
Les organisations doivent identifier :
- Quelles fonctions critiques dépendent de quels prestataires ICT
- Les données hébergées en externe
- La propriété des configurations
- Les points d’intégration
Sans cette cartographie, les tests de sortie sont impossibles.
4.2 Portabilité et export des données
Les questions critiques incluent :
- Les dépôts peuvent-ils être exportés dans des formats standards ?
- Les configurations CI/CD peuvent-elles être récupérées ?
- Les historiques d’artefacts sont-ils portables ?
- Les journaux peuvent-ils être exportés pour la conservation réglementaire ?
Si les journaux et l’historique des pipelines ne peuvent pas être exportés, les preuves réglementaires peuvent être perdues lors de la sortie.
4.3 Préparation de la solution alternative
La sortie nécessite plus qu’une résiliation.
Les organisations doivent évaluer :
- Un prestataire alternatif est-il pré-évalué ?
- Les pipelines peuvent-ils être redéployés ailleurs ?
- Les templates Infrastructure-as-Code sont-ils cloud-agnostiques ?
- Les dépendances sont-elles conteneurisées ou portables ?
Le verrouillage fournisseur est un risque de résilience sous DORA.
4.4 Clauses contractuelles
Les contrats doivent inclure :
- Des clauses d’assistance à la sortie
- Des délais de support à la transition
- Des exigences de transfert de données
- Des garanties de conservation
- La transparence sur les sous-traitants
Les auditeurs vérifieront si ces clauses sont applicables et alignées avec les plans opérationnels.
5. Tests de stratégie de sortie en pratique
DORA attend que les stratégies de sortie soient testées, pas supposées.
Les approches de test peuvent inclure :
5.1 Exercices sur table
Ateliers basés sur des scénarios testant :
- Panne du fournisseur cloud
- Compromission du CI/CD SaaS
- Insolvabilité du fournisseur
- Sanctions affectant le prestataire
L’objectif est de valider les processus de décision et les délais.
5.2 Simulation de migration technique
Tests contrôlés tels que :
- Export des dépôts et réhébergement
- Reconstruction des pipelines dans un environnement secondaire
- Restauration des artefacts depuis des sauvegardes indépendantes
- Déploiement des applications depuis un registre alternatif
Ces tests révèlent les dépendances cachées.
5.3 Tests combinés DR + sortie
Une approche mature intègre la stratégie de sortie dans les tests DR :
Exemple de scénario :
« Le CI/CD SaaS principal devient indisponible pendant 72 heures. »
Éléments de test :
- Les déploiements peuvent-ils continuer ?
- Les correctifs d’urgence peuvent-ils être livrés ?
- Les templates de pipeline sont-ils portables ?
- Les preuves d’audit sont-elles préservées ?
Cela fait passer la stratégie de sortie du théorique à l’opérationnel.
6. Preuves des tests de stratégie de sortie
Du point de vue de l’audit, les organisations doivent produire :
- La documentation de la stratégie de sortie
- La classification des risques fournisseur
- Les enregistrements de cartographie des dépendances
- Les rapports de tests (sur table et techniques)
- Les lacunes identifiées et les plans de remédiation
- L’approbation de la direction sur la préparation à la sortie
Les preuves doivent montrer :
- Les tests ont été réalisés
- Les faiblesses ont été identifiées
- Les améliorations ont été implémentées
Les tests sans résultats documentés ne sont pas considérés comme suffisants.
7. Ce que les auditeurs évalueront
Les auditeurs vérifient généralement :
- Si les prestataires ICT critiques sont identifiés
- Si des stratégies de sortie sont définies par prestataire critique
- Si les plans de sortie sont réalistes et techniquement faisables
- Si les tests sont périodiques et documentés
- Si la portabilité des données est validée
- Si le BCP intègre les scénarios de défaillance des tiers
Les constats d’audit courants incluent :
- Plans de sortie limités aux clauses contractuelles
- Aucune validation technique
- Aucun prestataire alternatif identifié
- Absence de capacité d’export CI/CD
- Conservation des journaux manquante pendant la transition fournisseur
8. Schémas de défaillance courants
Les organisations échouent souvent parce que :
- Les pipelines CI/CD sont entièrement gérés par le fournisseur sans processus d’export
- Les registres d’artefacts sont propriétaires sans sauvegarde
- L’automatisation d’infrastructure dépend d’API spécifiques au fournisseur
- Les scénarios de sortie ne sont jamais répétés
- Les responsabilités pendant la sortie sont floues
La stratégie de sortie échoue lorsque l’architecture n’a pas été conçue avec la portabilité en tête.
9. Concevoir le CI/CD pour la préparation à la sortie
Pour s’aligner avec DORA Article 28, les architectures CI/CD devraient :
- Utiliser l’Infrastructure-as-Code
- Stocker les configurations de pipeline dans le contrôle de version
- Maintenir des sauvegardes indépendantes
- Éviter les dépendances codées en dur au fournisseur
- Supporter les builds reproductibles
- Préserver les preuves de conformité en dehors des systèmes contrôlés par le fournisseur
La préparation à la sortie devrait être un principe architectural, pas une réflexion de récupération après coup.
Conclusion
Sous DORA Article 28, la stratégie de sortie est un contrôle de résilience lié à :
- La gestion des risques tiers
- La continuité opérationnelle
- La responsabilité réglementaire
Il ne suffit pas d’affirmer que la sortie est possible.
Les organisations doivent prouver que :
- La sortie est techniquement faisable
- Les dépendances sont comprises
- Des chemins alternatifs existent
- Des tests ont été réalisés
- Les preuves sont conservées
Dans les environnements réglementés, la résilience inclut la capacité de partir.
Articles connexes
- DORA Article 28 — Architecture
- DORA Article 28 — Checklist auditeur
- DORA Article 28 — Pack de preuves
- DORA Article 28 — Mapping des contrôles CI/CD
