DORA et le chiffrement : ce qu'un éditeur fintech doit prouver à ses clients financiers

DORA s'applique-t-il à un éditeur de logiciel, ou seulement aux banques ?

DORA s'applique aux deux. Le règlement (UE) 2022/2554, en application depuis le 17 janvier 2025, vise d'abord les entités financières (banques, assurances, fintechs, établissements de paiement). Mais son article 28 étend le cadre à leurs prestataires TIC tiers, dont les éditeurs de logiciels. Concrètement, un éditeur qui vend à une entité financière hérite d'exigences contractuelles sur la gestion du risque TIC, y compris le chiffrement.

C'est le changement que beaucoup d'éditeurs découvrent en négociant un contrat. Le client régulé ne demande plus seulement un logiciel qui marche. Il demande un logiciel dont il peut documenter la conformité DORA dans son propre registre. Le règlement (UE) 2022/2554, publié au Journal officiel de l'Union européenne, fait de la chaîne de sous-traitance TIC un objet de supervision. Votre logiciel devient une pièce du dossier de conformité de votre client.

Le principe de proportionnalité s'applique : les micro-entreprises et certaines petites entités bénéficient d'un cadre simplifié (articles 4 et 16 du règlement). Mais la proportionnalité concerne le régime de l'entité financière, pas la question de savoir si vous chiffrez : un client régulé qui vous confie des données financières attendra le chiffrement quelle que soit sa taille.

Que dit précisément DORA sur le chiffrement ?

DORA n'écrit pas le mot « chiffrement » dans son article central, mais il le rend incontournable. L'article 9(2) du règlement exige de « maintenir des normes élevées en matière de disponibilité, d'authenticité, d'intégrité et de confidentialité des données, que ce soit au repos, en cours d'utilisation ou en transit ». Garantir la confidentialité de données au repos sans chiffrement n'a pas de sens technique. Le texte l'impose donc implicitement.

Le cadre est détaillé par l'Autorité de contrôle prudentiel et de résolution (ACPR), qui supervise l'application de DORA en France et rappelle que la responsabilité de l'entité financière reste entière sur ses prestataires.

Le détail est précisé par les normes techniques de réglementation (RTS) adoptées par les autorités européennes de surveillance. Le RTS sur la gestion des risques TIC consacre son article 6 au chiffrement et aux contrôles cryptographiques et son article 7 à la gestion des clés. Ces textes exigent que l'entité financière élabore, documente et mette en œuvre une politique de chiffrement. Pour un éditeur, cela veut dire que votre client vous demandera de documenter vos propres mesures : quels algorithmes, quelle gestion des clés, quel journal.

Quelles données un éditeur fintech doit-il chiffrer en priorité ?

Les coordonnées bancaires (IBAN, BIC, numéros de compte) viennent en tête. La sanction de la CNIL contre Free en janvier 2026, 42 millions d'euros pour des IBAN stockés en clair (délibérations SAN-2026-001 et SAN-2026-002 du 8 janvier 2026, publiées sur Légifrance), a montré qu'un IBAN non chiffré est une faute caractérisée, même hors du secteur financier. Pour un éditeur qui manipule ces données au nom d'un client régulé, l'enjeu est double : DORA côté client, RGPD côté sous-traitant.

Viennent ensuite les données KYC (copies de pièces d'identité, justificatifs, questionnaires d'adéquation), les données de scoring et de crédit, les données de paiement soumises à PCI-DSS, et la correspondance client. Chaque catégorie agrège des informations personnelles sensibles dont la compromission expose simultanément votre client à DORA et à un contentieux RGPD.

Le chiffrement pertinent ici est le chiffrement applicatif au niveau du champ : on chiffre l'IBAN et le numéro de compte dans la base, pas seulement le disque. C'est cette granularité que le RGPD Article 32 et les RTS DORA rendent défendable.

Les trois états des données que DORA distingue

DORA exige la confidentialité dans trois états, chacun avec sa réponse technique.

Les données au repos sont stockées : un IBAN dans une table PostgreSQL, un dossier KYC dans un bucket S3, un historique de transactions dans un entrepôt. C'est le périmètre où les failles sont les plus fréquentes. L'AES-256-GCM est le mécanisme recommandé par l'ANSSI pour ce périmètre, cité dans son guide des mécanismes cryptographiques PG-083 v3.00 du 20 mars 2026. Le mode GCM est spécifié par le NIST SP 800-38D.

