NIS2 est une directive européenne, à reprendre dans la loi de chaque pays de l’Union, qui élargit fortement le nombre d’organisations soumises à des obligations de cybersécurité. En France, cette « loi NIS2 » est le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, dont l’examen à l’Assemblée nationale, prévu début octobre 2026, a été reporté sans nouvelle date.

Même si la loi ne la vise pas, une PME qui travaille pour une organisation concernée verra arriver ses exigences par contrat : mieux vaut s’y préparer.

Où en est la loi NIS2 au 21 octobre 2026

Les pays de l’Union devaient reprendre la directive au plus tard le 17 octobre 2024. En France, le projet de loi, déposé au Sénat le 15 octobre 2024 en procédure accélérée, y a été adopté en première lecture le 12 mars 2025 ; la commission spéciale de l’Assemblée nationale a adopté son texte le 10 septembre 2025. Il reprend trois directives : NIS2, celle sur la résilience des entités critiques et celle liée au règlement DORA pour le secteur financier.

Prévu en séance publique les 7 et 9 octobre 2026, le texte a été retiré de l’ordre du jour le 6 octobre ; les réunions qui fixent cet ordre du jour ne l’ont pas réinscrit les 13 et 20 octobre. Aucune nouvelle date n’est fixée à ce jour (voir le dossier législatif de l’Assemblée nationale).

Le 8 juillet 2026, la Commission européenne a décidé de saisir la Cour de justice de l’Union européenne contre la France, l’Espagne, l’Irlande et les Pays-Bas pour ce retard. Elle demande à la Cour une somme forfaitaire et des astreintes journalières (pénalités par jour de retard) jusqu’à la reprise complète de la directive.

Après la promulgation viendront les décrets et arrêtés d’application. Selon l’ANSSI, l’agence de l’État chargée de la cybersécurité, dans sa FAQ sur l’avancement de la transposition, NIS2 entrera en vigueur en France quand tous ces textes seront publiés, sans que toutes les exigences s’appliquent dès cette date : les délais de mise en conformité ne sont pas encore arrêtés.

NIS2 : qui est concerné directement

Selon l’ANSSI, plusieurs milliers d’organisations seront concernées, surtout des moyennes et grandes entreprises, des collectivités et des administrations. Leurs 18 secteurs forment deux groupes :

• les secteurs « hautement critiques », dont l’énergie, les transports, la santé, l’eau potable, les infrastructures numériques, la banque ou les prestataires qui gèrent l’informatique d’autres entreprises (infogérance) ;
• les autres secteurs « critiques », dont l’industrie manufacturière, l’agroalimentaire, la gestion des déchets, la chimie, les services postaux et les fournisseurs numériques.

Une entreprise d’un secteur hautement critique est en principe « entité essentielle » si elle emploie au moins 250 personnes, ou si son chiffre d’affaires annuel dépasse 50 millions d’euros et son bilan 43 millions d’euros. Les autres entreprises des secteurs concernés sont « entités importantes » si elles emploient au moins 50 personnes, ou si leur chiffre d’affaires et leur bilan annuels dépassent 10 millions d’euros. Les micro et petites entreprises ne sont en principe pas soumises à la loi, sauf cas particuliers (certains acteurs des noms de domaine, par exemple).

Pour vérifier votre situation, l’ANSSI propose un test en ligne sur MonEspaceNIS2, où l’on peut aussi se pré-enregistrer.

Ce que devront faire les entreprises concernées

L’ANSSI résume le dispositif en trois obligations : s’enregistrer auprès d’elle, autorité nationale compétente ; mettre en place des mesures de gestion des risques pour atteindre les objectifs de sécurité fixés par le texte français ; lui signaler les incidents importants et les failles de sécurité critiques.

Ces mesures sont décrites dans le Référentiel Cyber France (ReCyF) de l’ANSSI, dont la version 2.5 du 17 mars 2026 reste une version de travail, susceptible d’évoluer avec les débats parlementaires. Il fixe 20 objectifs de sécurité : les quinze premiers pour les entités importantes et essentielles, les cinq derniers pour les seules entités essentielles. Selon l’ANSSI, ces objectifs deviendront obligatoires par décret une fois la loi promulguée ; les « moyens acceptables de conformité » proposés pour les atteindre resteront en principe facultatifs, sauf cas particuliers. Certains acteurs du numérique relèvent d’un règlement européen spécifique.

La directive prévoit enfin que la direction approuve ces mesures, supervise leur mise en œuvre et puisse être tenue responsable en cas de manquement. Selon l’ANSSI, les sanctions pourront atteindre 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial pour une entité essentielle, et 7 millions d’euros ou 1,4 % pour une entité importante.

