Banques et assurances : le dossier de la transformation numérique conforme

Depuis le 17 janvier 2025, le règlement DORA sur la résilience opérationnelle numérique s’applique à l’ensemble du secteur financier de l’Union européenne. Il ne vient pas seul. En quelques années, banques et assureurs ont vu s’empiler des textes qui encadrent l’intelligence artificielle, les données, la cybersécurité, l’accessibilité des services et la lutte contre le blanchiment. Le résultat, dans beaucoup d’établissements, est un portefeuille de projets de conformité qui avancent à côté des projets de transformation, avec leurs propres équipes, leurs propres budgets et leurs propres documents.

Ce dossier défend une autre approche : traiter la conformité comme une propriété des systèmes de la banque numérique et de l’assurance, conçue en même temps qu’eux. Il s’adresse aux directions générales, aux directions des risques, de la conformité et des systèmes d’information des banques, des assureurs, des mutuelles et des établissements de paiement, en Europe et dans les zones francophones qui s’inspirent de ses règles.

La pile réglementaire en un tableau

Chaque texte a son objet, son calendrier et son autorité. Les connaître ensemble permet de repérer les recoupements, et d’éviter de construire trois fois le même registre.

Deux recoupements méritent d’être notés d’emblée. DORA, l’AI Act et le RGPD exigent tous trois une connaissance précise des systèmes et des prestataires : un inventaire commun, tenu à jour, sert les trois. Et l’AI Act comme le RGPD imposent de pouvoir expliquer une décision prise à l’égard d’un client : la même traçabilité répond aux deux.

DORA : ce qui change dans les systèmes

DORA s’organise autour de cinq piliers : la gestion des risques liés aux technologies de l’information et de la communication, la notification des incidents majeurs, les tests de résilience, la gestion des risques liés aux prestataires tiers, et le partage d’informations sur les menaces. Le texte remplace une mosaïque d’orientations nationales et européennes, comme celles de l’Autorité bancaire européenne sur la gestion des risques informatiques et sur l’externalisation, par un règlement directement applicable.

Dans les systèmes, trois conséquences se font sentir dès les premiers mois. L’inventaire d’abord : les fonctions critiques ou importantes, les actifs qui les supportent et leurs dépendances doivent être identifiés et documentés. Beaucoup d’établissements découvrent à cette occasion des applications sans propriétaire et des flux non documentés. Le registre d’information des prestataires ensuite : chaque contrat de service informatique, avec ses sous-traitants, ses lieux de traitement et les fonctions qu’il soutient, doit y figurer dans un format défini par les autorités européennes. La gestion des incidents enfin : classer un incident, le notifier dans les délais, produire un rapport final suppose des outils de détection et de suivi capables de fournir les informations demandées, pas seulement une procédure écrite.

Les tests de pénétration fondés sur la menace, la forme la plus exigeante de test prévue par DORA, ne concernent que les entités désignées par les autorités. Les autres doivent néanmoins tester régulièrement leurs systèmes, leurs sauvegardes et leurs plans de continuité, et documenter les résultats.

L’intelligence artificielle dans le crédit et l’assurance

L’AI Act classe parmi les systèmes à haut risque deux usages au cœur des métiers financiers : l’évaluation de la solvabilité et la notation de crédit des personnes physiques, à l’exception de la détection de fraude, et l’évaluation des risques et la tarification en assurance vie et en assurance santé. Les obligations correspondantes, qui s’appliqueront pour l’essentiel à partir du 2 août 2026, portent sur la gestion des risques, la qualité des données d’entraînement, la documentation technique, la journalisation, la transparence envers les utilisateurs, le contrôle humain, la robustesse et la cybersécurité.

Le RGPD pesait déjà sur ces usages. Son article 22 encadre les décisions fondées exclusivement sur un traitement automatisé produisant des effets juridiques ou significatifs. La Cour de justice de l’Union européenne a précisé en décembre 2023, dans l’affaire SCHUFA, que l’établissement d’une note de solvabilité par un tiers peut constituer une telle décision lorsqu’elle joue un rôle déterminant dans l’octroi d’un crédit. Le contrôle humain doit donc être réel, et l’explication fournie au client intelligible.

