Directive NIS2 : votre hébergement WordPress est-il prêt ?

La directive européenne NIS2 renforce les exigences de cybersécurité applicables à de nombreuses organisations opérant dans l’Union européenne. Pour une entreprise utilisant WordPress, la question n’est donc pas seulement de savoir si le CMS est à jour : il faut aussi vérifier si l’hébergement, les sauvegardes, la protection réseau et les procédures d’incident sont adaptés au niveau de risque.

Un site vitrine de PME, une boutique WooCommerce, un portail client ou un multisite WordPress ne sont pas automatiquement « soumis à NIS2 ». La directive cible des entités, selon leur activité, leur taille et leur importance potentielle pour l’économie ou la société. En revanche, même lorsqu’une entreprise n’entre pas formellement dans son champ, NIS2 fixe un niveau de référence très utile pour choisir un hébergeur WordPress sérieux.

Ce guide distingue les obligations réglementaires des mesures pragmatiques à demander à son prestataire. Il ne remplace pas une analyse juridique : les modalités concrètes dépendent de la transposition de la directive dans le droit de chaque État membre et de la qualification de votre organisation.

NIS2 : ce que la directive change concrètement

La directive UE 2022/2555, couramment appelée NIS2, remplace la première directive NIS. Son objectif est d’élever le niveau commun de cybersécurité au sein de l’Union européenne pour les organisations dont la défaillance peut avoir des conséquences importantes.

Elle impose notamment aux entités concernées de mettre en place des mesures de gestion des risques cyber et de notifier certains incidents significatifs. Le texte cite des domaines très concrets :

analyse des risques et politiques de sécurité des systèmes d’information ;
gestion des incidents de cybersécurité ;
continuité d’activité, sauvegardes, reprise après sinistre et gestion de crise ;
sécurité de la chaîne d’approvisionnement, donc des prestataires techniques ;
gestion des vulnérabilités et des mises à jour ;
contrôle de l’efficacité des mesures de sécurité ;
hygiène numérique, formation et gestion des accès ;
recours approprié au chiffrement, à l’authentification multifacteur et à des communications sécurisées.

Pour un responsable de site WordPress, la conséquence majeure est simple : l’hébergeur devient un maillon documenté de la sécurité. Il ne suffit plus de comparer l’espace disque, le tarif d’appel ou la promesse de performances. Il faut être capable d’expliquer comment le prestataire protège l’infrastructure, restaure les données, réagit à une attaque et informe ses clients.

Cette logique complète les sujets déjà abordés dans notre guide sur les éléments à vérifier avant de choisir un hébergement WordPress. NIS2 ne transforme pas tous les sites en infrastructures critiques, mais elle rend l’évaluation des fournisseurs beaucoup plus structurée.

Quelles entreprises et quels sites WordPress peuvent être concernés ?

NIS2 ne s’applique pas à un site selon qu’il utilise WordPress, Drupal, Shopify ou un développement maison. La directive vise des organisations appartenant à des secteurs déterminés, notamment des secteurs « hautement critiques » et d’autres secteurs critiques.

Parmi les activités explicitement visées figurent notamment les services numériques tels que les fournisseurs de services d’informatique en nuage, les fournisseurs de services de centres de données, les fournisseurs de services gérés et les fournisseurs de services de sécurité gérés. Un hébergeur, un opérateur de cloud ou une agence qui administre l’infrastructure et la sécurité de plusieurs clients peut donc être concerné selon sa situation.

La directive repose généralement sur un critère de taille : les moyennes et grandes entités sont visées, avec des seuils liés notamment à 50 salariés et à un chiffre d’affaires annuel ou un bilan annuel supérieur à 10 millions d’euros. Des exceptions existent toutefois pour certaines entités importantes, indépendamment de leur taille. Les autorités nationales identifient les organisations concernées selon les règles applicables dans leur pays.

Un e-commerce WordPress est-il automatiquement soumis ?

Non. Une boutique WooCommerce qui vend ses propres produits ne devient pas automatiquement une entité NIS2 du seul fait qu’elle réalise des ventes en ligne. L’analyse dépend de l’activité réelle de l’entreprise, de sa taille, de son appartenance éventuelle à un secteur couvert et des règles nationales.

En revanche, une entreprise qui exploite une plateforme numérique pour mettre en relation des vendeurs tiers et des acheteurs, ou qui fournit des services techniques à d’autres entreprises, doit examiner son statut avec davantage d’attention. Il faut aussi tenir compte d’autres cadres réglementaires applicables à l’activité, comme le RGPD pour les données personnelles.

