NIS2 et vos fournisseurs de logiciels : ce que chaque partie doit faire

01Où en est NIS2 à l’automne 2026 ?

La directive NIS2 (ouvre un site externe), la directive (UE) 2022/2555, a été publiée au Journal officiel le 27 décembre 2022 et est entrée en vigueur le 16 janvier 2023. Les États membres devaient adopter et publier leurs mesures nationales au plus tard le 17 octobre 2024 et les appliquer à partir du 18 octobre 2024, date à laquelle la première directive NIS a été abrogée.

NIS2 étant une directive, c’est la loi nationale de transposition qui lie une organisation, et non la directive elle-même. La transposition est inégale : certains États membres ont appliqué leur loi à temps, d’autres seulement en 2025 ou en 2026, et la Commission européenne a engagé des procédures d’infraction contre les États qui ont manqué l’échéance. L’enregistrement, les portails de notification et les autorités de contrôle diffèrent donc d’un pays à l’autre.

02Entités essentielles et entités importantes

NIS2 s’applique aux entités publiques et privées des secteurs de l’annexe I (secteurs hautement critiques : énergie, transports, secteur bancaire, infrastructures des marchés financiers, santé, eau potable, eaux usées, infrastructure numérique, gestion des services TIC, administration publique et espace) et de l’annexe II (autres secteurs critiques : services postaux et d’expédition, gestion des déchets, produits chimiques, denrées alimentaires, fabrication, fournisseurs numériques et recherche). En règle générale, elle vise les moyennes et grandes organisations. Certaines entrent dans le champ quelle que soit leur taille, comme les prestataires de services de confiance, les fournisseurs de services DNS et les entités de l’administration centrale.

L’article 3 répartit ensuite ces organisations en deux catégories :

• Entités essentielles : principalement les grandes organisations des secteurs de l’annexe I, ainsi que des entités essentielles quelle que soit leur taille, comme les prestataires de services de confiance qualifiés, les registres de noms de domaine de premier niveau, les fournisseurs de services DNS et les entités de l’administration centrale. Elles font l’objet d’une supervision proactive, qui peut comprendre des audits et des inspections sur place.
• Entités importantes : les autres organisations relevant des annexes I et II. La supervision s’exerce a posteriori : l’autorité intervient lorsque des éléments indiquent que l’entité ne respecte pas ses obligations.

Les deux catégories ont les mêmes obligations de fond : mesures de gestion des risques (article 21), notification des incidents (article 23) et responsabilité de la direction (article 20). La différence tient à la supervision et aux amendes. En cas de violation des articles 21 ou 23, la loi nationale doit prévoir des amendes d’un montant maximal d’au moins 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial pour les entités essentielles, et d’au moins 7 millions d’euros ou 1,4 % pour les entités importantes, le montant le plus élevé étant retenu. Chaque État membre décide si, et dans quelle mesure, des amendes peuvent être infligées aux entités de l’administration publique.

Votre fournisseur de logiciels est-il lui-même concerné ?

Développer des logiciels n’est pas, en soi, un secteur NIS2. Un fournisseur peut pourtant être directement concerné. L’annexe I couvre les fournisseurs de services gérés, que NIS2 définit largement : des entités qui installent, gèrent, exploitent ou entretiennent des produits TIC, des réseaux, des infrastructures ou des applications pour leurs clients, sur place ou à distance. Un fournisseur de taille moyenne ou plus qui exploite ou maintient des applications pour ses clients peut donc relever de NIS2 en propre, tout comme les fournisseurs de services d’informatique en nuage et de centres de données. Pour ces fournisseurs, le règlement d’exécution (UE) 2024/2690 (ouvre un site externe) détaille les exigences techniques.

La plupart des fournisseurs de logiciels rencontrent toutefois NIS2 par l’intermédiaire de leurs clients, qui traduisent leur propre obligation sur la chaîne d’approvisionnement en clauses contractuelles, questionnaires et audits. Les produits logiciels relèvent en outre du règlement sur la cyberrésilience (ouvre un site externe), le règlement (UE) 2024/2847 : ses obligations de signalement des vulnérabilités activement exploitées et des incidents graves s’appliquent à partir du 11 septembre 2026, et ses autres obligations à partir du 11 décembre 2027.

03Les dix mesures minimales de l’article 21

