L'horloge NIS2 européenne est déjà en marche : pourquoi votre interrogation SNMP de cinq minutes ne tiendra pas le délai de 24 heures

Le délai d'alerte précoce de 24 heures de NIS2 démarre dès que vous prenez connaissance d'un incident important. Si votre supervision réseau interroge encore les compteurs d'équipements toutes les cinq minutes, le compteur tourne déjà avant que quiconque dans votre NOC n'ait vu l'événement. Cet écart, entre la cadence réglementaire et la cadence de télémétrie, est la part de la conformité NIS2 qu'aucun tableau de bord ne peut combler.

Ce que nous ne prétendons pas

Avant l'exposé réglementaire ou la démonstration technique, voici la lecture honnête :

Ce que NIS2 exige réellement

NIS2 est la deuxième génération de directive de l'Union européenne sur la sécurité des réseaux et des systèmes d'information (directive (UE) 2022/2555). Elle remplace la version initiale de 2016 et fixe un socle harmonisé de cybersécurité dans les 27 États membres ; les règles nationales s'appliquent à compter du 18 octobre 2024. La directive englobe environ 160 000 entités : FAI régionaux, IXP, opérateurs de cloud souverain et de data centers, MSSP et prestataires de services de confiance, aux côtés des opérateurs tier 1. Tous se trouvent dans le même périmètre de conformité, avec le même délai de notification.

La plupart des opérateurs n'ont pas intégré ce qu'implique en pratique un délai de 24 heures ancré sur la prise de connaissance. Avant l'argumentaire sur la télémétrie, voici à quoi ce délai ressemble.

Cela mérite qu'on s'y arrête un instant. Un régulateur qui découvre par la suite que l'incident a réellement commencé à T-moins-90 minutes, parce que votre cycle SNMP de 5 minutes a manqué les trois premiers états, ne vous rendra pas le temps que la cadence d'interrogation a consommé.

Qui NIS2 attrape, et ce qu'il en coûte de passer à côté

ENISA estimates more than 160,000 entities fall under NIS2, against 10–15,000 under NIS1. The directive splits them into entités essentielles (Annex I: energy, transport, banking, health, water, digital infrastructure, ICT service management, public administration) and entités importantes (Annex II: postal, waste, food, manufacturing of critical products).

Qui est concerné dans l'audience d'IP Infusion

• Regional fibre ISPs, mobile and Open RAN operators: essentielle, exemptés du seuil de taille.
• IXPs, data-centre and cloud providers (including sovereign cloud): essentielle.
• Prestataires de services de confiance : toujours essentiels, sans plancher de taille.
• MSP et MSSP : essentiels au titre de la gestion des services TIC.

Pour les communications électroniques publiques, le DNS, les TLD et les services de confiance, le seuil de taille ne vous met pas à l'abri.

Sanctions, responsabilité personnelle et délai de notification

Article 34's €10M or 2% of turnover figure for essential entities (€7M / 1.4% for important entities) is the EU-wide plancher that member states can exceed, not a cap; none have gone lower. Article 20 puts the obligation on named individuals at the management body, and Article 32(5)(b) lets regulators temporarily prohibit a CEO or legal representative from managerial functions until the breach is remediated. Article 33 extends the same enforcement to important entities; Germany codifies personal executive liability in Section 38(2) of the BSIG (the German IT Security Act). Article 23 anchors the reporting clock on awareness: 24-hour early warning, 72-hour incident notification, one-month final report.

L'Allemagne mène la transposition avec la NIS2UmsuCG (en vigueur depuis le 6 décembre 2025, plus de 29 500 entités concernées, sans période transitoire). L'Italie et l'Autriche atteindront leur pleine application en octobre 2026 ; la plupart des autres grands marchés sont déjà en vigueur ou encore en cours de rédaction. L'application a commencé : depuis le début de 2026, le BSI a adressé des mises en demeure formelles à des entités concernées, l'Allemagne a ouvert des procédures pour notification d'incident tardive, la France a émis des avertissements formels et l'Italie a lancé des inspections sectorielles. Les amendes assises sur le chiffre d'affaires les plus lourdes ne sont pas encore tombées, mais une montée en charge de type RGPD est manifestement enclenchée.

Article 21(2) lists ten minimum risk-management measures. The ones that drive this post are (b) incident handling, (f) policies to assess effectiveness of measures, et (d) supply chain security. The first two share a technical prerequisite most operators have not built: continuous, standards-based network telemetry. The third requires a supply chain you can actually inspect.

Déjà en production dans les juridictions ayant transposé NIS2

