Reporting d'incidents

Pourquoi le chronomètre commence avant que vous ne le sachiez

Une erreur récurrente consiste à croire que le délai de notification démarre au moment où l'incident est confirmé, documenté et compris. Ce n'est pas le cas. NIS2 fait courir le délai à partir du moment où l'entité a connaissance de l'incident significatif — c'est-à-dire dès qu'un signal suffisamment consistant existe pour qu'un professionnel raisonnable estime probable qu'un incident affecte la sécurité des réseaux et systèmes d'information. Ce point de départ est délibérément bas : il ne s'agit pas d'attendre la certitude, mais de réagir au soupçon documenté.

Cette bascule de logique change la manière dont une équipe sécurité doit travailler. Le réflexe naturel — creuser, confirmer, puis alerter — devient une source de non-conformité si l'investigation dépasse la fenêtre de 24 heures. Le bon réflexe est inverse : déclencher la notification précoce sur la base d'un faisceau d'indices, puis continuer l'investigation en parallèle, la notification étant conçue pour être mise à jour au fur et à mesure.

Le délai NIS2 se compte en heures calendaires, pas en heures ouvrées. Un incident détecté un vendredi soir à 22h impose une alerte précoce le samedi à 22h au plus tard, week-end ou pas. Une astreinte capable de qualifier un incident et de déclencher une notification hors horaires de bureau est une exigence organisationnelle, pas un confort.

Les trois jalons de notification

NIS2 structure l'obligation de reporting en trois étapes successives, chacune avec un objectif distinct. Il ne s'agit pas de répéter trois fois la même information, mais de fournir un niveau de détail croissant à mesure que la compréhension de l'incident progresse.

Un rapport intermédiaire peut être exigé par l'autorité compétente entre la notification à 72 heures et le rapport final, en particulier lorsque l'incident est encore en cours ou que sa résolution s'étend sur plusieurs semaines. Ce rapport n'est pas systématique : il répond à une demande explicite, généralement motivée par la criticité de l'entité ou l'ampleur de l'incident.

Le dispositif ReCyF comme guichet de transmission

En pratique, une entité française ne notifie pas directement une multitude d'interlocuteurs européens. Le dispositif ReCyF joue le rôle de guichet de transmission national : il reçoit la notification, l'horodate, et la route vers le CSIRT national ainsi que, lorsque l'entité relève d'un secteur régulé spécifique, vers l'autorité sectorielle compétente. Ce routage évite à l'entité notifiante d'avoir à identifier elle-même, dans l'urgence, quelle autorité est destinataire de quelle information — une source d'erreur fréquente lorsque l'entité opère dans plusieurs secteurs à la fois.

Ce canal unique a une conséquence opérationnelle directe : l'horodatage retenu pour apprécier le respect du délai est celui de la transmission via ReCyF, pas celui d'un éventuel échange informel préalable avec un correspondant sécurité. Un appel téléphonique à une autorité, même passé dans les temps, ne remplace pas le dépôt formel. C'est ce dépôt qui fait foi.

ReCyF ne se substitue pas à l'obligation de fond : il en est le vecteur. L'entité reste responsable de la qualité et de l'exactitude des informations transmises, y compris lorsque celles-ci sont reprises automatiquement d'un jalon à l'autre.

Ce qu'il faut réellement écrire dans chaque notification

La tentation, sous la pression du délai, est de remplir un formulaire a minima pour "cocher la case". C'est une erreur qui se paie au moment du rapport final, lorsque l'autorité compare la cohérence des trois documents.

Pour l'alerte précoce à 24 heures, l'objectif n'est pas l'exhaustivité mais la traçabilité du signal :

• Nature de l'incident telle que perçue à ce stade (indisponibilité, compromission de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire, activité malveillante suspectée)
• Indication si une origine malveillante ou illicite est soupçonnée, même sans certitude
• Estimation, même grossière, d'un impact transfrontalier potentiel
• Point de contact interne joignable pour la suite de l'échange

Pour la notification d'incident à 72 heures, une évaluation qualifiée est attendue :

