Règlement DORA et IA dans le secteur financier

Qu'est-ce que DORA, et pourquoi le règlement concerne-t-il l'IA dans le secteur financier ?

Le Digital Operational Resilience Act, ou DORA, formellement le règlement (UE) 2022/2554, est directement applicable depuis le 17 janvier 2025 et crée pour la première fois un cadre uniforme à l'échelle de l'UE pour la résilience opérationnelle numérique du secteur financier. Selon l'art. 2 de DORA, le règlement s'applique à 20 catégories d'entités financières, des établissements de crédit et des assureurs aux entreprises d'investissement, aux établissements de paiement et aux prestataires de services sur crypto-actifs. DORA regroupe cinq piliers jusqu'ici dispersés entre différentes exigences prudentielles : la gestion du risque lié aux TIC (art. 5-16), la notification des incidents majeurs liés aux TIC (art. 17-23), les tests de résilience opérationnelle numérique, y compris les tests de pénétration fondés sur la menace (TLPT, art. 24-27), la gestion du risque lié aux prestataires tiers de services TIC avec la surveillance des prestataires critiques (art. 28-44) et le partage d'informations (art. 45). Le partage d'informations est facultatif. Pour les systèmes d'IA, ce sont surtout les quatre premiers piliers qui comptent.

Le levier décisif pour l'IA est le document d'orientation de la BaFin sur les risques TIC liés à l'utilisation de l'IA dans les entités financières, du 18 décembre 2025, qui classe expressément les systèmes d'IA comme une sous-catégorie des « réseaux et systèmes d'information » au sens de l'art. 3, point 2, de DORA. L'ensemble des obligations DORA s'applique donc aussi aux charges de travail d'IA et d'agents IA, de la collecte des données au développement du modèle et au déploiement, jusqu'à l'exploitation courante avec surveillance de la dérive et la mise hors service. Mettre en production un agent IA dans une banque ou chez un assureur revient ainsi à construire un système TIC réglementé, avec toutes les obligations de résilience, de tests et de gestion des prestataires tiers.

Les quatre piliers obligatoires de DORA appliqués aux agents IA

Gestion du risque lié aux TIC (art. 5-16). Les systèmes d'IA doivent être intégrés dans la gestion du risque lié aux TIC à l'échelle de l'établissement. Le document d'orientation de la BaFin formule l'approche par cycle de vie comme attente prudentielle : collecte des données → développement du modèle → déploiement → exploitation courante avec surveillance de la dérive → mise hors service. Sont expressément attendus l'entraînement adversarial et la surveillance de la dérive des modèles. Formellement non contraignant, ce document inverse toutefois dans les faits la charge de la preuve dans la pratique de surveillance : un établissement qui ne le suit pas doit documenter, lors des contrôles de la BaFin, l'équivalence de ses mesures alternatives.

Tests de résilience (art. 24-27). Les systèmes reposant sur l'IA sont soumis à l'obligation de tester régulièrement la résilience opérationnelle numérique, jusqu'aux tests de pénétration fondés sur la menace (TLPT) pour les établissements importants. Pour des agents stochastiques basés sur des LLM, c'est un défi méthodologique, car les procédures de test classiques sont conçues pour des systèmes déterministes.

Notification des incidents (art. 17-23). Les risques d'IA propres à chaque fournisseur, comme des citations réglementaires hallucinées, des données de portefeuille client hallucinées ou la dérive des modèles dans des systèmes de scoring en production, sont considérés dans le contexte BFSI comme des risques opérationnels significatifs. Ils ne doivent toutefois être notifiés que s'ils remplissent, en tant qu'incident lié aux TIC, les critères de l'art. 18 de DORA et sont donc considérés comme majeurs (art. 19 de DORA). L'ordre de grandeur est considérable : au cours des trois premiers trimestres de 2025, 525 incidents majeurs liés aux TIC ont été notifiés à la BaFin, dont environ 70 % par des établissements de crédit.

Risque lié aux prestataires tiers de services TIC (art. 28-44). C'est le levier le plus puissant pour l'IA, et l'objet de la section suivante.

Risque lié aux prestataires tiers de services TIC et désignation des CTPP

