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

Publié le 19 juin 2026 · Par Richard DEMONGEOT, RDEM Systems · 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.

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 :

Rapport	Délai	L'horloge démarre à…
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	horodatage connaissance / classification
Rapport intermédiaire	Dans les 72 heures de la notification initiale	horodatage notification initiale
Rapport final	Dans un délai d'un mois après le dernier rapport intermédiaire	horodatage 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 :

Norme	Règlement	Pertinence pour le temps
RTS sur le cadre de gestion du risque TIC	(UE) 2024/1774	Journalisation, 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/1772	Critè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é.

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érentiel	Règlement	Ce qu'il demande au temps
DORA	(UE) 2022/2554	Résultats de résilience — détection, horloges d'incident, forensique (cette page). Aucun seuil chiffré.
MiFID II RTS 25	(UE) 2017/574	Précision chiffrée des horloges de négociation (jusqu'à 100 µs). Voir le guide RTS 25.
NIS 2	(UE) 2022/2555	Gestion du risque et déclaration d'incident pour entités essentielles/importantes. Voir NIS 2.
ISO 27001	A.8.17	Contrôle de synchronisation des horloges. Voir ISO 27001 8.17.
PCI-DSS v4.0	Exig. 10.6	Serveurs 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 :

• Mesurer gigue, offset, latence → ntp-tester.eu
• Diagnostiquer pare-feu / port 123 / démon → check-ntp.net
• Architecture de référence entreprise → ntp.rdem-systems.com