De la disponibilité à la réversibilité
Les établissements financiers ont largement intégré le cloud et les solutions SaaS dans leurs systèmes d’information. Ces environnements soutiennent désormais des fonctions critiques : authentification, relation client, analyse de données, conformité, détection fraude, supervision sécurité, messagerie, collaboration ou encore opérations métiers.
Pendant longtemps, la résilience cloud a surtout été abordée sous l’angle de la disponibilité : disponibilité multi-régions, engagements de service, plans de reprise, architecture redondante, supervision des SLA.
Mais cette approche ne suffit plus. Dans un contexte DORA, la question devient plus large : un établissement peut-il réellement sortir d’un fournisseur critique, basculer vers une alternative ou reprendre l’exploitation d’un service essentiel dans des conditions maîtrisées ?
La réversibilité ne se limite pas à une clause contractuelle. Elle doit devenir une capacité opérationnelle testée.
Risque de concentration : un sujet systémique
Le risque de concentration apparaît lorsqu’un établissement, ou plusieurs acteurs d’un même secteur, dépendent fortement d’un nombre limité de fournisseurs technologiques.
Dans le secteur financier, ce risque concerne notamment :
- les hyperscalers cloud ;
- les fournisseurs SaaS transverses ;
- les prestataires IAM ;
- les services de cybersécurité externalisés ;
- les plateformes de données ;
- les prestataires de paiement ou de conformité ;
- les outils critiques de collaboration et de communication.
L’enjeu n’est pas uniquement individuel. Une défaillance majeure d’un prestataire utilisé par de nombreux établissements peut produire des effets de place : indisponibilité simultanée de services, difficulté de coordination, saturation des capacités de support, dépendance à des plans de remédiation pilotés par le fournisseur.
C’est précisément ce type de dépendance que DORA cherche à encadrer à travers la gestion du risque ICT tiers et la supervision des prestataires TIC critiques.
Le plan de sortie ne doit pas être confondu avec le PRA
Un Plan de Reprise d’Activité vise à rétablir un service après incident. Il peut s’appuyer sur le même fournisseur, sur une autre région ou sur une architecture redondante.
Un plan de sortie cloud ou SaaS répond à une question différente : que faire si le fournisseur n’est plus utilisable, plus acceptable, plus conforme ou plus capable de fournir le service dans des conditions compatibles avec les exigences de l’établissement ?
Les scénarios peuvent être multiples :
- rupture contractuelle ;
- incident grave prolongé ;
- non-conformité réglementaire ;
- perte de confiance dans le fournisseur ;
- changement de stratégie ;
- impossibilité d’obtenir les preuves nécessaires ;
- dégradation durable de la qualité de service ;
- contrainte géopolitique ou juridique.
Un exit plan crédible doit donc couvrir des hypothèses plus larges qu’une simple panne.
Portabilité des données : condition minimale, mais insuffisante
La première brique d’un plan de sortie est la portabilité des données.
L’établissement doit pouvoir répondre à plusieurs questions simples :
- quelles données sont hébergées chez le fournisseur ?
- où sont-elles localisées ?
- dans quel format peuvent-elles être exportées ?
- à quelle fréquence ?
- avec quelles métadonnées ?
- avec quel historique ?
- dans quels délais ?
- avec quelles garanties d’intégrité ?
Dans beaucoup de projets, la réversibilité est considérée comme acquise parce qu’un export de données est théoriquement possible. Mais un export brut ne garantit pas une reprise opérationnelle.
Les données doivent être exploitables, documentées, cohérentes et réinjectables dans un environnement alternatif. Cela implique de vérifier les schémas, les dépendances, les journaux, les identifiants, les règles métiers et les paramètres de configuration.
La portabilité doit être testée, pas seulement décrite.
IAM, clés et identités : les dépendances souvent sous-estimées
Les dépendances IAM constituent l’un des principaux angles morts des plans de sortie.
Un service cloud ou SaaS peut dépendre de multiples composants :
- annuaire d’entreprise ;
- fédération d’identité ;
- SSO ;
- MFA ;
- comptes techniques ;
- rôles d’administration ;
- secrets applicatifs ;
- certificats ;
- clés de chiffrement ;
- politiques d’accès conditionnel.
Si ces dépendances ne sont pas documentées, la sortie devient difficile, même lorsque les données sont disponibles.
La gestion des clés est particulièrement critique. Les établissements doivent savoir si les clés sont gérées par le fournisseur, par le client ou par un tiers. Les modèles BYOK, HYOK ou HSM dédié ne produisent pas les mêmes garanties opérationnelles.
Un plan de sortie doit prévoir la rotation, la révocation, l’export éventuel, la destruction et la preuve de non-réutilisation des clés selon les scénarios concernés.
Logs et preuves : préserver la capacité d’investigation
Lors d’une sortie d’un fournisseur, les données métiers ne sont pas les seules informations importantes.
Les logs, traces d’accès, journaux d’administration, historiques d’événements et preuves d’exploitation peuvent être nécessaires pour :
- reconstituer un incident ;
- démontrer la conformité ;
- alimenter une enquête interne ;
- répondre à un audit ;
- prouver la continuité des contrôles ;
- documenter une décision de sortie.
Un exit plan doit donc inclure les exigences de récupération des journaux : format, granularité, durée de conservation, intégrité, horodatage et capacité d’exploitation dans les outils internes.
Sans logs exploitables, l’établissement peut perdre une partie de sa mémoire opérationnelle au moment précis où il en a besoin.
Réversibilité contractuelle : nécessaire, mais non suffisante
Les contrats doivent prévoir les conditions de sortie :
- restitution des données ;
- délais d’assistance ;
- support pendant la transition ;
- maintien temporaire du service ;
- destruction des données ;
- restitution des journaux ;
- coopération en cas d’incident ;
- continuité des obligations de confidentialité ;
- sous-traitance et dépendances de rang inférieur.
Ces clauses sont indispensables, mais elles ne garantissent pas la faisabilité technique.
Une clause de réversibilité non testée peut donner une impression de maîtrise sans capacité réelle d’exécution. Le rôle des équipes achats et juridiques doit donc être articulé avec celui des équipes IT, cloud, cybersécurité, risques et métiers.
La réversibilité contractuelle doit être vérifiée par la réversibilité opérationnelle.
Tester le plan de sortie : passer du document à la preuve
Le point le plus important reste le test.
Un plan de sortie crédible doit produire des preuves. Il ne suffit pas d’affirmer qu’une sortie est possible ; il faut démontrer que certains éléments clés ont été testés.
Les tests peuvent être progressifs :
- export d’un jeu de données représentatif ;
- import dans un environnement alternatif ;
- vérification de l’intégrité et de la cohérence ;
- test de récupération des logs ;
- simulation de perte d’accès au fournisseur ;
- test de restauration d’un service critique ;
- exercice de bascule partielle ;
- test de révocation des accès et des clés ;
- simulation de communication avec le fournisseur en situation de crise.
Tous les scénarios ne nécessitent pas une migration complète. Mais les hypothèses structurantes doivent être validées.
Un comité risques doit pouvoir distinguer un plan théorique d’une capacité testée.
Multi-cloud : une réponse partielle
Le multi-cloud est parfois présenté comme une solution au risque de concentration. Il peut réduire certaines dépendances, mais il ne supprime pas automatiquement le risque.
Un environnement multi-cloud peut rester dépendant d’un même fournisseur IAM, d’un même outil de supervision, d’un même prestataire d’infogérance, d’un même pipeline DevOps ou d’une même solution de sécurité.
Il peut également augmenter la complexité opérationnelle : compétences multiples, supervision fragmentée, coûts plus élevés, duplication des contrôles, difficulté de cohérence entre environnements.
Le multi-cloud ne doit donc pas être une posture déclarative. Il doit être rattaché à des cas d’usage précis : continuité, portabilité, souveraineté, réduction du risque fournisseur, exigences métiers ou contraintes réglementaires.
SaaS : le cas le plus difficile
La réversibilité SaaS est souvent plus complexe que la réversibilité IaaS ou PaaS.
Dans un SaaS, l’établissement maîtrise moins l’infrastructure, les formats de données, les workflows internes, les logs détaillés, les mécanismes d’export et les dépendances techniques.
Les questions à traiter dès la sélection du fournisseur sont donc essentielles :
- les données sont-elles exportables dans un format ouvert ?
- les pièces jointes, métadonnées et historiques sont-ils inclus ?
- les workflows peuvent-ils être reconstruits ailleurs ?
- les droits et rôles sont-ils exportables ?
- les journaux sont-ils suffisamment détaillés ?
- les API permettent-elles une extraction fiable ?
- le fournisseur assiste-t-il réellement la migration sortante ?
Dans certains cas, la sortie d’un SaaS critique relève moins d’une bascule technique que d’un projet de transformation métier.
Rôle des métiers et des comités risques
Un plan de sortie ne peut pas être piloté uniquement par l’IT.
Les métiers doivent identifier les fonctions prioritaires, les niveaux de service minimaux, les données indispensables, les périodes critiques et les impacts acceptables.
Les comités risques doivent disposer d’une lecture claire :
- niveau de dépendance au fournisseur ;
- services critiques concernés ;
- solutions alternatives disponibles ;
- délais réalistes de sortie ;
- coûts de migration ;
- risques résiduels ;
- tests déjà réalisés ;
- limites connues.
La valeur d’un exit plan tient à sa lisibilité décisionnelle. Il doit permettre au management de comprendre ce qui est réellement possible, dans quels délais et avec quels risques.
Alignement avec DORA
DORA impose aux entités financières une gestion structurée des risques liés aux prestataires TIC, notamment lorsqu’ils soutiennent des fonctions critiques ou importantes.
Cette gestion implique une capacité à identifier les dépendances, évaluer les risques, encadrer contractuellement les relations, suivre les performances et anticiper les scénarios de sortie.
Les discussions européennes sur les prestataires TIC critiques et le risque de concentration renforcent cette exigence. L’oversight européen ne dispense pas les établissements de leur propre responsabilité : ils doivent connaître leurs dépendances et démontrer leur capacité à les gérer.
Dans ce cadre, l’exit strategy devient un élément de gouvernance, de résilience et de preuve.
Indicateurs utiles pour piloter la réversibilité
Plusieurs indicateurs peuvent aider à suivre la maturité :
- nombre de services critiques dépendant d’un fournisseur unique ;
- taux de contrats incluant des clauses de sortie testables ;
- taux de services disposant d’un exit plan documenté ;
- nombre de tests de portabilité réalisés ;
- délai estimé de sortie par service ;
- taux de dépendances IAM documentées ;
- capacité de récupération des logs ;
- nombre de scénarios de sortie testés ;
- niveau de couverture des prestataires de rang inférieur ;
- volume d’exceptions acceptées.
Ces indicateurs permettent d’éviter une approche purement déclarative.
Perspective pour les banques et assurances
Les plans de sortie cloud et SaaS ne doivent plus être considérés comme des annexes contractuelles.
Ils deviennent un composant central de la résilience opérationnelle numérique. Leur crédibilité repose sur trois éléments : une cartographie précise des dépendances, des mécanismes contractuels exploitables et des tests réels.
Pour les banques et assurances, l’enjeu n’est pas de sortir systématiquement des fournisseurs critiques, mais de ne pas dépendre d’eux sans capacité de décision.
Un exit plan crédible ne promet pas une bascule simple. Il rend visible ce qui est possible, ce qui ne l’est pas encore, les délais nécessaires, les risques résiduels et les investissements à prioriser.
Dans un contexte DORA, cette transparence devient un élément clé de la maîtrise du risque de concentration et de la résilience de place