NIS2 et hébergement web : le plan de conformité 2026

La directive européenne NIS2 place la cybersécurité au niveau de la gouvernance et de la continuité d’activité. Pour un site e-commerce, une plateforme métier ou un service web à forte disponibilité, elle ne se limite donc pas à installer un pare-feu ou à activer un certificat SSL : elle oblige à mieux maîtriser les risques liés aux prestataires techniques, dont l’hébergeur.

Ce guide ne constitue pas un avis juridique. Il propose une méthode opérationnelle pour identifier les contrôles à demander à un hébergeur web, réunir les preuves utiles et bâtir un plan de remise à niveau réaliste. L’objectif est clair : savoir ce qui protège réellement votre infrastructure, ce qui est écrit au contrat et ce qui a été testé dans des conditions proches du réel.

NIS2 : ce que la directive change pour les organisations numériques

La directive NIS2, officiellement la directive (UE) 2022/2555, renforce les exigences européennes en matière de cybersécurité. Elle remplace la première directive NIS et élargit le périmètre des entités susceptibles d’être concernées. Les États membres doivent la transposer dans leur droit national : les obligations concrètes, les autorités compétentes et les modalités de contrôle dépendent donc aussi de la réglementation applicable dans chaque pays.

Dans son principe, NIS2 distingue des entités essentielles et des entités importantes. Elle vise notamment des secteurs tels que l’énergie, les transports, la santé, les infrastructures numériques, les administrations publiques, les services postaux, la gestion des déchets, certaines activités industrielles et des fournisseurs de services numériques.

Pour les entreprises du web, le point important est le suivant : la directive vise explicitement plusieurs services d’infrastructure numérique, parmi lesquels les fournisseurs de services de cloud computing, les fournisseurs de services de centre de données, les fournisseurs de réseaux de diffusion de contenu (CDN), les fournisseurs de DNS et les registres de noms de domaine de premier niveau.

Un hébergeur mutualisé, un fournisseur de serveur dédié, une plateforme cloud, un CDN ou un prestataire infogéré ne sont pas automatiquement soumis au même régime dans tous les cas. Leur qualification dépend de leur activité réelle, de leur taille, de leur implantation et de la transposition nationale. De même, un e-commerçant n’entre pas mécaniquement dans le champ de NIS2 parce qu’il exploite un site web.

En revanche, même lorsqu’une entreprise n’est pas directement concernée, les principes de NIS2 deviennent une référence de maturité. Un donneur d’ordre soumis à des exigences fortes devra évaluer ses fournisseurs. Un site qui traite des paiements, gère un catalogue à forte valeur commerciale ou dépend d’une disponibilité continue a donc intérêt à adopter ce niveau de contrôle.

La bonne question n’est pas seulement « mon hébergeur est-il NIS2 ? », mais « puis-je démontrer que les risques liés à mon hébergement sont identifiés, contractualisés, surveillés et testés ? »

Les obligations à traduire en exigences d’hébergement

L’article 21 de NIS2 demande aux entités concernées de prendre des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées pour gérer les risques. Pour un responsable e-commerce ou une direction technique, ce texte doit être traduit en exigences mesurables vis-à-vis de l’hébergeur.

La directive couvre notamment :

les politiques d’analyse des risques et de sécurité des systèmes d’information ;
la gestion des incidents ;
la continuité d’activité, les sauvegardes, la reprise après sinistre et la gestion de crise ;
la sécurité de la chaîne d’approvisionnement ;
la sécurité dans l’acquisition, le développement et la maintenance des systèmes ;
la gestion et la divulgation des vulnérabilités ;
l’évaluation de l’efficacité des mesures de cybersécurité ;
l’hygiène informatique, la formation, le chiffrement, la gestion des accès et l’authentification forte.

Ces exigences recoupent les critères d’un hébergement premium réellement évaluable. Un hébergeur ne doit pas seulement annoncer une infrastructure « sécurisée » : il doit préciser le partage des responsabilités. Par exemple, il peut sécuriser le réseau, l’hyperviseur et le matériel, alors que votre équipe reste responsable des mises à jour de WordPress, des extensions, des comptes administrateurs et du code applicatif.

