DORA, AI Act, RGPD pour FinTech : le guide opérationnel 2026
Depuis le 17 janvier 2025, les entités financières européennes naviguent dans un nouveau régime de résilience opérationnelle imposé par le Règlement DORA (Digital Operational Resilience Act, UE 2022/2554). En parallèle, l’AI Act (Règlement UE 2024/1689) entre progressivement en application jusqu’en août 2027, tandis que le RGPD continue de s’appliquer avec une jurisprudence IA en mouvement constant.
Pour les FinTechs, banques, assurances et sociétés de gestion qui déploient des systèmes d’intelligence artificielle, la question n’est plus « devons-nous nous mettre en conformité ? » mais « comment satisfaire les trois cadres simultanément, sans casser nos roadmaps produit ? ».
Ce guide propose une méthode opérationnelle 2026 pour cartographier vos obligations cumulées, prioriser les chantiers de conformité, et industrialiser la gouvernance des systèmes IA — sans alourdir vos cycles de livraison.
1. Calendrier réglementaire 2025-2027
Avant d’agir, il faut connaître précisément la séquence d’entrée en vigueur des trois textes. Cette chronologie détermine vos priorités opérationnelles.
| Date | Texte | Article(s) | Effet pratique |
|---|---|---|---|
| 2018-05-25 | RGPD | Tous | Continuité — protection données personnelles |
| 2025-01-17 | DORA | Tous | Résilience opérationnelle numérique applicable aux entités financières et prestataires TIC critiques |
| 2025-02-02 | AI Act | Art. 5 | Pratiques d’IA interdites applicables (manipulation, scoring social, identification biométrique en temps réel sauf exceptions) |
| 2025-08-02 | AI Act | Codes de bonne conduite | Obligations modèles IA à usage général (GPAI) |
| 2026-08-02 | AI Act | Gouvernance + sanctions | Mise en place du Bureau de l’IA + sanctions applicables |
| 2027-08-02 | AI Act | Art. 6 (systèmes IA haut risque) | Obligations complètes pour systèmes IA haut risque (incluant scoring crédit, KYC, détection fraude) |
Ce que cela signifie en pratique : à fin 2026, une FinTech qui exploite un système IA pour le scoring crédit ou la détection de fraude doit satisfaire DORA + RGPD intégralement, et anticiper AI Act art. 6 pour ne pas se retrouver hors conformité en août 2027.
Pour la documentation détaillée, consultez notre page Expertise FinTech qui détaille les obligations DORA et ACPR par typologie d’institution.
2. DORA — Résilience opérationnelle numérique
Champ d’application
DORA s’applique à toutes les entités financières opérant en UE : établissements de crédit, entreprises d’investissement, sociétés de gestion d’OPCVM/FIA, prestataires de services de paiement, infrastructures de marché, assurances et réassurances, sociétés financières non bancaires significatives.
Point critique souvent négligé : DORA s’applique aussi aux prestataires TIC tiers critiques (cloud providers, éditeurs IA, intégrateurs) qui fournissent des services à ces entités. Si vous déployez de l’IA pour une banque française, vous êtes dans le périmètre indirect via votre client.
Les 5 piliers DORA
Le règlement structure ses obligations autour de cinq blocs :
- Gestion des risques TIC (art. 5-16) : cadre de gouvernance, identification des risques, contrôles, surveillance continue
- Gestion des incidents TIC (art. 17-23) : classification, notification dans les délais réglementaires, reporting au superviseur (ACPR en France)
- Tests de résilience opérationnelle (art. 24-27) : tests réguliers, dont des TLPT (Threat-Led Penetration Tests) pour les acteurs significatifs
- Gestion des risques liés aux tiers TIC (art. 28-44) : registre des prestataires, due diligence, plans de sortie, droit d’audit contractuel
- Partage d’information sur les menaces (art. 45) : participation aux communautés sectorielles
Focus article 28 — Le registre des prestataires TIC
C’est l’article qui transforme le plus profondément les pratiques opérationnelles. Toute entité financière soumise à DORA doit tenir un registre exhaustif et à jour de ses prestataires TIC, avec :
- Identification du prestataire (raison sociale, SIREN/SIRET équivalent étranger)
- Description du service rendu et des données traitées
- Localisation géographique des serveurs et du personnel
- SLA contractuels et indicateurs de performance
- Droit d’audit contractuel pour le client et son superviseur (ACPR)
- Plan de sortie documenté (réversibilité technique et juridique)
- Évaluation du caractère critique ou important de la fonction sous-traitée
L’ACPR a déjà commencé à demander ces registres lors de ses contrôles 2025-2026. Ne pas en avoir = non-conformité immédiate.
Sanctions DORA
Les autorités de supervision (ACPR en France, EBA/ESMA/EIOPA au niveau UE) peuvent appliquer des sanctions administratives jusqu’à 2 % du chiffre d’affaires annuel mondial pour les entités financières, ou des sanctions plus lourdes pour les prestataires TIC critiques désignés.
Cas concret : une société de gestion qui externalise sa détection fraude à un éditeur IA hébergé sur AWS US doit (a) inscrire l’éditeur IA dans son registre art. 28, (b) documenter le risque Cloud Act US, (c) prévoir un plan de sortie technique en moins de 12 mois, (d) auditer annuellement la résilience du prestataire. Sans ces éléments, l’ACPR peut suspendre le service en cas de contrôle inopiné.
3. AI Act — Gouvernance des systèmes d'intelligence artificielle
Classification par niveau de risque
L’AI Act adopte une approche par les risques en quatre niveaux :
| Niveau | Statut | Exemples FinTech |
|---|---|---|
| Risque inacceptable | Interdit (art. 5) | Manipulation cognitive, scoring social, identification biométrique temps réel sauf exceptions |
| Haut risque | Obligations strictes (art. 6 + Annexe III) | Scoring crédit, évaluation solvabilité, KYC/AML automatisé dans certains cas, recrutement, contrôle frontières |
| Risque limité | Transparence (art. 50) | Chatbots, génération de contenus, assistants utilisateurs |
| Risque minimal | Aucune obligation | Filtres anti-spam, jeux, recommandations basiques |
Point crucial pour les FinTechs : selon l’Annexe III, les systèmes IA utilisés pour évaluer la solvabilité ou établir la cote de crédit des personnes physiques sont classés haut risque. Cela inclut les modèles de machine learning utilisés pour les décisions de prêt, la tarification d’assurance individuelle, ou certains algorithmes de KYC.
Article 13 — Documentation technique
Pour un système IA haut risque, vous devez tenir à jour une documentation technique comprenant :
- Description générale du système IA et de sa finalité prévue
- Données d’entraînement, validation et test (provenance, qualité, biais identifiés)
- Spécifications techniques des algorithmes
- Mesures de surveillance humaine prévues (art. 14)
- Métriques de performance, robustesse, cybersécurité
- Notice d’utilisation à destination du déployeur
Cette documentation doit être conservée 10 ans après mise sur le marché et accessible aux autorités de surveillance sur demande.
Article 50 — Transparence
Quel que soit le niveau de risque, certains systèmes IA doivent informer l’utilisateur qu’il interagit avec une IA :
- Chatbots et assistants conversationnels
- Systèmes de génération de contenus (deepfakes, synthèse vocale)
- Systèmes de catégorisation biométrique ou reconnaissance émotionnelle
Pour une FinTech qui déploie un assistant client conversationnel, l’art. 50 exige un disclaimer visible dès le premier message. Pas en bas de page, pas dans les CGU — au début de l’interaction.
Sanctions AI Act
Les sanctions sont calibrées sur le niveau de violation :
- Violations art. 5 (pratiques interdites) : jusqu’à 35 M€ ou 7 % du CA mondial
- Violations art. 6-50 (haut risque, transparence) : jusqu’à 15 M€ ou 3 % du CA mondial
- Documentation incorrecte / non-coopération : jusqu’à 7,5 M€ ou 1 % du CA mondial
Cumul DORA + AI Act
Pour une banque qui déploie un système IA haut risque (par exemple un modèle de scoring crédit) :
- DORA impose la résilience opérationnelle (tests, plan de sortie, registre)
- AI Act art. 6 impose la documentation technique, la surveillance humaine, l’évaluation de conformité
- AI Act art. 50 impose la transparence si le client interagit avec le système
Les obligations se superposent sans s’annuler. Une seule documentation art. 13 ne suffit pas pour la conformité DORA — il faut aussi le registre art. 28 et les tests de résilience.
4. RGPD — Protection des données et IA
Article 22 — Décisions automatisées
L’article 22 du RGPD interdit les décisions entièrement automatisées produisant des effets juridiques sur les personnes, sauf exceptions strictes (consentement explicite, exécution contractuelle, autorisation légale).
Application FinTech : un refus de crédit purement algorithmique, sans intervention humaine significative, est en principe interdit. La pratique des banques européennes est d’introduire un superviseur humain qui examine les cas refusés par l’algorithme, conformément à l’art. 22 RGPD et à l’art. 14 AI Act (surveillance humaine pour systèmes haut risque).
Article 28 — Sous-traitance et DPA
Tout prestataire TIC qui traite des données personnelles pour le compte d’une entité financière doit être lié par un Data Processing Agreement (DPA) conforme à l’article 28 RGPD. Ce DPA doit couvrir :
- L’objet, la durée, la nature et la finalité du traitement
- Les catégories de données personnelles
- Les obligations du sous-traitant (sécurité, notification de violation, audit)
- Les sous-traitants ultérieurs autorisés
- La localisation géographique des serveurs
Le piège classique : un prestataire IA sur infrastructure AWS ou Azure US déclare « hébergement EU » dans son contrat, mais les serveurs de management, les sauvegardes ou les logs transitent par les datacenters américains. Le Cloud Act US (Clarifying Lawful Overseas Use of Data Act, 2018) autorise alors les autorités américaines à exiger l’accès à ces données — ce qui constitue un transfert hors UE non autorisé.
Cloud Act vs RGPD — Pourquoi la souveraineté de l’infrastructure est critique
Le Cloud Act crée une incompatibilité juridique entre le RGPD et l’usage de cloud providers américains pour les données sensibles. La CNIL, dans plusieurs avis, a souligné que les transferts vers les États-Unis ne bénéficient plus d’une décision d’adéquation pleine depuis l’invalidation du Privacy Shield (Schrems II, 2020) et l’arrivée du Data Privacy Framework (2023) — dont la robustesse juridique reste contestée.
Conséquence pratique : pour une FinTech, héberger les données IA sur des infrastructures hors juridiction américaine n’est plus une option marketing, c’est un prérequis de conformité.
Les pays bénéficiant d’une décision d’adéquation au sens de l’article 45 RGPD (niveau de protection équivalent au RGPD reconnu par la Commission européenne) sont, en 2026 : Suisse, Andorre, Argentine, Canada (commercial), Iles Féroé, Guernesey, Israël, Ile de Man, Japon, Jersey, Nouvelle-Zélande, République de Corée, Royaume-Uni, Uruguay, États-Unis (DPF, contesté). L’Allemagne, la France, et tous les États membres UE sont par construction conformes (zone EEE).
5. Méthode d'audit opérationnel — 5 étapes
Comment passer du cadre réglementaire à un plan d’action concret ? Voici la méthode que nous appliquons sur les missions OGMA Systems.
Étape 1 — Cartographier les systèmes IA déployés
Listez tous les systèmes IA actifs dans votre organisation, qu’ils soient internes ou externalisés :
- Modèles de scoring crédit ou tarification
- Algorithmes de détection de fraude ou AML
- Systèmes KYC automatisés (OCR, NLP, vérification croisée)
- Chatbots et assistants conversationnels
- Outils de monitoring transactionnel
- Modèles de RH (recrutement, évaluation)
Pour chaque système, documentez : finalité, données traitées, fournisseur (interne ou tiers), niveau de criticité métier.
Étape 2 — Classifier par niveau de risque AI Act
Sur la base de l’Annexe III de l’AI Act, classez chaque système :
- Risque inacceptable → arrêt immédiat (rare, mais à vérifier)
- Haut risque → obligations art. 6 + 13 + 14
- Risque limité → transparence art. 50 uniquement
- Risque minimal → veille de conformité (pas d’obligation supplémentaire)
Étape 3 — Auditer la documentation existante
Pour les systèmes haut risque, vérifiez :
- Documentation technique art. 13 : description, données, performance, surveillance humaine
- DPA art. 28 RGPD : tous les prestataires impliqués sont-ils sous DPA ? Localisation OK ?
- Évaluation d’impact RGPD (EIPD) : faite et à jour ?
- Notice d’utilisation art. 13.3 : disponible pour le déployeur ?
Étape 4 — Tester la résilience DORA
Pour les fonctions critiques :
- Scénarios de stress (panne prestataire, attaque DDoS, fuite de données)
- Tests de plan de sortie (combien de temps pour basculer vers un autre prestataire ?)
- Tests TLPT si applicable (Threat-Led Penetration Tests)
- Documentation des résultats et des plans d’amélioration
Étape 5 — Remontée des écarts et roadmap correction
Consolidez les écarts en un seul document priorisé :
| Priorité | Écart identifié | Cadre | Échéance | Effort |
|---|---|---|---|---|
| P0 | Registre art. 28 DORA inexistant | DORA | Immédiat | 2-4 semaines |
| P1 | Documentation art. 13 AI Act incomplète sur 3 modèles | AI Act | < 6 mois | 6-8 semaines |
| P2 | DPA RGPD obsolète sur 2 prestataires | RGPD | < 3 mois | 1-2 semaines |
| P3 | Tests de résilience non documentés | DORA | < 12 mois | 8-12 semaines |
Cette roadmap devient votre plan de mise en conformité présentable à l’ACPR ou à votre comité d’audit.
6. Le Compliance Gate fail-closed — pourquoi la gouvernance technique change tout
L’audit ponctuel produit une photo à un instant T. Six mois plus tard, après plusieurs mises à jour modèles et changements de prestataires, la photo est obsolète. C’est le piège classique des démarches de conformité IA.
Notre approche — Gouvernance technique permanente
Chez OGMA Systems, nous installons un Compliance Gate fail-closed dans la chaîne d’exécution des systèmes IA déployés chez nos clients. Concrètement :
- Chaque décision IA passe par un composant de vérification de conformité avant exécution
- Si un doute existe (donnée manquante, score sous le seuil de confiance, sortie hors périmètre attendu), l’action est bloquée par défaut (fail-closed) et remontée à un superviseur humain
- Chaque blocage est journalisé avec horodatage, raison du blocage, identifiant utilisateur, et décision finale
Le terme fail-closed est emprunté à la sécurité informatique : par opposition à fail-open où une défaillance laisse passer le trafic, fail-closed signifie que l’absence d’autorisation explicite bloque l’action. Le défaut est sécurisé, pas l’inverse.
Lien avec AI Act et DORA
Le Compliance Gate fail-closed satisfait simultanément :
- AI Act art. 14 (surveillance humaine) — chaque décision douteuse est remontée à un humain
- AI Act art. 13 (documentation) — chaque blocage produit un journal exploitable
- DORA art. 17-23 (gestion incidents) — les blocages systématiques alimentent la base d’incidents
- RGPD art. 22 (décisions automatisées) — l’humain reprend la main sur les cas refusés
Et surtout, il permet de prouver à l’ACPR ou à un superviseur que la gouvernance n’est pas seulement déclarative, elle est opérationnelle 24/7.
Le Compliance Gate est un des trois piliers techniques d’OGMA Systems. Il est documenté en détail sur notre page Solutions avec une description de l’architecture RAG souverain hébergée Scaleway.
7. Souveraineté de l'infrastructure — au-delà du marketing
« Souveraineté » est devenu un mot-valise. En 2026, il faut être précis : qu’est-ce qu’une infrastructure souveraine pour une FinTech française qui doit satisfaire DORA + RGPD + AI Act ?
Critères opérationnels de souveraineté
Une infrastructure peut être qualifiée de souveraine pour une FinTech française si et seulement si :
- Localisation des données : tous les serveurs (production, sauvegarde, logs, management) sont en France ou dans l’EEE, ou dans un pays adéquat art. 45 RGPD
- Personnel d’opération : les administrateurs ayant accès aux données sont sous juridiction UE/EEE
- Juridiction du contrat : le contrat principal est régi par le droit français ou d’un État membre UE
- Absence d’extraterritorialité : aucun cadre légal étranger (Cloud Act US, CLOUD Act, FISA 702) ne peut s’appliquer aux données
Ce dernier critère est le plus discriminant. Il exclut de facto les hyperscalers américains (AWS, Azure, GCP) pour les données sensibles, même si leurs filiales européennes proposent des contrats locaux.
Notre stack — 5 sous-traitants documentés
Notre politique de confidentialité §4 liste les 5 sous-traitants RGPD au sens de l’article 28 :
| Sous-traitant | Rôle | Localisation | Cadre RGPD |
|---|---|---|---|
| OGMA Systems (Florian Andreani) | Responsable du traitement | France (Toulon) | Art. 6.1.b/f |
| Scaleway SAS | Hébergement site, base de données, sauvegardes | France (Paris & Lille) | Art. 28 — DPA signé |
| Plausible Insights OÜ (Plausible Analytics) | Mesure d’audience cookieless | Estonie (UE) · hébergement Hetzner Allemagne (UE) | Art. 28 — DPA RGPD-conforme |
| Google LLC (UpdraftPlus + Workspace EU) | Sauvegardes chiffrées AES-256 | UE (Workspace EU) | Art. 28 — chiffrement avant transfert |
| Proton AG | Calendrier de réservation audit | Suisse — pays adéquat art. 45 | Art. 28 — chiffrement bout-en-bout natif |
Aucun de ces sous-traitants n’est soumis au Cloud Act US. C’est ce qui nous permet d’écrire, factuellement et sans risque juridique : « 100 % France » et « Anti-Cloud Act ».
8. Erreurs fréquentes à éviter en 2026
Voici les pièges que nous voyons régulièrement dans nos missions d’audit chez les FinTechs françaises.
Erreur 1 — « Notre prestataire est conforme RGPD donc tout va bien »
La conformité RGPD du prestataire ne couvre pas ses obligations DORA ni AI Act. Une FinTech doit auditer chaque prestataire sur les trois cadres simultanément.
Erreur 2 — « Nous avons signé un DPA, c’est fait »
Un DPA art. 28 RGPD ne garantit pas le respect de DORA art. 28 (registre prestataires TIC critiques). Les deux articles 28 ne couvrent pas les mêmes obligations — RGPD pour les données, DORA pour la résilience opérationnelle.
Erreur 3 — « Notre IA est en risque limité, on est tranquille »
La classification AI Act est dynamique. Un système IA qui passe d’une finalité limitée (chatbot FAQ) à une finalité haut risque (assistance à la décision crédit) change automatiquement de catégorie. Il faut réévaluer à chaque évolution produit.
Erreur 4 — « On est hébergé en Europe, ça suffit »
L’hébergement géographique en Europe ne protège pas contre les juridictions étrangères. Un prestataire dont la maison-mère est aux US peut se voir notifier une demande Cloud Act, même si ses serveurs sont à Francfort. La juridiction du contrat principal et de la maison-mère compte autant que la localisation physique.
Erreur 5 — « On fera l’audit avant l’inspection ACPR »
L’ACPR a déjà commencé à demander les registres art. 28 DORA lors de ses contrôles. Attendre l’inspection pour faire l’audit, c’est accepter une non-conformité documentée — donc des sanctions potentielles.
9. Conclusion — Une roadmap conformité 2026 en quatre semaines
Pour conclure, voici la roadmap minimum 2026 que nous recommandons à toute FinTech française :
Semaine 1 — Cartographie
- Lister tous les systèmes IA actifs (internes + externalisés)
- Lister tous les prestataires TIC (cloud, IA, intégrateurs, auditeurs)
Semaine 2 — Classification AI Act et audit DPA RGPD
- Classer chaque système IA par niveau de risque (Annexe III)
- Vérifier que chaque prestataire a un DPA art. 28 RGPD à jour
Semaine 3 — Registre DORA art. 28
- Construire le registre des prestataires TIC critiques
- Rédiger les plans de sortie pour les fonctions critiques
Semaine 4 — Documentation et tests
- Compiler la documentation art. 13 AI Act pour les systèmes haut risque
- Lancer un test de résilience DORA sur la fonction la plus critique
À l’issue des 4 semaines, vous disposez d’un dossier de conformité présentable à votre comité d’audit interne ou à l’ACPR. Vous identifiez les 3-5 chantiers prioritaires pour les 3-6 mois suivants.
FAQ — Questions fréquentes sur DORA, AI Act et RGPD pour FinTech
Quelle est la différence entre DORA art. 28 et RGPD art. 28 ?
DORA art. 28 traite de la gestion des risques liés aux prestataires TIC tiers (registre, due diligence, plan de sortie, tests de résilience). RGPD art. 28 traite de la sous-traitance des données personnelles (DPA, instructions documentées, sécurité). Les deux articles partagent le numéro mais couvrent des obligations distinctes — il faut satisfaire les deux.
Mon entreprise est une PME hors secteur financier, suis-je concerné par DORA ?
Non, pas directement. DORA s’applique aux entités financières et à leurs prestataires TIC critiques. Mais si vous êtes prestataire IA pour une banque française, vous êtes dans le périmètre indirect via votre client — qui exigera de vous des conformités DORA dans ses contrats.
À partir de quand l’AI Act art. 6 (haut risque) est-il pleinement applicable ?
Les obligations complètes pour les systèmes IA haut risque s’appliquent à partir du 2 août 2027, soit 24 mois après l’entrée en vigueur de la gouvernance (août 2026). Les pratiques interdites (art. 5) sont en revanche applicables depuis février 2025.
Le Cloud Act US peut-il s’appliquer à un cloud provider français ?
Oui, dans certains cas — si le cloud provider français a des opérations aux US ou utilise des sous-traitants américains. C’est pourquoi il est important d’auditer non seulement la localisation physique des serveurs, mais aussi la chaîne juridique complète du prestataire et de ses sous-traitants.
Combien coûte un audit IA & conformité chez OGMA Systems ?
L’audit initial de 30 minutes en visioconférence est offert et sans engagement. Si vous décidez de poursuivre, nos formules d’accompagnement sont transparentes en architecture 3 paliers TPE/PME : LUG à partir de 99 €/mois HT (TPE-2 freelance/agence), TARANIS de 259 à 999 €/mois HT (TPE-3 + PME-1/2), DAGDA à partir de 5 000 €/mois HT sur devis (Direction IA Entreprise). Trial 14 jours sans CB sur LUG. Engagement annuel -15 %.
Pourquoi la souveraineté de l’infrastructure est-elle un sujet réglementaire ?
Parce que les cadres comme DORA, RGPD et AI Act exigent la traçabilité juridique des données — qui peut y accéder, sous quelle juridiction, avec quelles garanties. Une infrastructure soumise au Cloud Act US ne peut pas garantir l’absence d’accès américain — c’est une non-conformité juridique latente, indépendamment de la qualité technique du prestataire.
Pour aller plus loin
- Politique de confidentialité OGMA Systems : /confidentialite/ — détail des 5 sous-traitants RGPD art. 28, transferts UE/pays adéquats, mesure d’audience cookieless conforme CNIL délibération 2020-091
- Expertise FinTech : /expertise-fintech/ — automatisation KYC/AML, détection fraude explicable, conformité DORA & ACPR, souveraineté des données financières
- Solutions techniques : /solutions/ — architecture Compliance Gate fail-closed, RAG souverain Scaleway, infrastructure 100 % France
- Offres d’accompagnement : /offres/ — architecture 3 paliers (LUG/TARANIS/DAGDA) + 5 add-ons modulaires + cohorte fondatrice 5 places diverses TPE/PME (-50 % à 24 mois prix gelé) + FAQ détaillée