NIS2 et loi résilience : ce que la nouvelle réglementation cyber change pour votre site web en 2026

Pourquoi ce sujet : la transposition française de la directive NIS2, portée par le projet de loi dit « résilience », revient dans l'actualité parlementaire de l'été 2026 et le terme « NIS2 » cumule 5 400 recherches mensuelles en France, or la quasi-totalité des contenus disponibles s'adresse aux DSI et ignore le cas concret du site web d'entreprise, terrain sur lequel Pulsar apporte une réponse directe (sécurité, maintenance, journalisation, continuité).

Depuis des mois, la directive NIS2 s'invite dans les comités de direction. Elle inquiète, elle est mal comprise, et elle est presque toujours abordée sous l'angle du système d'information interne : postes de travail, serveurs métiers, messagerie, ERP. Une brique passe systématiquement entre les mailles du filet : le site web de l'entreprise, souvent hébergé à l'extérieur, souvent maintenu par un tiers, souvent oublié des cartographies. Cet article explique ce que NIS2 exige réellement, qui est concerné (y compris par ricochet), et surtout comment traduire ces obligations en actions concrètes sur un site vitrine, un intranet ou un parc de sites.

NIS2, loi résilience : de quoi parle-t-on exactement ?

NIS2 est le nom courant de la directive (UE) 2022/2555 du 14 décembre 2022, qui remplace la première directive NIS de 2016. Son objectif est simple à énoncer : relever le niveau de cybersécurité d'un très grand nombre d'organisations européennes, en imposant des mesures de gestion des risques et une obligation de notification des incidents.

Là où NIS1 ne visait, en France, que quelques centaines d'opérateurs de services essentiels, NIS2 élargit massivement le périmètre : selon l'ANSSI, environ 15 000 entités françaises devraient entrer dans le champ d'application, réparties sur dix-huit secteurs d'activité. On passe donc d'un dispositif réservé aux très grands opérateurs à un dispositif qui touche des ETI, des collectivités, des établissements publics, des industriels, des acteurs de la santé, de l'énergie, des transports, de l'eau, du numérique, de la recherche ou encore de la fabrication.

Où en est la transposition française ?

La directive prévoyait une transposition par les États membres pour le 17 octobre 2024. La France n'a pas tenu ce calendrier. La transposition passe par un projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, communément appelé « loi résilience », qui poursuit son parcours parlementaire.

Point à retenir, et il est capital pour ne pas se tromper de tempo : le fait que le texte français ne soit pas encore définitivement adopté ne suspend rien. Les entreprises concernées disposeront d'un délai pour atteindre la conformité complète une fois la loi promulguée, mais ce délai se consommera vite pour qui n'a rien anticipé. Et surtout, nous y venons, l'effet le plus immédiat de NIS2 ne vient pas du régulateur : il vient des clients.

Votre organisation est-elle concernée ? Les deux catégories à connaître

NIS2 introduit deux statuts, qui se déterminent en croisant un secteur d'activité et une taille d'entreprise.

