⚡ Réponse rapide
Toute fintech titulaire d'un agrément financier européen (établissement de paiement ou de monnaie électronique, entreprise d'investissement, PSCA agréé MiCA, société de gestion) applique DORA depuis le 17 janvier 2025 : gouvernance du risque TIC, registre des prestataires TIC, notification initiale d'un incident majeur 4 heures après sa classification et au plus tard 24 heures après sa détection. Les microentreprises bénéficient d'allègements ciblés, pas d'une exemption.
Une fintech de cinquante personnes qui gère deux millions de comptes clients affiche parfois une surface d'attaque numérique plus large qu'une banque régionale employant dix fois plus de monde. C'est le paradoxe au cœur de la conformité DORA fintech : le règlement européen (UE) 2022/2554 ne distingue pas les acteurs selon leur ancienneté ou leur taille d'équipe, mais selon leur statut réglementaire. Depuis le 17 janvier 2025, les fintech agréées — néobanques, établissements de paiement, prestataires de services sur crypto-actifs — répondent aux mêmes exigences de résilience numérique que les groupes bancaires historiques. Un principe de proportionnalité change beaucoup de choses en pratique, mais encore faut-il savoir exactement où il s'applique, et où il ne s'applique pas.
Quelles fintech sont réellement soumises à DORA ?
Le critère d'entrée dans le champ de DORA n'est ni la taille, ni la culture d'entreprise, ni le fait de se définir comme une « fintech » — c'est l'agrément réglementaire. L'article 2 énumère les catégories d'entités financières concernées : établissements de crédit, établissements de paiement, établissements de monnaie électronique, entreprises d'investissement, prestataires de services sur crypto-actifs agréés au titre de MiCA, prestataires de financement participatif relevant du règlement (UE) 2020/1503, sociétés de gestion, entreprises d'assurance et de réassurance, institutions de retraite professionnelle, parmi une vingtaine de catégories. Si votre structure détient l'un de ces agréments, elle est une entité concernée par DORA, point final. Ce que beaucoup de fondateurs découvrent tard : une structure technologique qui vend ses services à des banques sans détenir elle-même d'agrément financier n'entre pas dans ce champ. Elle peut en revanche être concernée par un autre mécanisme, celui des prestataires tiers de services TIC, détaillé plus loin.
| Type de fintech | Statut réglementaire type | Soumise à DORA en tant qu'entité financière ? |
|---|---|---|
| Néobanque | Établissement de crédit ou de paiement agréé | Oui |
| Fintech de paiement / porte-monnaie électronique | Établissement de paiement ou de monnaie électronique | Oui |
| Plateforme crypto | Prestataire de services sur crypto-actifs (PSCA) sous MiCA | Oui |
| Plateforme de financement participatif | Agrément ECSP (règlement 2020/1503) | Oui |
| Néo-courtier / robo-advisor | Entreprise d'investissement, société de gestion | Oui |
| Fintech Banking-as-a-Service opérant sous licence d'un partenaire | Aucun agrément propre | Non directement, mais encadrée via le contrat avec la banque partenaire (article 30) |
| Fintech B2B (scoring, KYC, agrégation, cœur bancaire en marque blanche) | Aucun agrément financier | Non, mais potentiellement désignée prestataire TIC critique |
| Insurtech sans agrément propre | Aucun | Non directement ; l'assureur partenaire, lui, est soumis à DORA |
Le cas particulier du Banking-as-a-Service
Les fintech qui opèrent sous la licence d'une banque partenaire (BaaS) ne détiennent pas d'agrément propre et ne sont donc pas directement dans le périmètre de l'article 2. Mais la banque partenaire, elle, est une entité financière soumise à DORA : elle doit s'assurer que ses prestataires — dont la fintech BaaS — respectent les clauses contractuelles minimales de l'article 30. La fintech BaaS est donc encadrée par ricochet contractuel plutôt que par soumission directe au règlement.
Microentreprise, article 16, proportionnalité : trois notions que l'on confond trop souvent
C'est sans doute la zone de confusion la plus coûteuse pour une jeune fintech : penser que « être petit » ouvre automatiquement droit à un régime allégé sous DORA. Le règlement distingue en réalité trois mécanismes qui se recoupent seulement en partie.
Le premier est le cadre simplifié de l'article 16. Il ne repose pas sur un seuil de taille mais sur une liste fermée de statuts réglementaires : les petites entreprises d'investissement non interconnectées, les établissements de paiement exemptés au titre de la directive (UE) 2015/2366, les établissements de monnaie électronique exemptés au titre de la directive 2009/110/CE, certains établissements exemptés au titre de la directive 2013/36/UE, et les petites institutions de retraite professionnelle. Pour ces entités, les articles 5 à 15 du règlement ne s'appliquent pas : elles restent néanmoins tenues de disposer d'un cadre documenté de gestion du risque TIC, de surveiller leurs systèmes, de détecter et traiter les incidents, et de tester leurs plans de continuité. Conséquence concrète : un établissement de paiement pleinement agréé — pas « exempté » au sens de la directive — ne relève pas de l'article 16, même s'il compte huit salariés.
Le deuxième mécanisme est la microentreprise, définie à l'article 3, point 60 : une entité financière employant moins de dix personnes et dont le chiffre d'affaires annuel et/ou le total du bilan annuel n'excède pas deux millions d'euros — des seuils qui reprennent ceux de la recommandation de la Commission 2003/361/CE. Cette catégorie est distincte de la liste de l'article 16 : une fintech peut être une microentreprise sans figurer parmi les statuts exemptés de l'article 16, et bénéficier malgré tout d'allègements ponctuels prévus pour elle ailleurs dans le règlement — notamment l'exclusion des tests de pénétration fondés sur la menace, détaillée plus bas.
Le troisième mécanisme, la proportionnalité de l'article 4, s'applique à toutes les entités financières : les exigences doivent être mises en œuvre en tenant compte de la taille, du profil de risque global, et de la complexité des services de l'entité. C'est ce principe, et non un régime dérogatoire, qui justifie qu'une fintech de vingt personnes documente son cadre de gestion des risques TIC de façon plus concise qu'un groupe bancaire systémique — sans en être dispensée.
| Ce qui est allégé (article 16 / microentreprises) | Ce qui reste obligatoire pour tous |
|---|---|
| Formalisme de la documentation du cadre de risque TIC | Existence d'un cadre documenté de gestion du risque TIC |
| Gouvernance (pas d'organe dédié pour un dirigeant unique) | Notification des incidents majeurs, mêmes délais que pour un grand groupe |
| Exclusion du champ des tests TLPT | Tests de résilience de base, réguliers, proportionnés |
| Certaines modalités de reporting détaillé | Registre des prestataires TIC, quelle que soit la taille |
| — | Clauses contractuelles minimales de l'article 30 |
PSCA, MiCA et la fin du régime PSAN
DORA vise, à l'article 2, paragraphe 1, point f, les « prestataires de services sur crypto-actifs » agréés au titre du règlement MiCA (UE) 2023/1114 — pas le régime français d'enregistrement PSAN issu de la loi PACTE, qui n'était qu'une étape transitoire. La période permettant à un prestataire enregistré PSAN de continuer à opérer en France sans agrément MiCA s'est achevée le 1er juillet 2026 : seuls les prestataires disposant d'un agrément PSCA délivré par l'AMF peuvent désormais fournir légalement des services sur crypto-actifs. La question n'est donc plus « PSAN ou PSCA » mais bien la conformité DORA d'une entité PSCA pleinement agréée, au même titre qu'un établissement de paiement.
Tests de résilience (TLPT) : qui est vraiment concerné ?
C'est l'un des points les plus mal compris de DORA fintech. Le règlement ne soumet pas toutes les entités financières aux tests de pénétration fondés sur la menace (TLPT) prévus à l'article 26 : les entités visées à l'article 16, premier alinéa, ainsi que les microentreprises, en sont exclues d'office. Pour les autres, ce n'est pas non plus automatique : l'autorité compétente identifie elle-même, sur la base de critères d'impact, d'importance systémique et de maturité du risque informatique, quelles entités doivent réaliser un TLPT au moins tous les trois ans. Une fintech de taille moyenne peut donc ne jamais être désignée si son profil de risque ne le justifie pas — ce sont les tests de résilience « de base », proportionnés, qui restent systématiques pour tous.
Notification d'incident : les délais qu'il faut connaître par cœur
L'idée reçue selon laquelle il suffirait de « notifier son régulateur dans les 4 heures » simplifie à l'excès une mécanique en trois temps, précisée par le règlement délégué (UE) 2025/301. Le compte à rebours des 4 heures démarre à la classification de l'incident comme majeur — pas à sa découverte — avec un plafond absolu : la notification initiale doit de toute façon intervenir au plus tard 24 heures après que l'entité a eu connaissance de l'incident. Viennent ensuite un rapport intermédiaire, puis un rapport final.
| Étape | Délai |
|---|---|
| Notification initiale | 4 heures après la classification en incident majeur, et au plus tard 24 heures après en avoir eu connaissance |
| Rapport intermédiaire | 72 heures après l'envoi de la notification initiale |
| Rapport final | 1 mois après le rapport intermédiaire (ou sa dernière mise à jour) |
Pour une fintech française, cette chaîne se joue auprès de l'ACPR ou de l'AMF selon l'agrément détenu. Autant dire qu'un processus de notification d'incident qui n'a jamais été testé « à froid » a toutes les chances de rater le premier délai le jour où un incident réel survient.
Quand les fintech sont touchées : deux précédents à retenir
Les fintech ne sont pas à l'abri, et deux dossiers largement documentés l'illustrent. En septembre 2022, Revolut a confirmé une violation de données ayant exposé les informations personnelles de plus de 50 000 clients, après une attaque d'ingénierie sociale ciblant un employé ; l'incident a été notifié à l'autorité de protection des données lituanienne, pays où Revolut détient sa licence bancaire européenne. Du côté de N26, la BaFin a ordonné en novembre 2021 une limitation du nombre de nouveaux clients que la néobanque allemande pouvait accueillir chaque mois, en raison d'insuffisances de son dispositif de lutte contre le blanchiment ; une amende distincte de 4,25 millions d'euros lui avait été infligée la même année pour des déclarations de soupçon transmises tardivement. Deux affaires différentes — cybersécurité d'un côté, LCB-FT de l'autre — qui pointent le même constat : la vitesse de croissance d'une fintech dépasse souvent la maturité de ses dispositifs de contrôle, ce que DORA vient encadrer sur le volet numérique.
La dépendance au cloud, le vrai défi opérationnel des fintech
La plupart des fintech sont nées « cloud-native » : infrastructure hébergée chez un hyperscaler, outils métier en SaaS, cœur système parfois entièrement délégué à un éditeur tiers. Cette architecture crée une concentration de la dépendance informatique que DORA oblige à documenter et à piloter. Chaque contrat avec un fournisseur cloud ou SaaS critique doit figurer dans le registre des prestataires TIC, intégrer les clauses contractuelles minimales de l'article 30, et s'accompagner — pour les fonctions critiques — d'une stratégie de sortie documentée en cas de défaillance du fournisseur. Les grands fournisseurs cloud ont publié des addendums contractuels alignés sur DORA que les équipes juridiques peuvent demander directement à leur gestionnaire de compte plutôt que de rédiger ces clauses depuis zéro.
Fintech B2B : le prestataire qui devient un maillon DORA malgré lui
Beaucoup de fintech ne vendent pas de service financier au grand public mais fournissent de la technologie à des banques et des assureurs : agrégation de comptes, scoring de crédit, KYC/AML, paiement en marque blanche. Ces structures ne sont pas des entités financières au sens de DORA, mais leurs clients, eux, le sont — et répercutent mécaniquement leurs obligations contractuelles vers leur fournisseur. Une fintech B2B doit donc s'attendre à des questionnaires de conformité DORA, à voir les clauses de l'article 30 intégrées dans ses contrats, et à des demandes d'audit. Si ses services sont utilisés par un nombre suffisant d'entités financières européennes, elle peut même être formellement désignée prestataire TIC critique (CTPP) et passer sous supervision directe des autorités européennes.
Se mettre en conformité avec des ressources limitées : une trajectoire en six étapes
Une fintech n'a en général ni département conformité étoffé, ni RSSI à temps plein dédié à DORA. Cela ne dispense de rien, mais impose une hiérarchisation claire plutôt qu'un chantier « big bang ».
| Étape | Action |
|---|---|
| 1 | Déterminer précisément son statut : régime plein, cadre simplifié de l'article 16, et/ou qualification de microentreprise |
| 2 | Cartographier les fonctions critiques ou importantes de l'activité |
| 3 | Constituer le registre des prestataires TIC (cloud, SaaS, sous-traitance informatique) |
| 4 | Mettre en place le circuit de classification et de notification des incidents majeurs |
| 5 | Rédiger un cadre de gestion des risques TIC proportionné, validé par la direction |
| 6 | Planifier des tests de résilience adaptés au profil de risque, en y intégrant un TLPT si l'autorité compétente a identifié l'entité comme devant s'y soumettre |
Aucune de ces étapes ne se boucle en un sprint : mieux vaut avancer progressivement, documenter chaque décision, et accepter qu'une politique de quinze pages parfaitement appliquée vaut mieux qu'un document de cent pages jamais relu.
DORA, un signal de maturité pour les investisseurs et les partenaires bancaires
Les investisseurs spécialisés en fintech intègrent de plus en plus la maturité réglementaire dans leur grille d'analyse, et les questions de conformité DORA apparaissent désormais couramment dans les due diligence, aux côtés des sujets de sécurité et de protection des données. Une fintech capable de présenter un cadre documenté, des tests réalisés et une gouvernance claire de son risque informatique rassure ses partenaires sur sa capacité à opérer durablement dans un secteur régulé. À l'inverse, négliger DORA expose une fintech agréée à un risque réglementaire direct, avec des conséquences qui vont du rappel à l'ordre aux sanctions financières en cas de manquement caractérisé.
Questions fréquentes
Une fintech sans agrément financier est-elle concernée par DORA ?
Pas directement en tant qu'entité financière. Mais si elle fournit des services technologiques à des banques, assureurs ou sociétés de gestion, ses clients — eux soumis à DORA — répercuteront leurs obligations contractuelles (clauses de l'article 30, audits, questionnaires). Une fintech B2B très utilisée peut même être désignée prestataire TIC critique.
Quelle est la différence entre une microentreprise DORA et le cadre simplifié de l'article 16 ?
La microentreprise (article 3, point 60) est une catégorie de taille : moins de dix salariés et chiffre d'affaires et/ou bilan annuel n'excédant pas deux millions d'euros. L'article 16 est une liste fermée de statuts réglementaires exemptés (petits établissements de paiement, petites entreprises d'investissement, etc.), indépendante de tout seuil de taille. Les deux ouvrent des allègements différents, parfois cumulables.
Les PSCA (ex-PSAN) sont-ils soumis à DORA ?
Oui. DORA vise à l'article 2 les prestataires de services sur crypto-actifs agréés sous MiCA. Le régime français PSAN, issu de la loi PACTE, n'était qu'une étape transitoire ; il s'est achevé le 1er juillet 2026. Toute plateforme crypto en activité doit désormais détenir un agrément PSCA et respecter DORA comme n'importe quelle autre entité financière.
Quels sont les délais de notification d'un incident majeur ?
Le règlement délégué (UE) 2025/301 fixe trois échéances : notification initiale dans les 4 heures suivant la classification de l'incident comme majeur, et au plus tard 24 heures après en avoir eu connaissance ; rapport intermédiaire sous 72 heures après la notification initiale ; rapport final dans le mois suivant le rapport intermédiaire.
Une fintech microentreprise doit-elle réaliser des tests TLPT ?
Non. L'article 26 exclut explicitement les microentreprises, ainsi que les entités relevant de l'article 16, du champ des tests de pénétration fondés sur la menace (TLPT). Elles restent en revanche soumises à des tests de résilience de base, réguliers et proportionnés à leur profil de risque.
Une fintech Banking-as-a-Service est-elle directement soumise à DORA ?
Non, si elle n'a pas d'agrément propre : elle n'entre pas dans la liste des entités financières de l'article 2. Elle est en revanche encadrée indirectement, via les clauses contractuelles que sa banque partenaire — elle-même soumise à DORA — doit lui imposer au titre de l'article 30 sur les prestataires TIC.
Peut-on mutualiser la conformité DORA au sein d'un groupe ou d'un incubateur ?
Partiellement. Certains éléments peuvent être mutualisés : politique de sécurité de groupe, SOC partagé, tests de résilience communs. Mais chaque entité agréée reste individuellement responsable devant son superviseur : le registre des prestataires TIC et la notification des incidents majeurs sont des obligations propres à chaque entité, non transférables.
Une néobanque comme Revolut ou N26 est-elle soumise à DORA ?
Oui. Toute néobanque détenant un agrément d'établissement de crédit, de paiement ou de monnaie électronique en Europe relève de DORA depuis le 17 janvier 2025, sous la supervision de son régulateur national — l'ACPR en France, la BaFin en Allemagne, ou une autre autorité selon le pays d'agrément.
DORA, un plancher de conformité que les meilleures fintech dépassent volontairement
DORA est une réalité opérationnelle pour toute fintech agréée depuis le 17 janvier 2025 — pas une échéance à venir, ni un chantier optionnel selon la taille de l'équipe. Les structures qui s'en sortent le mieux ne visent pas le minimum légal exact applicable à leur statut : elles construisent une gouvernance numérique lisible, un registre de prestataires à jour et un processus de notification déjà testé. Les entités financières traditionnelles font face à des exigences comparables : pour aller plus loin, direction nos guides sur les obligations DORA pour les banques, sur DORA pour les assureurs, ou sur le cadre complet du règlement.