NIS2 Article 23 : Cartographie des champs Scan vs Modèle

Un scan SaaSFort couvre environ 5 % de ce qu’exige réellement l’Article 23 de NIS2 lorsque vous soumettez une notification d’incident. Les 95 % restants doivent être rédigés par un humain sous pression temporelle — généralement avec le BSI Meldeportal ouvert dans une fenêtre et un canal Slack en feu de l’autre côté.

Cet article est la cartographie honnête des champs. Chaque champ de preuves de l’Article 23, ce que le scanner peut fournir, ce que le modèle de préparation aux incidents couvre, et comment chacun se mappe à la structure du BSI Meldeportal allemand.

Si vous maintenez une position différente en interne — que les scans génèrent d’une façon ou d’une autre des rapports d’incidents automatiquement — votre premier auditeur lisant le résultat le détectera. Mieux vaut le savoir maintenant.

La répartition honnête : 5 % scanner, 95 % modèle

L’Article 21 (contrôles préventifs) et l’Article 23 (notification d’incident) répondent à des questions différentes pour des lecteurs différents. Ils partagent le vocabulaire NIS2 ; ils ne partagent pas les preuves.

Question	Article 21	Article 23
À quoi répond-il ?	Contrôles en place, point dans le temps	Ce qui s’est passé, quand, qui a été touché, ce que vous avez fait
Lecteur	Auditeur avant l’événement	Régulateur après l’événement
Type de preuve	Préventive	Réactive
Généré par le scan ?	Oui (60 contrôles mappés sur 60)	Non (0 contrôle sur 60)

Notre analyse des lacunes de l’Article 23 développe le raisonnement technique sous-jacent. La conclusion est structurelle : les scans observent la posture de l’extérieur vers l’intérieur ; les incidents sont détectés via les logs, l’EDR, le SIEM et les signalements clients — des signaux de l’intérieur vers l’extérieur auxquels le scanner n’a pas accès. L’horloge des 24 heures démarre à la prise de conscience interne, pas lors d’une vérification programmée.

Cette répartition structurelle est exactement ce que le modèle de préparation aux incidents est conçu à combler.

La cartographie des champs de l’Article 23

L’Article 23 de NIS2 (combiné à l’implémentation du BSI Meldeportal) exige 16 champs de preuves répartis sur les trois stades de soumission. Voici chacun d’eux, avec un sourçage honnête.

#	Champ Article 23	Fourni par le scan ?	Fourni par le modèle ?	Notes
1	Date/heure de prise de conscience	Non	Oui	Champ à plus fort enjeu. Personne ne le calcule correctement sous stress. Remplissable dans la feuille de calcul de l’horloge de prise de conscience.
2	Classification de l’incident (taxonomie ENISA RSI)	Non	Oui	7 catégories, liste déroulante dans le modèle.
3	Niveau de sévérité / impact	Non	Oui	Dimensions opérationnelle, financière, réputationnelle.
4	Services et actifs affectés	Non	Oui	Le scan voit un domaine externe — ne connaît pas votre graphe d’actifs interne.
5	Nombre d’utilisateurs affectés	Non	Oui	Zéro signal de télémétrie utilisateur dans le scan.
6	Durée de l’interruption	Non	Oui	L’horodatage du scan ≠ la chronologie de l’incident.
7	Étendue géographique	Non	Oui	Non modélisée par le scanner.
8	Indicateurs de menace (IPs, hachages, domaines, TTPs MITRE)	Partiel (5 %)	Oui	Le scan trouve des expositions (CVE dans une lib JS, .git exposé, source maps), pas des IoC actifs. Le modèle contient un registre IoC complet.
9	Cause malveillante présumée	Non	Oui	Le scanner ne peut pas distinguer une action malveillante d’une mauvaise configuration.
10	Élément transfrontalier	Non	Oui	Routage multi-CSIRT si plusieurs États membres sont affectés.
11	Mesures d’atténuation prises	Non	Oui	Réactif, post-événement.
12	Reprise / PCA-PRA / RTO-RPO réels	Non	Oui	Hors périmètre du scanner.
13	Analyse des causes racines (rapport final)	Non	Oui	Requiert une forensique des logs.
14	Leçons tirées	Non	Oui	Artefact post-incident.
15	Piste d’audit des notifications (horloge 24h/72h/1 mois)	Non	Oui	La feuille de calcul de l’horloge de prise de conscience est la piste d’audit.
16	Journal d’escalade / communications internes	Non	Oui	Registre pré-formaté dans le modèle.

Couverture : scanner ≈ 5 %, modèle ≈ 95 %. Les 5 % sont réels mais adjoints : la sortie du scan vous donne une ligne crédible « régression de contrôle observée à T=… » dans l’alerte précoce, plus un registre d’expositions pré-incident qui ancre l’analyse des causes racines ultérieurement.

Mapping des champs du BSI Meldeportal (format CSIRT)