• Gravité et impact évalués selon les critères de significativité retenus par l'entité
• Indicateurs de compromission identifiés à ce stade
• Mesures d'atténuation déjà déployées et leur efficacité observée
• Demande d'assistance à l'autorité, le cas échéant

Pour le rapport final à un mois, l'exigence est celle d'une analyse post-incident complète :

• Description détaillée et chronologie de l'incident
• Type de menace ou cause racine identifiée
• Mesures d'atténuation et correctives mises en œuvre, y compris structurelles
• Impact transfrontalier confirmé, s'il y a lieu

Une incohérence entre l'alerte précoce et le rapport final n'est pas anormale en soi — l'analyse progresse, l'estimation initiale peut évoluer. Ce qui pose problème, c'est l'absence de justification de cette évolution. Documentez systématiquement pourquoi la qualification a changé entre deux jalons.

Exemple de progression sur un cas concret

Un opérateur de service essentiel détecte, un mardi à 14h, un comportement réseau anormal évoquant une exfiltration de données depuis un serveur applicatif exposé. L'alerte précoce est déposée via ReCyF le mardi à 22h : nature "suspicion d'exfiltration", origine malveillante jugée probable, impact transfrontalier non évalué à ce stade faute d'information. Le vendredi à 10h, la notification à 72 heures confirme l'exfiltration, chiffre le volume de données concernées à partir des journaux d'accès, et documente l'isolement du serveur comme mesure d'atténuation. Un mois plus tard, le rapport final identifie la cause racine — une vulnérabilité non corrigée sur un composant tiers — et détaille le plan de remédiation, incluant la mise en place d'un cycle de gestion des correctifs plus court pour les composants exposés.

Ce scénario illustre un point souvent sous-estimé : la qualité du rapport final dépend directement de la rigueur avec laquelle les journaux et décisions ont été conservés dès l'alerte précoce. Une équipe qui improvise sa documentation au moment de rédiger le rapport final reconstruit un mois d'événements de mémoire, avec les pertes d'exactitude que cela implique.

Autorités destinataires et cas particuliers

La notification via ReCyF atteint par défaut le CSIRT national. Selon le secteur d'activité de l'entité, une autorité sectorielle compétente est également destinataire — c'est le cas par exemple pour les secteurs de l'énergie, de la santé ou des infrastructures numériques, où une autorité de régulation sectorielle existe en parallèle de l'autorité NIS2 générale.

Lorsqu'un incident affecte plusieurs États membres, l'information transite entre CSIRT nationaux sans que l'entité ait à multiplier ses démarches auprès de chaque autorité étrangère concernée. C'est précisément la fonction du réseau de CSIRT coordonné au niveau européen : centraliser la diffusiondiffusionIAFamille de modèles génératifs qui synthétisent une image (ou autre signal) en dénisant progressivement un bruit.Voir dans le glossaire transfrontalière à partir d'un point d'entrée national unique.

Préparez à l'avance un gabarit de notification pré-rempli avec les champs stables de votre organisation — identifiants d'entité, secteur, contacts, systèmes critiques déjà cartographiés. En situation d'incident, seule l'information propre à l'événement reste à rédiger, ce qui fait gagner un temps précieux sur une fenêtre de 24 heures déjà courte.

Conserver la preuve du respect des délais

Déposer une notification dans les temps ne suffit pas si l'entité ne peut pas, plusieurs mois plus tard, démontrer à quel moment précis elle a eu connaissance de l'incident. En cas de contrôle, l'autorité compétente ne se contente pas de vérifier le contenu des trois rapports : elle peut demander à reconstituer la chronologie complète, depuis le premier signal technique jusqu'au dépôt effectif via ReCyF.

Cela suppose de conserver, indépendamment des documents transmis aux autorités, un journal interne horodaté couvrant au minimum les éléments suivants :

• L'horodatage du premier signal ayant conduit à la qualification d'un incident probable
• L'identité de la personne ou de l'équipe ayant procédé à cette qualification
• L'horodatage de chaque validation intermédiaire dans la chaîne de décision interne
• L'horodatage exact du dépôt de chaque notification via ReCyF, avec accusé de réception

