Le cloud est devenu le système nerveux du secteur financier européen. Plus de 80% des banques européennes utilisent au moins un service cloud pour leurs opérations, selon une étude EBA de 2024. Mais cette dépendance massive se heurte désormais au cadre strict de DORA — un règlement qui n'interdit pas le cloud, mais qui en change profondément les conditions d'utilisation.
Si vous êtes DSI ou RSSI dans un établissement financier, la question n'est plus "faut-il aller dans le cloud ?" mais "comment y aller — ou y rester — en restant conforme à DORA ?"
Le cloud dans DORA : ni interdit, ni encouragé
DORA ne mentionne jamais le mot "cloud" de manière isolée. Il parle de "prestataires de services ICT tiers" — et les cloud providers en sont évidemment un cas emblématique. Les obligations DORA s'appliquent au cloud comme à tout autre service ICT externalisé, avec un niveau d'exigence qui dépend de la criticité des fonctions supportées.
La nuance importante : DORA ne distingue pas IaaS, PaaS et SaaS. Qu'il s'agisse d'une infrastructure complète hébergée chez un hyperscaler, d'une plateforme de développement cloud ou d'un logiciel SaaS de gestion de portefeuille, les mêmes obligations s'appliquent. Seul le niveau de criticité de la fonction supportée modifie l'intensité des exigences.
Les exigences contractuelles pour les services cloud
L'article 30 de DORA impose des clauses contractuelles minimales pour tout contrat avec un prestataire ICT. Pour les services cloud supportant des fonctions critiques, les exigences sont renforcées. Consultez notre article détaillé sur la gestion des risques ICT tiers pour le cadre complet.
Clauses spécifiques au cloud
| Exigence | Implication pour le cloud | Difficulté de négociation |
|---|---|---|
| Description complète des services | Périmètre exact des services cloud, SLA par composant | Moyenne |
| Localisation des données | Pays de traitement ET de stockage, y compris backup et DR | Élevée |
| Droits d'audit | Inspection physique des datacenters et des sous-traitants | Très élevée |
| Notification d'incidents | Délais de notification alignés sur les obligations DORA de l'entité | Moyenne |
| Portabilité des données | Formats standards, absence de verrouillage propriétaire | Élevée |
| Stratégie de sortie | Plan de migration, période de transition, assistance post-résiliation | Élevée |
| Sous-traitance | Transparence complète sur la chaîne de sous-traitance cloud | Très élevée |
| Chiffrement | Chiffrement au repos et en transit, gestion des clés | Moyenne |
Le problème des contrats d'adhésion cloud
Parlons franchement. Les hyperscalers — AWS, Azure, Google Cloud — proposent des contrats d'adhésion standardisés. Négocier des clauses spécifiques est possible pour les gros clients (spend annuel > 1 million d'euros) mais très difficile pour les autres. Les clauses DORA — en particulier les droits d'audit physique illimités et l'encadrement de la sous-traitance — se heurtent au modèle commercial des cloud providers.
Les solutions émergentes : les addenda DORA proposés par certains hyperscalers (AWS a lancé le sien fin 2024), les pooled audits mutualisés entre clients, et les rapports SOC 2 enrichis intégrant les exigences DORA. Ces mécanismes ne remplacent pas le droit d'audit individuel mais offrent un premier niveau de conformité acceptable.
Localisation des données — le sujet qui fâche
DORA exige que l'entité financière sache précisément où ses données sont traitées et stockées. Pour un service cloud, ça inclut le datacenter principal, les sites de réplication, les backups, et les environnements de disaster recovery.
La question de la localisation géographique est sensible. DORA n'impose pas que les données restent dans l'UE — mais l'entité doit évaluer les risques liés à la localisation, notamment en matière de souveraineté des données et d'accès par des autorités de pays tiers.
Les guidelines EBA de 2019 sur l'externalisation étaient déjà strictes sur ce point. DORA renforce ces exigences en imposant que la localisation soit documentée dans le registre d'informations pour chaque service cloud, avec un niveau de granularité inédit.
Multi-cloud et risque de concentration
Le multi-cloud est souvent présenté comme la solution au risque de concentration. Répartir ses workloads entre deux ou trois cloud providers réduit la dépendance à un seul acteur. En théorie.
En pratique, le multi-cloud vrai — avec des workloads réellement portables entre providers — reste complexe et coûteux. Beaucoup d'établissements font du "multi-cloud accidentel" : AWS pour l'infra, Azure pour Office 365, Google pour certaines applications. Ce n'est pas du multi-cloud au sens de la résilience — c'est de la fragmentation.
DORA pousse les entités à réfléchir sérieusement à la concentration. L'article 29 impose d'évaluer le risque de dépendance excessive à un seul prestataire cloud. Si 90% de vos workloads critiques sont chez le même provider, le régulateur posera des questions.
Cloud souverain et DORA — la convergence
Les initiatives de cloud souverain européen (S3NS en France avec Thales et Google, Bleu avec Orange et Capgemini pour Azure) trouvent dans DORA un argument supplémentaire. Un cloud opéré et contrôlé par des entités européennes, dans des datacenters européens, avec une immunité aux lois extraterritoriales — ça coche beaucoup de cases DORA.
Mais les offres souveraines ne sont pas encore au niveau fonctionnel des hyperscalers, et les prix sont souvent 30 à 50% plus élevés. Le calcul économique doit intégrer le coût de la conformité DORA : si un cloud souverain simplifie significativement la conformité, le surcoût se justifie peut-être.
La stratégie de sortie cloud — le plan B obligatoire
DORA exige une stratégie de sortie pour chaque prestataire cloud supportant une fonction critique. Ce n'est pas un document théorique — c'est un plan opérationnel avec des échéances, des coûts et des alternatives.
Un DSI de banque privée m'a raconté son exercice de plan de sortie : "On a calculé que migrer notre core banking hors d'AWS nécessiterait 18 mois et coûterait 12 millions d'euros. Et encore, c'est un scénario optimiste. Ça remet les choses en perspective quand on parle de portabilité."
Les composantes d'un plan de sortie cloud conforme
Identification de prestataires alternatifs (autre cloud provider, cloud privé, rapatriement on-premise). Estimation réaliste des délais de migration — qui sont presque toujours sous-estimés. Budget de transition détaillé. Mesures de continuité pendant la migration. Format d'export des données garanti contractuellement. Tests périodiques de portabilité.
FAQ — DORA et cloud
Faut-il éviter le cloud public pour les fonctions critiques ?
Non. DORA n'interdit pas le cloud public. Mais il impose des conditions strictes : clauses contractuelles renforcées, droits d'audit, plans de sortie, évaluation du risque de concentration. Si ces conditions sont remplies, le cloud public reste une option parfaitement viable.
Les services SaaS de niche sont-ils concernés ?
Oui. Un outil SaaS de gestion de la relation client, une solution de signature électronique, un outil de visioconférence — tous sont des services ICT tiers au sens de DORA. Le niveau d'exigence dépend de la criticité de la fonction supportée, mais le registre doit les inclure tous.
Les certifications cloud (ISO 27001, SOC 2, C5) suffisent-elles pour DORA ?
Elles constituent une base solide mais ne suffisent pas seules. DORA impose des obligations spécifiques (registre, clauses contractuelles, droits d'audit, plan de sortie) qui vont au-delà de ce que couvrent ces certifications. Un rapport SOC 2 aide mais ne remplace pas la due diligence DORA.
Le cloud reste un accélérateur pour le secteur financier. DORA ne remet pas ça en question. Mais il impose de passer d'une adoption parfois opportuniste à une gouvernance structurée de l'externalisation cloud. Les entités qui maîtrisent cette transition combinent le meilleur des deux mondes : agilité du cloud et résilience réglementaire. Consultez notre guide complet pour le cadre global.