NIS 2 sans la France : trois voies pour que les DSI européens cessent d'attendre

# NIS 2 sans la France : trois voies pour que les DSI européens cessent d'attendre

En 2026, la transposition française de NIS 2 accuse toujours un retard significatif. Pendant ce temps, les entités opérant dans d'autres États membres — Allemagne, Belgique, Pays-Bas — se conforment déjà à leurs obligations nationales. Pour un DSI d'une ETI française avec des filiales ou des clients européens, l'attente n'est plus une option neutre : c'est un choix actif, avec des conséquences contractuelles et techniques qui se cristallisent chaque trimestre.

Ce comparatif ne recense pas des outils. Il examine trois postures d'architecture et de gouvernance que des DSI peuvent adopter dès maintenant — et analyse ce que chacune révèle ou aggrave en termes de dépendance technologique.

Pourquoi le retard français n'est pas un bouclier

NIS 2 (directive UE 2022/2555) aurait dû être transposée dans tous les États membres avant le 17 octobre 2024. La France n'a pas respecté ce délai. Le projet de loi d'adaptation, porté par l'ANSSI, a subi plusieurs reports liés à l'instabilité parlementaire.

Mais le retard de transposition ne signifie pas absence d'obligations. Plusieurs mécanismes rendent l'anticipation incontournable :

• Les partenaires européens appliquent déjà leur version nationale. Un sous-traitant français référencé comme entité importante par un donneur d'ordre allemand est soumis aux exigences NIS 2 de *son* client, même sans loi française applicable.
• Les clauses contractuelles se durcissent. Les appels d'offres publics et privés dans la zone EU intègrent progressivement des exigences de conformité NIS 2, indépendamment de la juridiction du prestataire.
• La directive elle-même a un effet direct partiel. Les États membres ne peuvent pas opposer leur retard de transposition pour exonérer des entités qui remplissent objectivement les critères de la directive.

L'attente n'est donc pas neutre. Elle crée une asymétrie de conformité au sein du marché unique, dont les acteurs extra-européens — notamment les grands intégrateurs américains — savent très bien tirer parti en proposant des plateformes dites « NIS 2-ready » qui centralisent les données de sécurité dans des environnements contractuellement opaques.

Trois postures comparées

Posture A — Alignement sur un cadre national européen existant (approche de référencement croisé)

Principe : Le DSI choisit un État membre ayant déjà transposé NIS 2 (Allemagne, Belgique, Pays-Bas) comme référentiel pilote. Il structure sa politique de sécurité sur les exigences publiées par l'autorité compétente de cet État (BSI en Allemagne, CCN en Belgique), en anticipant que la version française sera largement alignée.