Cette frontière est souvent la première cause d’un faux sentiment de conformité. Une offre « managée » peut réduire le travail d’exploitation, mais elle ne couvre pas nécessairement le durcissement applicatif, le paramétrage d’un WAF, la revue des droits IAM ou la restauration d’une base de données après une erreur métier.

Savoir si votre hébergeur entre dans le périmètre pertinent

Commencez par cartographier les services réellement consommés. Le nom commercial de l’offre ne suffit pas : un même fournisseur peut proposer du cloud public, des serveurs dédiés, de la colocation, du CDN, du DNS managé, des sauvegardes et de la protection anti-DDoS, avec des responsabilités distinctes.

Les questions de qualification à poser

Le prestataire exploite-t-il lui-même le centre de données, ou agit-il comme revendeur ?
Le service s’apparente-t-il à un service de cloud computing, à un centre de données, à un CDN ou à une autre infrastructure numérique visée par NIS2 ?
Dans quels pays sont situés les sites d’hébergement, les sauvegardes et les équipes de support ?
Quels sous-traitants interviennent pour le réseau, l’anti-DDoS, la supervision, le DNS, la messagerie ou les sauvegardes ?
Le fournisseur peut-il partager ses politiques de sécurité, ses attestations et ses procédures de notification d’incident ?

Un hébergeur sérieux pourra répondre clairement, même s’il ne communique pas tous les détails sensibles de son architecture. Il est normal qu’un prestataire refuse de publier des configurations de sécurité détaillées. En revanche, l’opacité totale sur les processus, les localisations, la sous-traitance ou la gestion des incidents est un signal d’alerte.

Ne confondez pas non plus conformité réglementaire et certification. Une certification ISO/IEC 27001 peut constituer un indicateur utile de système de management de la sécurité de l’information. Un rapport SOC 2 peut également apporter des éléments d’assurance, surtout pour des fournisseurs internationaux. Mais aucun de ces documents ne transfère votre responsabilité, ni ne prouve à lui seul que votre architecture répond à vos risques.

Les garanties de sécurité à exiger de l’hébergeur

La sécurité d’hébergement doit être examinée sous trois angles : protection physique et réseau, sécurité de la plateforme, et capacité à collaborer lors d’un incident.

Protection de l’infrastructure et du réseau

Demandez quelles protections existent contre les attaques par déni de service distribué (DDoS), comment sont séparés les environnements clients et comment les accès administrateurs sont contrôlés. Dans une architecture cloud, vérifiez également les mécanismes de segmentation réseau, par exemple les réseaux privés, les groupes de sécurité ou les pare-feux applicatifs.

Un CDN tel que Cloudflare, Fastly ou Akamai peut absorber une partie du trafic malveillant et rapprocher le contenu des visiteurs. Cela ne remplace pas les protections au niveau de l’origine : l’adresse IP du serveur d’origine doit être restreinte lorsque l’architecture le permet, et le serveur doit rester maintenu.

Le chiffrement en transit via TLS est indispensable, mais ne résume pas la sécurité. Vérifiez le cycle de renouvellement des certificats, les responsabilités de configuration et l’existence d’une surveillance des échéances. La réduction de la durée de vie des certificats rend cette automatisation d’autant plus importante, comme l’explique notre article sur les certificats SSL et leurs échéances.

Correctifs, vulnérabilités et journalisation

Le contrat doit dire qui applique les correctifs à chaque couche : matériel, hyperviseur, système d’exploitation, serveur web, base de données, CMS et dépendances applicatives. Pour un serveur infogéré, demandez les plages de maintenance, les procédures de correctif urgent et les conditions dans lesquelles une intervention peut affecter votre application.

Les journaux sont essentiels lors d’une enquête. Vérifiez que vous pouvez accéder aux logs système, web, CDN, pare-feu et authentification dans une durée de rétention adaptée à vos besoins. Une conservation très courte peut rendre impossible l’analyse d’une intrusion découverte tardivement. Centraliser les événements dans une solution comme Elastic, Splunk ou un SIEM adapté à votre organisation améliore la corrélation, à condition de définir les alertes réellement utiles.

