DORA : leçons de la première année

Par Jonas Osman Abdelghafour.

Un cycle complet de déclaration d'incidents sous le règlement sur la résilience opérationnelle numérique (DORA) a produit un constat net : la contrainte déterminante est rarement la technologie de détection. C'est la capacité à classifier correctement un incident, à rassembler des données d'impact précises, et à déposer une déclaration dans des délais serrés pendant que l'incident est encore géré. Les entreprises en difficulté l'ont été pour des raisons organisationnelles, non techniques.

La classification est la partie difficile

Les critères de classification de DORA — clients et contreparties affectés, durée et indisponibilité de service, dispersion géographique, pertes de données, criticité des services touchés et impact économique — sont raisonnables pris individuellement mais exigeants collectivement sous contrainte de temps. Les évaluer requiert de savoir quels services métier dépendent du composant affecté, combien de clients se trouvent derrière ces services, et quelle a été réellement la durée d'indisponibilité.

Les entreprises disposant d'une cartographie maintenue reliant services métier, applications et infrastructure ont répondu en quelques heures. Celles qui n'en avaient pas ont passé la fenêtre de déclaration à reconstruire cette cartographie à partir de connaissances tacites, ce qui est à la fois lent et peu fiable. L'investissement le plus précieux issu de la première année n'est pas l'outillage ; c'est une cartographie des dépendances de service maintenue à jour comme un contrôle, et non rafraîchie pour un audit.

La deuxième leçon de classification concerne l'agrégation. Des incidents récurrents individuellement sous les seuils peuvent devenir déclarables lorsqu'ils sont reliés entre eux. Cela requiert un registre d'incidents structuré de manière à identifier une cause racine commune, ce que de nombreux systèmes de tickets ne prennent pas en charge par défaut.

Les délais imposent un processus préconstruit

Le modèle de déclaration par étapes — notification initiale, rapport intermédiaire, rapport final — suppose qu'une entreprise puisse produire rapidement une vue préliminaire défendable et l'affiner ensuite. Deux comportements provoquent l'échec. Le premier consiste à attendre la certitude avant de notifier ; le cadre n'exige pas de certitude au stade initial. Le second est une chaîne de validation juridique et de communication conçue pour une divulgation réfléchie plutôt que pour des délais réglementaires.

Le remède est banal et efficace : des modèles pré-remplis avec les données statiques de l'entreprise, un approbateur délégué disposant de l'autorité pour déposer en dehors des heures ouvrées, un responsable de la déclaration d'incidents distinct du commandant de l'incident, et une répétition à chaque exercice majeur de résilience. Les entreprises ayant simulé leur processus de déclaration avant d'en avoir besoin ont connu la première année la plus fluide.

Le registre des tiers justifie son coût

Le registre d'informations sur les dispositifs contractuels avec des tiers prestataires TIC a été largement perçu comme une charge de collecte de données. Il devient un atout dès qu'un incident implique un prestataire, car il indique immédiatement quels contrats, quels services, quelle criticité et quelles modalités de sortie s'appliquent. Les problèmes récurrents de qualité des données n'ont rien de surprenant : identifiants d'entités incohérents, chaînes de sous-traitance enregistrées uniquement au premier rang, et évaluations de criticité héritées plutôt qu'effectivement évaluées.

La concentration de quatrième rang est le risque que cet exercice révèle et que peu d'entreprises ont traité. Plusieurs prestataires reposant sur la même région cloud ou le même fournisseur d'identité constituent un point de défaillance unique qu'une évaluation prestataire par prestataire ne peut pas voir. L'analyse doit être menée sur l'ensemble du registre, et non entrée par entrée.

Des tests qui produisent des constats utiles

Les tests de résilience sous DORA ne sont utiles que lorsque les scénarios sont sévères et plausibles : perte d'un prestataire critique, corruption plutôt que simple indisponibilité des données, et compromission de l'outillage même utilisé pour répondre. Les tests d'intrusion pilotés par la menace, pour les entreprises concernées, doivent viser les services métier, pas seulement l'infrastructure. Les constats doivent être suivis jusqu'à clôture avec la même discipline que les constats de validation, et les hypothèses de délai de reprise utilisées dans la planification de résilience doivent être testées, non simplement affirmées.

Priorités pour l'année deux

• Maintenir la cartographie des dépendances services-actifs comme un contrôle vivant doté d'un propriétaire.
• Automatiser l'extraction des données de classification depuis les sources de supervision et de gestion de la relation client.
• Déléguer l'autorité de dépôt et répéter le parcours de déclaration en dehors des heures ouvrées.
• Nettoyer le registre des tiers et analyser la concentration sur l'ensemble de celui-ci, y compris les sous-traitants.
• Tester des scénarios de corruption de données et de perte de prestataire, et valider les délais de reprise annoncés.
• Rendre compte de la posture de résilience au conseil en termes de services métier, non de comptage de systèmes.

La question sous-jacente de DORA est de savoir si une entreprise peut continuer à fournir ses services critiques malgré une perturbation. Le régime déclaratif n'est que le mécanisme qui rend visible la réponse honnête.

Sources principales : Règlement (UE) 2022/2554 (DORA) et normes techniques réglementaires/d'exécution associées sur la classification des incidents, la déclaration et le registre d'informations ; rapport d'évaluation des risques de l'ABE, juin 2026.