IA conformité DORA banque assurance | Guide 2026
Depuis le 17 janvier 2025, le règlement DORA (Digital Operational Resilience Act, Règlement (UE) 2022/2554) s’applique pleinement à l’ensemble des entités financières européennes. Pour les banques et les assureurs français, cette échéance marque une nouvelle ère pour l’IA conformité DORA banque assurance : elle ne concerne pas seulement les infrastructures informatiques traditionnelles, mais englobe désormais les systèmes d’intelligence artificielle déployés en production.
La question de l’IA et de la conformité DORA en banque et assurance est donc devenue centrale pour les directions informatiques et les équipes de conformité. Cet article analyse les obligations concrètes que DORA impose aux modèles d’IA, la manière de les intégrer dans le cadre de gestion des risques TIC, et les points de vigilance à anticiper dès aujourd’hui.
IA conformité DORA banque assurance | Guide 2026
Temps de lecture : ~11 min
- Résumé en bref
- Quels systèmes d’IA entrent dans le périmètre DORA ?
- IA et conformité DORA en banque et assurance : les obligations concrètes
- Fournisseurs d’IA tiers : les obligations de DORA que vous ne pouvez pas ignorer
- DORA et AI Act : une double conformité pour les systèmes d’IA à haut risque
- Les attentes de l’ACPR et des autorités européennes
- Comment construire une feuille de route de conformité DORA pour vos projets IA
- Aller plus loin avec la conformité IA et DORA
- FAQ
Résumé en bref
Voici les grandes lignes de cet article :
- DORA couvre les systèmes d’IA critiques (scoring crédit, détection de fraude, tarification) au même titre que tout système TIC essentiel.
- Les modèles d’IA doivent être intégrés dans la cartographie des actifs TIC, le cadre de gestion des risques et les plans de continuité d’activité.
- Les fournisseurs de modèles et d’infrastructures IA sont soumis aux obligations de gestion du risque tiers prévues par DORA, avec des clauses contractuelles spécifiques.
- DORA et l’AI Act se combinent pour les systèmes d’IA à haut risque, créant une double couche d’obligations pour les établissements financiers.
- L’ACPR, l’EBA, l’EIOPA, l’ESMA et le BaFin ont chacun précisé leurs attentes, avec des exigences concrètes en matière de gouvernance et de tests.
- Des sanctions significatives sont prévues pour les entités non conformes, ce qui rend l’anticipation indispensable.
Quels systèmes d’IA entrent dans le périmètre DORA ?
Le règlement DORA ne définit pas spécifiquement l’intelligence artificielle, mais il couvre l’ensemble des systèmes TIC dont dépendent les opérations des entités financières. Dès lors qu’un modèle d’IA joue un rôle essentiel dans les processus métiers, il est assimilé à un système TIC critique et tombe pleinement dans le champ du règlement.
Cas d’usage IA financiers concernés par DORA
Les cas d’usage les plus directement concernés dans le secteur financier sont nombreux. Les modèles de scoring crédit automatisé conditionnent l’octroi de prêts à des milliers de clients et sont clairement identifiés comme critiques. La tarification assurantielle algorithmique, utilisée par les assureurs pour calculer les primes en temps réel, entre dans la même catégorie.
Les systèmes de détection de fraude par IA, qui analysent en continu les transactions bancaires, et les outils de surveillance des marchés financiers complètent ce périmètre. Pour chacun de ces systèmes, l’entité financière doit les intégrer à sa cartographie des actifs TIC, à son cadre de gestion des risques TIC, à ses plans de continuité d’activité et de reprise après sinistre, ainsi qu’à ses protocoles de tests de résilience.
IA et conformité DORA en banque et assurance : les obligations concrètes
Le règlement DORA structure ses exigences autour de cinq piliers principaux. Chacun d’eux a des implications directes pour les projets IA en production.
| Pilier DORA | Obligation générale | Application aux systèmes d’IA |
|---|---|---|
| Cadre de gestion des risques TIC | Dispositif documenté et intégré au système global de gestion des risques | Identifier et classer chaque modèle d’IA selon sa criticité ; documenter les risques spécifiques (biais, dérive, adversarial attacks) |
| Tests de résilience | Tests réguliers des systèmes TIC critiques, dont les TLPT (tests de pénétration basés sur la menace) | Inclure les modèles IA dans les tests de robustesse et l’adversarial testing ; tester les scénarios de défaillance des modèles |
| Gestion des incidents TIC | Classification, notification aux autorités et remédiation des incidents majeurs | Définir ce qu’est un incident lié à un modèle d’IA (hallucination critique, dérive de performance, manipulation) et les seuils de notification |
| Risque tiers TIC | Due diligence, clauses contractuelles, droits d’audit, plan de sortie fournisseur | Appliquer ces exigences aux fournisseurs de modèles d’IA, d’API et d’infrastructure cloud MLOps |
| Partage d’informations | Participation aux dispositifs de partage d’informations sur les menaces cyber | Inclure les menaces spécifiques aux systèmes d’IA (data poisoning, prompt injection) dans les échanges sectoriels |
La gestion des risques TIC appliquée aux modèles d’IA
Le cadre de gestion des risques TIC exigé par DORA doit couvrir l’intégralité du cycle de vie des modèles IA. Cela signifie documenter les risques à chaque étape : conception, entraînement, mise en production, monitoring en production et retrait.
L’explainability des modèles devient une exigence opérationnelle et non plus seulement éthique, car elle conditionne la capacité à expliquer une décision lors d’un contrôle ou d’un incident. La journalisation et la traçabilité des décisions IA doivent être assurées de manière à permettre une reconstruction complète de la chaîne de décision en cas d’incident majeur. Ce sujet rejoint les enjeux abordés dans notre guide sur la gouvernance IA et la validation des modèles.
Tests de résilience : ce que DORA impose réellement aux modèles IA
Les tests de résilience constituent l’une des exigences les plus structurantes pour les équipes MLOps des établissements financiers. DORA distingue deux niveaux de tests. Le premier niveau concerne l’ensemble des entités financières et comprend des tests réguliers de robustesse des systèmes TIC critiques. Le second niveau, les tests de pénétration basés sur la menace (TLPT), s’applique aux entités d’importance systémique et couvre les systèmes les plus critiques, y compris les modèles d’IA.
Pour les systèmes d’IA, cela se traduit concrètement par des tests d’adversarial testing (simulation d’attaques visant à tromper le modèle), des tests de dérive de performance dans des conditions dégradées, et des scénarios de reprise après défaillance du modèle. Le BaFin, dans son guide sur les risques TIC liés à l’IA, précise que ces tests doivent être proportionnels à la criticité du système d’IA concerné et intégrés aux processus de sécurité TIC existants.
Bon à savoir
Le BaFin exige que chaque institution financière dispose d’une stratégie IA formellement approuvée par la direction, intégrant les exigences de gouvernance, de sécurité et de supervision des systèmes d’IA dans le cadre DORA. Cette exigence s’applique indépendamment de la taille de l’établissement.
Fournisseurs d’IA tiers : les obligations de DORA que vous ne pouvez pas ignorer
L’un des aspects les plus complexes de la conformité DORA pour les banques et assureurs concerne la gestion des prestataires IA tiers. Qu’il s’agisse d’un fournisseur de modèles de langage, d’une plateforme MLOps en cloud ou d’un éditeur de solution de scoring, ces prestataires entrent dans le périmètre de la gestion des risques liés aux prestataires TIC tiers critiques prévu par DORA.
Due diligence et clauses contractuelles pour les prestataires IA
Les obligations concrètes portent sur plusieurs dimensions. La due diligence préalable à tout contrat doit évaluer la solidité opérationnelle du fournisseur, sa capacité à respecter les exigences de continuité d’activité et ses pratiques de sécurité. Les clauses contractuelles DORA doivent obligatoirement inclure des dispositions sur le reporting d’incidents, les droits d’audit prestataires, les obligations de sécurité et les niveaux de service. Le plan de sortie fournisseur doit être formalisé pour chaque prestataire critique, afin de garantir la continuité des opérations en cas de rupture de la relation contractuelle.
Cette exigence pose une question stratégique majeure pour les établissements financiers : la dépendance à des fournisseurs de modèles dont l’infrastructure est hébergée hors de l’Union européenne crée des risques de conformité supplémentaires, notamment en matière de droits d’audit et de localisation des données. C’est précisément dans ce contexte que des plateformes d’IA souveraines hébergées en France, comme SafeBrain, présentent un avantage structurel : elles permettent d’exercer effectivement les droits d’audit, de localiser les données sur le territoire national et de simplifier la gestion contractuelle dans le cadre DORA. Nous détaillons ces enjeux dans notre article sur l’IA souveraine en France.
DORA et AI Act : une double conformité pour les systèmes d’IA à haut risque
Les banques et assureurs français doivent naviguer simultanément entre deux cadres réglementaires européens majeurs. L’AI Act (Règlement (UE) 2024/1689), applicable progressivement depuis 2024, classe certains systèmes d’IA utilisés dans le secteur financier comme des systèmes d’IA à haut risque. C’est notamment le cas du scoring crédit automatisé, qui figure explicitement dans l’annexe III de l’AI Act.
La combinaison des deux règlements crée une double couche d’obligations. L’AI Act impose des exigences sur la qualité des données d’entraînement, la transparence, la supervision humaine et la documentation technique du modèle. DORA ajoute les exigences de résilience opérationnelle numérique, de gestion des incidents et de maîtrise des prestataires tiers. En pratique, les équipes de conformité doivent construire un référentiel unifié qui adresse simultanément les deux textes pour éviter les doublons et les angles morts.
Notre article sur l’AI Act européen et son impact sur les entreprises apporte des éléments complémentaires sur ce sujet.
À retenir
Le Comité mixte des autorités européennes de surveillance (AES), qui regroupe l’EBA, l’EIOPA et l’ESMA, travaille à la coordination des exigences DORA et AI Act pour éviter les incohérences entre les deux règlements. Les établissements financiers ont intérêt à suivre de près les orientations communes qui seront publiées.
Les attentes de l’ACPR et des autorités européennes
L’ACPR (Autorité de Contrôle Prudentiel et de Résolution) positionne DORA comme une réglementation transverse pour la résilience numérique des banques et assurances françaises. Dans le cadre de ses travaux de supervision, l’ACPR attend des entités qu’elles intègrent leurs solutions IA critiques dans l’annexe sur la gestion des risques liés aux TIC, exigée depuis 2025. Les établissements doivent être en mesure de démontrer que leurs modèles d’IA font l’objet d’une gouvernance documentée, de tests réguliers et d’une surveillance continue.
L’EBA a publié des orientations détaillées sur la mise en oeuvre de DORA pour les entités bancaires, insistant sur l’intégration du cadre de gestion des risques TIC aux dispositifs prudentiels existants. L’EIOPA a, de son côté, précisé les attentes pour les assureurs et intermédiaires, avec un focus particulier sur la continuité des services et la gestion des prestataires TIC tiers. L’ESMA a souligné que DORA harmonise les règles pour 21 types d’entités financières, ce qui inclut les usages d’IA en surveillance des marchés et prévention des abus de marché.
Les sanctions prévues par DORA pour les entités non conformes sont significatives. Les autorités nationales compétentes disposent du pouvoir d’imposer des mesures administratives et des sanctions financières. Pour les prestataires TIC tiers critiques désignés au niveau européen, le cadre de supervision directe par les autorités européennes est pleinement applicable depuis le 17 janvier 2025 et prévoit des astreintes journalières pouvant atteindre 1 % du chiffre d’affaires mondial journalier moyen.
Comment construire une feuille de route de conformité DORA pour vos projets IA
Face à la complexité de ces exigences, une approche structurée en plusieurs étapes permet de progresser efficacement. La première étape consiste à réaliser une cartographie complète de tous les systèmes d’IA en production ou en cours de déploiement, en les classant selon leur criticité opérationnelle pour les activités de l’établissement. Cette cartographie doit être intégrée à la cartographie globale des actifs TIC exigée par DORA.
Les étapes clés d’une feuille de route de conformité DORA pour l’IA
La deuxième étape porte sur l’évaluation des fournisseurs de modèles et d’infrastructures IA au regard des exigences de gestion du risque tiers. Pour chaque prestataire, il convient de vérifier la conformité des clauses contractuelles existantes, d’identifier les manques et de négocier les avenants nécessaires. La troisième étape consiste à intégrer les modèles d’IA critiques dans les plans de tests de résilience, en définissant des scénarios de test adaptés aux risques spécifiques des systèmes d’IA, notamment le data poisoning ou les attaques par prompt injection, ainsi que la défaillance de l’infrastructure.
Enfin, la mise en place d’un dispositif de monitoring en production et de MLOps et gouvernance des modèles permet d’assurer la surveillance continue et la traçabilité requises par DORA. Sur ce dernier point, la gouvernance IA est un sujet que nous avons traité en détail dans notre article dédié sur la gouvernance IA et le comité d’éthique. Ces travaux de conformité peuvent aussi s’appuyer sur notre checklist de conformité IA et RGPD.
Aller plus loin avec la conformité IA et DORA
Le règlement DORA a profondément modifié le cadre réglementaire dans lequel les banques et assureurs français déploient leurs systèmes d’intelligence artificielle. Les modèles de scoring, de détection de fraude et de tarification algorithmique ne peuvent plus être gérés en dehors du cadre de gestion des risques TIC.
La maîtrise des prestataires IA tiers, la capacité à tester la résilience des modèles en production et la combinaison avec les exigences de l’AI Act constituent les trois défis majeurs à relever dès maintenant. Les établissements qui anticipent ces obligations en construisant une gouvernance IA robuste et en choisissant des partenaires technologiques conformes aux exigences DORA seront mieux positionnés pour répondre aux attentes croissantes de l’ACPR et des autorités européennes.
En résumé : IA et conformité DORA en banque assurance
En intégrant leurs modèles d’IA critiques au cadre de gestion des risques TIC, en maîtrisant leurs prestataires tiers et en articulant DORA avec l’AI Act, les banques et assureurs peuvent transformer une contrainte réglementaire en levier de fiabilité et de transparence. Une approche progressive, structurée autour de la cartographie des usages, des tests de résilience et de la gouvernance des modèles, permet de sécuriser les projets IA tout en conservant leur valeur métier.
FAQ
Un modèle d’IA utilisé uniquement en interne (sans impact client direct) est-il concerné par DORA ?
Oui, dès lors qu’il est considéré comme essentiel au fonctionnement des opérations de l’entité financière. La criticité ne se mesure pas uniquement à l’impact client mais aussi à l’impact sur la continuité des processus internes. Un modèle d’IA utilisé pour la surveillance des risques opérationnels ou la gestion de la liquidité peut ainsi être qualifié de système TIC critique.
Quelle est la différence entre un audit DORA et un audit AI Act pour un système de scoring crédit ?
L’audit DORA porte sur la résilience opérationnelle du système : sa disponibilité, sa sécurité, la gestion des incidents et la maîtrise du prestataire. L’audit AI Act porte sur la qualité du modèle lui-même : données d’entraînement, biais, supervision humaine, documentation technique. Les deux audits sont complémentaires et doivent être coordonnés pour éviter les redondances.
Les établissements de taille modeste (banques régionales, mutuelles) sont-ils soumis aux mêmes obligations DORA que les grandes banques ?
DORA prévoit un principe de proportionnalité : les obligations sont calibrées en fonction de la taille, du profil de risque et de la complexité de l’entité. Les petites entités financières non complexes bénéficient d’un cadre simplifié de gestion des risques TIC. En revanche, les exigences relatives à la gestion des incidents et aux prestataires tiers s’appliquent à toutes les entités entrant dans le champ du règlement.
Comment documenter la traçabilité des décisions d’un modèle d’IA pour satisfaire aux exigences DORA ?
La journalisation doit capturer a minima les données d’entrée utilisées par le modèle, la version du modèle ayant produit la décision, l’horodatage et le résultat de la décision. Pour les systèmes à haut risque au sens de l’AI Act, des logs supplémentaires sur la supervision humaine sont requis. Ces journaux doivent être conservés selon des durées définies par les réglementations sectorielles applicables et accessibles lors des contrôles de l’ACPR.
Quelles clauses contractuelles DORA sont indispensables dans un contrat avec un fournisseur de plateforme IA ?
Le règlement DORA impose a minima des clauses sur la description précise des services fournis, les niveaux de service et leur mesure, la localisation des données et des traitements, les obligations de notification d’incidents dans les délais DORA, les droits d’audit de l’entité financière sur le prestataire, les modalités de sous-traitance, et un plan de sortie permettant la continuité des opérations en cas de rupture contractuelle.
Existe-t-il un registre centralisé des prestataires TIC tiers critiques désignés au niveau européen ?
Oui, les autorités européennes de surveillance (EBA, EIOPA, ESMA) sont chargées de désigner les prestataires TIC tiers critiques au niveau de l’UE et d’exercer une supervision directe sur eux. Les entités financières qui utilisent ces prestataires désignés doivent s’assurer que leurs contrats respectent les exigences DORA et coopérer avec les autorités dans le cadre des inspections.