• Les entités essentielles (EE) : globalement les grandes entreprises (à partir de 250 salariés, ou plus de 50 M€ de chiffre d'affaires et plus de 43 M€ de bilan) opérant dans un secteur dit « hautement critique » : énergie, transports, santé, eau potable, infrastructures numériques, administration publique, espace, banque, marchés financiers.
• Les entités importantes (EI) : les entreprises moyennes (à partir de 50 salariés, ou plus de 10 M€ de chiffre d'affaires ou de bilan) des mêmes secteurs, ainsi que celles de secteurs « critiques » complémentaires : services postaux, gestion des déchets, industrie chimique, agroalimentaire, fabrication, fournisseurs numériques, recherche.

La distinction n'est pas cosmétique : elle détermine le régime de supervision (contrôles proactifs pour les EE, contrôles a posteriori pour les EI) et le plafond des sanctions. Pour les entités essentielles, l'amende administrative peut atteindre 10 millions d'euros ou 2 % du chiffre d'affaires annuel mondial ; pour les entités importantes, 7 millions d'euros ou 1,4 %. Dans les deux cas, c'est le montant le plus élevé qui s'applique.

Le point que tout le monde manque : la responsabilité des dirigeants

NIS2 sort la cybersécurité du seul champ technique. Le texte engage explicitement les organes de direction, qui doivent approuver les mesures de gestion des risques, en superviser la mise en œuvre et se former. Autrement dit, « je ne savais pas, c'est le prestataire qui gère » n'est plus une position défendable. C'est un changement culturel majeur : la sécurité d'un site web n'est plus un sujet d'informaticien, c'est un sujet de comité de direction.

« Nous ne sommes pas concernés » : l'effet ricochet de la chaîne d'approvisionnement

C'est la phrase que nous entendons le plus souvent. Elle est vraie dans la lettre, et fausse dans les faits.

NIS2 impose aux entités essentielles et importantes de gérer les risques liés à leur chaîne d'approvisionnement, y compris à leurs fournisseurs et prestataires de services directs. Concrètement, une entité concernée doit évaluer la sécurité de ses fournisseurs, exiger d'eux des garanties, et intégrer ces exigences dans ses contrats.

Traduction pour une PME qui n'est pas elle-même dans le périmètre : si vous fournissez un service, un logiciel, un site, une prestation numérique ou même un service non numérique à une entité soumise à NIS2, vous allez recevoir des questionnaires de sécurité, des clauses contractuelles nouvelles, des demandes de preuves. Le régulateur ne viendra pas vous voir. Votre client, lui, viendra, et son achat dépendra de vos réponses.

Nous voyons déjà arriver, dans les appels d'offres et les renouvellements de contrats, des exigences très concrètes : politique de mises à jour documentée, délai de correction des vulnérabilités critiques, journalisation conservée, plan de reprise testé, authentification forte sur les accès d'administration, notification d'incident sous 24 heures. Une entreprise qui ne sait pas répondre à ces questions perd le marché, sans qu'aucune sanction administrative n'ait jamais été prononcée. C'est aujourd'hui, en 2026, le premier effet réel de NIS2 sur le tissu économique français.

Ce que NIS2 exige concrètement, traduit pour un site web

L'article 21 de la directive liste dix familles de mesures minimales. Elles sont rédigées de manière volontairement générique, pour s'appliquer aussi bien à une centrale électrique qu'à un service numérique. Voici comment elles se traduisent, très concrètement, sur le périmètre d'un site web ou d'un parc de sites.

1. Analyse des risques et politique de sécurité des systèmes d'information

Il faut savoir ce que l'on possède avant de pouvoir le protéger. Sur le web, cela signifie disposer d'un inventaire à jour : quels sites, quels noms de domaine, quels CMS et dans quelles versions, quels hébergeurs, quels certificats, quelles extensions, qui détient les accès, quelles données personnelles sont traitées. Dans les faits, la plupart des organisations que nous auditons découvrent à cette étape des sites oubliés (un mini-site de campagne, un ancien site régional, un espace de préproduction laissé en ligne) qui constituent des portes d'entrée idéales.

2. Gestion des incidents

NIS2 impose une chaîne de notification en trois temps pour les incidents significatifs : une alerte précoce dans les 24 heures suivant la prise de connaissance, une notification circonstanciée dans les 72 heures, un rapport final dans un délai d'un mois. Ces délais sont serrés. Ils supposent d'avoir, en amont, défini ce qu'est un incident, qui le détecte, qui le qualifie, qui décide et qui rédige. Un site web défiguré à 23 h un vendredi ne laisse pas le temps d'improviser une procédure.

3. Continuité d'activité : sauvegardes, reprise, gestion de crise

C'est le point où l'écart entre le discours et la réalité est le plus grand. Presque toutes les entreprises affirment avoir des sauvegardes. Beaucoup moins savent dire à quelle fréquence elles sont réalisées, où elles sont stockées, si elles sont hors du serveur de production, si elles sont chiffrées, et surtout quand la dernière restauration a été testée. Une sauvegarde jamais restaurée n'est pas une sauvegarde : c'est une hypothèse.

4. Sécurité de la chaîne d'approvisionnement

Pour un site web, la chaîne d'approvisionnement est double. Il y a les prestataires humains (agence, hébergeur, régie publicitaire, intégrateur) et il y a la chaîne logicielle : le CMS, ses extensions, ses thèmes, les bibliothèques JavaScript chargées depuis des CDN tiers, les scripts d'analytics et de tracking. Chaque script tiers embarqué dans une page est un fournisseur de fait, avec un droit d'exécution dans le navigateur de vos visiteurs. Les attaques par supply chain sur le web (compromission d'une extension populaire, d'un plugin abandonné, d'un script hébergé chez un tiers) sont devenues l'un des vecteurs d'intrusion les plus efficaces.

5. Sécurité de l'acquisition, du développement et de la maintenance, incluant la gestion des vulnérabilités

La directive nomme explicitement la maintenance. C'est là que le sujet devient tangible : il ne suffit pas d'avoir un site sécurisé au jour de sa mise en ligne, il faut un processus qui garantit qu'il le reste. Cela suppose une veille sur les failles publiées, un délai de correction défini pour les vulnérabilités critiques, un environnement de préproduction pour tester les mises à jour, et une traçabilité de ce qui a été appliqué et quand.

6. Évaluation de l'efficacité des mesures

Écrire une politique ne suffit pas : il faut prouver qu'elle fonctionne. Audits périodiques, tests de restauration, revue des accès, contrôle du niveau de patch. La preuve, ici, prime sur l'intention.

7. Hygiène informatique et formation

Les contributeurs d'un site (rédacteurs, marketing, communication) disposent souvent d'accès au back-office. Ils sont, statistiquement, la première porte d'entrée par hameçonnage. Une politique NIS2 crédible inclut leur sensibilisation, pas seulement celle des équipes techniques.

8. Cryptographie et chiffrement

HTTPS partout, certificats valides et renouvelés automatiquement, redirection systématique du HTTP vers le HTTPS, en-têtes de sécurité correctement positionnés, chiffrement des sauvegardes. Ce sont des acquis pour beaucoup ; les audits montrent que ce n'est pas le cas pour tous, en particulier sur les sites secondaires du parc.

9. Sécurité des ressources humaines, contrôle d'accès et gestion des actifs

Qui a un compte administrateur sur votre site ? Depuis quand ? L'ancien stagiaire, l'agence précédente, le développeur freelance de 2019 ? La revue périodique des comptes et le retrait des accès au départ d'un collaborateur ou à la fin d'un contrat sont des mesures triviales à énoncer et rarement appliquées.

10. Authentification multifacteur et communications sécurisées

L'authentification à deux facteurs sur les accès d'administration et sur les accès techniques (FTP/SFTP, base de données, panneau d'hébergement) est explicitement visée. C'est probablement la mesure au meilleur rapport effort/bénéfice de toute la liste.

Le site web, angle mort de la conformité

Dans la plupart des démarches de mise en conformité que nous croisons, la cartographie initiale est faite par la DSI et couvre le système d'information interne. Le site web, lui, appartient souvent à la direction de la communication ou du marketing, il est hébergé chez un tiers, et il a parfois été livré par une agence qui n'existe plus. Il n'apparaît donc dans aucune cartographie, ne figure dans aucun plan de reprise, et personne ne sait exactement qui détient les accès root du serveur.

C'est une faille de gouvernance, pas une faille technique, et c'est précisément ce type de faille que NIS2 cherche à corriger.

Pourtant, un site web d'entreprise concentre plusieurs des risques les plus visibles :

• Il est exposé publiquement, en permanence. Contrairement à un ERP interne, il est scanné en continu par des robots qui cherchent des versions vulnérables connues.
• Il traite des données personnelles : formulaires de contact, candidatures, inscriptions à une newsletter, espaces clients. Une compromission déclenche potentiellement à la fois une notification NIS2 et une notification CNIL au titre du RGPD.
• Il est la vitrine de la confiance. Un site défiguré ou signalé comme dangereux par les navigateurs abîme la marque bien au-delà de l'incident technique.
• Il repose massivement sur des composants tiers dont l'entreprise n'a pas la maîtrise : extensions, thèmes, scripts externes.

Méthode en sept étapes pour mettre un site web au niveau NIS2

Voici la démarche que nous appliquons chez nos clients. Elle vaut aussi bien pour une organisation directement concernée que pour un fournisseur qui doit répondre aux exigences de ses donneurs d'ordre.

Étape 1 : Inventorier le parc

Recenser tous les actifs web : sites principaux, sites secondaires, landing pages de campagne, intranets, extranets, préproductions, sous-domaines. Pour chacun : hébergeur, CMS et version, PHP et version, date de dernière mise à jour, propriétaire métier, prestataire, présence de données personnelles. Cette étape révèle presque toujours des surprises. Un audit de site web structuré est le moyen le plus rapide d'obtenir cette photographie.

Étape 2 : Évaluer les risques et prioriser

Tous les sites ne se valent pas. Un site qui collecte des candidatures n'a pas le même profil de risque qu'un mini-site événementiel archivé. Classer les actifs selon leur exposition et leur criticité permet d'allouer l'effort là où il compte, plutôt que de saupoudrer.

Étape 3 : Combler les écarts techniques prioritaires

Dans l'ordre d'efficacité, pour un budget donné : remettre à niveau les CMS et extensions en retard, activer l'authentification à deux facteurs sur tous les comptes d'administration, supprimer les comptes dormants, vérifier que les sauvegardes sont externalisées et chiffrées, tester une restauration réelle, mettre à jour la version de PHP si elle n'est plus supportée, fermer ou isoler les environnements de préproduction accessibles publiquement.

Étape 4 : Industrialiser la maintenance

La conformité n'est pas un état, c'est un régime permanent. Il faut un processus récurrent : veille de sécurité, application des correctifs dans un délai contractualisé, test en préproduction, mise en production tracée, rapport périodique. C'est exactement l'objet d'un contrat de maintenance de site web : transformer une bonne intention en obligation de résultat, avec des engagements de délai.

Étape 5 : Outiller la détection et la journalisation

On ne notifie pas en 24 heures un incident qu'on n'a pas détecté. Supervision de la disponibilité, alerte sur les erreurs, journalisation des connexions au back-office, conservation des journaux sur une durée définie, alerte sur les modifications de fichiers sensibles. Sans journaux, l'analyse post-incident est impossible et le rapport final à 30 jours devient un exercice de fiction.

Étape 6 : Écrire les procédures et les faire vivre

Qui appelle-t-on à 22 h un samedi si le site est défiguré ? Qui décide de couper le site ? Qui prévient la direction, le DPO, les clients ? Une procédure d'incident tient sur deux pages ; son absence coûte des heures d'errance au pire moment. Idem pour le plan de reprise : il doit être écrit, et il doit être testé.

Étape 7 : Documenter et prouver

NIS2 est une réglementation de la preuve. Rapports de maintenance datés, historique des correctifs appliqués, comptes rendus de tests de restauration, registre des accès, résultats d'audit. Ce dossier est aussi, très concrètement, ce que vous enverrez à vos clients quand ils vous adresseront leur questionnaire fournisseur.

Les erreurs fréquentes que nous constatons

• Attendre la promulgation du texte. Le calendrier réglementaire n'est pas le calendrier commercial : les exigences arrivent par les contrats, souvent avant la loi.
• Confondre conformité et outil. Acheter un pare-feu applicatif ou un plugin de sécurité ne produit pas de conformité. NIS2 demande un processus, une gouvernance et des preuves.
• Oublier les sites secondaires. L'attaquant, lui, ne les oublie pas. Le maillon faible d'un parc n'est presque jamais le site principal.
• Croire que l'hébergeur « fait la sécurité ». L'hébergeur sécurise l'infrastructure ; la sécurité applicative (le CMS, ses extensions, son code, ses accès) reste à la charge du propriétaire du site. Cette confusion est la plus coûteuse de toutes.
• Ne pas tester les sauvegardes. Nous ne le répéterons jamais assez.
• Traiter le sujet uniquement en interne technique alors que NIS2 engage la direction et impose de former les dirigeants.

Checklist actionnable : les questions à poser dès cette semaine

• Disposons-nous d'une liste exhaustive et à jour de tous nos sites, sous-domaines et environnements en ligne ?
• Quelle est la version de notre CMS et de PHP sur chacun d'eux ? Sont-elles encore supportées ?
• Combien de comptes administrateurs existent ? Sont-ils tous encore légitimes ? Sont-ils protégés par une authentification à deux facteurs ?
• Où sont stockées les sauvegardes ? Sont-elles hors du serveur de production ? Chiffrées ? Quand avons-nous testé une restauration pour la dernière fois ?
• Sommes-nous alertés automatiquement si un site tombe, ou l'apprenons-nous par un client ?
• Combien de temps s'écoule-t-il, chez nous, entre la publication d'un correctif de sécurité critique et son application effective ?
• Avons-nous une procédure écrite d'incident, avec des noms et des numéros de téléphone ?
• Si un client nous envoie demain un questionnaire de sécurité fournisseur, sommes-nous capables d'y répondre avec des preuves ?

Si vous ne pouvez pas répondre à cinq de ces huit questions, l'écart à combler est réel, mais il est franchissable, et il se traite dans l'ordre.

Ce que NIS2 change dans la relation avec votre prestataire web

La directive fait basculer la maintenance web d'un statut de « coût technique » à celui de fonction de conformité. Concrètement, plusieurs éléments deviennent non négociables dans un contrat.

• Des engagements de délai écrits sur l'application des correctifs de sécurité et sur le rétablissement en cas d'incident, pas des « meilleurs efforts ».
• Une traçabilité fournie : rapports datés de ce qui a été mis à jour, quand, et avec quel résultat.
• Une obligation d'alerte : le prestataire doit vous signaler un incident, pas le résoudre discrètement, car c'est vous qui portez l'obligation de notification.
• La réversibilité : accès, code source, documentation et sauvegardes doivent vous être restituables à tout moment. Une dépendance totale à un prestataire est en soi un risque de chaîne d'approvisionnement.
• La supervision du parc entier, pas seulement du site vitrine principal. C'est l'objet du pilotage de parc digital.

Chez Pulsar, ces exigences ne sont pas des nouveautés : elles décrivent notre métier depuis 2005. Nous maintenons des sites pour des organisations qui, elles, sont directement concernées par NIS2, et nous savons donc à quoi ressemble un dossier de preuve qui tient. Ce qui change en 2026, c'est que ce niveau d'exigence, jusqu'ici réservé aux grands comptes, descend désormais vers l'ensemble de leurs fournisseurs.

Et si le site est trop ancien pour être mis à niveau ?

C'est une question légitime. Un site sous un CMS en fin de vie, sans mises à jour de sécurité disponibles, avec des développements spécifiques non documentés, peut effectivement se révéler impossible à sécuriser durablement. Dans ce cas, deux voies existent, et une seule est bonne selon le contexte.

La première consiste à maintenir sous perfusion : isoler le site, restreindre les accès, placer un filtrage devant, réduire la surface exposée, et accepter un risque résiduel maîtrisé pendant une période courte et bornée. C'est une solution de transition, pas une stratégie.

La seconde consiste à faire évoluer le socle : migration du CMS vers une version supportée, remise à niveau du code, reprise progressive plutôt que reconstruction complète. C'est le champ de la maintenance évolutive (TMA) : améliorer sans tout casser, par incréments, en préservant le référencement et le contenu existants. Dans la majorité des cas que nous traitons, cette voie coûte nettement moins cher qu'une refonte complète et produit un résultat conforme plus rapidement.

FAQ

Mon entreprise a moins de 50 salariés : NIS2 me concerne-t-elle ?

Pas directement, dans la très grande majorité des cas : les seuils de taille excluent les petites entreprises du champ d'application, sauf exceptions sectorielles. Mais si vous fournissez une prestation à une entité essentielle ou importante, vous serez concerné par ricochet, via les exigences de sécurité que votre client vous imposera contractuellement.

Quel est le délai pour se mettre en conformité ?

Les entités concernées disposeront d'un délai après la promulgation de la loi française pour atteindre la conformité complète, avec une montée en charge progressive des contrôles. Ce délai ne doit pas être lu comme un répit : l'inventaire, la remise à niveau technique et la mise en place d'un processus de maintenance documenté prennent plusieurs mois, et les exigences contractuelles de vos clients, elles, arrivent maintenant.

NIS2 remplace-t-elle le RGPD ?

Non, les deux textes coexistent et se cumulent. Le RGPD protège les données personnelles ; NIS2 vise la sécurité et la résilience des systèmes et des réseaux. Une fuite de données issue d'un site web compromis peut déclencher les deux obligations de notification en parallèle, avec des destinataires et des délais distincts.

Un site vitrine sans données sensibles est-il vraiment un enjeu ?

Oui, pour trois raisons. Il est exposé en permanence et constitue une porte d'entrée potentielle vers l'infrastructure. Il porte l'image et la confiance : un site défiguré ou marqué comme dangereux par les navigateurs a un coût réputationnel immédiat. Enfin, il fait partie de votre surface d'attaque, et à ce titre il figure dans les questionnaires de sécurité de vos clients.

Faut-il un budget important ?

Les mesures au meilleur rendement sont peu coûteuses : authentification à deux facteurs, suppression des comptes dormants, mises à jour régulières, sauvegardes externalisées et testées, supervision. Le coût réel n'est pas dans l'outillage, il est dans la régularité, donc dans le fait de confier cette régularité à quelqu'un dont c'est le métier, plutôt que de compter sur une disponibilité interne qui ne vient jamais.

En résumé

NIS2 ne demande rien d'exotique. Elle exige ce qu'une bonne pratique de maintenance web impose depuis toujours : savoir ce qu'on possède, tenir ses versions à jour, contrôler ses accès, sauvegarder et savoir restaurer, détecter et journaliser, savoir réagir, et pouvoir le prouver. La nouveauté est que ces pratiques deviennent opposables : par le régulateur pour les entités concernées, par les clients pour tous les autres.

Le site web est le maillon le plus exposé et le plus souvent oublié de cette chaîne. Le mettre au niveau n'est ni long ni ruineux quand on procède dans l'ordre : inventaire, priorisation, remise à niveau, industrialisation, preuve.

Vous voulez savoir où vous en êtes réellement ? Commencez par une photographie objective de votre parc : demandez un audit de votre site web, ou parlez-nous de votre situation via notre page de contact. Nous vous dirons franchement quel écart existe, ce qui est urgent, et ce qui peut attendre.

Sources de référence : directive (UE) 2022/2555 (NIS2) ; portail MonEspaceNIS2 de l'ANSSI. Les seuils, délais et montants cités sont ceux de la directive européenne ; les modalités françaises définitives dépendent du texte de transposition en cours d'examen.