Les prestataires WordPress sont particulièrement exposés

Une agence qui se limite à concevoir un thème ou à publier des contenus n’a pas le même rôle qu’un prestataire qui :

héberge des sites clients sur ses propres serveurs ;
administre des VPS, des bases de données ou des sauvegardes ;
dispose d’accès administrateur permanents aux sites et aux comptes d’hébergement ;
assure une supervision, des mises à jour et une réponse aux incidents ;
revend une offre d’hébergement managé sous sa marque.

Dans ce second cas, la sécurité de la chaîne de sous-traitance devient centrale. Le prestataire doit savoir qui héberge réellement les données, où elles sont stockées, quels mécanismes protègent le réseau et quels interlocuteurs sont mobilisables en cas d’incident.

Le bon réflexe n’est pas de demander si un hébergeur est « certifié NIS2 ». NIS2 est une directive qui impose des obligations à certaines entités ; ce n’est pas un label commercial universel pour les offres d’hébergement.

Les garanties de sécurité à exiger de son hébergeur WordPress

La sécurité d’un site WordPress est partagée. L’hébergeur protège généralement le datacenter, le réseau, les serveurs physiques et certains composants de la plateforme. Le client ou son agence reste souvent responsable du cœur WordPress, des extensions, des comptes administrateurs, du contenu et de la configuration applicative.

Cette répartition varie fortement entre un mutualisé classique, un VPS administré et une offre WordPress managée. Consultez notre comparaison hébergement managé ou mutualisé pour WordPress pour identifier ce qui change réellement dans l’exploitation quotidienne.

Protection de l’infrastructure et isolation des comptes

Demandez au fournisseur de décrire précisément les protections incluses, sans se contenter de formulations vagues telles que « sécurité renforcée ». Les points utiles à vérifier sont les suivants :

pare-feu réseau et filtrage des flux entrants ;
protection contre les attaques par déni de service distribué, ou DDoS ;
isolation des comptes sur l’hébergement mutualisé ;
mises à jour du système et des composants gérés par l’hébergeur ;
journalisation des événements d’infrastructure ;
chiffrement des échanges via TLS et gestion des certificats ;
possibilité d’activer l’authentification multifacteur sur l’espace client et les accès d’administration ;
procédure de traitement des vulnérabilités affectant la plateforme.

Un hébergeur ne peut pas empêcher à lui seul une extension WordPress vulnérable d’être exploitée. En revanche, il doit pouvoir limiter les mouvements latéraux entre comptes, détecter certains comportements anormaux, protéger son réseau et informer ses clients lorsque l’incident relève de son périmètre.

Pour la couche applicative, un pare-feu applicatif web, aussi appelé WAF, peut compléter les protections de l’hébergeur. Des services comme Cloudflare WAF proposent des mécanismes de filtrage HTTP, mais leur mise en place ne dispense ni des mises à jour WordPress ni d’une architecture d’hébergement robuste.

DDoS : vérifier le périmètre réel de la promesse

La protection DDoS est fréquemment mise en avant dans les offres commerciales. Pourtant, elle recouvre des réalités différentes : protection du réseau de l’hébergeur, filtrage d’attaques volumétriques, limitation de requêtes HTTP ou protection applicative via un CDN.

Avant de signer, demandez :

si la protection DDoS est incluse ou optionnelle ;
si elle s’applique à toutes les offres, y compris au mutualisé ;
si le fournisseur communique une procédure d’escalade pendant une attaque ;
si une indisponibilité peut entraîner une suspension automatique du site ;
quel est le rôle du client pour activer ou paramétrer la protection.

Pour un site qui reçoit des campagnes publicitaires, traite des commandes ou sert de portail client, il est raisonnable de prévoir une stratégie multicouche : hébergeur, CDN/WAF, limitation des accès à l’administration et surveillance des erreurs. Notre dossier sur le CDN intelligent pour WordPress aide à comprendre ce que ces services peuvent apporter, et ce qu’ils ne remplacent pas.

Sauvegardes et reprise : la preuve compte plus que la promesse

NIS2 cite explicitement la continuité des activités, les sauvegardes, la reprise après sinistre et la gestion de crise. C’est un point déterminant pour WordPress : une restauration fiable après un ransomware, une suppression accidentelle ou une mise à jour défaillante vaut souvent davantage qu’une sauvegarde annoncée « quotidienne » sans détail.

