Aller au contenu principal
Retour à l'aperçu

Partage d'informations cybersécurité NIS2 : participation volontaire, déclaration obligatoire

Par NIS2Certify
nis2partage-informationsarticle-29isacanssimsp
Partage d'informations cybersécurité NIS2 : participation volontaire, déclaration obligatoire

Votre client a rejoint un ISAC sectoriel l'automne dernier. Bonne décision : alerte précoce sur les groupes rançongiciels qui travaillent son secteur, en échange de ses propres indicateurs.

Neuf mois plus tard, un contrôleur demande à quels arrangements de partage d'informations de cybersécurité l'entité participe. La participation est réelle. La déclaration, non. Personne n'en a fait, parce que personne n'a lu au-delà du mot « volontaire ».

C'est l'article 29 de NIS2. Le partage d'informations cybersécurité NIS2 passe entre les mailles précisément parce que tout ce qui est visible paraît facultatif.

L'article 29 rend l'échange volontaire et la déclaration obligatoire

L'article 29, paragraphe 1, impose aux États membres de veiller à ce que les entités dans le champ — et, le cas échéant, hors champ — puissent échanger volontairement des informations pertinentes de cybersécurité. La directive énumère : cybermenaces, incidents évités de justesse, vulnérabilités, techniques et procédures, indicateurs de compromission, tactiques adverses, informations propres aux acteurs de la menace, alertes et recommandations de configuration des outils de détection.

Deux tests de finalité encadrent l'échange. Au titre du point a), il doit viser à prévenir, détecter, traiter des incidents ou s'en rétablir, ou en atténuer l'impact. Au titre du point b), il doit élever le niveau de cybersécurité : sensibilisation, limitation de la propagation des menaces, remédiation et divulgation des vulnérabilités, détection, confinement et prévention, stratégies d'atténuation, réponse et rétablissement, ou recherche collaborative public-privé.

Le paragraphe 2 fixe la forme. L'échange se déroule au sein de communautés d'entités essentielles et importantes et, le cas échéant, de leurs fournisseurs ou prestataires — au moyen d'un arrangement de partage d'informations de cybersécurité, justement parce que la matière est sensible.

Puis le paragraphe 4, la phrase que presque tous les programmes sautent : les États membres veillent à ce que les entités essentielles et importantes notifient aux autorités compétentes leur participation à ces arrangements au moment où elles y adhèrent, ou leur retrait dès que celui-ci prend effet.

Aucun seuil. Aucun test de matérialité. Aucun délai de grâce dans l'article lui-même.

Un arrangement n'est pas un groupe de discussion

Le mot « arrangement » fait ici un vrai travail, et c'est là que les évaluations dérapent dans les deux sens.

Pas un arrangement : quatre RSSI qui échangent des IOC sur Signal. Le blog public de menaces d'un éditeur. Une conversation de couloir en conférence.

Un arrangement : un ISAC sectoriel avec charte et conditions d'adhésion. Une communauté MISP avec règles TLP définies. Une plateforme opérée par un CSIRT ou une autorité. Un accord de partage formalisé avec des fournisseurs, inscrit au contrat.

Le paragraphe 3 confirme la forme : les arrangements peuvent préciser des éléments opérationnels, y compris des plateformes TIC dédiées, des outils d'automatisation, ainsi que le contenu et les conditions de l'échange. S'il y a adhésion, règles et schéma de classification, traitez-le comme déclarable.

La zone grise, c'est la communauté de menaces opérée par un éditeur — celle qu'un fournisseur EDR ou de renseignement sur les menaces anime pour ses clients. Si votre client a signé des conditions et alimente en retour, c'est un arrangement, quel que soit le vocabulaire de la page produit.

France : l'obligation européenne précède le décret

Le point délicat en France est le calendrier. La transposition par la loi relative à la résilience des infrastructures critiques et au renforcement de la cybersécurité a suivi un parcours parlementaire long, et les décrets et arrêtés d'application qui fixent le référentiel technique et les modalités d'enregistrement et de contrôle arrivent par vagues. La Commission a par ailleurs saisi la Cour de justice à propos du retard de transposition — nous avons traité ce point dans notre analyse du renvoi de la France et de l'Espagne devant la CJUE.

Conséquence pratique : ne considérez pas l'absence de canal de déclaration finalisé comme une absence d'obligation. L'ANSSI est l'autorité compétente unique pour NIS2 hors secteur financier, et les entités françaises participent déjà à des communautés de partage structurées, notamment autour du CERT-FR et de dispositifs sectoriels. Ces adhésions sont antérieures à la déclaration et n'apparaîtront dans aucun dossier tant que personne ne les y met.

La règle qui tranche : on notifie à l'autorité qui supervise l'entité, pas à celle qui anime l'ISAC. En cas de doute, partez de l'article 26 et du test de compétence.

