NIS2 en bref : qui est concerné et depuis quand
La directive (UE) 2022/2555, dite NIS2, devait être transposée en droit national par chaque État membre de l'Union européenne au plus tard le 17 octobre 2024. À mi-2026, 22 des 27 États membres ont officiellement adopté leur législation nationale — les cinq restants sont en cours de procédure législative. La première vague d'actions d'exécution est engagée dans plusieurs juridictions, et les autorités compétentes ont commencé à formuler des demandes formelles aux opérateurs. Ignorer la directive en espérant que « ça ne nous concerne pas » est un pari de plus en plus risqué.
La question du périmètre est la première que les responsables techniques se posent. NIS2 distingue deux catégories d'entités : les entités essentielles (Annexe I) et les entités importantes (Annexe II). L'appartenance à l'une ou l'autre dépend du secteur d'activité et de la taille. La règle de taille par défaut : plus de 50 salariés ou plus de 10 M€ de chiffre d'affaires annuel. En dessous de ces seuils, une organisation est en principe hors périmètre direct — mais attention : si vous êtes prestataire d'une entité essentielle ou importante, les exigences de sécurité de la chaîne d'approvisionnement (Article 21, point d) vous atteignent indirectement. Les secteurs couverts incluent l'énergie, les transports, la banque, la santé, l'eau, l'infrastructure numérique, ainsi que les fournisseurs numériques : IaaS, PaaS, SaaS, MSP, MSSP, opérateurs DNS, registres de noms de domaine de premier niveau (TLD).
Les 10 mesures de l'Article 21 NIS2
L'Article 21 de la directive NIS2 définit dix mesures de gestion des risques de cybersécurité que les entités essentielles et importantes doivent mettre en œuvre. Ces mesures couvrent l'ensemble du cycle de vie de la sécurité : de l'analyse des risques à la gestion des incidents, en passant par la continuité d'activité et la sécurité de la chaîne d'approvisionnement. Chaque mesure doit être proportionnée au risque et documentée afin de démontrer sa mise en œuvre aux autorités de supervision compétentes.
- Politiques d'analyse des risques et de sécurité des systèmes d'information
- Gestion des incidents : détection, notification et réponse
- Continuité d'activité : sauvegardes, reprise après sinistre, gestion de crise
- Sécurité de la chaîne d'approvisionnement (fournisseurs et sous-traitants)
- Sécurité dans l'acquisition, le développement et la maintenance des systèmes
- Politiques et procédures pour évaluer l'efficacité des mesures de cybersécurité
- Pratiques de base en matière de cyberhygiène et formation à la cybersécurité
- Politiques et procédures relatives à la cryptographie et au chiffrement
- Sécurité des ressources humaines, contrôle d'accès et gestion des actifs
- Utilisation de l'authentification multi-facteurs (MFA) ou de solutions d'authentification continue
Les 4 mesures qui touchent directement votre hébergement
Parmi les dix mesures de l'Article 21, quatre ont une traduction quasi directe dans les choix d'infrastructure et d'hébergement. Le Règlement d'exécution (UE) 2024/2690 du 17 octobre 2024 précise par secteur les exigences techniques applicables aux fournisseurs numériques — DNS, services cloud, CDN, MSP, MSSP — et constitue la référence opérationnelle à consulter en complément de la directive.
- Continuité et sauvegardes (Art. 21 §2.c) : les sauvegardes doivent être régulières, chiffrées, stockées hors du système principal, et leur restauration doit être testée. Un prestataire qui ne vous offre pas de sauvegardes délocalisées ou qui n'est pas en mesure de vous fournir les métadonnées (horodatage, intégrité) ne vous aide pas à remplir cette obligation.
- Cryptographie (Art. 21 §2.h) : le chiffrement des données en transit (TLS 1.2 minimum, TLS 1.3 recommandé) et au repos (volumes chiffrés, bases de données) doit être documenté. Le choix du chiffrement et la gestion des clés relèvent de votre responsabilité, mais votre hébergeur doit vous permettre de les mettre en œuvre.
- Contrôle d'accès et MFA (Art. 21 §2.i et §2.j) : l'accès aux interfaces d'administration (panneau d'hébergement, SSH, interfaces de gestion de VM) doit être protégé par MFA et soumis à un principe du moindre privilège. L'hébergeur doit proposer le MFA sur son panneau de gestion ; la configuration SSH relève de votre périmètre.
- Journalisation et détection (Art. 21 §2.b) : la capacité à détecter un incident et à en reconstituer le déroulement suppose des journaux système conservés dans le temps, intègres et accessibles. La rétention des logs, leur export vers un SIEM ou une plateforme centralisée, et leur protection contre la modification sont des exigences concrètes.
Ce que votre VPS ou serveur dédié doit satisfaire concrètement
Voici comment chacune de ces mesures se traduit en configuration opérationnelle sur un VPS ou un serveur dédié.
Sauvegardes. La bonne pratique est la règle 3-2-1 : trois copies des données, sur deux supports différents, dont une hors site. Sur un VPS, cela signifie a minima : un snapshot quotidien automatisé par l'hébergeur, plus une sauvegarde applicative exportée vers un stockage objet distinct (S3 compatible ou équivalent). La fréquence doit être définie en fonction de votre RPO (Recovery Point Objective) — pour la plupart des applications web critiques, 24 h est un maximum. Le test de restauration doit être documenté et répété au moins une fois par trimestre.
Chiffrement. TLS sur tous les points d'entrée (HTTPS, SMTP avec STARTTLS, accès API) avec une configuration rejetant les versions obsolètes (SSLv3, TLS 1.0, TLS 1.1). Pour les données au repos, les volumes contenant des données sensibles doivent être chiffrés — LUKS pour un système de fichiers Linux, chiffrement natif pour les bases de données si disponible. La gestion des certificats TLS doit être automatisée (ACME/Let's Encrypt ou équivalent) pour éviter les expirations non contrôlées.
Accès et MFA. L'accès SSH par mot de passe seul doit être désactivé — clés SSH uniquement, avec PasswordAuthentication no dans sshd_config. Pour les interfaces de gestion à haute valeur (panneau d'hébergement, consoles de virtualisation), le MFA par application TOTP ou clé matérielle (FIDO2) est exigé. Les comptes de service doivent avoir des clés dédiées, révocables indépendamment. La liste des accès actifs doit être auditée régulièrement.
Journaux. Les logs applicatifs (Nginx, Apache, PHP-FPM, bases de données) et système (auth, kernel, systemd) doivent être conservés dans un espace que l'application elle-même ne peut pas modifier. La durée minimale de rétention recommandée par la plupart des CSIRT nationaux est de 90 jours, avec une durée étendue (12 mois) pour les journaux d'authentification et d'administration. L'export vers une solution centralisée (syslog distant, Loki, Elasticsearch) est fortement recommandé pour préserver l'intégrité en cas de compromission du serveur.
Vérifier votre appartenance au périmètre NIS2
Identifiez votre secteur dans les Annexes I et II de la directive. Appliquez la règle de taille (> 50 salariés ou > 10 M€ de CA). Si vous êtes prestataire d'une entité essentiellement ou importante, évaluez les clauses de votre contrat de prestation — votre client peut vous imposer contractuellement des exigences de sécurité équivalentes.
Recenser toutes les interfaces d'administration exposées
Panneau d'hébergement, SSH, RDP, interfaces de base de données (phpMyAdmin, Adminer), consoles de monitoring, interfaces API de gestion — listez tout. Pour chaque interface, vérifiez : MFA activé, restriction par IP si possible, dernier audit de comptes actifs.
Auditer la politique de sauvegardes
Répondez aux questions suivantes : quelle est la fréquence des sauvegardes ? Où sont-elles stockées (même datacenter ou externe) ? Sont-elles chiffrées ? Avez-vous testé une restauration complète au cours des 90 derniers jours ? Avez-vous un RPO et un RTO définis par service critique ?
Tester la configuration TLS
Utilisez un outil d'analyse SSL (SSL Labs, testssl.sh) pour vérifier que vos domaines ne servent ni SSLv3, ni TLS 1.0/1.1, et que la suite de chiffrement ne contient pas d'algorithmes dépréciés (RC4, MD5, SHA-1 sur les certificats). Corrigez toute note inférieure à A sur SSL Labs.
Vérifier la rétention et l'intégrité des journaux
Identifiez l'emplacement de chaque fichier de log (auth, nginx/apache, application, base de données). Mesurez la durée de rétention actuelle. Vérifiez que les logs d'authentification ne sont pas accessibles en écriture par le compte applicatif. Mettez en place un export vers un stockage secondaire si ce n'est pas déjà fait.
Documenter la gestion des clés et certificats
Listez tous les certificats TLS en production avec leur date d'expiration. Vérifiez que le renouvellement est automatisé. Recensez les clés SSH actives par serveur et supprimez les clés orphelines (comptes désactivés, anciens prestataires). Documentez qui a accès à quoi.
Préparer la procédure de notification d'incident
NIS2 impose une notification initiale à l'autorité compétente dans les 24 heures suivant la détection d'un incident significatif, un rapport intermédiaire sous 72 heures, et un rapport final sous un mois. Définissez a minima : qui décide qu'un incident est significatif, qui notifie, et comment vous constituez la preuve du déroulement (logs).
Évaluer la sécurité de votre chaîne d'approvisionnement
Recensez les prestataires qui ont accès à votre infrastructure (hébergeur, infogérance, développeurs externes, intégrateurs). Pour chacun, évaluez le niveau de contrôle que vous exercez sur leurs accès et leur propre posture de sécurité. Les contrats avec ces prestataires doivent inclure des clauses de sécurité et de notification d'incident.
Ce que la NIS2 ne couvre pas directement : les organisations de moins de 50 salariés et de moins de 10 M€ de chiffre d'affaires annuel sont en principe hors du périmètre de la directive, sauf si elles opèrent dans des secteurs spécifiques listés à l'Annexe I ou si leur taille est supérieure aux seuils d'une « microentreprise » telle que définie par le règlement UE 2003/361. Cela ne signifie pas que ces organisations sont dispensées de toute obligation — d'autres réglementations (RGPD, réglementations sectorielles nationales) s'appliquent indépendamment — mais elles n'ont pas à satisfaire les exigences spécifiques de l'Article 21 NIS2. En revanche, si elles sont prestataires d'une entité en scope, leurs clients peuvent leur imposer contractuellement des mesures équivalentes au titre de la sécurité de la chaîne d'approvisionnement.
Faites défiler le tableau
| Critère | Entités essentielles (Annexe I) | Entités importantes (Annexe II) |
|---|---|---|
| Secteurs principaux | Énergie, transports, banque/finance, santé, eau potable, infrastructure numérique (DNS, TLD, IXP, cloud, CDN), administration publique, espace | Services postaux, gestion des déchets, industrie chimique, alimentation, fabrication industrielle, fournisseurs numériques (places de marché, moteurs de recherche, réseaux sociaux) |
| Seuil de taille | Moyenne et grande entreprise (> 50 salariés ou > 10 M€ CA) dans les secteurs Annexe I ; ou désignation explicite par l'État membre | Moyenne et grande entreprise (> 50 salariés ou > 10 M€ CA) dans les secteurs Annexe II |
| Régime de supervision | Proactif : audits réguliers, inspections sur site, surveillance continue possible | Réactif : contrôles déclenchés sur incident ou plainte |
| Amendes maximales | 10 M€ ou 2 % du chiffre d'affaires mondial annuel (le plus élevé des deux) | 7 M€ ou 1,4 % du chiffre d'affaires mondial annuel (le plus élevé des deux) |
| Délai de notification d'incident | Alerte initiale sous 24 h, rapport intermédiaire sous 72 h, rapport final sous 1 mois | Mêmes délais que les entités essentielles selon la plupart des transpositions nationales |
| Responsabilité des dirigeants | Les dirigeants peuvent être tenus personnellement responsables en cas de manquement grave | Responsabilité dirigeants : varie selon les transpositions nationales |
Mise en conformité : feuille de route pragmatique
La mise en conformité NIS2 n'est pas un projet ponctuel mais un programme de gestion des risques continu. Pour une organisation qui commence, une feuille de route en trois phases est réaliste.
Phase 1 — Cadrage (1 à 2 mois). Confirmer l'appartenance au périmètre, identifier les systèmes et services concernés (périmètre NIS2 ≠ totalité du SI), nommer un référent sécurité et définir les rôles. Produire une cartographie des actifs critiques et une première analyse de risque documentée. Identifier les lacunes les plus critiques : MFA manquant, sauvegardes non délocalisées, absence de journalisation centralisée.
Phase 2 — Mesures techniques immédiates (2 à 4 mois). Déployer le MFA sur toutes les interfaces d'administration. Mettre en place ou renforcer les sauvegardes délocalisées avec test de restauration. Auditer et corriger la configuration TLS. Centraliser les journaux avec rétention de 90 jours minimum. Revoir les accès des prestataires et mettre à jour les contrats. Rédiger la procédure de notification d'incident.
Phase 3 — Programme continu. Intégrer la sécurité dans le cycle de développement (revues de code, gestion des dépendances, tests de pénétration annuels). Mettre en place des exercices de continuité d'activité. Former les équipes aux pratiques de cyberhygiène. Documenter et tester la procédure de gestion de crise. Revoir l'analyse de risque au moins une fois par an ou après tout changement majeur d'infrastructure.
Sur le plan contractuel, vérifiez que votre contrat d'hébergement inclut des clauses sur : la notification d'incident (délai et canal), les responsabilités respectives en matière de sauvegardes, la portabilité des données, et les conditions d'accès aux journaux en cas d'enquête. Un SLA de disponibilité ne couvre pas ces dimensions — il faut les négocier explicitement.
Conclusion
La NIS2 n'est pas une réglementation abstraite : elle traduit en obligations concrètes des pratiques de sécurité que la majorité des équipes techniques reconnaissent comme bonnes depuis des années — sauvegardes fiables, accès contrôlés, journaux exploitables, procédures documentées. Ce qui change, c'est qu'elles deviennent exigibles, vérifiables et sanctionnables. Pour les entités en périmètre, la question n'est pas de savoir si ces pratiques valent la peine d'être mises en place, mais de documenter qu'elles le sont, et de choisir des partenaires d'infrastructure qui permettent cette documentation.
Pour approfondir : l'article sur les obligations spécifiques des hébergeurs et de leurs clients dans le cadre NIS2 ([nis2-hebergement-obligations-clients-2026](/blog/nis2-hebergement-obligations-clients-2026)), la gestion des consentements et obligations légales pour les hébergeurs ([digital-omnibus-cookies-consent-hebergeurs](/blog/digital-omnibus-cookies-consent-hebergeurs)), et les bonnes pratiques de sécurité des secrets applicatifs sur VPS ([docker-secrets-securite-vps-production](/blog/docker-secrets-securite-vps-production)).