Pour une banque ou un assureur, l’enjeu immédiat n’est pas de réécrire ses modèles, mais de savoir lesquels existent. Les modèles de notation, de tarification, de détection de fraude et de lutte contre le blanchiment se sont accumulés sur des années, développés en interne ou achetés. Un inventaire, avec pour chaque modèle sa finalité, ses données, son propriétaire, ses performances et sa documentation, est le préalable à toute qualification au titre de l’AI Act. Les pratiques interdites et l’obligation de maîtrise de l’IA par le personnel, applicables depuis le 2 février 2025, donnent déjà une raison de le constituer.

Le cœur de système : moderniser sans rompre

Beaucoup de banques et d’assureurs fonctionnent encore sur des systèmes centraux conçus il y a plusieurs décennies, robustes, mais coûteux à faire évoluer et maîtrisés par des équipes qui partent à la retraite. La tentation du remplacement complet est forte ; son histoire est riche en échecs coûteux, parce qu’un cœur de système concentre des milliers de règles métier jamais documentées.

Les approches qui réussissent sont progressives. Elles consistent à extraire une fonction à la fois, par exemple la gestion des clients, les paiements, puis les produits, derrière des interfaces stables, et à la reconstruire ou la remplacer pendant que l’ancien système continue de fonctionner. Chaque étape passe par une période de fonctionnement en parallèle, où l’ancien et le nouveau traitent les mêmes opérations et où les écarts sont analysés avant la bascule.

Cette progressivité a un intérêt réglementaire direct. DORA exige que les changements soient maîtrisés et réversibles ; le fonctionnement en parallèle et la capacité de revenir en arrière en sont la démonstration. La migration des données, souvent le poste le plus sous-estimé, doit être traitée comme un projet à part entière, avec ses contrôles de qualité, sa traçabilité et ses critères d’acceptation.

Le cloud et la dépendance aux prestataires

Le recours au cloud public est devenu courant dans le secteur financier, pour des applications périphériques d’abord, puis pour des fonctions plus centrales. DORA ne l’interdit pas ; il l’encadre. Les contrats avec les prestataires informatiques doivent comporter des clauses précises sur la localisation des données, les niveaux de service, l’accès des autorités et de l’établissement pour audit, la notification des incidents et les conditions de sortie. Les prestataires jugés critiques pour le secteur seront en outre placés sous la surveillance directe des autorités européennes de supervision.

La stratégie de sortie est la clause la plus souvent traitée de façon théorique. Pour chaque fonction critique hébergée chez un tiers, l’établissement doit savoir comment il la reprendrait ou la transférerait, en combien de temps et avec quelles données. Le règlement européen sur les données, applicable à partir du 12 septembre 2025, renforce par ailleurs les obligations des fournisseurs de cloud en matière de changement de prestataire, ce qui rend ces plans plus réalistes à construire.

Identité, fraude et lutte contre le blanchiment

L’entrée en relation à distance est devenue la norme dans la banque de détail. Elle repose sur une vérification d’identité, souvent par capture de la pièce d’identité et d’une vidéo, qui doit satisfaire aux obligations de vigilance tout en restant fluide. Le portefeuille européen d’identité numérique prévu par le règlement eIDAS révisé, que les États membres doivent mettre à disposition dans les années qui viennent, changera ce parcours : les banques, soumises à des obligations d’authentification forte, devront l’accepter à la demande de leurs clients. Nous avons détaillé ces conséquences dans notre note sur eIDAS 2.

Le paquet européen de lutte contre le blanchiment adopté en 2024 crée une autorité européenne dédiée et un règlement unique, directement applicable, qui harmonise les obligations de vigilance. Il s’appliquera pour l’essentiel à partir de 2027. D’ici là, les établissements ont intérêt à vérifier que leurs outils de connaissance client et de surveillance des opérations produisent des décisions traçables : pourquoi une alerte a été levée, qui l’a traitée, sur quelle base elle a été classée ou déclarée.