Une stratégie crédible repose sur plusieurs questions vérifiables :

à quelle fréquence les sauvegardes sont-elles créées ;
combien de temps sont-elles conservées ;
la base de données et les fichiers WordPress sont-ils inclus ;
les sauvegardes sont-elles stockées sur une infrastructure distincte de la production ;
la restauration est-elle incluse, automatisée ou facturée ;
peut-on restaurer un fichier, une base ou un environnement de test sans écraser la production ;
les sauvegardes sont-elles protégées contre la suppression ou l’altération malveillante ;
comment le fournisseur teste-t-il sa capacité de restauration.

La règle souvent appelée « 3-2-1 » constitue une bonne base opérationnelle : conserver trois copies des données, sur deux supports ou systèmes distincts, dont une copie hors site. Ce n’est pas une formule magique ni une exigence textuelle de NIS2, mais elle évite de dépendre d’une unique sauvegarde hébergée au même endroit que la production.

Pour les sites critiques, demandez aussi un objectif de point de reprise (RPO) et un objectif de délai de reprise (RTO). Le RPO exprime la quantité maximale de données que l’on accepte de perdre ; le RTO correspond au temps maximal acceptable avant le retour en service. Une boutique qui reçoit des commandes ne peut pas définir ces objectifs de la même manière qu’un blog institutionnel mis à jour une fois par mois.

Les sauvegardes immuables pour WordPress méritent une attention particulière : lorsqu’elles sont correctement configurées, elles renforcent la résistance face à une suppression ou un chiffrement malveillant. Elles n’exonèrent toutefois pas de contrôler régulièrement la possibilité de restaurer un site fonctionnel.

Gestion des incidents : supervision, alerte et responsabilités

La directive organise la notification des incidents significatifs pour les entités concernées. Elle prévoit notamment une alerte précoce dans les 24 heures après la prise de connaissance d’un incident significatif, une notification d’incident dans les 72 heures, puis un rapport final au plus tard un mois après cette notification. Les règles nationales précisent les autorités compétentes, les modalités et les cas concernés.

Ces délais réglementaires ne signifient pas qu’un hébergeur doit nécessairement résoudre toute panne en 24 ou 72 heures. Ils soulignent en revanche la nécessité d’une chaîne d’information rapide et documentée. Si l’hébergeur détecte un incident susceptible d’affecter votre service, vous devez savoir qui vous contacte, par quel canal et avec quelles informations.

Ce que le contrat d’hébergement devrait préciser

Les conditions générales suffisent rarement à évaluer le dispositif opérationnel. Pour un site important, recherchez un contrat, un SLA ou une annexe de sécurité précisant au minimum :

les canaux de support et les horaires de prise en charge ;
les engagements de disponibilité éventuels et leurs exclusions ;
les responsabilités respectives de l’hébergeur, de l’agence et du client ;
les modalités de notification en cas d’incident de sécurité ;
la localisation des données et le recours éventuel à des sous-traitants ;
les conditions de restitution des données en cas de résiliation ;
les mécanismes de sauvegarde et de restauration ;
la procédure d’escalade pour les incidents critiques.

Attention à ne pas confondre disponibilité et sécurité. Un SLA indiquant un niveau de disponibilité ne décrit pas nécessairement les protections anti-intrusion, la conservation des journaux ou le délai d’information en cas de compromission.

Préparer son propre plan de réponse WordPress

Même avec un excellent hébergeur, l’entreprise doit préparer sa réponse. Conservez hors du site les coordonnées du support, les accès d’urgence, l’inventaire des extensions, la liste des administrateurs et les procédures de restauration. Définissez aussi qui peut décider de passer le site en maintenance, de modifier les DNS ou d’informer les clients.

Un scénario simple à tester : une extension compromise crée un compte administrateur inconnu et envoie des redirections malveillantes. L’équipe doit pouvoir identifier le problème, couper les accès si nécessaire, restaurer une version saine, changer les identifiants, vérifier les journaux et documenter les actions. Une sauvegarde non testée ou un accès au compte d’hébergement détenu par un ancien prestataire transforme rapidement cet incident en crise.

NIS2, RGPD et contrat d’hébergement : ne pas mélanger les sujets

NIS2 et le RGPD peuvent concerner simultanément une même organisation, mais ils ne poursuivent pas exactement le même objectif. Le RGPD porte sur la protection des données à caractère personnel. NIS2 se concentre sur la cybersécurité, la gestion des risques et la résilience de certaines entités.