Ce journal n'a pas vocation à être transmis systématiquement à l'autorité, mais il constitue la pièce qui permet de répondre sereinement à une demande d'audit portant sur le respect effectif des délais. Une entité qui ne peut reconstituer cette chronologie qu'à partir de messageries informelles ou de la mémoire des équipes se met en difficulté, même si les trois notifications ont, dans les faits, été déposées à temps.

Cette exigence de traçabilité rejoint une logique plus large : la conformité NIS2 ne se prouve pas seulement par le résultat final, mais par la capacité à en démontrer le processus. Un dossier d'incident bien tenu protège autant l'entité qu'il protège les personnes concernées par l'incident lui-même.

Pièges opérationnels fréquents

Trois erreurs reviennent régulièrement dans les retours d'expérience d'entités soumises à NIS2.

La première est le retard de qualification : une équipe technique attend d'avoir un diagnostic complet avant de faire remonter l'information au responsable habilité à déclencher la notification. Cette chaîne de validation, utile en temps normal, devient incompatible avec un délai de 24 heures si elle n'est pas raccourcie pour les cas d'incident.

La deuxième est la confusion entre incident et incident significatif. NIS2 ne demande pas de notifier chaque alerte de sécurité mineure. Le seuil de significativité doit être défini en amont, dans la politique de gestion des incidents de l'entité, faute de quoi chaque équipe applique son propre jugement au moment critique — avec le risque soit de sur-notifier, soit de laisser passer un incident qui aurait dû l'être.

La troisième est l'absence de répétition. Un processus de notification qui n'a jamais été testé échoue presque systématiquement à sa première exécution réelle, généralement sur un détail logistique : qui a les droits d'accès à ReCyF, qui est habilité à signer la notification, comment joindre l'astreinte un dimanche.

Les exercices de simulation comme condition de fiabilité

Un plan de réponse à incident qui existe uniquement sur le papier ne garantit rien sur la capacité réelle à tenir un délai de 24 heures. Les exercices de simulation — souvent appelés exercices de table ou tabletop exercises lorsqu'ils sont menés sans interaction technique réelle — permettent de vérifier, hors contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire de crise, que chaque maillon de la chaîne fonctionne : détection, qualification, remontée hiérarchique, rédaction, dépôt via ReCyF.

Un exercice efficace ne se contente pas de vérifier que la procédure est comprise en théorie. Il chronomètre le temps réel nécessaire pour produire une alerte précoce à partir d'un scénario injecté, et il expose les points de friction : un contact obsolète, une procédure d'astreinte non testée un jour férié, une incertitude sur qui a le mandat de signer. Ces exercices gagnent à être menés au moins une fois par an, avec des scénarios renouvelés pour éviter que l'équipe ne rejoue simplement un script mémorisé.

La valeur d'un exercice se mesure aussi à sa capacité à générer des actions correctives suivies d'effet. Un exercice qui identifie un problème sans que celui-ci soit corrigé avant l'exercice suivant n'a produit qu'un constat, pas une amélioration.

Checklist avant de considérer un incident clos

• L'alerte précoce a-t-elle été déposée via ReCyF dans les 24 heures suivant la connaissance de l'incident, même en l'absence de certitude ?
• La notification à 72 heures reflète-t-elle une évaluation qualifiée, avec indicateurs et mesures d'atténuation documentés ?
• Un rapport intermédiaire a-t-il été demandé par l'autorité, et si oui, a-t-il été produit dans le délai fixé ?
• Le rapport final couvre-t-il la cause racine et non seulement les symptômes observés ?
• Les incohérences entre les trois jalons sont-elles expliquées plutôt que simplement présentes ?
• Les enseignements de l'incident ont-ils été intégrés au prochain exercice de simulation ?

Cette checklist n'est pas une fin en soi : elle sert de filtre avant clôture, pour vérifier que le dossier transmis aux autorités correspond à ce qu'une relecture froide, plusieurs semaines après l'incident, jugerait complet et cohérent.