La fraude, enfin, s’est déplacée vers la manipulation des clients eux-mêmes, qui sont amenés à autoriser des virements au profit de fraudeurs. Le règlement européen de 2024 sur les virements instantanés impose notamment une vérification de la concordance entre le nom du bénéficiaire et son identifiant de compte. Ce type de contrôle, simple dans son principe, suppose des systèmes capables de répondre en quelques secondes, à tout moment.

L’accessibilité : l’échéance de juin 2025

À partir du 28 juin 2025, l’acte européen sur l’accessibilité s’applique aux services bancaires destinés aux consommateurs, aux sites et applications de commerce en ligne, ainsi qu’à certains terminaux comme les distributeurs automatiques. Les sites, applications mobiles, parcours de souscription et documents contractuels doivent être utilisables par les personnes handicapées, sur la base des exigences de la norme européenne EN 301 549, qui renvoie aux règles internationales WCAG.

Pour beaucoup d’établissements, l’échéance arrive alors que les parcours numériques ont été conçus sans cette contrainte. La priorité est de traiter les parcours les plus utilisés et les plus critiques (connexion, consultation des comptes, virement, souscription, réclamation) et de cesser de produire des contenus non accessibles. L’accessibilité rejoint ici la conformité au sens large : elle se prouve par des audits, des déclarations et une organisation, pas par une affirmation.

Hors de l’Union : les zones francophones

Dans l’espace UEMOA, en zone CEMAC, au Maghreb ou ailleurs dans le monde francophone, les textes européens ne s’appliquent pas directement. Leur influence est pourtant réelle. Les régulateurs bancaires régionaux, comme la Commission bancaire de l’UMOA ou la COBAC, et la CIMA pour l’assurance, renforcent leurs propres exigences en matière de gestion des risques informatiques, de cybersécurité et de lutte contre le blanchiment, souvent en s’inspirant des standards internationaux. Les filiales de groupes européens appliquent les politiques de leur maison mère. Et les prestataires technologiques, qui servent des clients sur plusieurs continents, alignent leurs contrats et leurs produits sur les exigences les plus strictes.

Pour un établissement de ces zones, la démarche raisonnable consiste à identifier les exigences locales applicables, puis à les compléter par les principes européens qui ont un intérêt opérationnel propre (inventaire des systèmes, gestion des prestataires, traçabilité des décisions), sans chercher à transposer des obligations qui ne s’appliquent pas.

La conformité comme propriété du système

Le point commun de tous ces textes est qu’ils demandent des preuves. Prouver qu’un incident a été notifié dans les délais. Prouver qu’un modèle de notation a été validé avant sa mise en production et qu’il est surveillé. Prouver qu’une alerte de blanchiment a été traitée par une personne habilitée. Prouver qu’un client a été informé d’une décision automatisée et qu’il a pu la contester.

Lorsque ces preuves sont produites à la main, après coup, pour répondre à un contrôle, la conformité coûte cher et reste fragile. Lorsqu’elles sont produites par les systèmes eux-mêmes, au moment où les décisions sont prises, elles deviennent un sous-produit de l’activité. C’est la différence entre une conformité documentaire et une conformité opérationnelle.

Concrètement, cela suppose trois choses. Des décisions journalisées avec leur auteur, leur date, leur base et les données utilisées, dans un journal protégé contre la modification. Des référentiels partagés entre les fonctions risques, conformité et systèmes d’information : un seul inventaire des applications, des modèles et des prestataires. Et des contrôles automatisés là où c’est possible, qui signalent un écart au lieu d’attendre l’audit pour le découvrir.

Une méthode en six étapes