L’article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, fondées sur une approche « tous risques ». Elles tiennent compte de l’état des connaissances et des normes européennes et internationales pertinentes, et sont proportionnées à l’exposition aux risques, à la taille de l’entité et à la gravité probable des incidents. Elles comprennent au moins :

1. 01les politiques relatives à l’analyse des risques et à la sécurité des systèmes d’information ;
2. 02la gestion des incidents ;
3. 03la continuité des activités, par exemple la gestion des sauvegardes et la reprise après sinistre, et la gestion des crises ;
4. 04la sécurité de la chaîne d’approvisionnement, y compris les aspects de sécurité des relations avec les fournisseurs et prestataires de services directs ;
5. 05la sécurité de l’acquisition, du développement et de la maintenance des réseaux et systèmes d’information, y compris le traitement et la divulgation des vulnérabilités ;
6. 06des politiques et procédures pour évaluer l’efficacité de ces mesures ;
7. 07les pratiques de base en matière de cyberhygiène et la formation à la cybersécurité ;
8. 08des politiques et procédures relatives à la cryptographie et, le cas échéant, au chiffrement ;
9. 09la sécurité des ressources humaines, les politiques de contrôle d’accès et la gestion des actifs ;
10. 10l’authentification à plusieurs facteurs ou continue, et des communications vocales, vidéo, textuelles et d’urgence sécurisées, selon les besoins.

Les points 4 et 5 concernent directement les fournisseurs. L’article 21, paragraphe 3, demande aux entités de tenir compte des vulnérabilités propres à chaque fournisseur direct, de la qualité globale de ses produits et de ses pratiques de cybersécurité, ainsi que de ses procédures de développement sécurisé. Vos clients doivent donc s’intéresser à la manière dont vous développez vos logiciels, et pas seulement à ce que vous livrez.

04La direction approuve, supervise et en répond

Selon l’article 20, les organes de direction des entités essentielles et importantes approuvent les mesures de gestion des risques en matière de cybersécurité, en supervisent la mise en œuvre et peuvent être tenus responsables des violations. Leurs membres sont tenus de suivre une formation, et les entités sont encouragées à former régulièrement leur personnel. Pour les organismes publics, les règles nationales sur la responsabilité des institutions publiques et des agents publics continuent de s’appliquer.

Le dialogue avec les fournisseurs change en conséquence. Une direction qui doit approuver les mesures attend des éléments qu’elle peut suivre : quels fournisseurs soutiennent quels services, quels risques subsistent, et ce qui a réellement été testé.

05Notifier les incidents : 24 heures, 72 heures, un mois

L’article 23 impose de notifier les incidents importants au CSIRT ou à l’autorité compétente. Au sens de la directive, un incident est important s’il a causé ou peut causer une perturbation opérationnelle grave des services ou des pertes financières pour l’entité, ou des dommages matériels ou moraux considérables à d’autres personnes. La notification se fait par étapes :

Le cas échéant, les entités informent aussi sans retard injustifié les destinataires de leurs services des incidents importants susceptibles d’affecter ces services. Les lois nationales y ajoutent leurs propres formulaires et portails.

Le délai court à partir du moment où l’entité a connaissance de l’incident. Si l’incident commence dans un système du fournisseur, le client ne peut respecter les 24 heures que si le fournisseur le détecte, le qualifie et le signale en quelques heures. La détection, la journalisation et un canal de notification convenu relèvent donc du contrat, pas seulement de la technique.

06Ce qu’un client soumis à NIS2 demande à son fournisseur de logiciels

En pratique, l’article 21 se traduit par des mesures techniques et des preuves qu’un fournisseur doit pouvoir présenter sans lancer de projet. Voici celles que nous rencontrons le plus souvent :

• Un cycle de développement sécurisé. Modélisation des menaces pour les changements significatifs, revue de code par les pairs, tests de sécurité automatisés et analyse des dépendances dans la chaîne d’intégration, builds signés et nomenclature logicielle (SBOM) pour chaque version.
• Traitement et divulgation des vulnérabilités. Un canal public pour signaler une vulnérabilité, des délais de réponse convenus selon la gravité, et une information du client lorsqu’une vulnérabilité touche son environnement.
• Contrôle des accès du personnel du fournisseur. Comptes nominatifs, authentification à plusieurs facteurs, moindre privilège, élévation de droits limitée dans le temps et journal de chaque action d’administration dans l’environnement du client.
• Journalisation et preuves en cas d’incident. Des événements de sécurité journalisés avec un horodatage fiable, conservés pendant une durée convenue et exportables, pour que le client puisse répondre aux questions de l’alerte précoce et du rapport final.
• Coopération en cas d’incident. Un interlocuteur et un canal désignés, un délai de notification bien inférieur aux 24 heures du client, et un appui à l’analyse des causes.
• Continuité et reprise. Des sauvegardes dont la restauration a été testée, des objectifs de reprise alignés sur ceux du client, et une procédure exercée.
• Documentation de la chaîne. Une liste à jour des sous-traitants et des lieux d’hébergement, ainsi que des principaux composants et services tiers dont dépend la solution.
• Un plan de sortie. Export des données dans des formats exploitables, documentation et accompagnement du transfert, pour que le client puisse changer de fournisseur sans perdre la maîtrise du service.

