Incidents majeurs et notification

Pourquoi ce chapitre conditionne toute la conformité opérationnelle

Un programme DORA peut être irréprochable sur le papier — cartographie des actifs à jour, tests de résilience planifiés, contrats tiers révisés — et s'effondrer au premier incident réel si la chaîne de notification n'a pas été répétée. Ce n'est pas un exercice documentaire : c'est un processus chronométré, déclenché par un événement que personne ne choisit ni ne planifie, et jugé a posteriori sur des minutes et des heures, pas sur des intentions.

La notification d'incident majeur est aussi le point où DORA devient visible de l'extérieur. C'est le moment où une autorité compétente, parfois un client professionnel, parfois le marché, observe la capacité réelle d'une entité à détecter, qualifier et communiquer sur une défaillance de son système d'information. Une classification tardive ou une notification bâclée pèsera plus lourd, en termes de réputation et de suites de contrôle, que l'incident technique lui-même.

La notification d'incident n'est pas une formalité déclarative après coup. C'est un processus déclenché en temps réel, avec des délais courts qui commencent à courir dès la classification — pas dès la résolution complète de l'incident.

Qu'est-ce qu'un incident majeur au sens de DORA

DORA distingue plusieurs catégories d'événements liés aux technologies de l'information et de la communication (TIC) :

• l'incident TIC au sens large, tout événement imprévu affectant la sécurité, la disponibilité, l'intégrité ou l'authenticité des systèmes ;
• l'incident significatif, dont l'impact reste circonscrit ;
• l'incident majeur, qui franchit des seuils prédéfinis et déclenche une obligation de notification externe ;
• la cybermenace majeure, événement potentiel mais non encore matérialisé, dont la notification reste volontaire mais encouragée.

Seul l'incident majeur oblige à notifier l'autorité compétente selon le calendrier réglementaire. Le classement d'un événement dans cette catégorie ne relève pas d'une appréciation qualitative libre : il repose sur une grille de critères objectifs, précisée par les normes techniques de réglementation (RTS) et d'exécution (ITS) qui complètent le règlement DORA.

Les critères de classification

Ces critères ne s'appliquent pas isolément : la classification résulte généralement du franchissement combiné de plusieurs seuils, selon une logique définie par les RTS. Une entité doit donc disposer d'une grille pré-calibrée, alignée sur ses propres seuils d'activité, plutôt que de réinterpréter les critères à chaud pendant la crise.

Un incident purement interne, sans impact client ni service critique touché, peut rester un incident significatif consigné au registre sans notification externe. La frontière entre significatif et majeur est précisément l'objet de la grille de classification — elle doit être calibrée avant l'incident, pas pendant.

La chaîne de notification à l'autorité compétente

Une fois un incident classifié comme majeur, l'entité entre dans un calendrier de notification structuré en trois étapes vers son autorité compétente (NCA — National Competent Authority, ou l'autorité sectorielle désignée selon le type d'entité).

Notification initiale. Elle intervient dans un délai court après la classification de l'incident comme majeur — de l'ordre de quelques heures selon les textes techniques applicables. Elle peut être partielle et provisoire : l'objectif est d'alerter l'autorité, pas de livrer une analyse complète.

Rapport intermédiaire. Transmis lorsque la situation évolue de façon significative, ou à l'issue d'un délai fixé par les normes techniques après la notification initiale. Il actualise le statut : incident en cours, contenu, ou résolu, avec les impacts observés à date.

Rapport final. Produit une fois la cause racine identifiée et les mesures correctives engagées. Il documente l'analyse complète : chronologie, cause, impacts chiffrés, actions correctives et préventives.

Les délais réglementaires démarrent à la classification, pas à la résolution. Attendre une confirmation définitive de la cause racine avant d'envoyer la notification initiale expose l'entité à un dépassement de délai, sanctionnable indépendamment de la gravité réelle de l'incident.

Qui reste responsable en cas de sous-traitance

Lorsque l'incident trouve son origine chez un prestataire TIC tiers — hébergeur cloud, éditeur de logiciel critique, opérateur de paiement — l'obligation de notification demeure à la charge de l'entité financière cliente. Le contrat avec le prestataire doit prévoir une clause d'information rapide en cas d'incident de son côté, faute de quoi l'entité financière découvre l'incident trop tard pour respecter ses propres délais.

Un établissement de paiement constate une indisponibilité de son service de virements instantanés pendant trois heures, causée par une panne chez son fournisseur d'infrastructure cloud. Le nombre de clients affectés et la durée franchissent les seuils de classification. L'établissement — pas le fournisseur — doit notifier son autorité compétente selon le calendrier réglementaire, tout en engageant en parallèle une demande d'explication contractuelle auprès du prestataire.

Le contenu attendu des rapports

Les gabarits harmonisés définis par les autorités européennes de surveillance (EBA, ESMA, EIOPA) structurent chaque rapport autour de champs communs :

