Si votre entreprise opère en Belgique et aux Pays-Bas, vous vivez actuellement sous deux versions différentes de la même loi. Ce n’est pas un paradoxe, c’est la réalité pratique de NIS2 en 2026, et cela a des conséquences directes sur les logiciels que vous exploitez déjà.
La plupart des articles sur NIS2 expliquent la directive. Beaucoup moins expliquent ce que les obligations impliquent pour des systèmes construits des années avant que quiconque n’entende parler de NIS2 : l’ERP sans journalisation utile, l’intégration que personne n’a documentée, le serveur dont le cycle de correctifs est « quand quelque chose casse ». C’est dans cet écart que la conformité devient discrètement un problème d’ingénierie.
Où en sont réellement les choses
La Belgique a agi tôt et applique déjà la loi. La loi belge NIS2 et son arrêté royal sont entrés en vigueur le 18 octobre 2024, faisant de la Belgique l’un des quatre seuls États membres à respecter l’échéance initiale. Le Centre pour la Cybersécurité Belgique (CCB) agit à la fois comme autorité nationale de cybersécurité et comme CSIRT. Les entités concernées devaient s’enregistrer via le portail Safeonweb@Work avant le 18 mars 2025, et fin 2025 environ 1 500 entités essentielles et 2 500 entités importantes l’avaient fait. Le 18 avril 2026, la Belgique a franchi sa première échéance d’évaluation de conformité : les entités essentielles devaient soumettre une documentation vérifiée démontrant que les mesures de cybersécurité sont réellement en place, évaluée par un organisme accrédité ou par le CCB. Les auto-déclarations n’étaient pas acceptées.
Les Pays-Bas sont encore en rattrapage. La transposition néerlandaise, la Cyberbeveiligingswet (Cbw), remplace l’ancienne Wbni. Elle a été adoptée par la Chambre des représentants le 15 avril 2026, avec une entrée en vigueur attendue au cours de 2026. Entre-temps, la Commission européenne a renvoyé les Pays-Bas devant la Cour de justice le 8 juillet 2026 pour défaut de notification d’une transposition complète. Le NCSC-NL publie déjà des orientations et des attentes opérationnelles.
Pour une entreprise active dans les deux pays, le message est inconfortable mais clair : en Belgique vous êtes en retard si vous n’avez rien fait, et aux Pays-Bas l’écart de transposition est du temps de préparation, pas un sursis. Les enquêtes menées tout au long de 2026 ont régulièrement montré qu’une large majorité des organisations concernées se disent non prêtes.
Ce que NIS2 demande réellement
Écartez le langage juridique et NIS2 se résume à deux choses : un ensemble de mesures de diligence à mettre en place, et une obligation de notification lorsque quelque chose tourne mal.
Les mesures de diligence couvrent l’analyse de risques, le traitement des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, la sécurité dans l’acquisition et le développement, le contrôle d’accès, l’authentification multifacteur, la cryptographie, la gestion des vulnérabilités et la sensibilisation du personnel.
Le calendrier de notification rend NIS2 concret. Pour un incident important : une alerte précoce sous 24 heures, une notification plus complète sous 72 heures, et un rapport final sous un mois.
Relisez ce calendrier en pensant à votre système le plus ancien. Vingt-quatre heures, ce n’est pas beaucoup pour remarquer, confirmer et caractériser un incident. Ce n’est en réalité aucun temps du tout si le système en question ne peut pas vous dire ce qui s’est passé en son sein.
Pourquoi les systèmes historiques peinent
Voici la partie qui atterrit sur les équipes techniques plutôt que sur le juridique.
On ne peut pas notifier ce qu’on ne peut pas détecter
Le compte à rebours de 24 heures suppose que vous le remarquiez. Beaucoup de systèmes anciens ne journalisent presque rien d’utile : pas de piste d’audit structurée, pas de collecte centralisée, pas d’alerte sur les anomalies. Quand quelque chose de suspect se produit, la réponse honnête est souvent que personne ne le saurait avant des semaines.
Rétro-installer journalisation et supervision dans un système en production est un travail discret et minutieux. C’est aussi la chose la plus utile que la plupart des entreprises puissent faire pour leur préparation NIS2, car elle transforme une question sans réponse en question qui en a une.
La diligence suppose un inventaire que vous n’avez peut-être pas
Analyse de risques, gestion des vulnérabilités et contrôle d’accès présupposent tous que vous savez ce que vous exploitez. En pratique, beaucoup d’entreprises de taille moyenne ne peuvent pas produire une liste complète de leurs systèmes, dépendances, intégrations et droits d’accès. Les intégrations parallèles construites il y a des années pour un besoin ponctuel en sont un exemple récurrent.
La première tâche NIS2 pour la plupart des entreprises n’est donc pas de rédiger une politique. C’est de cartographier la réalité.
La gestion des vulnérabilités exige un chemin de correctifs qui fonctionne
Une obligation de traiter les vulnérabilités implique de pouvoir réellement appliquer des correctifs. Les systèmes tournant sur des frameworks en fin de vie, des environnements d’exécution non supportés ou des dépendances figées depuis des années ne peuvent souvent pas être corrigés sans une étape de modernisation préalable. C’est un programme de maintenance, pas une décision de politique interne, et cela demande du délai.
La sécurité de la chaîne se répercute sur vos fournisseurs, et sur vous
C’est la clause qui élargit discrètement NIS2 bien au-delà des entités formellement concernées. Les organisations dans le champ doivent gérer la sécurité de leurs relations fournisseurs. Donc si votre client est une entité essentielle ou importante, ses obligations arrivent chez vous sous forme d’exigences contractuelles, de questionnaires et de demandes de preuves, que NIS2 s’applique directement à vous ou non.
Beaucoup d’entreprises découvrent qu’elles sont concernées non par un régulateur, mais par le formulaire d’achat d’un client.
La documentation est désormais une preuve
L’échéance belge d’avril 2026 l’a rendu explicite : documentation vérifiée, évaluée en externe, et non auto-déclarée. La documentation cesse d’être une hygiène interne pour devenir l’artefact qui démontre la conformité. Les systèmes dont la connaissance réside dans la tête d’une seule personne ne peuvent pas la produire.
Ce que cela implique concrètement
La préparation NIS2 d’une entreprise disposant de systèmes anciens suit généralement une séquence prévisible :
- Cartographiez ce que vous exploitez. Systèmes, versions, dépendances, intégrations, flux de données, accès. C’est le socle de tout le reste.
- Réparez d’abord la détection. Journalisation, collecte centralisée et alertes, pour rendre le délai de 24 heures tenable.
- Établissez un chemin de correctifs. Identifiez ce qui ne peut pas être corrigé aujourd’hui et planifiez la modernisation nécessaire.
- Renforcez les accès. Contrôle d’accès et authentification multifacteur, y compris sur les vieux outils internes que tout le monde oublie.
- Écrivez-le. Architecture, runbooks, procédures d’incident, sous une forme lisible par un évaluateur externe.
- Répétez le parcours de notification. Sachez qui informe le CCB ou le NCSC-NL, avec quelles informations, dans quel délai.
Aucune de ces étapes n’est exotique. Ce sont toutes des travaux de maintenance sur des systèmes qui ne peuvent pas tomber pendant que le travail se fait.
Comment Dink peut aider
C’est le travail que nous faisons déjà, appliqué à une échéance de conformité.
Notre technology assessment à périmètre fixe produit exactement la carte que NIS2 suppose que vous possédez : ce qui tourne où, sur quelles versions, intégré à quoi, avec quels points de défaillance uniques et quelles lacunes de supervision et de capacité de reprise.
Ajouter de la journalisation, combler des vulnérabilités et moderniser des composants qui ne peuvent plus être corrigés sont des modifications sur des systèmes en production. Déploiements progressifs, changements réversibles et tests : c’est déjà ainsi que nous travaillons sur des systèmes critiques, parce que l’alternative, éteindre le système, n’existe pas.
Et documenter ce qui ne vit que dans les têtes est notre pratique standard lorsque nous reprenons un système. Sous NIS2, cette documentation n’est plus seulement utile en interne, elle est une preuve.
Vous ne savez pas si NIS2 s’applique à vous, ou vous le savez et vous regardez des systèmes qui n’ont jamais été conçus pour cela ? C’est un bon premier échange.
Questions fréquentes
NIS2 s’applique-t-il aux entreprises de taille moyenne ?
Souvent oui. NIS2 couvre généralement les organisations moyennes et grandes, à partir de 50 salariés ou 10 millions d’euros de chiffre d’affaires, dans 18 secteurs. Certains types d’entités sont concernés quelle que soit leur taille, et les États membres peuvent en désigner d’autres. Même hors du champ direct, les obligations de sécurité de la chaîne de vos clients peuvent vous atteindre contractuellement.
Quelle est la différence entre la Belgique et les Pays-Bas aujourd’hui ?
La Belgique a transposé NIS2 avec effet au 18 octobre 2024, exigé l’enregistrement auprès du CCB avant le 18 mars 2025, et fixé sa première échéance de conformité pour les entités essentielles au 18 avril 2026, avec documentation vérifiée en externe. Les Pays-Bas transposent via la Cyberbeveiligingswet, adoptée par la Chambre des représentants le 15 avril 2026, avec une entrée en vigueur attendue courant 2026. Les entreprises actives dans les deux pays font face à des calendriers différents pour la même directive.
Sous quel délai devons-nous notifier un incident ?
Pour un incident important : une alerte précoce sous 24 heures, une notification plus complète sous 72 heures, et un rapport final sous un mois. Respecter la première échéance dépend de la détection, et c’est là que les systèmes anciens échouent généralement.
Nos systèmes sont anciens. Par où commencer ?
Commencez par cartographier ce que vous exploitez réellement, puis réparez la détection via la journalisation et la supervision. Ces deux étapes débloquent tout le reste : impossible de faire de l’analyse de risques, de la gestion des vulnérabilités ou de la notification d’incident sans savoir ce qui existe et sans pouvoir observer ce qu’il fait.
Sommes-nous concernés si nos clients le sont mais pas nous ?
Fréquemment, oui. Les entités dans le champ doivent gérer la sécurité de leur chaîne d’approvisionnement, si bien que leurs obligations se transmettent aux fournisseurs par contrats, questionnaires de sécurité et exigences de preuves. Beaucoup d’entreprises rencontrent NIS2 pour la première fois via le processus d’achat d’un client plutôt que via un régulateur.
Il s’agit de conseils pratiques d’un point de vue d’ingénierie, non d’un avis juridique. Pour les décisions de périmètre et de classification, impliquez votre conseil juridique ou votre autorité nationale.
Vous vous demandez si vos systèmes tiendraient un délai de notification de 24 heures ? Commencez par un technology assessment à périmètre fixe, ou contactez-nous.