1. Cartographier les obligationsPour chaque texte applicable, lister les exigences qui touchent les systèmes et repérer les recoupements. Une seule exigence d’inventaire, de traçabilité ou de gestion des prestataires sert souvent plusieurs textes.
2. Inventorier les systèmes, les modèles et les prestatairesUn référentiel unique, partagé, avec un propriétaire pour chaque élément. C’est le socle de DORA, de l’AI Act et du RGPD à la fois.
3. Qualifier et prioriserFonctions critiques au sens de DORA, systèmes d’IA à haut risque au sens de l’AI Act, parcours soumis à l’accessibilité. Traiter d’abord ce qui est à la fois critique et en écart.
4. Intégrer les exigences aux projetsChaque projet de transformation reçoit, dès son cadrage, la liste des exigences qui le concernent et les preuves qu’il devra produire. La conformité est validée à la conception, pas à la recette.
5. Automatiser les preuvesJournalisation des décisions, suivi des incidents, surveillance des modèles, registre des prestataires alimenté par les contrats. Ce qui est produit par le système n’a pas à être reconstitué.
6. Tester et revoirExercices de continuité, tests de sortie partiels, revues de modèles, audits d’accessibilité. Chaque test produit un plan d’action suivi par la direction.

Le premier pas

Le premier pas utile est souvent le moins spectaculaire : rapprocher les inventaires existants. La direction des systèmes d’information a sa liste d’applications, la direction des risques ses fonctions critiques, la conformité son registre des traitements, les achats ses contrats, les équipes de données leurs modèles. Les réunir dans un référentiel commun révèle en quelques semaines les angles morts, et donne à chaque projet de transformation la base qui lui manquait.

Notre expertise cybersécurité et conformité accompagne ce travail, de la cartographie des obligations à l’organisation des tests. Notre produit Gouvernance répond à l’exigence commune à tous ces textes : prouver qui a décidé quoi, quand, et sur quelle base.

1. Règlement (UE) 2022/2554 du 14 décembre 2022 sur la résilience opérationnelle numérique du secteur financier (DORA), Journal officiel de l’Union européenne.
2. Règlement (UE) 2024/1689 du 13 juin 2024 établissant des règles harmonisées concernant l’intelligence artificielle, annexe III.
3. Cour de justice de l’Union européenne, arrêt du 7 décembre 2023, SCHUFA Holding (Scoring), C-634/21.
4. Directive (UE) 2019/882 du 17 avril 2019 relative aux exigences en matière d’accessibilité applicables aux produits et services.
5. Autorité bancaire européenne, orientations sur la gestion des risques liés aux TIC et à la sécurité (2019) et sur l’externalisation (2019).

Questions fréquentes

DORA s'applique-t-il aux petites entités financières ?

Oui, DORA s'applique à un large éventail d'entités financières, mais avec un principe de proportionnalité : certaines obligations, comme les tests de pénétration fondés sur la menace, ne concernent que les entités désignées par les autorités, et un cadre simplifié existe pour certaines petites entités.

Un modèle de notation de crédit est-il forcément un système d'IA à haut risque ?

L'AI Act classe à haut risque les systèmes d'IA destinés à évaluer la solvabilité des personnes physiques ou à établir leur note de crédit, à l'exception de ceux utilisés pour détecter la fraude financière. Un modèle statistique classique peut entrer dans la définition de système d'IA selon sa conception ; l'analyse se fait au cas par cas.

Les obligations de l'AI Act s'appliquent-elles déjà ?

Les pratiques interdites et l'obligation de maîtrise de l'IA s'appliquent depuis le 2 février 2025. Les obligations relatives aux systèmes à haut risque, dont la notation de crédit, s'appliquent pour l'essentiel à partir du 2 août 2026.

Une banque hors de l'Union européenne est-elle concernée ?

Directement, seulement si elle opère dans l'Union ou y fournit des services. Indirectement, souvent : les filiales de groupes européens, les correspondants bancaires et les régulateurs nationaux s'inspirent de ces textes, et les prestataires technologiques les appliquent à tous leurs clients.