While the incumbents publish NIS2 readiness whitepapers, European operators on OcNOS are already in production inside transposed jurisdictions. eww ITandTEL runs a sovereign MPLS backbone in Upper Austria on disaggregated 400G ZR+ hardware (essential-entity profile under Austria's NISG 2026). DIGI Group runs OcNOS for OLT aggregation in Romania, where the DNSC can verify the hardware and software substitution path. AnschlussWerk across DACH and ASOM-Net in Denmark run OcNOS in production under Germany's NIS2UmsuCG, the most aggressive regime in Europe. Three jurisdictions, three operators, one architectural shape. The rest of this post is the technical reasoning behind that shape.

Pourquoi votre télémétrie réseau est le maillon manquant (et pourquoi l'industrie vous vend la mauvaise solution)

Your detection is only as fast as your telemetry. NIS2 never uses the word "monitoring" in its operative articles, and vendors have taken that as cover to frame the directive as a governance exercise. That framing does not hold up: Implementing Regulation (EU) 2024/2690 and ENISA's Technical Implementation Guidance v1.0 (26 June 2025) name network traffic monitoring, log management and anomaly detection outright for digital-infrastructure entities, and operators outside IR 2024/2690 scope face the same expectations through national transposition. Article 23's 24-hour clock leaves very little room once a five-minute SNMP cycle has eaten part of it.

Pourquoi SNMP ne peut pas porter la charge

Trois modes de défaillance, qui amputent chacun la fenêtre de réponse sous un délai de 24 heures :

• Cadence d'interrogation. Un intervalle de 5 à 15 minutes signifie que votre connaissance de tout événement accuse un retard pouvant atteindre un cycle complet. Une attaque DDoS volumétrique se terminant à l'intérieur d'une fenêtre, ou un retrait BGP qui reconverge avant le prochain sondage, est invisible pour le NMS. Vous l'apprenez par une plainte en aval, et vous avez déjà brûlé des heures du budget de 24 heures.
• Échantillonnage de la dernière valeur uniquement. Si un lien bascule cinquante fois entre deux sondages, vous ne voyez qu'un seul état final. La chronologie forensique qu'attendent la notification à 72 heures et le rapport final à un mois de l'article 23 est difficile à reconstituer à partir de données jamais capturées.
• Transport fragile. Les traps SNMP sur UDP/162 fonctionnent en mode envoi-et-oubli. Lors d'une tempête de plan de contrôle, précisément au moment où vous avez le plus besoin de l'alerte, les traps sont la première chose que le réseau abandonne. Les chaînes de communauté SNMPv1/v2c sont en clair, et le déploiement de SNMPv3 USM dans les équipements de transit reste irrégulier.

Un opérateur peut tout à fait respecter la cadence de notification de la directive en restant sur SNMP, à condition que ses processus soient suffisamment rigoureux. Le compromis porte sur la latence de prise de connaissance et la profondeur forensique : la fenêtre de réponse est plus étroite qu'elle ne pourrait l'être, et la chronologie reconstituée pour le régulateur est plus mince.

Ce que les « plateformes de conformité » se trompent à faire

Le discours dominant des fournisseurs traite NIS2 comme un achat de SIEM, de XDR ou d'AIOps. Les plateformes elles-mêmes (Cisco, Splunk, Dynatrace et les autres) sont excellentes dans leur domaine, mais le modèle d'ingestion dont elles héritent ne peut pas dépasser ses propres entrées : les plateformes d'observabilité ingèrent ce que le réseau leur fournit, elles ne peuvent pas détecter ce que le réseau n'a jamais remonté. La tarification à l'ingestion au Go pénalise alors le volume de télémétrie qui rend justement la détection utile. Le transport carrier-grade, les IXP, l'interconnexion des data centers et le substrat de cloud souverain, là où les obligations télécoms de NIS2 mordent réellement, demeure largement invisible aux piles d'endpoint et de périmètre.

La solution durable consiste à pousser le plan de détection dans l'OS réseau lui-même, dans un format neutre vis-à-vis du fournisseur. Même physique, quel que soit le logo qui se trouve au-dessus.

Ce que change réellement la télémétrie en streaming

Les détails comptent :

• gNMI s'exécute en gRPC sur HTTP/2, prend en charge TLS et propose des abonnements aux événements ON_CHANGE aux côtés d'un mode Sample pour les compteurs périodiques. Streaming en temps réel. Pas une interrogation à cinq minutes.
• OpenConfig YANG vous offre un schéma unique tous fournisseurs confondus : le même XPath /interfaces/interface/state/counters/in-discards est portable sur tout OS réseau implémentant openconfig-interfaces. Un seul analyseur sur l'ensemble du parc, avec les mêmes règles d'alerte et la même piste d'audit par-dessus.
• Transport sécurisé par TLS : les sessions gNMI sont mutuellement authentifiées par certificats X.509, et non par des chaînes de communauté en clair.

Nous avons exposé l'argumentation technique plus longue en février 2026 dans Stop polling, start streaming: why SNMP is crippling your network visibility. NIS2 est ce qui en fait, d'une préférence architecturale, une exigence réglementaire.

L'open networking fournit le socle de télémétrie que les architectures NIS2 exigent

NIS2 pose deux attentes techniques sur lesquelles repose le reste de la posture de notification d'un opérateur : visibilité continue au niveau réseau (Articles 21(2)(b/c/f/g) and, for digital-infrastructure entities, IR 2024/2690) and transparence des fournisseurs (Article 21(2)(d)). The proprietary majors now all expose OpenConfig YANG and gNMI, so the gap is not about telemetry standards. It is about supply-chain layer count: a vertically-integrated chassis is one vendor across silicon, hardware, NOS and orchestration; a disaggregated stack splits the same network into independently sourceable layers, which is what makes the Article 21(2)(d) supplier assessment tractable.

This matters more as European operators move to IPoDWDM with 400G ZR+ optics and SR-MPLS / SRv6 in the core, where optical pre-FEC BER drift, segment-routing transitions and BFD session state are the early-warning signals SNMP cannot see fast enough to be useful.

Télémétrie en streaming native, non rapportée a posteriori

OcNOS exposes gNMI en tant que sous-système au niveau du système, not a management overlay, with TLS-secured transport and OpenConfig YANG schemas. The properties that matter for NIS2:

• Modèles de données OpenConfig YANG pour les interfaces, BGP, routing-policy, et les chemins système et plateforme. Un schéma normalisé est ce qui permet à un jeu de règles d'alerte unique de survivre dans un parc multi-fournisseur. Sans cela, chaque équipement est son propre problème d'analyseur.
• gNMI Subscribe avec streaming d'événements ON_CHANGE pour l'état, plus un mode Sample périodique pour les compteurs. Push, pas poll. La différence se manifeste dans la latence de prise de connaissance, pas dans les matrices comparatives de fonctionnalités.
• La validation d'origine BGP RPKI rejette les routes BGP invalides au niveau de l'équipement. Un contrôle anti-détournement de préfixes auditable, pertinent au regard des obligations plus larges de sécurité réseau de l'article 21, paragraphe 2.
• Échantillonnage de flux sFlow au débit ligne sur l'ensemble de la gamme, aux côtés des flux d'état et de compteurs de gNMI plutôt qu'à leur place.
• BMP route monitoring with BGP-LS topology export so a controller or SIEM sees every announce and withdraw, not just interface counters. Exactly the kind of state-transition record the 72-hour and 30-day reporting clocks expect.

La désagrégation, c'est la transparence de la chaîne d'approvisionnement

L'article 21(2)(d) impose aux entités d'évaluer les pratiques de sécurité de chaque fournisseur direct. Le règlement d'exécution (UE) 2024/2690 en fait une exigence de divulgation par composant, et les lignes directrices de l'ENISA de juin 2025 l'interprètent comme une obligation SBOM implicite.

Un châssis monolithique constitue une nomenclature unique et fermée que l'opérateur ne peut ni inspecter, ni auditer, ni substituer de l'intérieur. Une pile désagrégée (OcNOS sur matériel whitebox Edgecore ou UfiSpace, fourni via des intégrateurs tels qu'EPS Global dans l'UE) scinde cette nomenclature en couches sourçables indépendamment, chacune dotée de sa propre SBOM, chacune remplaçable selon son propre calendrier. Le coût de la 5G Toolbox allemande (sortie de Huawei du cœur 5G d'ici fin 2026, des systèmes de gestion réseau en accès et transport d'ici fin 2029) illustre ce qu'engendre l'enfermement mono-fournisseur lorsqu'une désignation de fournisseur à haut risque tombe. L'article 21(2)(d) revient à savoir si la chaîne d'approvisionnement derrière la couche de transport est inspectable. Les architectures de cette forme le sont. Les architectures verticalement intégrées ne le sont pas.

Les déploiements d'eww ITandTEL, de DIGI, d'AnschlussWerk et d'ASOM-Net présentés plus haut ne relèvent pas du hasard. Ils partagent les quatre mêmes traits : un matériel désagrégé que l'opérateur peut auditer, une télémétrie en streaming native dès le premier jour, une chaîne d'approvisionnement qui résiste à une désignation de fournisseur à haut risque sans rip-and-replace pluriannuel, et une piste d'audit qu'un évaluateur du BSI, de l'ANSSI, de l'ACN ou du DNSC peut réellement inspecter.

NIS2 n'est pas une case à cocher que l'on achète à un fournisseur. C'est un audit de chaîne d'approvisionnement régi par un problème de physique. Aucun tableau de bord situé au-dessus du plan de télémétrie ne peut détecter un incident plus vite que le plan qui se trouve en dessous ne se rafraîchit.

Les plateformes de conformité unifiées proposées par les acteurs en place reproduisent l'exposition à un fournisseur concentré que l'article 21, paragraphe 2, point d) est conçu pour mettre au jour, ce qui constitue une position inconfortable pour y remédier.

À propos d'IP Infusion · IP Infusion est le leader des solutions de réseau désagrégé. OcNOS est déployé en production par des opérateurs de services, des IXP, des opérateurs de centres de données et des plateformes de cloud souverain en Europe, en Amérique du Nord, en APAC et en EMEA. En savoir plus sur ipinfusion.com.