Rien de cela n’est nouveau pour une équipe d’ingénierie mature. Ce qui change avec NIS2, c’est que le client doit pouvoir le démontrer. Notre page confiance et conformité décrit notre manière de travailler en tant que fournisseur, avec un système de management de la sécurité de l’information certifié ISO/IEC 27001.

07Une liste de contrôle pour les contrats et les achats

1. 01Reliez les fournisseurs aux services. Indiquez quels fournisseurs soutiennent quels services concernés, et lesquels ont accès à vos systèmes ou à vos données.
2. 02Classez-les selon leur criticité. Réservez les exigences les plus fortes aux fournisseurs qui exploitent ou peuvent modifier des systèmes critiques.
3. 03Inscrivez les mesures dans le contrat. Exigences de sécurité, délai et canal de notification des incidents, traitement des vulnérabilités, journalisation et durée de conservation, droits d’audit ou de preuve, règles de sous-traitance et localisations.
4. 04Demandez des preuves, pas des déclarations. Des certificats avec leur périmètre, des résultats de tests, une SBOM, la date du dernier test de restauration.
5. 05Convenez de la sortie dès le départ. Restitution des données, accompagnement de la transition et période pendant laquelle le fournisseur continue d’assurer le service.
6. 06Entraînez-vous ensemble. Organisez un exercice d’incident avec vos fournisseurs critiques, y compris l’alerte précoce dans les 24 heures.
7. 07Révisez régulièrement. Fournisseurs, services et menaces évoluent ; un registre des fournisseurs mis à jour une fois par an est dépassé la plus grande partie de l’année.

08La loi nationale fixe les détails

L’enregistrement, les portails de notification, les formulaires, l’autorité compétente et d’éventuelles exigences supplémentaires relèvent de la loi nationale. Certains États membres rattachent les mesures de l’article 21 à un référentiel ou à une certification nationale. En règle générale, une entité relève de l’État membre où elle est établie. L’article 26 prévoit des exceptions : les fournisseurs de communications électroniques publiques relèvent de chaque pays où ils fournissent leurs services, les fournisseurs de cloud, de centres de données et de services gérés ainsi que plusieurs autres fournisseurs numériques du pays de leur établissement principal, et les entités de l’administration publique de l’État qui les a créées.

09Ce qu’il faut suivre dans les prochains mois

• Votre transposition nationale : délais d’enregistrement, textes d’application et orientations de votre autorité.
• La proposition d’omnibus numérique (ouvre un site externe) de la Commission du 19 novembre 2025, COM(2025) 837, qui ferait passer les notifications d’incidents au titre de NIS2, du RGPD, de DORA et d’autres textes par un point d’entrée unique géré par l’ENISA. En octobre 2026, elle était toujours en discussion au Parlement européen (ouvre un site externe)) ; tant qu’elle n’est ni adoptée ni applicable, les canaux et délais actuels restent en vigueur.
• Les évaluations coordonnées des risques des chaînes d’approvisionnement TIC critiques au niveau de l’UE (article 22), dont les entités doivent tenir compte dans le choix des mesures relatives à leurs fournisseurs.
• Le calendrier du règlement sur la cyberrésilience pour les produits logiciels, pleinement applicable à partir du 11 décembre 2027.

Pour les entités financières, le règlement sur la résilience opérationnelle numérique (DORA) remplace les règles de NIS2 sur la gestion des risques liés aux TIC, la notification des incidents et la supervision ; voir notre article sur DORA et les prestataires tiers de services TIC. La Commission tient à jour une présentation de NIS2 et de ses actes d’exécution sur sa page consacrée à NIS2 (ouvre un site externe).