Les données en transit circulent entre systèmes. Le protocole TLS 1.3 assure leur chiffrement, mais DORA exige d'en documenter et d'en tester la robustesse.

Les données en cours d'utilisation sont traitées en mémoire. Les technologies de confidential computing adressent ce périmètre, mais leur déploiement reste embryonnaire. Pour la plupart des éditeurs, l'effort porte d'abord sur le repos et le transit.

Comment prouver sa conformité DORA à un client régulé ?

Par la documentation, pas par les déclarations. DORA n'est pas un référentiel technique : le texte ne prescrit ni algorithme, ni longueur de clé. Cette approche fondée sur le risque laisse à chaque acteur la responsabilité de dimensionner ses mesures et, surtout, de démontrer qu'elles sont proportionnées, réévaluées, et que les clés sont gérées sur tout leur cycle de vie.

Pour un éditeur, la charge de preuve est concrète : il faut pouvoir montrer au client la politique de chiffrement, la hiérarchie de clés, la rotation, et un journal d'audit des opérations. C'est précisément le dossier qu'une entité financière doit verser à son propre registre au titre de l'article 28. Un éditeur qui fournit ce dossier tout fait réduit le périmètre d'audit de son client, et débloque la signature.

Une plateforme de chiffrement applicatif comme MAFATE génère un rapport de conformité adossé au journal d'audit réel des opérations, exportable en PDF, CSV ou JSON, avec un preset DORA article 28. Précision d'honnêteté, parce que ce point est sensible : ce rapport contribue au dossier de conformité, il ne constitue pas un certificat, et il n'est pas signé cryptographiquement. Il documente ce qui a été chiffré, quand, avec quelle clé. C'est ce que l'auditeur de votre client vérifiera, pas une promesse marketing.

DORA, RGPD : un cadre qui se cumule, pas un choix

Un éditeur qui subit une fuite de données financières non chiffrées expose son client régulé à deux fronts : la CNIL au titre du RGPD (sanction jusqu'à 20 millions d'euros ou 4 % du chiffre d'affaires mondial) et le superviseur DORA au titre de la résilience opérationnelle. L'article 46 de DORA organise l'articulation avec les autres cadres. Le chiffrement est le dénominateur commun : une mesure qui répond aux deux à la fois.

Un mot sur NIS2, souvent citée dans le même souffle : la directive (UE) 2022/2555 n'est pas transposée en France. La Commission européenne a saisi la Cour de justice de l'Union européenne le 8 juillet 2026 pour défaut de transposition (Le Monde Informatique, juillet 2026), et l'examen du projet de loi Résilience est repoussé à septembre 2026 au plus tôt. Écrire que NIS2 « s'applique » aujourd'hui en France serait faux. Pour un éditeur fintech, l'obligation réelle et présente vient de DORA et du RGPD, pas de NIS2. NIS2 arrive, elle s'anticipe, elle ne s'invoque pas encore comme une obligation en vigueur.

Construire une architecture de chiffrement qui tient dans le temps

L'ANSSI a publié le 20 mars 2026 la version 3.00 de son guide PG-083, qui intègre les recommandations d'hybridation post-quantique. Sans céder au battage sur le post-quantique, l'enseignement est utile pour un éditeur : une architecture de chiffrement modulaire, capable de changer d'algorithme sans refonte, vaut mieux qu'un choix figé dans le code.

C'est un argument pour externaliser la brique cryptographique plutôt que de la coder soi-même. Un éditeur qui délègue la gestion des clés et le journal d'audit à une plateforme dédiée absorbe ces évolutions par configuration, et concentre ses développeurs sur son produit. MAFATE propose cette brique aux éditeurs SaaS régulés, avec l'architecture publiée sur sa page sécurité et sa page conformité.

Si un contrat vous est aujourd'hui bloqué parce qu'un client régulé vous réclame une preuve de conformité DORA sur le chiffrement, c'est exactement le problème que cette approche résout. Parler à un ingénieur fait gagner les semaines de collecte documentaire que vos concurrents passent encore à la main.