La généralisation du cloud et des services SaaS dans le secteur financier a profondément transformé les architectures IT, mais aussi la nature du risque opérationnel. Au-delà des incidents ponctuels, la question de la dépendance structurelle à un nombre limité de prestataires s’impose désormais comme un enjeu central de résilience.
Dans le cadre de DORA, cette dépendance n’est plus uniquement analysée sous l’angle contractuel ou de performance. Elle est abordée comme un risque systémique, notamment lorsque plusieurs acteurs de la place reposent sur les mêmes fournisseurs critiques. Les travaux des Autorités européennes de supervision (EBA, ESMA, EIOPA) ont ainsi mis en avant la notion de concentration risk et la nécessité d’encadrer les prestataires ICT critiques dans une logique de supervision harmonisée.
Dans ce contexte, la capacité à sortir d’un fournisseur – ou à basculer vers une alternative – devient un critère clé de maturité.
De la dépendance technique à la dépendance opérationnelle
Dans de nombreux cas, la dépendance au cloud ne se limite pas à l’hébergement. Elle s’étend à des briques critiques : gestion des identités, services managés, bases de données, outils d’observabilité, pipelines DevOps, voire fonctions métiers entières dans le cas du SaaS.
Cette dépendance progressive crée une situation où la réversibilité devient complexe, non pas en théorie, mais dans sa mise en œuvre concrète. Les audits récents montrent régulièrement que :
les données sont exportables, mais dans des formats difficilement exploitables ;
les dépendances IAM sont insuffisamment documentées ;
les clés de chiffrement ne sont pas toujours maîtrisées par l’établissement ;
les logs et historiques ne sont pas intégralement récupérables ;
les intégrations avec d’autres systèmes rendent toute migration risquée.
DORA impose de ne plus considérer ces éléments comme secondaires. La gestion du risque ICT tiers inclut explicitement la capacité à identifier, documenter et maîtriser les dépendances critiques.
Construire un plan de sortie crédible
Un exit plan crédible ne se résume pas à une clause contractuelle. Il doit reposer sur une compréhension fine des composants techniques et des processus opérationnels concernés.
Sur le plan technique, cela suppose d’identifier et de documenter :
les données : localisation, formats, volumétrie, fréquence de mise à jour, dépendances applicatives ;
les identités et accès (IAM) : comptes, rôles, fédérations, dépendances aux services d’authentification ;
les clés de chiffrement : localisation (fournisseur ou client), modalités d’export ou de rotation ;
les journaux et traces : accès aux logs, durée de rétention, exploitabilité ;
les intégrations : API, flux inter-applicatifs, dépendances aux services tiers ;
les outils d’exploitation : supervision, orchestration, automatisation.
Mais un plan de sortie crédible est aussi un sujet opérationnel. Il doit préciser :
les responsabilités (internes et prestataires),
les délais réalistes de bascule,
les priorités métier (quels services doivent être rétablis en premier),
les scénarios de dégradation temporaire.
Dans les établissements les plus matures, ces éléments sont consolidés dans une cartographie des dépendances cloud, souvent intégrée aux dispositifs de gestion des risques tiers.
Tester la réversibilité : un point encore trop rarement adressé
L’un des constats récurrents des audits et contrôles est l’absence de tests réels de réversibilité. Beaucoup d’organisations disposent de plans théoriques, mais peu ont validé leur faisabilité.
DORA introduit une exigence implicite forte : la résilience ne peut être démontrée sans test. Cela vaut aussi pour les scénarios de défaillance d’un prestataire.
Les tests peuvent prendre plusieurs formes :
extraction partielle de données et rechargement dans un environnement alternatif ;
simulation de perte d’un service critique (IAM, base de données, API) ;
bascule vers une autre région ou un autre fournisseur ;
test de récupération des logs et des éléments probants.
L’objectif n’est pas nécessairement de réaliser une migration complète, mais de vérifier que les hypothèses du plan de sortie sont réalistes. Ces tests permettent souvent d’identifier des dépendances non documentées ou des points de blocage techniques.
Réversibilité et exigences contractuelles
La maîtrise de la réversibilité passe également par le cadre contractuel. Les exigences DORA relatives à la gestion des risques ICT tiers insistent sur la nécessité de formaliser :
les modalités de restitution des données,
les délais d’accès en cas de sortie,
les obligations d’assistance du prestataire,
les conditions de continuité de service pendant la transition.
Dans les discussions européennes sur la supervision des prestataires ICT critiques, la question de la transparence et de la capacité de sortie est régulièrement mise en avant comme un élément structurant de la résilience.
Cependant, même un contrat bien rédigé ne compense pas une absence de préparation technique. La réversibilité reste avant tout une capacité opérationnelle.