Fournisseurs et prestataires : concernés sans être visés

La directive impose aussi d’assurer « la sécurité de la chaîne d’approvisionnement », y compris dans les relations avec les fournisseurs et prestataires directs. Le ReCyF en fait un objectif, « Maîtrise de l’écosystème », dont les moyens proposés prévoient notamment que l’entreprise concernée :

• tienne à jour la liste de ses prestataires et fournisseurs informatiques, avec un contact pour chacun ;
• s’assure que chaque prestation respecte ses propres obligations, notamment en gestion des risques et en signalement des incidents, et en obtienne des garanties contractuelles : plan d’assurance sécurité (engagements de sécurité écrits du prestataire), charte de télémaintenance (règles des interventions à distance) ou indicateurs de suivi, par exemple ;
• vérifie régulièrement cette conformité, éventuellement par des audits.

L’éditeur du logiciel métier, l’infogérant ou l’hébergeur d’une entreprise concernée doivent donc s’attendre à des questionnaires de sécurité, des clauses contractuelles et des demandes d’audit. Ces exigences viendront du contrat, pas de la loi, mais pourront peser lors du renouvellement des marchés.

Ce que votre PME peut préparer dès maintenant

Quelques chantiers de base, inspirés du ReCyF, répondent à l’essentiel des questions d’un client :

• la liste de vos systèmes, comptes administrateurs et accès chez vos clients ;
• l’authentification multifacteur (un code ou une clé en plus du mot de passe) pour les accès à distance et les comptes aux droits étendus ;
• des mises à jour de sécurité régulières, en suivant les alertes du CERT-FR (le centre d’alerte de l’État), et des logiciels encore maintenus par leur éditeur ;
• des sauvegardes protégées et des restaurations réellement testées ;
• une procédure d’incident, avec une personne chargée de prévenir vos clients sans délai ;
• un dossier prêt à transmettre : mesures en place, liste de vos sous-traitants, engagements tenables. Mieux vaut s’engager sur ce que l’on sait tenir que signer une annexe de sécurité inapplicable.

Un exemple concret

Prenons, à titre d’illustration, une PME de 20 personnes, au chiffre d’affaires inférieur à 10 millions d’euros, qui développe et héberge l’application de planning d’un groupe de cliniques privées de 400 salariés. Elle n’est en principe pas soumise à la loi. Son client, du secteur de la santé (hautement critique) et de plus de 250 personnes, serait en principe entité essentielle. Avant de renouveler le contrat, il envoie un questionnaire sur ces mêmes sujets, délais des mises à jour compris, et demande l’acceptation d’un audit.

Si la PME a inventorié ses accès, activé l’authentification multifacteur sur l’administration de l’hébergement, testé une restauration complète et rédigé un court plan d’assurance sécurité, elle répond point par point, preuves à l’appui. Le questionnaire devient un argument commercial plutôt qu’un risque de perdre le marché.

Questions fréquentes

La loi NIS2 est-elle déjà en vigueur en France ?

Non. Au 21 octobre 2026, l’Assemblée nationale n’a pas examiné en séance le projet de loi adopté par le Sénat. Il faudra ensuite un texte voté dans les mêmes termes par les deux assemblées, le cas échéant après une commission mixte paritaire (députés et sénateurs réunis pour trouver un accord), puis la promulgation et les décrets.

Mon entreprise a moins de 50 salariés : est-elle concernée ?

Avec moins de 50 personnes et un chiffre d’affaires ou un bilan ne dépassant pas 10 millions d’euros, elle n’est en principe pas directement soumise à la loi, sauf cas particuliers. Si vous travaillez pour une entité essentielle ou importante, ses exigences vous parviendront par le contrat.

Dois-je m’inscrire dès maintenant sur MonEspaceNIS2 ?

Le pré-enregistrement est ouvert aux organisations qui se savent concernées, mais l’obligation ne s’appliquera qu’une fois la loi en vigueur. Une PME sous-traitante non soumise à la loi n’a pas à le faire : la démarche revient à son client, s’il est concerné.

411bit accompagne les TPE, PME et ETI dans la préparation à NIS2 : audit de cybersécurité, choix des mesures prioritaires, aide pour répondre aux questionnaires de vos donneurs d’ordre, puis, si vous le souhaitez, supervision et maintien en condition opérationnelle (surveillance et entretien de vos systèmes), sur devis établi au livrable. Contactez-nous pour en parler : chaque demande reçoit une réponse sous 24 heures ouvrées. Voir aussi : sécuriser son informatique sans bloquer la croissance.

