NIS2 et éditeur SaaS : êtes-vous concerné, et que demanderont vos clients ?

NIS2 concerne directement un éditeur SaaS s'il est au moins une entreprise moyenne (50 salariés, ou plus de 10 millions d'euros de chiffre d'affaires et de total de bilan) et que son service relève d'un secteur visé, en particulier l'informatique en nuage. En dessous, il est concerné indirectement : ses clients soumis à NIS2 devront prouver la sécurité de leurs fournisseurs, et le lui demanderont par contrat. En France, au 6 novembre 2026, la loi de transposition n'est pas encore adoptée. Cet article fait le point sur les textes, sans remplacer l'avis d'un avocat ou de l'ANSSI sur votre cas.

Où en est la transposition en France (relevé du 6 novembre 2026)

La directive (UE) 2022/2555, dite NIS2, devait être transposée par les États membres avant le 17 octobre 2024. La France a choisi un texte unique, le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, qui transpose aussi la directive sur la résilience des entités critiques et adapte le droit français au règlement DORA.

D'après le dossier législatif de l'Assemblée nationale, consulté le 6 novembre 2026 :

Le texte a déjà été retiré plusieurs fois de l'ordre du jour, la dernière fois début octobre 2026. Une inscription n'est donc pas une adoption. Après le vote de l'Assemblée, il restera, selon le cas, une commission mixte paritaire, la promulgation, puis les décrets d'application qui fixeront les seuils fins, les délais de mise en conformité et les modalités d'enregistrement.

En juillet 2026, la Commission européenne a saisi la Cour de justice de l'Union européenne contre la France, l'Irlande, l'Espagne et les Pays-Bas pour défaut de transposition. La pression monte, mais le calendrier exact reste incertain.

Méfiez-vous des pages qui affirment que la loi est votée et que l'enregistrement est obligatoire : ce n'était pas le cas à la date de ce relevé. L'ANSSI rappelle sur son espace d'aide MonEspaceNIS2 que NIS2 entrera en vigueur en France une fois tous les textes de transposition publiés, et que l'entrée en vigueur ne vaut pas application immédiate de toutes les exigences.

Attendre la loi pour s'y mettre serait pourtant une erreur. Les grands comptes appliquent déjà la logique de la directive à leurs achats, et plusieurs pays voisins l'ont transposée : un éditeur qui vend en Belgique, en Allemagne ou en Italie peut y être soumis avant de l'être en France.

Votre SaaS est-il dans le périmètre ?

Trois questions, dans cet ordre.

1. Votre activité figure-t-elle dans les annexes ?

La directive liste des secteurs dans deux annexes. Pour un éditeur de logiciel, les rubriques à regarder sont :