Aujourd'hui, l'IA dans le secteur financier tourne presque toujours sur une infrastructure externe : clouds des hyperscalers, fournisseurs externes de modèles et de LLM ou centres de données des réseaux bancaires. C'est précisément là qu'intervient DORA : les art. 28-30 encadrent la manière dont les entités financières gèrent leur risque lié aux prestataires tiers de services TIC, les art. 31-44 la surveillance directe des prestataires critiques. Le 18 novembre 2025, les autorités européennes de surveillance (AES) ont désigné pour la première fois 19 prestataires tiers critiques de services TIC (Critical ICT Third-Party Providers, CTPP), parmi lesquels, selon la liste des AES, AWS, Microsoft, Google Cloud, Oracle, IBM, SAP, Deutsche Telekom, Equinix et Bloomberg. Pour chacun de ces prestataires, l'une des trois autorités joue le rôle de chef de file (superviseur principal ou Lead Overseer : EBA, EIOPA ou ESMA). Elle peut demander des informations, mener des enquêtes et des inspections et émettre des recommandations (art. 35 de DORA). Ces recommandations ne sont pas contraignantes : le prestataire doit indiquer dans un délai de 60 jours civils s'il entend les suivre ou expliquer pourquoi il ne le fera pas (art. 42, paragraphe 1, de DORA). S'il ne répond pas dans les délais ou si le superviseur principal juge l'explication insuffisante, celui-ci le rend public (art. 42, paragraphe 2, de DORA). En dernier recours, les autorités compétentes peuvent obliger les entités financières à suspendre temporairement l'utilisation du service et, si nécessaire, à résilier le contrat (art. 42, paragraphe 6, de DORA).

Pour les banques et les assureurs côté déployeur, les conséquences sont concrètes :

• Les plans de sortie pour les fonctions critiques ou importantes doivent être suffisamment testés et réexaminés régulièrement, et pas seulement documentés (art. 28, paragraphe 8, de DORA).
• Les risques de concentration doivent être évalués avant la conclusion du contrat (art. 29 de DORA, pour les fonctions critiques ou importantes) ; les architectures multicloud et réversibles gagnent ainsi en importance.
• Les charges de travail d'agents IA hébergées chez les hyperscalers restent soumises à une observation prudentielle supplémentaire.

Le risque de concentration est particulièrement visible dans la région DACH (Allemagne, Autriche, Suisse) : pour ses charges de travail d'IA, presque chaque banque dépend soit de l'un des hyperscalers désignés, soit des solutions de son réseau bancaire. En Allemagne, Finanz Informatik (FI) pour les caisses d'épargne (Sparkassen) et Atruvia AG pour les Volksbanken et Raiffeisenbanken exploitent délibérément des stacks d'IA on-premise et souverains (notamment des modèles open source comme Mixtral/Llama dans leurs propres centres de données). Le S-KIPilot de FI a été déployé en 2025, dans sa version 6, sur quelque 60 000 postes de travail des Sparkassen. La logique CTPP de DORA renforce structurellement ces modèles de réseau, tant que la désignation et le document d'orientation de la BaFin conservent leur rigueur actuelle.

Art. 30 de DORA : le catalogue de clauses contractuelles comme filtre d'achat

L'art. 30 de DORA impose des contenus contractuels obligatoires pour les prestataires tiers de services TIC et fait ainsi de la sélection des fournisseurs d'IA un véritable verrou de conformité. Sont notamment obligatoires les droits d'audit, les clauses de sortie, les contrôles des sous-traitants, les descriptions des services avec des objectifs de performance quantitatifs et qualitatifs ainsi que l'indication des lieux où les données sont traitées (art. 30, paragraphe 2, point b, et paragraphe 3, point a, de DORA). L'art. 30, paragraphe 3, exige des droits d'audit, des stratégies de sortie et des objectifs de performance précis pour les services TIC qui soutiennent des fonctions critiques ou importantes. Chez les hyperscalers établis, ces clauses font aujourd'hui partie du texte standard ; chez les jeunes start-up d'IA, elles bloquent fréquemment les achats.

L'art. 30 de DORA n'est d'ailleurs pas le seul référentiel. Dans les appels d'offres IA des banques et des assureurs, d'autres critères d'évaluation s'ajoutent :

Le BSI Test Criteria Catalogue for AI Systems in Finance (version provisoire de juin 2025, version complète 2.0 de juin 2026) comprend près de 100 critères d'évaluation répartis en dix domaines thématiques, dont la sécurité et la robustesse, la transparence, l'équité, la qualité des données et la gouvernance. L'expérience montre que des attestations selon BSI AIC4, ISO 42001, SOC 2 ou ISO 27001 améliorent les chances des fournisseurs d'IA dans les appels d'offres BFSI.

Obligations DORA pour les agents IA dans les banques et les assurances

Pour les agents IA dans le secteur financier, six domaines de risque propres au secteur sont à prendre en compte au-delà de DORA ; ils n'apparaissent qu'en marge de la conformité IA horizontale :

