EN FR Accueil

DORA & synchronisation horaire NTP
Règlement (UE) 2022/2554

Aucun seuil chiffré d'horloge — mais la détection, les horloges de déclaration d'incident et le RTS de journalisation reposent tous sur un temps synchronisé et traçable

Publié le 19 juin 2026 · Par Richard DEMONGEOT, RDEM Systems · À propos de l’auteur · Audience : responsables de la résilience opérationnelle, RSSI et gestionnaires du risque TIC dans les banques, assureurs, entreprises d'investissement et leurs prestataires tiers de services TIC soumis à DORA.

1. Périmètre : qui DORA lie — et pourquoi sans chiffre d'horloge

Le règlement sur la résilience opérationnelle numérique — règlement (UE) 2022/2554 (DORA) s'applique depuis le 17 janvier 2025 à un large ensemble d'entités financières (établissements de crédit, établissements de paiement et de monnaie électronique, entreprises d'investissement, assureurs, prestataires de services sur crypto-actifs, etc.) et, via son cadre de supervision, à leurs prestataires tiers critiques de services TIC.

Contrairement à MiFID II RTS 25, DORA ne contient aucune exigence chiffrée de précision d'horloge. Pas de « ±100 µs », pas de table de granularité. Cette absence est la chose la plus importante à comprendre — et le piège. Les obligations de DORA sont fondées sur les résultats, et plusieurs de ces résultats supposent silencieusement que le temps de votre parc est synchronisé, traçable et digne de confiance.

2. Pourquoi le temps est porteur sans seuil

Trois résultats de DORA se brisent dès que les horloges divergent :

  • On ne corrèle pas ce qu'on n'aligne pas. Détecter une anomalie (art. 10) suppose de joindre des événements de pare-feu, d'applications, de systèmes d'identité et de prestataires TIC. Si leurs horloges divergent de quelques secondes, la chronologie de l'attaque se brouille et la logique de détection se déclenche à tort.
  • On ne prouve pas un délai qu'on ne peut horodater. Les horloges de déclaration (art. 19) partent de « la connaissance » et de « la classification ». Ce sont des horodatages. Une horloge contestée ou dérivante transforme « nous avons déclaré dans les 4 heures » en un débat impossible à gagner.
  • On ne reconstitue pas une chaîne forensique qui ne s'aligne pas. L'analyse post-incident et le rapport final (art. 19) dépendent d'une séquence d'événements cohérente entre systèmes — qui n'existe que si les horodatages partagent une seule référence.

La question pertinente pour DORA n'est donc pas « quelle précision ? » mais « quelle fiabilité et cohérence ? » — une référence authentifiée unique, synchronisée sur tout le parc, avec la chaîne documentée.

3. Détection des anomalies (article 10)

L'article 10 impose aux entités financières de disposer de mécanismes pour détecter rapidement les activités anormales, y compris les problèmes de performance des réseaux TIC et les incidents liés aux TIC, et pour identifier les points uniques de défaillance potentiels. La détection à l'échelle, c'est de la corrélation, et la corrélation ne vaut que ce que valent les horodatages qu'elle joint.

Les entités financières mettent en place des mécanismes pour détecter rapidement les activités anormales […] y compris les problèmes de performance des réseaux TIC et les incidents liés aux TIC, et pour identifier les points uniques de défaillance matériels potentiels. — Article 10, paragraphe 1, règl. (UE) 2022/2554 (paraphrase)

Conséquence pratique : la couche temps est elle-même un point unique de défaillance potentiel. Une source de temps non authentifiée et à raccordement unique dont dépend chaque journal est exactement le type de dépendance que l'article 10 demande de repérer et de supprimer — d'où un service de temps résilient et authentifié (voir §6) comme partie de sa satisfaction.

4. Les horloges de déclaration d'incident majeur (articles 17 à 20)

Les articles 17 et 18 imposent un processus documenté de gestion des incidents liés aux TIC et une classification des incidents (les incidents majeurs et les cybermenaces importantes étant distingués). L'article 19 impose de déclarer les incidents majeurs à l'autorité compétente ; l'article 20 fixe le contenu harmonisé et les délais de déclaration. Les délais ci-dessous ne figurent pas dans le corps de l'article 19 lui-même — ils sont fixés par les normes de déclaration adoptées au titre de l'article 20 — le RTS (UE) 2025/301 (contenu et délais des rapports) et l'ITS (UE) 2025/302 (modèles) — mais chacun est ancré à un horodatage :

RapportDélaiL'horloge démarre à…
Notification initialeDès que possible — dans les 4 heures suivant la classification comme majeur, et au plus tard 24 heures après en avoir eu connaissancehorodatage connaissance / classification
Rapport intermédiaireDans les 72 heures de la notification initialehorodatage notification initiale
Rapport finalDans un délai d'un mois après le dernier rapport intermédiairehorodatage rapport intermédiaire

Ces délais sont fixés par les normes techniques de déclaration adoptées au titre de l'article 20, et non chiffrés par l'article 19. Le point pour la couche temps reste le même : chacun se mesure entre deux instants enregistrés.

5. Les RTS qui concrétisent (2024/1774 & 2024/1772)

DORA délègue le détail aux autorités européennes de surveillance, dont les normes techniques sont l'endroit où la dépendance au temps devient opérationnelle :

NormeRèglementPertinence pour le temps
RTS sur le cadre de gestion du risque TIC(UE) 2024/1774Journalisation, enregistrement des événements et contrôles d'intégrité/authenticité que sous-tend un temps traçable et authentifié.
RTS sur la classification des incidents(UE) 2024/1772Critères et seuils d'importance des incidents « majeurs » — appliqués à une chronologie d'événements qui doit être cohérente en interne.

Le RTS (UE) 2024/1774 en particulier intègre la journalisation et la protection de l'intégrité et de l'authenticité des données au cadre de gestion du risque. Des journaux dont les horodatages ne sont pas synchronisés — ou dont la source de temps est usurpable — échouent au test d'utilité (impossible de les corréler) comme au test d'intégrité (impossible de leur faire confiance).

6. Une topologie de temps résiliente pour DORA

Parce que DORA porte sur la résilience et non sur un chiffre, l'objectif de conception est l'absence de point unique de défaillance et une référence authentifiée et supervisée :

        ┌───────────────────────────────────────────────┐
        │  Références diverses (pas de dépendance unique)│
        │  ─────────────────────────────────────────────  │
        │  GNSS + PPS  ·  UTC(k) labo national           │
        │  sources publiques NTS authentifiées          │
        └─────────────────┬─────────────────────────────┘
                          │  NTS (RFC 8915) — authentifié
                          ▼
        ┌───────────────────────────────────────────────┐
        │  Serveurs de temps internes redondants (pairés)│
        │  ─────────────────────────────────────────────  │
        │  supervisés en offset & joignabilité          │
        │  alerte sur dérive = anomalie détectable      │
        └─────────────────┬─────────────────────────────┘
                          │  une référence cohérente
                          ▼
        ┌───────────────────────────────────────────────┐
        │  Tout le parc journalise sur la même horloge   │
        │  ─────────────────────────────────────────────  │
        │  SIEM · apps · identité · prestataires TIC     │
        │  corrélation & chronologie d'incident tiennent │
        └───────────────────────────────────────────────┘

C'est le schéma Stratum 1 supervisé et authentifié qu'exploite et documente RDEM Systems : une référence disciplinée par GNSS, supervisée par PPS, distribuée via NTS, redondante et supervisée. L'architecture de référence et le rôle du serveur sont sur le hub — l'infrastructure de temps RDEM, la référence du serveur Stratum 1, et NTS (RFC 8915) pour le canal authentifié.

Lorsque la chaîne de temps résiliente est fournie en service plutôt que construite en interne, RDEM Systems opère la synchronisation et maintient la traçabilité documentée et auditable vers UTC — l'audit de traçabilité vers UTC, au forfait ou en régie.

Reste une question que le schéma ne résout pas : qui opère les sources amont. DORA traite le risque lié aux prestataires TIC tiers comme un risque de résilience à part entière, et une entité financière européenne dont toute la chaîne de temps repose sur time.google.com ou l'horloge d'un hyperscaler a, de fait, externalisé sa référence temporelle hors de l'UE — sans contrat, sans SLA et sans recours. C'est l'argument de la source de temps souveraine : non pas une préférence politique, mais la suppression d'une dépendance tierce que le régulateur vous demandera de justifier.

7. Ce que recherche un contrôleur

Pour la couche temps, constituez :

  1. Architecture & analyse des SPOF. La topologie de temps, montrant des références diverses et l'absence de point unique de défaillance — réponse directe à l'article 10.
  2. Authentification. La preuve que le canal de temps est authentifié (NTS), à l'appui des contrôles d'intégrité/authenticité du RTS (UE) 2024/1774.
  3. Supervision & alerte. La preuve que l'offset d'horloge et la joignabilité des sources sont supervisés et qu'une dérive lève une alerte — autrement dit, la panne d'horloge est elle-même une anomalie détectable.
  4. Preuve de synchronisation sur le parc. Statut échantillonné de systèmes représentatifs (SIEM, applications, identité, principaux prestataires TIC) montrant une référence unique cohérente.
  5. Validation des sources. Sortie du Validateur NTP en ligne sur chaque source externe — stratum, offset, refID, joignabilité double pile — pour le dossier.

8. DORA vs MiFID II et les autres référentiels

DORA est la couche de résilience ; les autres fixent les contrôles spécifiques. Le bon modèle mental :

RéférentielRèglementCe qu'il demande au temps
DORA(UE) 2022/2554Résultats de résilience — détection, horloges d'incident, forensique (cette page). Aucun seuil chiffré.
MiFID II RTS 25(UE) 2017/574Précision chiffrée des horloges de négociation (jusqu'à 100 µs). Voir le guide RTS 25.
NIS 2(UE) 2022/2555Gestion du risque et déclaration d'incident pour entités essentielles/importantes. Voir NIS 2.
ISO 27001A.8.17Contrôle de synchronisation des horloges. Voir ISO 27001 8.17.
PCI-DSS v4.0Exig. 10.6Serveurs désignés, sources approuvées, paramètres protégés. Voir PCI-DSS 10.6.

Une entité financière soumise à plusieurs de ces référentiels n'a pas besoin d'infrastructures de temps séparées : un seul service résilient, authentifié et traçable satisfait les résultats de DORA, le chiffre de RTS 25 et les exigences de contrôle de NIS 2, ISO 27001 et PCI-DSS à la fois. Cartographiez-les tous dans la checklist d'audit NTP. DORA est mis en œuvre par votre autorité nationale compétente, selon les normes fixées par les autorités européennes de surveillance (ABE, AEAPP, AEMF), les prestataires tiers critiques de services TIC relevant du cadre de supervision dédié des AES.

Autre angle ? Le bon outil :

Questions fréquentes

DORA impose-t-il une précision d'horloge comme MiFID II ?

Non. Contrairement à MiFID II RTS 25, qui fixe des paliers de divergence chiffrés (jusqu'à 100 microsecondes), DORA (règlement (UE) 2022/2554) ne fixe aucun seuil chiffré de précision d'horloge. Ses exigences sont fondées sur les résultats : les entités financières doivent détecter les anomalies, gérer et déclarer les incidents liés aux TIC dans des délais fixes, et reconstituer les événements à des fins forensiques. Chacun de ces résultats dépend d'un temps synchronisé et traçable ; le temps exact est donc un contrôle implicite mais porteur, plutôt qu'un chiffre à atteindre.

Quels articles de DORA touchent à la synchronisation horaire ?

Aucun article ne nomme NTP, mais plusieurs sont inopérants sans temps synchronisé : l'article 10 (détection des activités anormales) requiert des horodatages corrélés entre systèmes ; les articles 17 et 18 (gestion et classification des incidents) requièrent une chronologie d'événements exacte ; les articles 19 et 20 (déclaration des incidents majeurs et modèles harmonisés) imposent des délais fixes que vous devez pouvoir prouver. Le détail d'application figure dans le règlement délégué (UE) 2024/1774 (gestion du risque TIC, dont la journalisation) et (UE) 2024/1772 (classification des incidents).

Quels sont les délais de déclaration d'incident majeur DORA ?

Pour un incident classé majeur, les délais sont fixés par les normes techniques de déclaration (RTS/ITS) adoptées au titre de l'article 20, et non par le corps de l'article 19 lui-même. Ils sont : une notification initiale dès que possible — dans les 4 heures suivant la classification comme majeur et au plus tard 24 heures après en avoir eu connaissance ; un rapport intermédiaire dans les 72 heures de la notification initiale ; et un rapport final dans un délai d'un mois après le dernier rapport intermédiaire. Chacune de ces horloges démarre à un horodatage enregistré (connaissance, classification, rapport précédent) : si vos systèmes divergent sur le moment d'un événement, vous ne pouvez pas prouver de façon fiable le respect du délai.

DORA exige-t-il NTS (NTP authentifié) ?

Pas nommément. Mais le cadre de gestion du risque TIC de DORA (article 9 et RTS (UE) 2024/1774) exige de protéger l'intégrité et l'authenticité des données et la résilience des systèmes de support. Une source de temps usurpable mine les horodatages dont dépendent votre détection et vos preuves d'incident. NTS (RFC 8915) est la façon normalisée d'authentifier le canal de temps ; c'est donc le contrôle naturel pour satisfaire cette attente d'intégrité pour la couche temps.

En quoi DORA diffère-t-il de MiFID II RTS 25 sur le temps ?

Ils répondent à des questions différentes. MiFID II RTS 25 (règl. (UE) 2017/574) régit la précision d'une horloge de négociation par rapport au temps UTC, avec des paliers chiffrés. DORA régit la résilience opérationnelle : il ne fixe pas de budget d'horloge, mais exige que la détection, la chronologie des incidents et la reconstitution forensique fonctionnent — ce qui repose entièrement sur un temps synchronisé, traçable et authentifié. Une entreprise soumise aux deux atteint le chiffre de RTS 25 et utilise la même infrastructure de temps résiliente pour satisfaire les résultats de DORA.