Continuité : SLA, redondance, sauvegardes et reprise

La disponibilité annoncée dans un SLA ne suffit pas. Un taux de disponibilité ne décrit ni les exclusions, ni le mode de calcul, ni le temps nécessaire pour restaurer une boutique après une corruption de données. La continuité doit être conçue autour de deux objectifs métiers :

RTO : le délai maximal acceptable pour remettre le service en fonctionnement ;
RPO : la quantité maximale de données que l’entreprise accepte de perdre, exprimée en durée.

Par exemple, un site marchand qui accepte un RPO d’une heure doit disposer de mécanismes permettant de restaurer les données avec une perte maximale théorique d’une heure. Une sauvegarde quotidienne ne répond pas à cet objectif. À l’inverse, définir un RPO très faible sans prévoir le budget, la réplication et les procédures nécessaires ne constitue pas une stratégie crédible.

Demandez à l’hébergeur :

la fréquence des sauvegardes et leur durée de conservation ;
la localisation et l’isolement des copies ;
le chiffrement des sauvegardes ;
la procédure de restauration, son coût éventuel et son délai ;
la possibilité de réaliser une restauration de test ;
les options de réplication dans une autre zone ou un autre site ;
les scénarios couverts par son plan de reprise d’activité.

Une sauvegarde non testée n’est qu’une hypothèse. Testez au minimum la restauration d’une base de données, des médias, des fichiers de configuration et des secrets nécessaires au démarrage. Pour un e-commerce, validez aussi les fonctions critiques après restauration : connexion client, panier, paiement, gestion des commandes et synchronisations avec les outils tiers.

La disponibilité perçue doit enfin être observée depuis l’extérieur. Des outils de supervision synthétique comme UptimeRobot, Pingdom ou StatusCake peuvent détecter une indisponibilité. Ils doivent être complétés, lorsque l’enjeu le justifie, par des données de Real User Monitoring afin de mesurer l’expérience réelle des visiteurs.

Incidents : exiger une procédure utilisable en situation de crise

NIS2 prévoit une logique de notification graduée pour les incidents significatifs : une alerte précoce dans les 24 heures, une notification dans les 72 heures, puis un rapport final dans le mois suivant la notification. Les modalités précises d’application dépendent de la transposition nationale et de la situation de l’entité.

Pour votre hébergeur, l’enjeu est pratique : recevrez-vous les informations assez tôt pour protéger vos clients, prendre les décisions de continuité et satisfaire vos propres obligations ?

Le contrat ou une annexe de sécurité devrait préciser :

ce qu’est un incident de sécurité ou de disponibilité notifiable ;
le canal d’alerte disponible 24 heures sur 24, si votre niveau de service le nécessite ;
le délai d’information contractuel ;
les informations communiquées : périmètre, chronologie, services affectés, mesures prises et actions attendues de votre part ;
les interlocuteurs nommés des deux côtés ;
les modalités de coopération pour préserver les preuves et analyser les journaux ;
la remise d’un rapport d’incident après résolution.

Privilégiez un engagement précis à une formule vague telle que « le client sera informé dans les meilleurs délais ». Les bonnes questions sont : qui appelle, quel numéro est utilisé, à quel moment, et que se passe-t-il si votre contact principal est indisponible ?

Checklist contrat, accès et architecture

Avant de considérer un environnement comme suffisamment maîtrisé, passez en revue cette checklist avec l’hébergeur, l’équipe de développement et la personne responsable de la sécurité.

Contrat et gouvernance fournisseur

Inventaire à jour des services, sous-traitants et localisations de données.
Annexe de sécurité précisant le partage des responsabilités.
SLA, fenêtres de maintenance, exclusions et mécanismes d’escalade documentés.
Droit d’obtenir des éléments d’audit ou des attestations pertinentes.
Processus encadré de changement de sous-traitant ou de localisation.
Plan de réversibilité : récupération des données, délais, formats et suppression à la fin du contrat.