• annexe I, infrastructures numériques : fournisseurs de services d'informatique en nuage, de centres de données, de réseaux de diffusion de contenu, de services DNS, prestataires de services de confiance ;
• annexe I, gestion des services TIC entre entreprises : fournisseurs de services gérés et de services de sécurité gérés (infogérance, exploitation des systèmes d'un client) ;
• annexe II, fournisseurs numériques : places de marché en ligne, moteurs de recherche en ligne, plateformes de réseaux sociaux.

La directive définit le service d'informatique en nuage comme un service numérique qui permet l'administration à la demande et un large accès à distance à un ensemble modulable et variable de ressources informatiques partageables. Son considérant 33 cite le SaaS parmi les modèles de service en nuage, à côté de l'IaaS et du PaaS. Beaucoup d'éditeurs SaaS entrent donc dans cette rubrique, mais la qualification de votre service précis reste une question d'analyse, que la loi française et ses décrets pourront préciser.

Un éditeur dont le logiciel est installé chez le client et qui n'exploite rien pour lui n'est pas, à ce titre, dans le périmètre de NIS2. Il peut en revanche relever du Cyber Resilience Act (voir plus bas).

2. Quelle est votre taille ?

NIS2 s'applique d'abord aux entités qui atteignent au moins le seuil de la moyenne entreprise au sens de la recommandation 2003/361/CE.

Une entreprise de moins de 50 salariés qui dépasse 10 M€ à la fois en chiffre d'affaires et en total de bilan n'est plus petite : elle compte comme moyenne.

Deux pièges fréquents :

• les effectifs et montants se consolident avec les entreprises partenaires ou liées : une filiale de 20 personnes d'un groupe de 400 n'est pas une petite entreprise au sens de la recommandation ;
• certaines activités sont visées quelle que soit la taille (prestataires de services de confiance, registres de noms de domaine, services DNS, réseaux de communications électroniques publics), et un État peut désigner une entité plus petite si elle est la seule à fournir un service critique.

3. Essentielle ou importante ?

Les mesures de sécurité exigées sont les mêmes pour les deux statuts. La différence porte sur la supervision (contrôles a priori pour les entités essentielles, a posteriori pour les importantes) et sur les sanctions : la directive impose aux États un plafond d'amende d'au moins 10 millions d'euros ou 2 % du chiffre d'affaires mondial pour une entité essentielle, et d'au moins 7 millions d'euros ou 1,4 % pour une entité importante (article 34).

Pour vous situer, l'ANSSI propose un test d'éligibilité sur MonEspaceNIS2, sans valeur juridique tant que la loi n'est pas promulguée.

Ce que NIS2 exige d'un éditeur concerné

L'article 21 de la directive fixe dix familles de mesures minimales. Voici ce qu'elles signifient concrètement pour un SaaS.

Pour les fournisseurs de services en nuage, de services gérés et quelques autres catégories numériques, le règlement d'exécution (UE) 2024/2690 détaille déjà ces exigences techniques et ce qui rend un incident « important ». Il s'applique directement, sans transposition, aux entités qui relèvent de la loi nationale.

En France, l'ANSSI a publié en mars 2026 un document de travail, le Référentiel Cyber France (ReCyF), qui décline ces objectifs en mesures. Il n'est pas obligatoire en soi, mais c'est la grille la plus probable des futurs contrôles.

Deux obligations changent la vie d'une petite équipe :

• la notification des incidents importants (article 23) : alerte précoce sous 24 heures, notification sous 72 heures, rapport final un mois plus tard. Sans journaux et sans procédure, ces délais sont intenables ;
• la responsabilité de la direction (article 20) : les organes de direction approuvent les mesures, en supervisent la mise en œuvre et suivent une formation. La sécurité n'est plus un sujet que l'on délègue entièrement au développeur.

Pour vos clients : la sécurité de la chaîne d'approvisionnement

C'est l'effet le plus concret pour la majorité des éditeurs, même petits. L'article 21 oblige chaque entité soumise à tenir compte des vulnérabilités propres à chacun de ses fournisseurs directs et de la qualité de leurs pratiques de développement. Votre SaaS en fait partie.

Concrètement, attendez-vous à recevoir :

• un questionnaire de sécurité, souvent long, à remplir avant la signature ou au renouvellement ;
• des clauses contractuelles : délai de notification des incidents (parfois plus court que celui de la directive, pour que le client tienne le sien), droit d'audit ou remise d'un rapport d'audit, sous-traitants ultérieurs listés, localisation des données, réversibilité ;
• des preuves : politique de sécurité, résultats de tests d'intrusion, procédure de sauvegarde et date du dernier test de restauration, certification quand vous en avez une ;
• des exigences techniques : authentification unique (SSO) et multifacteur, journaux d'accès exportables, chiffrement, séparation des données entre clients.

Notre article sur le contrat SaaS, CGV et SLA détaille les clauses habituelles. Avec NIS2, elles cessent d'être une négociation entre grands comptes : une ETI cliente en a besoin pour sa propre conformité.

La check-list de l'éditeur, par ordre de priorité

Que vous soyez dans le périmètre ou seulement fournisseur d'une entité soumise, l'ordre de marche est le même.

1. Faites le test de périmètre : activité, taille consolidée, pays où vous vendez. Notez la conclusion et sa date.
2. Inventoriez : serveurs, bases de données, services tiers, comptes d'administration, dépendances logicielles.
3. Fermez les accès faibles : authentification multifacteur partout pour l'équipe, comptes nominatifs, droits minimaux, révocation au départ.
4. Testez une restauration de sauvegarde, en vrai, et chronométrez-la.
5. Écrivez la procédure d'incident : qui décide, qui prévient les clients, sous quel délai, avec quels journaux.
6. Évaluez vos propres fournisseurs : hébergeur, prestataire d'envoi d'e-mails, paiement, intelligence artificielle. Vous serez interrogé sur eux.
7. Préparez un dossier de sécurité réutilisable : réponses types au questionnaire, schéma d'architecture, politique de sécurité.
8. Faites valider par la direction, et formez-la : c'est une exigence de la directive, et c'est ce qui débloque les arbitrages budgétaires.

Notre article sur la sécurité d'une application métier reprend les fondamentaux techniques, et celui sur l'hébergement d'une application métier en France aide à choisir un hébergeur que vos clients accepteront.

Le Cyber Resilience Act, en deux mots

Le règlement (UE) 2024/2847, dit Cyber Resilience Act, vise les produits comportant des éléments numériques mis sur le marché européen, logiciels installés compris. Ses obligations de signalement des vulnérabilités activement exploitées s'appliquent depuis le 11 septembre 2026, et l'essentiel des exigences à partir du 11 décembre 2027.

Un pur service en ligne relève en principe de NIS2 plutôt que du CRA. Le CRA peut toutefois vous concerner si vous fournissez aussi une application mobile, un logiciel de bureau ou un boîtier, ou si votre service distant est indispensable au fonctionnement d'un produit vendu. Dans ce cas, les deux textes s'additionnent.

Les erreurs les plus fréquentes

• Conclure trop vite « je suis trop petit » sans consolider les effectifs du groupe, ni regarder les pays de vos clients.
• Confondre RGPD et NIS2. Le RGPD protège les données personnelles ; NIS2 vise la sécurité et la continuité du service lui-même. Un incident peut relever des deux, avec deux notifications distinctes. Notre article sur le RGPD dans une application métier traite le premier volet.
• Acheter un outil avant d'avoir une procédure. Un tableau de bord de conformité ne remplace ni la restauration testée ni la procédure d'incident.
• Promettre dans un contrat ce que le logiciel ne sait pas faire : journaux exportables, notification en quelques heures, suppression prouvée des données. Ces engagements se préparent dans le code.

Quand la conformité devient un sujet de développement

Une partie de NIS2 relève de l'organisation. Une autre se joue dans le logiciel : séparation des données entre clients, journaux d'accès, authentification multifacteur et SSO, sauvegardes restaurables, mises à jour des dépendances, capacité à exporter les données en fin de contrat. Un SaaS conçu sans ces fonctions les ajoute plus cher après coup, au moment où un grand compte les exige pour signer. L'architecture de SaaS multi-tenant est le premier endroit où cela se décide.

LPR Studio conçoit et exploite des logiciels, dont ses propres produits, avec ces exigences intégrées dès la conception. Si vous préparez un SaaS ou la refonte d'un service existant pour des clients exigeants, nous pouvons vous présenter en visio, sous 5 jours ouvrés, un prototype gratuit qui montre ces fonctions dans vos écrans : c'est le principe expliqué dans voir son logiciel avant de le payer. Pour le budget, notre article sur le coût de développement d'un SaaS donne les ordres de grandeur.