CRA et NIS2 : périmètres et obligations à coordonner
CRA et NIS2 : comparez les périmètres, les délais de notification et les preuves utiles, avec le statut de la transposition française en septembre 2026.
- Deux périmètres à vérifier séparément
- Préparer deux fiches de périmètre
- Le calendrier français reste déterminant
- Une procédure d’incident, plusieurs décisions
- Tenir une chronologie commune et des décisions distinctes
- Mutualiser les achats et les preuves
- Partager les pièces sans confondre les responsabilités
- Exemple fictif : un correctif chez plusieurs clients
- Ne pas additionner mécaniquement les sanctions
- Ce qu’il faut retenir
- FAQ
Le CRA réglemente la cybersécurité des produits comportant des éléments numériques. La directive NIS2 organise la cybersécurité de certaines entités et de leurs réseaux et systèmes d’information. Une entreprise peut relever des deux textes, mais fabriquer un logiciel ne suffit pas à la classer automatiquement comme entité essentielle ou importante.
Deux périmètres à vérifier séparément
| Question | CRA | NIS2 |
|---|---|---|
| Quel objet ? | Produit, y compris certaines solutions de traitement de données à distance | Entité et services relevant des secteurs couverts |
| Quels critères ? | Produit, connexion, mise à disposition commerciale, exclusions et rôle dans la chaîne | Activité, taille, exceptions et qualification nationale |
| Quelle responsabilité principale ? | Fabricant ; obligations distinctes des autres opérateurs | Entité essentielle ou importante et gouvernance correspondante |
| Quelles preuves ? | Risques produit, documentation, conformité, gestion des vulnérabilités | Gestion des risques des systèmes, continuité, chaîne d’approvisionnement, incidents |
Sources : CRA, Art. 2–3 et 13 ; NIS2, Art. 2–3, 20–21 et annexes I–II. Utilisez les guides de périmètre du CRA et des entités concernées par NIS2 pour documenter votre analyse.
Préparer deux fiches de périmètre
La fiche produit peut commencer par ce qui est fourni au client, la version, l’usage prévu et le rôle commercial de l’entreprise. Identifiez les éléments développés, intégrés ou distribués et les exclusions éventuellement pertinentes. Un nom de gamme ne suffit pas si plusieurs configurations ont des fonctions et des composants différents.
La fiche entité décrit la personne juridique, les activités effectivement exercées, les services, les éléments de taille et les règles nationales pertinentes. Une organisation qui achète un produit soumis au CRA ne devient pas, pour cette seule raison, une entité NIS2. Inversement, une activité entrant dans le champ de NIS2 peut utiliser des produits très divers.
Les conclusions de ces fiches doivent indiquer leurs hypothèses. « Activité de services gérés à confirmer » est une question ouverte, pas une exemption. Demandez à la personne qui connaît les contrats et les opérations de préciser ce qui est réellement assuré. Le juriste peut ensuite confronter ces faits aux définitions et aux critères applicables.
Prévoyez un réexamen après changement d’activité, acquisition ou commercialisation d’une nouvelle version. Pour la France, consignez aussi la date de vérification du droit de transposition. Le dossier doit pouvoir distinguer une mesure déjà obligatoire, une préparation aux obligations futures et un engagement contractuel accepté.
Le calendrier français reste déterminant
Au 28 septembre 2026, la transposition française de NIS2 n’est pas achevée. Le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité figure à l’ordre du jour de l’Assemblée nationale du 7 octobre 2026. Cette programmation ne vaut pas adoption du texte ni entrée en vigueur de ses obligations futures.
Le CRA est un règlement directement applicable suivant ses propres échéances : notifications Art. 14 depuis le 11 septembre 2026 ; application générale le 11 décembre 2027. Le calendrier CRA précise les transitions, notamment pour les produits déjà mis sur le marché. Les obligations françaises existantes doivent continuer à être examinées sans attendre la future transposition.
Une procédure d’incident, plusieurs décisions
N’utilisez pas un unique indicateur « incident notifiable ». Documentez pour chaque texte : événement, entité tenue de signaler, instant de connaissance, destinataire et échéance.
| Régime | Alerte et notification | Rapport final |
|---|---|---|
| CRA, vulnérabilité activement exploitée | 24 heures puis 72 heures après connaissance | 14 jours après disponibilité d’une mesure corrective ou d’atténuation |
| CRA, incident grave affectant la sécurité du produit | 24 heures puis 72 heures après connaissance | Un mois après la notification à 72 heures |
| NIS2, incident important | 24 heures puis 72 heures après connaissance, selon le dispositif transposé | Un mois après la notification ; si l’incident continue, rapport d’avancement puis rapport final dans le mois suivant son traitement |
Pour les prestataires de services de confiance, NIS2 prévoit une notification sous 24 heures, par exception à l’étape ordinaire de 72 heures. Le CRA utilise la plateforme unique pour le CSIRT coordonnateur et l’ENISA ; NIS2 vise le CSIRT ou l’autorité compétente selon le dispositif applicable. Sources : CRA, Art. 14 et 16 ; NIS2, Art. 23(3)–(4).
Le guide de signalement des vulnérabilités CRA aide à préparer le circuit fabricant. Ajoutez une analyse RGPD lorsque des données personnelles sont affectées.
Tenir une chronologie commune et des décisions distinctes
La cellule de crise peut partager une chronologie des faits : alerte reçue, produit concerné, services affectés, éléments techniques disponibles et actions engagées. Évitez de transformer la première heure inscrite dans le journal en point de départ automatique pour tous les textes. Pour chaque obligation, documentez les faits qui établissent la connaissance de l’événement qualifié.
Une fiche de décision peut comporter le fondement examiné, la personne tenue de notifier, le seuil applicable, la conclusion, son auteur, l’heure retenue et la prochaine échéance. Lorsque les informations sont incomplètes, identifiez ce qui manque et qui le recherche. Le manque de certains détails ne justifie pas d’attendre un dossier entièrement stabilisé alors qu’une obligation de notification est déclenchée.
Les délais du tableau sont des maxima, à articuler avec l’exigence de signaler sans retard injustifié. Un calendrier préparatoire ne permet pas de différer volontairement une notification. Conservez les pièces transmises et les accusés disponibles ; une tâche marquée « envoyée » dans l’outil interne n’établit pas à elle seule le destinataire et le contenu effectifs.
Mutualiser les achats et les preuves
L’Art. 21(2)(d) de NIS2 vise la sécurité de la chaîne d’approvisionnement. Les pièces CRA peuvent contribuer à cette appréciation, sans remplacer l’analyse des risques propres à l’entité.
Pour chaque produit important pour votre activité, conservez une fiche avec : fabricant, version, usage, dépendances critiques, fin d’assistance, mécanisme de correctif, contact incident et justificatifs de conformité applicables. Le CRA n’impose pas que toute nomenclature logicielle soit publiée ou systématiquement remise avec le produit : précisez vos demandes contractuelles et la confidentialité nécessaire.
Exemple hypothétique : un prestataire de services gérés utilise un routeur chez ses clients. Il examine sa propre qualification NIS2 et ses risques d’exploitation. S’il revend le routeur, il vérifie également son rôle de distributeur ; une commercialisation sous sa marque peut le faire relever des obligations du fabricant.
Partager les pièces sans confondre les responsabilités
Une preuve peut servir à plusieurs analyses, à condition de préciser ce qu’elle démontre. Vous pouvez organiser le dossier commun ainsi :
| Pièce | Utilité pour le produit | Question pour l’entité utilisatrice |
|---|---|---|
| Description du correctif | Comprendre les versions et vulnérabilités traitées | Quels systèmes doivent être mis à jour ? |
| Fin d’assistance annoncée | Identifier la période de suivi du fabricant | Comment maintenir le service après cette date ? |
| Instructions de sécurité | Décrire les conditions d’utilisation prévues | La configuration déployée les respecte-t-elle ? |
| Contact de signalement | Alerter le fabricant sur un problème produit | Qui suit la demande et les conséquences locales ? |
Cette grille proposée complète les obligations examinées ; elle ne reproduit pas un formulaire imposé. Attribuez un propriétaire à la pièce et un responsable à chaque décision. L’équipe produit peut publier un correctif sans que l’équipe d’exploitation l’ait installé. Le dossier doit rendre visible cette différence.
Pour un fournisseur externe, précisez dans la commande les informations attendues, le canal d’urgence et les modalités de suivi. Une demande de garantie générale « conforme CRA et NIS2 » apporte peu si le produit, le service et le rôle du fournisseur restent indéterminés. Cherchez des réponses rattachées à votre usage et vérifiables au moment de la réception.
Exemple fictif : un correctif chez plusieurs clients
Reprenons le prestataire de services gérés dans un scénario entièrement fictif. Un fabricant lui annonce un correctif de routeur. Le message indique les versions concernées, mais ne permet pas de conclure qu’une exploitation a eu lieu chez ses clients. Le prestataire possède un inventaire partiel et constate une interruption chez l’un d’eux.
Trois recherches sont nécessaires : identifier les équipements effectivement concernés, comprendre l’interruption et obtenir les informations produit manquantes. Le fabricant examine ses obligations CRA. Le prestataire examine les conséquences sur ses services et le régime national qui lui est applicable. Le client doit disposer des informations utiles à ses propres décisions ; aucune de ces analyses ne peut être remplacée par la simple mention du correctif.
La fiche commune conserve donc des statuts distincts : correctif disponible, déploiement à vérifier, cause de l’interruption inconnue et qualification de l’incident en cours. Un éventuel traitement de données personnelles ajoute une analyse RGPD. Cet exemple illustre la coordination à organiser, sans affirmer qu’une notification a été réalisée ni présumer l’application de tous les régimes.
Ne pas additionner mécaniquement les sanctions
NIS2 impose aux États des plafonds d’amende d’au moins 10 millions d’euros ou 2 % du chiffre d’affaires mondial pour les entités essentielles, et d’au moins 7 millions ou 1,4 % pour les importantes, le montant le plus élevé étant retenu. Il s’agit des violations des Art. 21 ou 23 et de règles à transposer, pas d’amendes françaises automatiquement exigibles à ces montants. Art. 34(4)–(5).
L’Art. 35(2) de NIS2 prévoit aussi une articulation spécifique avec une amende RGPD prononcée pour le même comportement. Pour le CRA, consultez le régime des sanctions et ses exceptions. Une addition abstraite de plafonds ne représente pas le risque juridique d’un dossier donné.
Ce qu’il faut retenir
- Qualifiez le produit et l’entité séparément.
- Distinguez le CRA applicable de la transposition française de NIS2 encore en cours.
- Mutualisez les preuves, mais conservez chaque décision de notification.
- Vérifiez les obligations contractuelles des fournisseurs et leur assistance de sécurité.
FAQ
Un fabricant de logiciel relève-t-il automatiquement de NIS2 ?
Non. Son activité, sa taille et les éventuelles exceptions doivent être confrontées au champ de la directive et au droit national applicable.
Une notification CRA suffit-elle pour NIS2 ?
Il ne faut pas le présumer. Les événements, responsabilités et destinataires diffèrent ; vérifiez les mécanismes de transmission effectivement applicables.
La conformité CRA remplace-t-elle l’analyse fournisseur ?
Non. Elle peut fournir des éléments de preuve sur le produit, mais ne couvre pas à elle seule son déploiement, son exploitation et ses effets sur vos services.
Recevez nos analyses de conformité numérique.
Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies.