DORA : ce qui constitue une preuve technique
DORA s'applique depuis le 17 janvier 2025. L'essentiel du texte porte sur la gouvernance, les tests et les contrats. Une part étroite — la cryptographie, les certificats, le registre des actifs et les informations que vos clients du secteur financier vous demandent désormais par écrit — laisse des traces que chacun peut observer de l'extérieur. Ce guide parcourt cette part article par article, et dit clairement où elle s'arrête.
Rédigé par l’équipe d’ingénierie SkyQon · Dernière vérification : 6 août 2026
Ce que DORA exige réellement
Le règlement sur la résilience opérationnelle numérique — le règlement (UE) 2022/2554 — est un règlement et non une directive. Il n'y a ni étape de transposition ni variante nationale à vérifier : le même texte s'applique dans chaque État membre, et ce depuis le 17 janvier 2025.
Le texte s'organise en cinq blocs. La gestion du risque informatique occupe les articles 5 à 16. La gestion et la notification des incidents vont de l'article 17 à l'article 23. Les tests de résilience opérationnelle numérique couvrent les articles 24 à 27. Le risque lié aux prestataires informatiques tiers — là où la plupart des fournisseurs rencontrent DORA pour la première fois — s'étend de l'article 28 au cadre de supervision, jusqu'à l'article 44. Le partage d'informations clôt l'ensemble à l'article 45.
Deux dispositions donnent le ton. L'article 5, paragraphe 2, charge l'organe de direction de définir, approuver et superviser le cadre de gestion du risque informatique, et le rend responsable de sa mise en œuvre — la même responsabilité personnelle que NIS2 impose à la direction à son article 20. Et l'article 9, paragraphe 1, impose aux entités financières de surveiller et de contrôler en continu la sécurité et le fonctionnement de leurs systèmes informatiques. Cet adverbe compte : un contrôle qualifié de continu ne se prouve pas par un document produit une fois par an.
Texte officiel: Regulation (EU) 2022/2554
Deux publics, et le second est généralement pris de court
DORA lie directement les entités financières — banques, assureurs et réassureurs, entreprises d'investissement, établissements de paiement et de monnaie électronique, plates-formes de négociation, prestataires de services sur crypto-actifs et le reste de la liste de l'article 2. Ces entreprises savent qu'elles sont concernées.
Les prestataires informatiques tiers sont dans une autre situation. À moins que les autorités européennes de surveillance ne vous désignent comme critique au titre de l'article 31, DORA ne vous réglemente pas directement. Il vous atteint par l'intermédiaire de vos clients, et il vous atteint fortement. L'article 28, paragraphe 4, impose à l'entité financière une diligence raisonnable avant la signature. L'article 28, paragraphe 5, n'autorise à contracter qu'avec des prestataires respectant des normes appropriées de sécurité de l'information et, pour les services soutenant des fonctions critiques ou importantes, impose de tenir dûment compte de l'usage par le prestataire des normes de sécurité les plus récentes et les plus exigeantes. L'article 30 fixe ensuite le contenu obligatoire du contrat.
Pour la plupart des fournisseurs, DORA n'arrive donc pas sous la forme d'un courrier d'un superviseur. Il arrive sous la forme d'un questionnaire de diligence de cinquante points envoyé par le service achats d'un client, suivi de clauses contractuelles que vous n'avez pas rédigées, puis du même questionnaire envoyé par le client suivant trois semaines plus tard.
La conséquence pratique mérite d'être dite simplement : pour un fournisseur, être prêt pour DORA est d'abord un enjeu commercial avant d'être un enjeu de conformité. Les entreprises qui répondent vite, de façon cohérente et avec une pièce vérifiable en annexe signent plus rapidement que celles qui rouvrent le tableur à chaque fois.
Quels articles laissent des traces observables de l'extérieur
L'essentiel de DORA est invisible depuis l'extérieur de votre périmètre, tout comme l'essentiel de NIS2. Une poignée de dispositions font exception, car ce qu'elles régissent est précisément ce qu'un client, un navigateur ou un serveur de messagerie peut constater par lui-même.
| Disposition | Ce qu'elle exige | Observable de l'extérieur |
|---|---|---|
| Art. 8 | Recenser, classer et documenter les actifs informatiques et leurs dépendances ; tenir des inventaires et les maintenir à jour. | La partie du parc accessible depuis l'extérieur, et les identités cryptographiques qui la servent. |
| Art. 9 | Surveillance et contrôle continus ; intégrité et confidentialité des données au repos, en cours d'utilisation et en transit ; sécurité des moyens de transfert des données ; protection des clés cryptographiques et chiffrement. | Chaque poignée de main TLS que vos services publics accomplissent, et les certificats qui les sous-tendent. |
| Art. 24–25 | Un programme de tests de résilience ; l'article 25, paragraphe 1, cite parmi les tests appropriés les évaluations et analyses de vulnérabilités, les analyses de sources ouvertes et les évaluations de la sécurité des réseaux. | L'évaluation externe continue — un élément d'entrée du programme, jamais le programme lui-même. |
| Art. 26–27 | Les tests de pénétration fondés sur la menace, pour les entités tenues d'en réaliser, avec des exigences relatives aux testeurs. | Rien. Un TLPT est un exercice cadré, adossé à une convention. |
| Art. 28–30 | Un registre d'informations couvrant tous les accords contractuels informatiques ; une diligence raisonnable précontractuelle ; un contenu contractuel obligatoire. | La posture externe du fournisseur lui-même, et la plupart des données techniques qu'exige une ligne du registre. |
| RTS Art. 6 | Une politique documentée de chiffrement et de contrôles cryptographiques, précisant comment la technologie cryptographique est mise à jour à mesure que la cryptanalyse progresse. | Les algorithmes, tailles de clés et versions de protocole que votre parc négocie réellement. |
| RTS Art. 7 | Un registre de tous les certificats et des dispositifs qui les stockent, pour les actifs soutenant des fonctions critiques ou importantes, ainsi qu'un renouvellement rapide avant expiration. | Si le registre correspond à la réalité, et si les renouvellements ont effectivement eu lieu à temps. |
Tout le reste — classification des incidents, continuité d'activité, plans de sortie, supervision par le conseil, droits d'audit contractuels — est interne ou contractuel, et aucun outil externe ne peut le voir. Tout produit prétendant prouver DORA dans son ensemble décrit quelque chose qu'il ne peut pas observer.
Les RTS sont plus précises que le règlement
L'article 15 de DORA a chargé les autorités européennes de surveillance d'élaborer des normes techniques harmonisant les outils, méthodes, processus et politiques de gestion du risque informatique. Le résultat est le règlement délégué (UE) 2024/1774 de la Commission du 13 mars 2024, et c'est là que les exigences cryptographiques cessent d'être abstraites.
L'article 6 impose une politique documentée de chiffrement et de contrôles cryptographiques, fondée sur une classification des données approuvée et une évaluation du risque informatique. L'article 6, paragraphe 2, en fixe le périmètre : chiffrement des données au repos et en transit, des données en cours d'utilisation lorsque cela est nécessaire, des connexions réseau internes et des échanges avec des tiers. L'article 6, paragraphe 3, exige des critères de sélection des techniques cryptographiques tenant compte des pratiques de référence et des normes, et oblige l'entité qui ne peut s'y conformer à adopter des mesures d'atténuation et de surveillance.
Vient ensuite le paragraphe le plus utile à connaître. L'article 6, paragraphe 4, exige que la politique prévoie « la mise à jour ou la modification, si nécessaire, de la technologie cryptographique en fonction de l'évolution de la cryptanalyse ». C'est l'agilité cryptographique inscrite dans le droit financier européen, des années avant que quiconque ne s'accorde sur une date de migration post-quantique. L'article 6, paragraphe 5, complète le dispositif en exigeant que toute mesure d'atténuation adoptée au titre des paragraphes 3 ou 4 soit consignée, avec une explication motivée — une obligation de preuve écrite dans le texte, et non déduite de celui-ci.
L'article 7 traite de la gestion des clés, et deux de ses paragraphes sont exceptionnellement concrets. L'article 7, paragraphe 4, impose un registre de tous les certificats et des dispositifs qui les stockent, couvrant au moins les actifs informatiques soutenant des fonctions critiques ou importantes, tenu à jour. L'article 7, paragraphe 5, impose le renouvellement rapide des certificats avant leur expiration. Les deux sont mesurables, les deux se vérifient face à la réalité, et les deux sont typiquement ce qu'un tableur cesse de refléter dans le trimestre qui suit sa rédaction.
Texte officiel: Delegated Regulation (EU) 2024/1774
Pourquoi la politique n'est pas la preuve
Une politique est un contrôle de conception : elle énonce ce qui devrait se produire. Ce que la supervision et la diligence des clients interrogent, c'est ce qui s'est effectivement produit, sur toute la période et sur tout le parc. C'est l'efficacité opérationnelle, et c'est un autre document.
DORA est inhabituellement explicite sur ce point, ce qui rend la cible plus facile à atteindre qu'avec un texte se bornant à exiger une politique. L'article 6, paragraphe 5, des RTS demande de consigner les mesures d'atténuation et de les expliquer. L'article 28, paragraphe 3, impose de produire le registre d'informations à l'autorité compétente sur demande. L'article 24, paragraphe 5, exige des procédures pour hiérarchiser, classer et corriger chaque problème révélé par les tests — un relevé de remédiation, pas une liste de constats.
Appliquée au parc cryptographique, la différence est concrète. Une politique imposant une sécurité de transport robuste relève de la conception. Un relevé montrant ce que chaque point d'accès public a négocié chaque semaine pendant onze mois, que quatre exceptions sont apparues à des dates précises et que chacune a été clôturée dans un délai défini, relève de l'efficacité opérationnelle. Seul le second répond à « montrez-moi ».
Le registre d'informations, et pourquoi les questionnaires se sont durcis
L'article 28, paragraphe 3, impose à chaque entité financière de tenir et de mettre à jour un registre d'informations couvrant tous les accords contractuels portant sur des services informatiques, au niveau de l'entité ainsi qu'aux niveaux sous-consolidé et consolidé, en distinguant les accords soutenant des fonctions critiques ou importantes des autres. Les entités rendent compte au moins une fois par an à leur autorité compétente des nouveaux accords, des catégories de prestataires et des services concernés, et doivent produire le registre complet sur demande.
Un registre ne vaut que par les données de ses lignes, et l'essentiel de ces données appartient au fournisseur : entité juridique et identifiant, type de service informatique, lieu d'exécution du service et lieu de traitement et de stockage des données, dispositions de sous-traitance, et clauses d'audit, de sortie et de restitution des données. L'article 30, paragraphe 2, érige plusieurs de ces éléments en exigences contractuelles à part entière — dont l'obligation d'indiquer les régions ou pays concernés et d'informer le client à l'avance de tout changement.
C'est pourquoi les fournisseurs du secteur financier européen reçoivent désormais le même ensemble structuré de questions de chaque client, plusieurs fois par an, sur des modèles légèrement différents. L'information change rarement. Le coût réside entièrement dans le fait d'y répondre à nouveau.
Une limite mérite d'être posée honnêtement : le registre est une obligation de l'entité financière et ne peut être déléguée. Un fournisseur ne peut pas s'en acquitter à sa place. Ce qu'il peut faire, c'est en réduire le coût de remplissage — publier les réponses une fois, les tenir à jour, et y joindre des preuves qu'un examinateur peut vérifier sans passer un appel.
Le quatrième acteur derrière votre prestataire tiers
L'article 29 s'intitule « Évaluation préliminaire du risque de concentration informatique au niveau de l'entité », et ses deux paragraphes posent des questions différentes. L'article 29, paragraphe 1, porte sur la concentration sur le prestataire direct : l'accord revient-il à contracter avec un prestataire difficilement substituable, ou à empiler plusieurs accords critiques auprès du même prestataire ou de prestataires étroitement liés ? L'article 29, paragraphe 2, porte sur ce qui se trouve derrière ce prestataire : lorsqu'un contrat autorise la sous-traitance d'une fonction critique ou importante, l'entité doit peser les avantages et les risques, prendre en compte les sous-traitants établis dans des pays tiers, et évaluer si des chaînes de sous-traitance longues ou complexes compromettraient sa capacité même à surveiller la fonction.
Dans la couche de confiance, cette question abstraite prend une forme très concrète. Quelle autorité de certification signe les certificats de tout le parc. Vers quels serveurs de noms les zones délèguent. De quelle infrastructure de messagerie les domaines dépendent. Ce sont des dépendances amont partagées que personne n'a contractées délibérément, et elles se concentrent en silence : une perte de confiance chez une autorité de certification, ou une panne chez un fournisseur DNS, fait tomber d'un coup tout ce qui en dépendait.
L'intérêt est que cette concentration-là se mesure depuis l'extérieur, pour votre parc comme pour celui de vos fournisseurs, sans la coopération de quiconque. Savoir si une concentration donnée est acceptable reste une décision de risque qui vous appartient — mais vous ne pouvez pas la prendre sur une dépendance que vous n'avez jamais comptée.
Ce que SkyQon prouve, dit précisément
Les preuves DORA de SkyQon couvrent huit catégories. Chacune porte la disposition qu'elle alimente et un niveau de couverture indiqué sur le document lui-même, et la formulation provient d'une correspondance versionnée reprise mot pour mot dans le rapport signé — ce que vous lisez ici est donc ce qu'un examinateur y lira.
| Catégorie de preuve | Disposition | Couverture |
|---|---|---|
| Cryptographie et agilité cryptographique — préparation post-quantique du parc de certificats et capacité de migration à mesure que la cryptanalyse progresse | Art. 9 / RTS Art. 6 | Directe |
| Hygiène du transport et des certificats — versions de protocole, validité et expiration, robustesse des clés et des signatures, qualification eIDAS | Art. 9 | Directe |
| Authentification des e-mails — posture SPF, DKIM, DMARC et TLS-RPT sur les domaines surveillés | Art. 9 | Directe |
| Sécurité DNS — DNSSEC, CAA et hygiène DNS sur les domaines surveillés | Art. 9 | Directe |
| Preuve continue de la surface d'attaque — actifs fantômes, mal configurés et abandonnés, alimentant le volet évaluation des vulnérabilités des tests | Art. 24–25 | À l'appui |
| Continuité de la surveillance — continuité démontrée de la surveillance externe sur la période | Art. 24–25 | À l'appui |
| Registre des identités cryptographiques — un registre dédoublonné de chaque certificat et identité, sur les actifs analysés, renouvelés automatiquement, découverts et non-TLS | Art. 8 | À l'appui |
| Quatrième partie et concentration — dépendances amont partagées en matière d'autorité de certification, de DNS et de messagerie, et leur degré de concentration | Art. 28–30 | À l'appui |
Quatre directes, quatre à l'appui, aucune présentée comme une conformité. Directe signifie que notre télémétrie est la preuve principale pour cette disposition. À l'appui signifie qu'elle est l'un des éléments parmi d'autres qu'il vous restera à réunir vous-même.
Côté fournisseur, la même télémétrie alimente une page de confiance partageable que vos clients financiers peuvent consulter sans compte, un jeu de champs de registre d'informations que vous remplissez une fois, un avenant à l'article 30 généré, et un rapport de preuve signé portant une empreinte de contenu que chacun peut recalculer auprès de notre vérificateur public. Les fournisseurs que vous enregistrez vous-même sont notés à partir des mêmes signaux publics, ce qui permet de poser la question de la concentration un cran plus loin.
Ce que cela ne prouve pas
La notification des incidents au titre des articles 17 à 23 est hors du produit. Nous détectons et horodatons ; nous ne transmettons rien à une autorité nationale compétente. Ces transmissions suivent la séquence de l'article 19 — notification initiale, rapport intermédiaire et rapport final — sur des modèles et dans des délais fixés au titre de l'article 20.
Les tests de pénétration fondés sur la menace, aux articles 26 et 27, sont entièrement hors périmètre. Il en va de même du côté acheteur du registre : SkyQon fournit des preuves côté fournisseur et n'est pas une plateforme de gouvernance qui tiendrait le registre d'informations d'une entité financière à sa place.
Deux limites à l'intérieur même de ce que nous couvrons. L'analyse de concentration mesure les dépendances d'autorité de certification, de DNS et de messagerie ; la concentration liée à l'hébergement, au niveau réseau et à la diffusion de contenu n'est pas incluse, faute de source fiable — et une inférence hasardeuse serait pire qu'une lacune déclarée. Par ailleurs, la notation des fournisseurs mesure une surface de confiance externe : ce n'est pas une note de sécurité fondée sur des données de compromission ou de botnet — une autre catégorie de produit, avec d'autres données derrière.
Enfin, le cadrage. Tout est présenté comme aligné sur DORA, jamais comme une conformité ou une certification DORA. L'article 5, paragraphe 2, place l'approbation et la supervision sur votre organe de direction, et aucun document d'aucun fournisseur ne les déplace.
Un enchaînement pratique
- Déterminez de quel côté du contrat vous êtes. Les obligations incombent aux entités financières. Les fournisseurs en héritent par les articles 28 à 30. Beaucoup d'entreprises sont les deux à la fois, et les deux rôles exigent des documents différents à partir des mêmes données.
- Constituez le registre des certificats avant qu'on ne vous le demande. L'article 7, paragraphe 4, des RTS en exige un, couvrant au moins les fonctions critiques ou importantes, tenu à jour. Tout questionnaire de diligence sérieux vous demande de le décrire. C'est la découverte du parc qui prend des semaines.
- Faites de la preuve de renouvellement un sous-produit. L'article 7, paragraphe 5, veut un renouvellement rapide avant expiration. La preuve est un relevé daté des renouvellements effectués à temps — à capter automatiquement, car il ne se reconstitue pas après coup.
- Répondez à la clause d'agilité cryptographique par un plan, pas par une affirmation. L'article 6, paragraphe 4, attend des dispositions permettant de faire évoluer la technologie cryptographique à mesure que la cryptanalyse progresse. Si vous ne le pouvez pas encore, l'article 6, paragraphe 5, attend que l'atténuation et son raisonnement soient consignés. Un inventaire de ce que vous exécutez aujourd'hui constitue la première moitié de l'une comme de l'autre réponse.
- Rédigez une seule fois vos réponses de registre. Entité juridique, type de service, localisations, sous-traitants ultérieurs, contact sécurité, délais de notification, objectifs de reprise, conditions de sortie. Publiez-les là où un client peut se servir seul, et le cinquième questionnaire coûtera ce qu'a coûté le premier — rien.
- Comptez votre concentration amont avant qu'un client ne le fasse à votre place. Une seule autorité de certification, un seul fournisseur DNS et une seule plateforme de messagerie derrière tout un parc : c'est un choix défendable et une surprise indéfendable. Toute la différence tient à savoir si vous avez apporté le chiffre à la réunion.
Questions fréquentes
Existe-t-il une certification DORA ?
Non. DORA impose des obligations aux entités financières et instaure un régime de supervision pour les prestataires désignés comme critiques au titre de l'article 31. Rien n'y certifie la conformité de quiconque, et aucun fournisseur ne peut accorder un tel statut. Considérez cette affirmation comme un signal sur le fournisseur.
DORA s'applique-t-il à moi si je ne fais que vendre un logiciel à une banque ?
Pas directement, sauf si vous êtes désigné comme prestataire informatique tiers critique. Il vous atteint par les obligations de votre client au titre des articles 28 à 30 : diligence raisonnable avant signature, clauses contractuelles précises, et une ligne de registre à tenir à jour.
Quel article couvre la cryptographie ?
L'article 9 au niveau 1 — en particulier le paragraphe 2 sur les données au repos, en cours d'utilisation et en transit, le paragraphe 3, point a), sur la sécurité des moyens de transfert des données, et le paragraphe 4, point d), sur la protection des clés et le chiffrement. Le détail qui compte en pratique se trouve dans les RTS : l'article 6 pour le chiffrement et les contrôles cryptographiques, l'article 7 pour la gestion des clés et des certificats.
Où se situe le post-quantique ?
À l'article 6, paragraphe 4, des RTS, qui exige des dispositions pour mettre à jour la technologie cryptographique à mesure que la cryptanalyse progresse. Il ne nomme pas la cryptographie post-quantique — il n'en avait pas besoin. Un plan de migration en est la réponse naturelle, et un inventaire de ce que vous exécutez aujourd'hui en est le préalable.
Une analyse externe suffit-elle pour les articles 24 et 25 ?
Non. L'article 25, paragraphe 1, cite les évaluations et analyses de vulnérabilités parmi de nombreux types de tests, à l'intérieur d'un programme que l'article 24 impose de concevoir, de faire réaliser par des testeurs indépendants et d'appliquer au moins une fois par an aux systèmes soutenant des fonctions critiques ou importantes. L'évaluation externe continue l'alimente ; elle ne le remplace pas.
En quoi cela diffère-t-il de NIS2 ?
Champ différent, superviseurs différents, mais en dessous largement les mêmes preuves techniques. DORA est un règlement d'application directe depuis janvier 2025 ; NIS2 est une directive qui vous lie par le droit national. Si vous produisez déjà des preuves pour l'un, l'essentiel resservira pour l'autre.
Lire le guide compagnon : NIS2 article 21(2) — ce qui constitue une preuve
Produisez ces preuves pour votre propre parc
L'option DORA Trust Center transforme la surveillance continue en une page de préparation fournisseur partageable, une prise en charge du registre d'informations, un avenant à l'article 30 généré et un rapport de preuve signé et vérifiable par empreinte — avec des niveaux de couverture indiqués honnêtement sur le document. Elle est disponible en option sur n'importe quelle formule payante. Commencez par une vérification gratuite pour voir où en est le vôtre.