Accès et secrets

Authentification multifacteur obligatoire pour le portail d’hébergement, le DNS, le CDN et les comptes d’administration.
Comptes nominatifs : aucun identifiant administrateur partagé entre collaborateurs.
Principe du moindre privilège pour SSH, bases de données, consoles cloud et outils de déploiement.
Revue régulière des droits, notamment lors des départs et changements de poste.
Clés SSH, mots de passe d’API et secrets applicatifs stockés dans un gestionnaire approprié, tel que 1Password, Bitwarden ou HashiCorp Vault selon le contexte.
Accès d’urgence (« break glass ») documenté, contrôlé et journalisé.

Infrastructure et exploitation

Mises à jour de sécurité planifiées et procédure d’urgence.
Supervision des ressources, de l’expiration des certificats et des erreurs applicatives.
Sauvegardes séparées de l’environnement de production et restaurations testées.
Protection DNS : MFA, verrouillage de transfert si disponible et revue des enregistrements critiques.
Documentation d’architecture tenue à jour : domaines, origines, adresses IP, dépendances et flux réseau.

Plan d’action en 90 jours pour une infrastructure web plus fiable

Un programme NIS2 ne se résout pas par un questionnaire envoyé à l’hébergeur. Il faut séquencer les priorités pour réduire les risques les plus graves sans bloquer l’exploitation du site.

Jours 1 à 30 : cartographier et fermer les risques immédiats

Recensez les domaines, serveurs, comptes cloud, CDN, DNS, bases de données, sauvegardes et intégrations critiques. Identifiez pour chaque service un propriétaire interne et un fournisseur. Activez l’authentification multifacteur là où elle manque, supprimez les anciens comptes et vérifiez les privilèges administrateurs.

À ce stade, récupérez le contrat, le SLA, l’annexe de traitement des données, les procédures d’incident et les documents de sécurité disponibles. Réalisez également un premier test de restauration sur un environnement isolé. Si vous découvrez que la restauration est impossible ou trop lente, la priorité est de corriger ce point avant de multiplier les projets de conformité.

Jours 31 à 60 : contractualiser et tester les scénarios de panne

Envoyez à l’hébergeur un questionnaire ciblé sur la sécurité, les sous-traitants, les sauvegardes, les vulnérabilités et les incidents. N’exigez pas un catalogue de déclarations génériques : demandez des réponses liées au service acheté.

Définissez ensuite vos RTO et RPO avec les équipes métier. Testez un scénario réaliste : indisponibilité d’un serveur, suppression accidentelle de données, erreur de déploiement ou indisponibilité du DNS. Documentez la décision de bascule, les rôles, les communications clients et le retour à la normale.

Jours 61 à 90 : industrialiser la preuve et l’amélioration continue

Formalisez un registre des fournisseurs critiques, un calendrier de revue des accès, un processus de suivi des vulnérabilités et un tableau de bord de disponibilité. Centralisez les preuves : comptes rendus de tests, rapports de restauration, attestations du fournisseur, tickets d’incident et décisions de correction.

Programmez au moins un exercice de crise impliquant l’hébergeur ou, à défaut, une simulation interne basée sur ses procédures. L’objectif n’est pas de produire un document parfait : c’est de réduire le temps de décision lorsque le site, le paiement ou le back-office devient indisponible.

Conclusion : faire de l’hébergement une preuve de résilience

NIS2 encourage une évolution utile : considérer l’hébergement comme un maillon critique de la sécurité et non comme une simple ligne de coût. Pour un site e-commerce, les priorités sont concrètes : connaître les responsabilités, sécuriser les accès, tester les sauvegardes, encadrer les incidents et exiger des engagements vérifiables.

Commencez par l’inventaire de vos dépendances et par un test de restauration. Ces deux actions révèlent rapidement les écarts entre les garanties théoriques de votre offre et la résilience réelle de votre activité. Si votre infrastructure soutient un chiffre d’affaires ou un service critique, utilisez cette checklist lors de votre prochain audit hébergeur ou renouvellement de contrat.