1. Gestion du risque de modèle. Depuis les révisions de 2023/2024, MaRisk AT 4.3.5 s'applique explicitement aussi aux modèles d'IA/ML et exige une documentation du cycle de vie, une validation indépendante, du backtesting et une revue périodique. Le document d'orientation de la BaFin attend en outre une documentation de l'entraînement adversarial et une surveillance de la dérive des modèles.
2. Explicabilité des décisions de crédit. Selon l'art. 22 du RGPD, les décisions de crédit produisant des effets juridiques ne peuvent être fondées exclusivement sur un traitement automatisé qu'à titre exceptionnel ; les personnes concernées ont alors le droit d'obtenir une intervention humaine, d'exprimer leur point de vue et de contester la décision (art. 22, paragraphe 3, du RGPD). S'y ajoute la classification du scoring de crédit comme IA à haut risque selon l'annexe III, point 5 b, du règlement sur l'IA, dont les obligations s'appliquent, d'après l'Omnibus numérique, à partir du 2 décembre 2027. En Allemagne, les § 505a et § 505b BGB imposent en outre une évaluation de la solvabilité avant tout crédit aux consommateurs. Ensemble, le RGPD et le règlement sur l'IA impliquent qu'une personne compétente doit pouvoir nommer les facteurs déterminants. Le scoring de crédit de bout en bout par LLM est donc pratiquement exclu ; l'IA reste cantonnée à des rôles de tri et d'explication.
3. Exhaustivité de la piste d'audit. Pour les contrôles prudentiels spéciaux (contrôle spécial de la BaFin, contrôle sur place de la FINMA, inspection de l'OeNB), chaque inférence doit être journalisée de manière infalsifiable et auditable, y compris le prompt, le contexte, les sources récupérées, la version du modèle et la sortie.
4. Exigences de latence. La conformité dans le trading exige <10 ms, la détection de fraude <1 s. Des agents LLM sur le hot path sont rarement envisageables.
5. Résidence des données. En Allemagne et en Autriche, les superviseurs insistent de plus en plus sur une résidence dans l'UE, voire nationale, des données d'entraînement et d'inférence de l'IA ; en Suisse, le secret bancaire (art. 47 LB) impose en pratique de conserver les données clients en Suisse.
6. Risque de concentration lié à la désignation des CTPP (voir plus haut).

En conséquence, en 2026, les décisions de crédit entièrement autonomes et les workflows de trading multi-agents entièrement autonomes ne sont pas en production. La norme, ce sont au contraire les agents de service client de niveau 1, la détection de fraude, le tri AML/KYC et le reporting réglementaire, toujours avec un humain dans la boucle (human-in-the-loop) lorsque les décisions produisent des effets juridiques.

Le contexte DACH : trois voies au lieu d'une seule ligne

DORA s'applique directement en Allemagne et en Autriche au titre de l'acquis de l'UE ; la Suisse reprend ces règles de manière autonome, secteur par secteur. Il en résulte une conformité à trois voies, que les établissements actifs dans toute la région DACH doivent prendre en compte :

Une enquête de la FINMA d'avril 2025 menée auprès d'environ 400 établissements montre le niveau d'adoption : environ 50 % des banques et assureurs suisses utilisent déjà l'IA ou développent des applications, et 25 % supplémentaires prévoient de l'adopter d'ici trois ans ; en moyenne, environ 5 applications sont en production et environ 9 en développement. Parmi les établissements qui utilisent l'IA, 91 % recourent à l'IA générative. La communication FINMA sur la surveillance a précédé de douze mois exactement le document d'orientation de la BaFin, sans lui être tout à fait équivalente : la FINMA exige par exemple des inventaires centraux de l'IA avec classification des risques et des solutions de repli.

Le vide réglementaire autrichien est ambivalent : il laisse une marge de manœuvre, mais accroît l'incertitude lors des contrôles sur place, car les attentes ne sont pas codifiées à l'avance. Un service central dédié à l'IA a été créé en 2024 auprès de RTR-GmbH, pour conseiller et non pour exercer une surveillance sectorielle.

Perspectives et conseils pratiques

Les lignes bougent sur le plan réglementaire : il faudra suivre les prochaines versions du document d'orientation de la BaFin et son interprétation lors des contrôles spéciaux, d'éventuelles précisions de la FINMA au-delà de la communication 08/2024 et la ligne directrice formelle sur l'IA attendue de la FMA autrichienne. Reste aussi à savoir si les premières recommandations des superviseurs principaux aux CTPP pousseront vraiment les établissements de la région DACH vers un multicloud effectif ou si l'on s'en tiendra à des plans de sortie symboliques.

En pratique : si tu mets de l'IA en production dans le secteur financier en 2026, tu devrais traiter le document d'orientation de la BaFin comme une norme interne (y compris là où la FMA n'a pas encore sa propre ligne directrice), rendre opérationnels le canal de notification des incidents DORA et les TLPT, utiliser le BSI Test Criteria Catalogue Finance comme filtre fournisseurs et penser l'IA dès le départ comme un système TIC avec une gestion complète du cycle de vie. D'expérience, la conformité représente 30-50 % de l'effort de mise en œuvre dans les secteurs réglementés de la région DACH : c'est à la fois un risque et un avantage concurrentiel.

À titre informatif, ne constitue pas un conseil juridique. Date des sources utilisées : mai 2026, certaines informations mises à jour en octobre 2026 ; les délais provisoires et les lignes directrices annoncées sont susceptibles d'évoluer.