Une banque peut sauvegarder ses données chaque nuit et rester incapable de quitter son fournisseur cloud. Parce que ses applications parlent son langage, que ses équipes utilisent ses outils et que son dispositif de sécurité repose sur ses services. C’est cette dépendance que DORA met sous tension. En ce mois de septembre 2026, la question n’est plus seulement de savoir si le cloud fonctionne, mais si l’établissement saurait continuer à fonctionner sans lui. Et la réponse ne tient pas dans une clause de réversibilité.
DORA change la question posée aux banques
Applicable depuis le 17 janvier 2025, le règlement européen sur la résilience opérationnelle numérique du secteur financier organise la gestion des risques informatiques, la notification des incidents majeurs, les tests de résilience et la surveillance des prestataires technologiques. Son principe est simple : externaliser une fonction ne transfère pas la responsabilité de l’établissement financier.
Pour les services informatiques soutenant des fonctions critiques ou importantes, DORA prévoit notamment des stratégies de sortie documentées, suffisamment testées et réexaminées périodiquement. L’objectif est de pouvoir mettre fin à une relation sans perturber indûment l’activité, compromettre le respect des exigences réglementaires ou dégrader la continuité et la qualité des services aux clients.
DORA n’impose donc ni d’abandonner le cloud ni de travailler systématiquement avec plusieurs fournisseurs. Il demande de comprendre ses dépendances et de prévoir des solutions de remplacement praticables. La nuance compte : acheter une seconde plateforme ne garantit pas davantage de résilience que conserver un seul prestataire avec une architecture maîtrisée.
Sortir du cloud, mais sortir de quoi ?
Imaginons une banque dont une application de crédit utilise une base de données gérée, un service d’identification, une plateforme d’analyse et des outils de surveillance fournis par le même groupe. Exporter les dossiers clients ne suffit pas. Il faut aussi reconstruire les règles d’accès, les traitements, les alertes et les preuves nécessaires aux contrôles.
La dépendance se loge dans les détails : formats propriétaires, interfaces, mécanismes de chiffrement, compétences internes, licences ou interconnexions avec d’autres applications. Plus un service cloud prend en charge de tâches complexes, plus il peut accélérer les projets. Mais ce confort peut rendre le remplacement difficile. C’est le compromis central entre efficacité immédiate et liberté future.
Il faut également distinguer trois situations. Une panne appelle une reprise rapide. Une dégradation durable du fournisseur peut justifier une migration organisée. Une rupture contractuelle ou une contrainte juridique peut imposer un calendrier différent. Un plan unique, promettant une migration complète dans tous les cas, masque souvent ces différences plutôt qu’il ne les résout.
Le vrai test : continuer à servir les clients
Une sortie crédible commence par une question très concrète : quels services doivent absolument rester disponibles ? Consulter un solde, autoriser un paiement, traiter une opération de marché ou produire un reporting ne présentent pas les mêmes contraintes. La banque doit hiérarchiser ses activités, déterminer les interruptions acceptables et identifier les ressources nécessaires à leur reprise.
Le document de sortie doit ensuite rencontrer la réalité technique. Peut-on extraire les données dans un format exploitable ? Les sauvegardes restent-elles accessibles si les comptes du fournisseur sont bloqués ? Qui détient les clés de chiffrement ? L’environnement de remplacement dispose-t-il de la capacité nécessaire ? Les équipes savent-elles le faire fonctionner sans l’assistance habituelle ?
Ces vérifications peuvent combiner exercices sur table, restaurations, migrations partielles et essais techniques ciblés. DORA ne signifie pas que chaque banque doit déménager intégralement son système pour prouver sa préparation. Mais un contrat promettant de restituer les données n’est pas une démonstration de continuité. Les tests doivent révéler les obstacles, puis conduire à des corrections financées.
Le multicloud, utile mais pas magique
Répartir ses applications entre plusieurs clouds peut limiter certaines concentrations. Pourtant, une application hébergée chez un fournisseur et une autre chez son concurrent ne deviennent pas automatiquement interchangeables. Si chacune dépend de services spécifiques, la banque possède deux dépendances au lieu d’une solution de secours.
Faire fonctionner la même application sur deux plateformes est plus exigeant encore. Il faut synchroniser les données, maintenir des configurations cohérentes, organiser les bascules et préserver la sécurité. Cette complexité peut elle-même provoquer des incidents. Quant aux composants supposés indépendants, ils peuvent partager un opérateur réseau, un logiciel ou un prestataire d’identité.
La bonne approche peut donc être sélective : portabilité renforcée pour certaines fonctions, sauvegardes isolées pour d’autres, capacité de fonctionnement dégradé lorsque c’est pertinent. Des technologies ouvertes et des conteneurs peuvent faciliter une migration, sans effacer les dépendances aux bases de données, aux services de sécurité ou aux procédures d’exploitation.
Une négociation commerciale autant qu’un chantier informatique
La réversibilité se prépare avant la signature. Les contrats concernés doivent encadrer les droits d’accès et d’audit, l’assistance, la récupération des données et les conditions de résiliation. Pour les fonctions critiques ou importantes, les dispositions de sortie et de transition sont particulièrement déterminantes. Sans elles, la banque risque de négocier son départ au moment où elle dispose du moins de marge.
Le coût ne se limite pas au transfert des données. Une migration peut nécessiter une période de double exploitation, des développements, des validations de sécurité et la formation des équipes. Le prestataire de remplacement doit, lui aussi, être évalué. Revenir dans ses propres centres informatiques n’est une option sérieuse que si les infrastructures et les compétences existent réellement.
C’est pourquoi le conseil d’administration et la direction doivent pouvoir arbitrer sur des éléments compréhensibles : dépendances majeures, scénarios de rupture, délais plausibles et moyens mobilisables. Un plan de sortie sans budget, sans responsable identifié ou sans personnel disponible reste une déclaration d’intention.
Une dépendance individuelle, un risque collectif
DORA prévoit aussi une supervision européenne des prestataires informatiques désignés comme critiques, sous l’égide des autorités européennes de surveillance. Ce dispositif répond à une difficulté structurelle : plusieurs établissements peuvent dépendre des mêmes acteurs. Il ne remplace toutefois ni les contrôles de chaque banque ni sa responsabilité envers ses clients.
Le problème dépasse alors la seule portabilité. Si de nombreuses banques devaient quitter simultanément un fournisseur, les solutions de remplacement pourraient manquer de capacité ou d’équipes disponibles. C’est un scénario prospectif, pas un événement ici constaté. Il montre pourquoi la résilience doit être examinée à l’échelle du secteur, et pas seulement contrat par contrat.
Et maintenant ? La trajectoire la plus plausible n’est pas un exode général hors du cloud, mais une utilisation plus sélective de ses services les plus difficiles à remplacer. Les banques qui progresseront seront probablement celles capables de démontrer, tests à l’appui, ce qu’elles peuvent déplacer, maintenir en mode dégradé ou reconstruire. Se passer totalement de ses fournisseurs reste rarement réaliste. Ne plus être prisonnier d’eux constitue, en revanche, un objectif opérationnel crédible.