Un hébergeur peut traiter des données personnelles pour le compte de son client. Dans ce cas, il doit également être encadré comme sous-traitant au sens du RGPD, notamment par un accord de traitement des données approprié. La présence d’un tel accord ne prouve pas, à elle seule, que le niveau de cybersécurité attendu au titre de NIS2 est atteint.

À l’inverse, une protection anti-DDoS ou un plan de reprise sérieux ne remplace pas l’analyse de conformité RGPD : gestion des accès aux données, durée de conservation, transferts éventuels, information des personnes concernées et réponse aux violations de données restent à traiter.

Pour les organisations françaises, l’ANSSI publie des ressources utiles sur la cybersécurité et le cadre NIS2. Pour les enjeux de données personnelles, la CNIL demeure l’interlocuteur de référence.

La checklist pour évaluer ou changer d’hébergement WordPress

Cette checklist convient à une PME, un e-commerce, une agence ou un prestataire qui veut évaluer son offre actuelle avant un renouvellement ou une migration. Elle ne permet pas de conclure seule à l’assujettissement à NIS2, mais elle aide à collecter les éléments utiles.

1. Cartographier le site et ses dépendances

Identifiez les sites WordPress, sous-domaines, environnements de préproduction et bases de données.
Listez les extensions critiques : paiement, formulaires, espace membre, connecteurs ERP ou CRM.
Recensez les services externes : DNS, CDN, messagerie transactionnelle, sauvegarde, passerelle de paiement.
Déterminez le coût opérationnel d’une indisponibilité de quelques heures ou d’une perte de données.

2. Contrôler la sécurité réellement incluse

Le compte client et les accès techniques proposent-ils une authentification multifacteur ?
L’hébergeur décrit-il son dispositif de protection DDoS et son périmètre ?
Les comptes sont-ils isolés sur l’offre mutualisée ?
Les versions de PHP, MySQL ou MariaDB peuvent-elles être maintenues à jour ?
Disposez-vous de journaux exploitables en cas d’incident ?

La compatibilité technique mérite également d’être vérifiée. Par exemple, le maintien d’une version de PHP encore prise en charge est une condition élémentaire de sécurité. Notre article sur la préparation de l’hébergement WordPress à PHP 8.5 illustre les questions à poser sur le cycle de mise à jour, sans réduire le sujet à un simple numéro de version.

3. Auditer les sauvegardes par un test de restauration

Vérifiez la fréquence, la rétention et le lieu de stockage des sauvegardes.
Exportez périodiquement une copie indépendante de la base de données et des fichiers.
Testez la restauration sur un environnement distinct de la production.
Mesurez le délai nécessaire pour retrouver un site utilisable.
Documentez les accès nécessaires si l’administrateur habituel est indisponible.

4. Lire les clauses d’incident et de réversibilité

Connaissez-vous le canal à utiliser pour joindre l’hébergeur lors d’une urgence ?
Le fournisseur notifie-t-il les incidents affectant vos données ou votre disponibilité ?
Savez-vous récupérer vos fichiers, bases, certificats et zones DNS en cas de départ ?
Les responsabilités entre votre équipe, votre agence et l’hébergeur sont-elles écrites ?

5. Préparer une migration sans attendre la crise

Changer d’hébergeur après un incident est rarement la meilleure situation pour prendre une décision. Préparez un inventaire, vérifiez la portabilité du nom de domaine, conservez des sauvegardes indépendantes et testez votre procédure de bascule. Notre guide pour migrer WordPress sans interruption de service détaille les précautions à prendre pour limiter les risques pendant cette opération.

Conclusion : faire de l’hébergement un élément de votre résilience

NIS2 rappelle une réalité souvent négligée : un hébergeur WordPress n’est pas un simple fournisseur de capacité serveur. Il participe à la disponibilité, à l’intégrité et à la récupération de votre activité numérique. Les organisations directement concernées par la directive devront démontrer une gestion des risques adaptée ; les autres ont tout intérêt à adopter les mêmes réflexes proportionnés à leurs enjeux.

Commencez par demander des réponses écrites sur les sauvegardes, la protection DDoS, les délais d’alerte, la restauration et la réversibilité. Si votre prestataire ne peut pas expliquer clairement son périmètre de responsabilité, il est probablement temps de comparer son offre avec des solutions plus transparentes et mieux adaptées à votre site WordPress.