Architecture : Cela implique de déployer un SMSI (Système de Management de la Sécurité de l'Information) formalisé selon ISO 27001, enrichi des 10 domaines d'exigences NIS 2 (gestion des incidents, continuité, supply chain, chiffrement, contrôle d'accès, etc.). La documentation devient le socle — pas une plateforme.

Gouvernance : Le comité de pilotage sécurité intègre un référent NIS 2 distinct du RSSI opérationnel. Les reportings s'alignent sur les formats de notification d'incidents définis par le BSI ou le CCN, ce qui représente un investissement documentaire réel mais transférable.

Dépendance technologique : Faible à modérée. Cette posture ne présuppose aucune plateforme spécifique. Elle est compatible avec des outils souverains ou open source. Le risque de verrouillage est limité à celui des outils déjà en place dans le SI. C'est la posture la plus réversible.

Limite : Elle exige une capacité interne de lecture réglementaire et de traduction opérationnelle. Les ETI sans juriste spécialisé en droit numérique européen devront externaliser une partie de ce travail d'interprétation.

Posture B — Intégration d'une plateforme GRC mutualisée hébergée en Europe

Principe : Le DSI s'appuie sur une plateforme de type GRC (Gouvernance, Risques, Conformité) hébergée dans l'UE, avec des modules NIS 2 préconfigurés. Plusieurs acteurs européens — dont des éditeurs scandinaves et germaniques — proposent des environnements certifiés ISO 27001, hébergés en datacenter européen, avec des conditions contractuelles soumises au droit de l'UE.

Architecture : La plateforme centralise la cartographie des actifs critiques, les workflows de gestion d'incidents, la traçabilité des mesures correctives et les rapports de conformité. Elle s'intègre via API aux outils SIEM/SOC existants. L'enjeu architectural est précisément ici : si le SIEM est opéré par un acteur américain sous contrat de droit US (ce qui est fréquent dans les ETI équipées en solutions de l'acteur dominant du marché des endpoints), la plateforme GRC européenne devient une couche de présentation sur une infrastructure de données dont la gouvernance reste extraterritoriale.

Gouvernance : Mutualisée avec d'autres entités clientes de la plateforme dans certains modèles. Cela peut créer des économies d'échelle sur la veille réglementaire, mais introduit des questions sur la confidentialité des données de risque entre entités concurrentes partageant un même environnement.

Dépendance technologique : Modérée à forte, selon l'intégration. Le verrouillage ne vient pas de la plateforme GRC elle-même mais de son écosystème d'alimentation. Si les flux de logs proviennent d'agents déployés sur des endpoints gérés par un acteur américain, la conformité NIS 2 reste dépendante d'une chaîne de traitement dont aucune brique n'est souveraine. La plateforme GRC européenne habille alors un risque structurel sans le résoudre.

Limite : L'intégration technique avec des SI existants hétérogènes est chronophage. Le ROI de conformité n'est tangible qu'après 12 à 18 mois de déploiement effectif.

Posture C — Construction d'une capacité SOC internalisée sur stack ouverte

Principe : Le DSI construit ou consolide une capacité de détection et de réponse interne, articulée autour de composants open source auditables (SIEM, orchestration, threat intelligence), hébergés sur infrastructure propre ou auprès d'un opérateur cloud qualifié SecNumCloud.

Architecture : L'empilement technique repose sur des briques dont le code est auditable et dont les données restent sous contrôle direct. La notification d'incidents à l'autorité compétente s'effectue depuis des systèmes dont la traçabilité n'est pas conditionnée à un contrat de service tiers. C'est l'approche la plus alignée avec l'esprit de NIS 2, qui exige une maîtrise réelle des capacités de détection — pas seulement leur sous-traitance.

Gouvernance : Interne par construction. Le DSI dispose d'une visibilité directe sur les données de sécurité, sans passer par le tableau de bord d'un éditeur tiers. Les obligations NIS 2 de reporting dans les 24h (notification initiale) et 72h (rapport intermédiaire) sont techniquement satisfaisables sans dépendre d'un SLA fournisseur.

Dépendance technologique : Faible. C'est la posture qui desserre le plus les verrouillages. Elle élimine le risque CLOUD Act sur les données de sécurité, qui sont parmi les plus sensibles qu'une organisation produit (topologie réseau, vulnérabilités connues, comportements utilisateurs). Elle exige en contrepartie une compétence interne ou un partenaire MSSP européen capable d'opérer ces environnements.

Limite : C'est la posture la plus exigeante en capital humain. Elle est réaliste pour des ETI de taille suffisante (équipe sécurité d'au moins 3 à 5 personnes dédiées) ou pour des groupements d'ETI qui mutualisent un SOC sectoriel — un modèle qui se développe dans plusieurs filières industrielles françaises, même si lentement.

Ce que ce comparatif révèle sur les dépendances structurelles

| Critère | Posture A (cadre croisé) | Posture B (GRC mutualisée) | Posture C (SOC ouvert) |

|---|---|---|---|

| Réversibilité | Haute | Moyenne | Haute |

| Maîtrise des données de sécurité | Dépend du SI existant | Partielle | Complète |

| Risque extraterritorial (CLOUD Act) | Dépend du SI existant | Résiduel si SI alimentant reste US | Faible |

| Délai de mise en conformité opérationnelle | 6-12 mois | 12-18 mois | 18-30 mois |

| Capacité à notifier sous 24h sans dépendance fournisseur | Conditionnelle | Conditionnelle | Oui |

Le tableau fait apparaître une tension que le débat sur NIS 2 occulte souvent : la conformité réglementaire et la souveraineté opérationnelle ne sont pas la même chose. Il est possible de cocher toutes les cases NIS 2 avec des outils américains opérés sous droit américain — et de rester structurellement exposé à des accès contraints que la directive ne couvre pas.

Les acteurs extra-européens l'ont compris. Plusieurs d'entre eux commercialisent activement des offres « conformes NIS 2 » sans que cette conformité affecte en rien leur architecture de données ni leurs obligations légales vis-à-vis des autorités américaines. La directive européenne devient alors un argument commercial au service d'une dépendance accrue.

Ce que les DSI peuvent décider dès maintenant

L'attente de la loi française n'est ni une stratégie ni une protection. C'est un report de risque. Trois décisions concrètes n'exigent pas de cadre législatif national :

1. Cartographier les actifs critiques au sens NIS 2 (réseaux, systèmes d'information, chaîne d'approvisionnement numérique). Ce travail est indépendant de toute transposition.

2. Auditer les clauses contractuelles des fournisseurs critiques : où sont hébergées les données de sécurité ? Sous quelle juridiction ? Quelle est la procédure de notification en cas d'incident les concernant ?

3. Choisir une posture parmi les trois décrites — en sachant que le choix lui-même est une décision de gouvernance, pas seulement une décision technique.

Le retard français ne suspend pas la directive. Il suspend seulement les sanctions nationales. Ce n'est pas la même chose.