• identification de l'entité et de l'incident (référence unique, horodatage) ;
• classification et critères ayant conduit à la qualification de majeur ;
• services et fonctions affectés, y compris tiers impliqués ;
• impacts quantifiés : clients, transactions, montants, durée ;
• actions déjà engagées et mesures de confinement ;
• pour le rapport final, la cause racine et le plan de remédiation avec échéances.

Préparer un gabarit pré-rempli avec les champs statiques de l'entité (identifiants, contacts, coordonnées de l'autorité compétente, liste des services critiques déjà cartographiés) permet de gagner un temps précieux au moment où l'incident survient. La cellule de crise ne doit avoir à compléter que les champs variables liés à l'événement lui-même.

La communication aux clients et parties prenantes

La notification réglementaire et la communication aux clients répondent à des logiques différentes et suivent des calendriers distincts. La première est encadrée par des délais et des formats imposés par les textes techniques ; la seconde relève d'obligations contractuelles, de bonnes pratiques de transparence et de gestion de la confiance commerciale.

Un incident majeur affectant directement l'usage d'un service — indisponibilité d'une application bancaire, retard de règlement, exposition de données — appelle une communication proactive vers les clients concernés, même lorsque le rapport final réglementaire n'est pas encore finalisé. Attendre la clôture du dossier réglementaire pour informer les clients revient souvent à communiquer trop tard, après que l'information a déjà circulé par d'autres canaux — réseaux sociaux, presse, bouche-à-oreille.

La cohérence entre les deux communications reste néanmoins essentielle : les chiffres d'impact annoncés aux clients doivent rester compatibles avec ceux transmis à l'autorité, sous peine de contradictions embarrassantes en cas de contrôle croisé.

Le registre interne des incidents

Indépendamment de toute notification externe, DORA impose la tenue d'un registre exhaustif de tous les incidents TIC, majeurs comme significatifs. Ce registre :

• centralise la chronologie, la classification, les impacts et le traitement de chaque événement ;
• permet de démontrer, lors d'un contrôle, la cohérence de la grille de classification appliquée dans la durée ;
• alimente les analyses de tendance utilisées dans les revues de risque périodiques et dans les tests de résilience opérationnelle numérique ;
• sert de point de référence en cas de récidive ou d'incident lié, en particulier lorsqu'un même prestataire tiers est impliqué à plusieurs reprises.

Le registre doit être tenu à jour en continu, indépendamment du fait qu'un incident donné ait ou non déclenché une notification externe. C'est souvent ce registre, plus que les rapports individuels, que les autorités examinent en priorité lors d'un contrôle sur place : il révèle si la grille de classification est appliquée de façon constante ou ajustée au cas par cas pour éviter les notifications.

Distinction avec NIS2 et articulation des obligations

DORA constitue un régime sectoriel harmonisé, dédié aux entités financières, avec des critères de classification et des délais de notification propres. NIS2, de portée plus large, couvre les infrastructures critiques et les opérateurs de services essentiels tous secteurs confondus. Une entité financière relevant simultanément des deux régimes doit vérifier, au cas par cas, lequel s'applique à un incident donné — DORA prévalant en principe pour les entités et incidents strictement couverts par son champ d'application sectoriel, avec des mécanismes de coordination entre autorités prévus par les textes pour éviter une double notification incohérente.

Pièges fréquents et checklist opérationnelle

Les erreurs les plus courantes observées lors des premiers exercices de notification :

• grille de classification laissée à l'appréciation individuelle de l'astreinte, sans seuils chiffrés validés en amont ;
• absence de clause contractuelle imposant aux prestataires critiques une remontée d'information rapide en cas d'incident ;
• notification initiale retardée dans l'attente d'une cause racine confirmée ;
• registre interne alimenté a posteriori, plusieurs jours après l'incident, perdant en fiabilité chronologique ;
• communication client improvisée, sans validation préalable de cohérence avec les chiffres transmis à l'autorité ;
• absence de test réel de la procédure de notification, découverte de ses lacunes au premier incident réel plutôt qu'en simulation.

Une checklist minimale avant tout déploiement du processus :

1. grille de classification chiffrée et validée par la fonction risque ;
2. gabarit de notification pré-rempli pour chaque type d'incident probable ;
3. clause contractuelle de remontée rapide chez chaque prestataire TIC critique ;
4. procédure d'astreinte testée en simulation au moins une fois par an ;
5. registre interne connecté au processus de gestion des incidents dès la détection, pas après coup ;
6. modèle de communication client pré-validé par la conformité et la communication.

Ce qu'il faut retenir

La notification d'incident majeur transforme un problème technique en obligation chronométrée envers une autorité et, en parallèle, en devoir de transparence envers les clients. La classification doit être objectivée en amont, la chaîne de notification répétée avant l'incident réel, et le registre interne tenu en continu pour documenter la cohérence de la démarche dans la durée. Ce chapitre pose les bases opérationnelles qui seront mobilisées dans les chapitres suivants sur les tests de résilience et la gestion des prestataires tiers critiques.