La « faille PHP » corrigée le 21 octobre 2026 regroupe deux failles critiques, surnommées « PHP2Shell » par les chercheurs en sécurité. Elles peuvent permettre à un pirate, sans identifiant ni mot de passe, de lancer ses propres commandes sur le serveur de votre site, avec les droits du site. Selon PHP, toute installation qui fait fonctionner un site ou une application web est concernée.

Votre site ou votre application repose sur WordPress, PrestaShop ou un autre outil écrit en PHP ? Il reste exposé tant que PHP n’a pas été mis à jour sur le serveur, même s’il est bien conçu.

Ce qu’il faut savoir sur cette faille PHP

Annoncés par PHP la veille pour 16 h (heure de Paris), les correctifs sont sortis le 21 octobre. Selon l’avis de sécurité de PHP, une simple requête anonyme a suffi, dans certaines configurations, à démontrer une attaque, avant même que le site n’entre en jeu. Selon plusieurs sociétés de sécurité, des détails circulaient en ligne avant leur sortie.

Le CERT-FR, service d’alerte de l’ANSSI (l’agence nationale de cybersécurité), a publié une alerte. Il juge touchées toutes les versions de PHP 5 à 8.1, et les versions 8.2 à 8.5 antérieures aux correctifs. Depuis le 21 octobre, des sociétés de sécurité signalent des tentatives d’attaque, avec des constats encore divergents sur leur ampleur. Pour PHP, aucune parade n’est complète : seule la mise à jour protège.

Pourquoi mettre à jour WordPress ne suffit pas

Les failles sont dans PHP lui-même, le moteur qui fait tourner votre site, pas dans WordPress, PrestaShop ou les outils de développement. Mettre à jour extensions ou thème ne corrige donc rien : PHP doit être remplacé sur le serveur, puis redémarré. Méfiez-vous des extensions présentées comme des « correctifs PHP2Shell » : fonctionnant grâce à PHP, elles ne peuvent pas le réparer.

Pour l’une des failles, l’avis de PHP signale aussi une fuite d’informations de la mémoire du serveur. Selon des chercheurs, le pirate peut y récupérer mots de passe, données qui gardent un utilisateur connecté ou clés d’accès. Un site sans dégât visible a donc pu laisser fuir des informations sensibles.

Qui doit intervenir dépend de votre hébergement :

• hébergement mutualisé (serveur partagé) ou plateforme gérée : l’hébergeur, pas vous ;
• serveur dédié ou virtuel : vous ou votre prestataire d’infogérance ;
• application en « conteneurs » (Docker par exemple) : celui qui la maintient, en la reconstruisant avec un PHP corrigé.

Vérifier si votre site est protégé

Relevez la version de PHP utilisée par votre site :

• WordPress : Outils, puis Santé du site, onglet Infos, rubrique Serveur ;
• PrestaShop : Paramètres avancés, puis Informations ;
• Laravel, Symfony ou sur mesure : demandez à votre développeur la version utilisée par le serveur web, parfois différente de celle de la ligne de commande.

Une version 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou plus récente dans la même série, signifie que le correctif est actif. Une version plus ancienne n’est pas forcément vulnérable : PHP précise que les fournisseurs de systèmes Linux et de support prolongé ont reçu les correctifs à l’avance. Or ils peuvent intégrer un correctif sans changer le numéro de version affiché.

Dans le doute, demandez à votre hébergeur une confirmation écrite : correctifs des deux failles appliqués, PHP redémarré ensuite (sinon l’ancienne version continue de tourner), et date de l’intervention.

Si votre site tourne encore en PHP 8.1 ou 7.x

PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour officielles. PHP a tout de même publié des correctifs minimaux pour 7.4, 8.0 et 8.1, pour ceux qui fabriquent eux-mêmes leur PHP à partir du code source. Trois actions s’imposent :

• chercher une version corrigée chez le fournisseur du système Linux ou une société de support prolongé, ou faire appliquer le correctif publié par PHP ;
• appliquer dès aujourd’hui les deux mesures provisoires citées par le CERT-FR : désactiver le suivi de progression des envois de fichiers, et filtrer ces envois avec un pare-feu applicatif (un filtre placé devant le site) ;
• planifier sans attendre le passage à une version maintenue.