Si vous couvrez aussi la Wallonie, notez que la Belgique dispose de sa propre structure via le CCB. Une déclaration française ne couvre pas une entité belge.

Statut de Mise en Œuvre NIS2 par Pays (2025–2026)

Pleinement en vigueur

Belgique
Croatie
Hongrie
Lituanie
Lettonie
Italie
6 pays

Adopté — fin 2025

Allemagne
République tchèque
Finlande
3 pays

En cours — prévu 2026

Pays-Bas
France
Espagne
Pologne
Autriche
Suède
Irlande
7 pays

L'article 29 n'est ni l'article 23 ni l'article 30

Trois mécanismes distincts que les conversations clients fusionnent en « déclaration ».

L'article 23, c'est la notification obligatoire d'incident : alerte précoce sous 24 heures, notification sous 72 heures, rapport final sous un mois. Le détail figure dans notre décryptage des délais de notification NIS2.

L'article 30, c'est la notification volontaire. Les entités peuvent signaler incidents, menaces et incidents évités sous le seuil ; les entités hors champ le peuvent aussi.

L'article 29 est horizontal — d'entité à entité, non d'entité à État. L'échange est volontaire. Le seul élément obligatoire est de dire à l'autorité que vous y participez.

Deux modes d'échec en découlent : des clients qui déposent une notification article 29 en croyant avoir déclaré un incident, et des clients qui notifient scrupuleusement leurs incidents sans avoir jamais mentionné les trois communautés auxquelles ils appartiennent.


L'obligation s'applique-t-elle à votre client ?

Dans cet ordre.

L'entité est-elle essentielle ou importante au sens de NIS2 ? Sinon, le paragraphe 4 ne la vise pas — même si les conditions de l'arrangement peuvent lier un fournisseur.

L'entité participe-t-elle à un arrangement structuré au sens ci-dessus ?

Une notification a-t-elle été déposée auprès de l'autorité compétente, datée au moment de l'adhésion ou peu après ? « On l'a mentionné lors de l'enregistrement » n'est pas une notification.

Deux sur trois, ce n'est pas la conformité.


C'est au retrait que la traçabilité casse

L'adhésion se retient parce que quelqu'un signe. Le retrait, non.

Les adhésions s'éteignent quand le porteur quitte l'entreprise. Les abonnements ne sont pas renouvelés. Une communauté MISP s'endort sans sortie formelle. Un prestataire de sécurité est remplacé et le client perd sans bruit l'accès à la communauté attachée à ce contrat.

Le paragraphe 4 rattache la notification au moment où le retrait prend effet. Encore faut-il que quelqu'un remarque ce moment. En pratique, c'est un problème de registre, pas de droit.

Tenez une liste par client : nom de l'arrangement, opérateur, date d'adhésion, date de notification, référence de la notification, propriétaire interne, date de renouvellement. Revoyez-la quand vous actualisez les données d'enregistrement — le dossier est déjà ouvert. Voir notre point sur l'obligation d'enregistrement.

Ce que le contrôle demande réellement

La question arrive généralement dans une demande documentaire plus large. Le jeu de preuves est court :

  • La liste des arrangements auxquels l'entité participe
  • La preuve de notification pour chacun, datée
  • Les conditions ou la charte de chaque arrangement
  • Votre politique de traitement des informations reçues : classification, conservation, qui peut agir
  • La preuve que les informations sortantes ont été validées avant diffusion

Ce dernier point est sous-estimé. Partager des indicateurs pendant un incident en cours touche simultanément la confidentialité contractuelle, la responsabilité et le RGPD. Décidez à l'avance qui valide la diffusion sortante. Voir aussi notre checklist des preuves attendues en audit NIS2.

À intégrer à l'onboarding, pas au ménage annuel

Le correctif pratique coûte environ une heure par client et ne se refait jamais de zéro.

Ajoutez deux questions au questionnaire d'entrée : à quelles communautés de partage cette organisation appartient-elle, et qui, en interne, porte chaque adhésion. La plupart des clients en citent une et en oublient deux — le reste se trouve dans la pile d'outils de sécurité et les relations CSIRT.

Déposez ensuite les notifications manquantes, consignez-les, et alignez le registre sur le cycle de revue des données d'enregistrement.

Si vous voulez d'abord savoir où en est un client sur l'article 21, l'article 23 et les obligations de gouvernance avant de déclarer quoi que ce soit, lancez une évaluation gratuite de maturité NIS2 et travaillez les écarts qu'elle fait remonter.

Partager du renseignement sur les menaces est l'une des rares obligations NIS2 qui rend une organisation mesurablement plus sûre, et pas seulement mieux documentée. La déclaration est la partie bon marché. Faites-la une fois proprement et tenez le registre à jour.

Une autre question ?

Les réponses sont générées à partir de nos articles et ne constituent pas un avis juridique. N'entrez pas de données personnelles ou confidentielles.

    NIS2 : partage d'informations et déclaration à l'ANSSI