Pour les entités allemandes, les soumissions de l’Article 23 transitent par le BSI Meldeportal. La structure du Meldeformular a son propre dialecte bureaucratique — savoir comment les champs de l’Article 23 se mappent aux noms de champs du BSI fait gagner des heures durant les premières 24 heures.

Preuve Article 23	Champ BSI Meldeportal (DE)	Équivalent en français
Date/heure de prise de conscience	Zeitpunkt der Kenntnisnahme	Moment de la prise de conscience
Classification de l’incident	Art des Sicherheitsvorfalls	Type d’incident de sécurité
Sévérité / impact	Auswirkung auf den Betrieb	Impact opérationnel
Services et actifs affectés	Betroffene Systeme und Dienste	Systèmes et services affectés
Nombre d’utilisateurs affectés	Anzahl betroffener Nutzer	Nombre d’utilisateurs affectés
Durée de l’interruption	Dauer der Beeinträchtigung	Durée de l’interruption
Étendue géographique	Geografische Ausbreitung	Étendue géographique
Indicateurs de menace	Indikatoren der Kompromittierung	Indicateurs de compromission
Cause présumée	Vermutete Ursache (vorsätzlich/zufällig)	Cause présumée (délibérée/accidentelle)
Élément transfrontalier	Grenzüberschreitende Auswirkung	Impact transfrontalier
Atténuation appliquée	Bisher ergriffene Gegenmaßnahmen	Mesures d’atténuation à ce jour
Reprise / RTO-RPO	Wiederherstellungsstatus	État de la reprise

Piège : le Meldeportal accepte des champs en texte libre, mais le BSI les analyse avec des attentes structurées. Des entrées vagues déclenchent des demandes de suivi qui compriment votre fenêtre de 72 heures. Les conseils champ par champ pré-rédigés du modèle sont calibrés sur les formulations que lisent les analystes CSIRT du BSI.

Les États membres non allemands utilisent des portails CSIRT nationaux comparables — ANSSI en France, ACN en Italie, CCN-CERT en Espagne. Le dépôt multi-juridictionnel est couvert dans notre guide de conformité NIS2 pour MSP.

L’horloge de prise de conscience — Trois délais, une feuille de calcul

Le champ à plus fort effet de levier dans l’Article 23 est aussi celui que les équipes calculent incorrectement sous stress. L’horloge démarre à la prise de conscience, pas à la détection. La prise de conscience est le moment où la fonction responsable de votre organisation a reconnu que l’incident est significatif — typiquement un moment d’escalade documenté, pas la première alerte.

Les trois délais, calculés à partir de la prise de conscience :

Stade	Formule	Ce qui est soumis
Alerte précoce	prise_de_conscience + 24h	Reconnaissance de la prise de conscience, nature préliminaire, attaquant présumé (si connu)
Notification d’incident	prise_de_conscience + 72h	Évaluation initiale de l’impact, IoCs, effet transfrontalier
Rapport final	notification + 1 mois	Cause racine, atténuation appliquée, mesures préventives

La feuille de calcul de l’horloge de prise de conscience dans le kit de préparation aux incidents pré-calcule ces délais avec normalisation des fuseaux horaires (le BSI fonctionne en CET/CEST ; les équipes SaaS multi-régions en UTC). Cinq champs à remplir :

• incident_detecte_a (horodatage de votre alerte monitoring)
• prise_de_conscience_a (le moment d’escalade humain — c’est le départ de l’horloge)
• alerte_precoce_due_a (= prise_de_conscience + 24h)
• notification_due_a (= prise_de_conscience + 72h)
• rapport_final_du_a (= notification + 30j)

La distinction détection/prise de conscience est ce que les auditeurs sondera le plus. Documenter la prise de conscience par écrit — avec horodatage, qui a escaladé, quelle preuve a déclenché l’escalade — est le meilleur investissement de la première heure. Sans cela, un régulateur définit la prise de conscience pour vous, moins généreusement, après coup. Pour le détail de la notification en 24 heures, consultez notre guide BSI modèle 24 heures + exercice sur table.

Format du journal de communications internes

L’Article 23 attend une piste d’audit des communications internes pendant la réponse à l’incident. Les inspections BSI sous §29 BSIG demandent systématiquement ce journal même lorsque la soumission formelle de l’Article 23 est complète.

La structure minimale viable du journal (pré-formatée dans le modèle) :

horodatage	acteur	action	destinataire	canal
2026-05-02T21:47Z	SRE d’astreinte	escalade ransomware présumé dans prod-eu-west-1	CTO	PagerDuty
2026-05-02T21:51Z	CTO	déclare la prise de conscience, démarre l’horloge 24h	PDG, RSSI	téléphone
2026-05-02T22:04Z	RSSI	notifie le cabinet IR externe	cabinet IR	email