Ces mesures réduisent le risque sans le supprimer : le CERT-FR ne les a pas validées, et la première ne couvre qu’une des deux failles. Ce filtrage bloque aussi les envois de fichiers légitimes et peut perturber certains formulaires, à tester. Pour les versions sans suivi, le CERT-FR recommande d’isoler les équipements concernés, puis de migrer. Visez PHP 8.3 au minimum, idéalement 8.4 ou 8.5 : selon le calendrier officiel de PHP, la 8.2 ne recevra plus de correctifs de sécurité après le 31 décembre 2026. Passer de PHP 7 à PHP 8 impose souvent d’adapter le code, à valider sur une copie de test.

Comment savoir si votre site a été piraté

Corriger PHP ne dit pas ce qui a pu se passer avant. Faites contrôler par votre hébergeur ou votre prestataire, au minimum :

• les fichiers PHP récemment ajoutés ou modifiés sur le site : un pirate a pu y cacher une porte d’entrée ;
• les nouveaux comptes administrateurs, sur le site comme sur le serveur ;
• les tâches programmées inconnues et les programmes lancés par PHP ;
• dans les journaux, des envois de fichiers inhabituels suivis d’erreurs de mémoire ou d’erreurs serveur répétées, et des redémarrages inexpliqués de PHP.

Aucun de ces signes n’est une preuve à lui seul, et leur absence ne garantit rien. En cas de doute, changez les codes d’accès stockés sur le serveur : base de données, liaisons avec d’autres logiciels, paiement, envoi d’e-mails. Conservez les journaux avant toute remise en état, pour l’analyse et une éventuelle plainte. Si des données personnelles ont pu être consultées, le RGPD impose de notifier la CNIL au plus tard 72 heures après en avoir pris connaissance, si la violation présente un risque pour les personnes.

À transmettre à votre hébergeur ou à votre prestataire

• CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10 (CVSS 4.0) ; alerte CERTFR-2026-ALE-014 ;
• versions corrigées : 8.5.12, 8.4.27, 8.3.36, 8.2.35, puis redémarrage des processus PHP ;
• risque maximal avec Apache et mod_php ; attaque validée aussi sur PHP-FPM pour l’une des failles ;
• 8.1 et antérieures : contournements non qualifiés par le CERT-FR, session.upload_progress.enabled à Off (php.ini ou pool PHP-FPM) puis redémarrage, et blocage au WAF, ou à défaut surveillance, des requêtes multipart.

Un exemple concret

Prenons, à titre d’illustration, une PME de 20 personnes : un site vitrine WordPress chez un hébergeur mutualisé, un espace client Laravel sur un serveur dédié en PHP 8.1. Le site vitrine affiche 8.3.36 dans Santé du site : le correctif est actif. L’espace client est plus délicat, faute de version officielle corrigée en 8.1. Le jour même, le prestataire désactive le suivi de progression des envois, filtre les envois de fichiers là où ils sont inutiles et cherche une version corrigée chez le fournisseur Linux. Il contrôle ensuite journaux et fichiers et fait renouveler les clés d’accès. Le passage à PHP 8.4, avec la mise à jour de Laravel qu’il implique, se prépare sur une copie de test.

Questions fréquentes

Mon site est chez un hébergeur mutualisé : que dois-je faire ?

Vous ne pouvez pas mettre PHP à jour vous-même. Vous pouvez en revanche vérifier la version affichée, demander une confirmation écrite à l’hébergeur et quitter une ancienne version (7.4 ou 8.1) si votre offre le permet.

Un pare-feu suffit-il à protéger mon site ?

Non. Un pare-feu applicatif peut bloquer des attaques connues et faire gagner du temps, mais ne filtre que le trafic qui passe par lui et ne corrige pas PHP.

Faut-il fermer mon site en attendant ?

Si la mise à jour tarde et que le site traite des paiements ou des données sensibles, couper l’accès est raisonnable, dans l’esprit de l’isolement recommandé par le CERT-FR. Le « mode maintenance » de WordPress ou d’une boutique ne protège pas : l’attaque a lieu avant que le site n’entre en jeu. La coupure doit donc se faire sur le serveur ou chez l’hébergeur.

Le 21 octobre, dès la publication des correctifs, 411bit a mis à jour PHP sur les serveurs des clients dont il assure l’infogérance. Pour faire le point, 411bit propose de vérifier la version de PHP de vos sites et applications, d’appliquer la mise à jour ou de vous accompagner auprès de votre hébergeur, de faire passer en version maintenue une application restée en PHP 8.1 ou 7.x et de rechercher d’éventuels signes de piratage, avec une réponse sous 24 heures ouvrées : décrivez-nous votre situation. Si votre application a été développée par un autre prestataire, la reprise d’une plateforme B2B industrielle illustre la démarche : un audit de sécurité d’abord, la reprise en main ensuite.