Cinq champs, en ajout uniquement, jamais effacés. La question de l’auditeur qui déroute les équipes non préparées : « Montrez-moi quand la direction a été informée pour la première fois. » Si la réponse nécessite une reconstruction forensique de Slack, l’entreprise a déjà perdu le contrôle du cadrage.

Comment cela se connecte au modèle de préparation aux incidents

La cartographie des champs ci-dessus est l’index. Le kit de préparation aux incidents gratuit est la forme exécutable. Il comprend :

• Les modèles de notification 24h / 72h / 1 mois (FR + EN, .docx)
• La feuille de calcul de l’horloge de prise de conscience (remplissable)
• Le journal de communications internes (registre pré-formaté)
• Un exercice sur table avec trois scénarios (ransomware, chaîne d’approvisionnement, exfiltration de données)
• Le mapping au format CSIRT ci-dessus sous forme d’aide-mémoire imprimable

Le kit est en accès libre, gratuit, sans carte de crédit. Les nouveaux comptes SaaSFort reçoivent également automatiquement un essai Growth de 14 jours — utile parce que la sortie du scan fournit les 5 % qui sont effectivement dérivables : base d’exposition pré-incident, détection de régression de contrôle entre scans, et preuves de remédiation dans le rapport final (les rapports finaux de l’Article 23 exigent des « mesures appliquées pour prévenir la récurrence » — un scan clôturé est une preuve réutilisable).

Pour un contexte plus large sur l’origine des preuves de l’Article 21, le modèle d’auto-audit Article 21 NIS2 couvre le volet préventif du même programme de conformité.

Foire aux questions

Pourquoi SaaSFort ne génère-t-il pas automatiquement des rapports Article 23 ?

Parce que les données ne sont pas disponibles pour les générer. Les preuves de l’Article 23 proviennent des logs internes, de l’EDR, du SIEM, des signalements clients et du jugement humain sur la classification et l’impact. Un scanner externe n’a aucun accès à ces signaux. Nous pourrions simuler, mais le premier auditeur le détecterait. Les modèles sont la réponse honnête.

Cette cartographie est-elle spécifique au BSI ou s’applique-t-elle à tous les États membres de l’UE ?

Les 16 champs de preuves s’appliquent à toutes les implémentations NIS2 — ils proviennent de la Directive elle-même. Le mapping des noms de champs du Meldeportal est spécifique au BSI (Allemagne). Pour l’ANSSI (France), l’ACN (Italie) et le CCN-CERT (Espagne), les structures de champs sont similaires mais avec un dialecte bureaucratique différent ; les preuves sous-jacentes sont identiques.

Et si mon entreprise a vécu un « quasi-accident » — dois-je quand même notifier ?

L’Article 23 ne se déclenche que sur les incidents significatifs — interruption opérationnelle, perte financière ou dommage considérable à d’autres personnes. Un quasi-accident sans interruption ne déclenche généralement pas de notification. Documentez-le quand même en interne : les inspections futures recherchent des preuves de triage mûr, pas seulement des rapports soumis.

L’horloge de prise de conscience peut-elle être réinitialisée si de nouvelles informations émergent ?

Non. Une fois la prise de conscience documentée, l’horloge tourne. Les nouveaux faits vont dans la notification de 72 heures ou le rapport final. Réinitialiser la prise de conscience rétroactivement est un geste qui détruit la crédibilité lors d’une inspection — les auditeurs le testent spécifiquement.

Mon entreprise est un éditeur SaaS de moins de 50 personnes vendant à des acheteurs soumis à NIS2. L’Article 23 m’est-il applicable ?

Directement, uniquement si vous êtes indépendamment dans le périmètre. En cascade : oui — l’obligation de la chaîne d’approvisionnement de l’Article 21(2)(d) de votre client vous imposera contractuellement des délais de notification et des preuves. Le même modèle fonctionne pour les obligations directes et en cascade. Consultez notre guide de conformité de la chaîne d’approvisionnement SaaS B2B.

Quelle est la relation entre l’Article 23 et la notification de violation RGPD en 72 heures ?

Ils se chevauchent sur les incidents de données personnelles mais opèrent indépendamment. L’Article 23 NIS2 va au BSI / CSIRT national ; l’Article 33 RGPD va à l’autorité de protection des données (CNIL en France, BfDI en Allemagne). Le même incident peut déclencher les deux notifications avec des délais différents. Notre guide NIS2 vs RGPD couvre la stratégie de dépôt sur deux voies.

---

Les modèles documentent. Les scans vérifient. Ensemble, ils couvrent l’Article 21 et l’Article 23. Téléchargez le kit de préparation aux incidents gratuit — modèles 24h/72h/1 mois, feuille de calcul de l’horloge de prise de conscience, journal de communications internes, exercice sur table, mapping BSI Meldeportal. Les nouveaux comptes bénéficient également d’un essai Growth de 14 jours — lancez un scan de référence pour établir votre registre d’expositions pré-incident. Pour le cadre complet, téléchargez notre SaaS Security Playbook 2026 gratuit.