Sécuriser son informatique passe pour un frein à l’activité : mots de passe imposés, accès bloqués, projets ralentis. C’est un faux dilemme. Bien menée, la sécurité protège votre entreprise sans gêner vos équipes, et elle est invisible au quotidien.

La plupart des dirigeants repoussent le sujet de la sécurité par crainte de ralentir leurs équipes. C’est un faux dilemme : une sécurité bien conçue est invisible au quotidien et ne se voit que le jour où elle vous sauve.

Les risques réels d’une PME

• Un rançongiciel qui chiffre les fichiers et bloque la production
• Un faux email de fournisseur qui détourne un virement
• Un ancien salarié dont les accès n’ont jamais été coupés
• Une sauvegarde jamais testée qui se révèle inutilisable le jour J

« On est trop petits pour intéresser quelqu’un »

C’est la phrase qu’on entend le plus souvent, et c’est la plus fausse. Les attaques qui touchent les PME ne sont presque jamais ciblées. Ce sont des campagnes automatisées qui balaient des milliers d’adresses et s’arrêtent sur celles qui ne résistent pas. Votre taille ne vous protège pas, elle fait juste de vous une cible plus facile qu’un grand groupe qui a une équipe dédiée.

Un exemple concret

Prenez une PME industrielle de 30 personnes. Un vendredi après-midi, un salarié ouvre une pièce jointe qui ressemble à une facture fournisseur. Le lundi matin, les fichiers de production sont chiffrés.
Le décompte des dégâts :

• Quatre jours d’activité à l’arrêt, soit environ 40 000 € de chiffre d’affaires décalé ou perdu.
• Une sauvegarde qui existait, mais qui n’avait jamais été testée : trois semaines de données irrécupérables.
• Des clients prévenus avec retard, et deux commandes annulées.

Les mesures qui auraient évité tout cela coûtaient quelques centaines d’euros par mois : un cloisonnement réseau, une sauvegarde testée tous les mois, et vingt minutes de sensibilisation par salarié. C’est toute l’équation de la sécurité en PME.

Sécuriser son informatique en six mesures concrètes

1. Cloisonner le réseau : un poste compromis ne doit pas donner accès à tout
2. Sécuriser les accès distants par des connexions chiffrées
3. Vérifier les sauvegardes : une sauvegarde non testée n’existe pas
4. Couper les comptes inutilisés : départs, stagiaires, prestataires
5. Sensibiliser les équipes : la majorité des incidents commencent par un email
6. Superviser : détecter une anomalie en heures plutôt qu’en semaines

On savait qu’on avait des failles, sans savoir lesquelles. L’audit a tout mis à plat, avec un plan d’action clair et chiffré. Plus aucun incident depuis.

Par où commencer

Par un état des lieux. Un audit de sécurité répond en quelques semaines à trois questions : où sont vos risques réels, lesquels traiter en priorité, et combien coûte chaque mesure. Vous ressortez avec une liste de chantiers classés, pas avec un rapport de 80 pages que personne ne lira.

Questions fréquentes

Un antivirus ne suffit-il pas ?

Non. L’antivirus arrête une partie des menaces connues, mais il ne fait rien contre un faux email de fournisseur, un accès oublié ou une sauvegarde défaillante. La majorité des sinistres en PME passent à côté de l’antivirus, pas à travers.

Combien coûte un audit de sécurité ?

Pour une PME, comptez quelques jours de travail selon la taille du parc. C’est sans commune mesure avec le coût d’un arrêt de production, et cela vous évite surtout d’investir au hasard dans des outils dont vous n’avez pas besoin.

Mes équipes vont-elles être bloquées ?

Si la sécurité gêne, c’est qu’elle est mal conçue. Un accès distant chiffré, une authentification à deux facteurs bien paramétrée ou une sauvegarde automatique ne changent rien au quotidien des utilisateurs. Ce qui bloque vraiment les équipes, c’est un rançongiciel.

Que faire si on est déjà attaqué ?

On isole les machines touchées du réseau sans les éteindre, on ne paie pas, et on appelle quelqu’un de compétent tout de suite. La rapidité de réaction fait toute la différence entre quelques heures d’interruption et plusieurs semaines.
411bit réalise des audits de sécurité avec un rapport lisible par un dirigeant et un plan d’action priorisé et chiffré. Demandez votre audit.
Pour aller plus loin : les recommandations de l’ANSSI et notre article sur la migration ERP sans interruption.