NIS2 et votre site : ce que vos clients vous demanderont en tant que fournisseur

L'e-mail vient d'un client avec qui vous travaillez depuis des années. En pièce jointe, un questionnaire de sécurité pour fournisseurs : des dizaines de questions sur le chiffrement, les correctifs, les sauvegardes et les incidents, à rendre avant la fin du mois. Vous dirigez une petite structure. Vous n'êtes ni une banque, ni un hôpital, ni une compagnie d'électricité. Alors pourquoi cet intérêt soudain ?

Parce que votre client est très probablement soumis à NIS2, la directive européenne sur la cybersécurité, qui le rend responsable de la sécurité de sa chaîne d'approvisionnement. Elle ne vous impose aucune obligation directe. Le questionnaire est le moyen par lequel votre client remplit la sienne et la met par écrit.

Cet article explique ce que dit le texte, lesquelles de ces questions votre site public et votre domaine de messagerie traitent à votre place, et comment réunir les preuves avant qu'on vous les demande. Ce n'est pas un conseil juridique. Si vous ne savez pas si votre propre entreprise relève de NIS2, consultez d'abord les indications de votre autorité nationale.

D'où viennent les questions

La directive (UE) 2022/2555, dite NIS2, énumère à l'article 21 les mesures de gestion des risques de cybersécurité que les entités essentielles et importantes doivent prendre. Le point d) du paragraphe 2 dispose : « la sécurité de la chaîne d'approvisionnement, y compris les aspects liés à la sécurité concernant les relations entre chaque entité et ses fournisseurs ou prestataires de services directs ».

Le paragraphe 3 va plus loin. En choisissant ces mesures, les entités doivent tenir compte des vulnérabilités propres à chaque fournisseur et prestataire de services direct, ainsi que de la qualité globale de leurs produits et de leurs pratiques en matière de cybersécurité.

Votre client ne peut pas juger vos pratiques de cybersécurité sans vous poser la question. Il répercute donc une partie de l'obligation le long de la chaîne, par des questionnaires, des clauses contractuelles et des demandes de preuves. Si vous fournissez des logiciels, de l'hébergement ou de l'assistance informatique, ou si vous avez accès à ses systèmes, attendez-vous à une longue liste. Si vous vendez quelque chose sans rapport, la liste peut être plus courte, mais elle peut quand même arriver, car il est plus simple pour un service achats d'envoyer le même formulaire à tous les fournisseurs.

Il y a aussi une raison très ordinaire pour laquelle votre domaine compte. Vous faites partie des adresses d'où votre client reçoit des factures. Si quelqu'un peut envoyer un e-mail qui ressemble au vôtre, il peut envoyer une fausse facture avec d'autres coordonnées bancaires. Pour votre client, c'est un risque de chaîne d'approvisionnement, même si vous ne touchez jamais à ses serveurs.

Pourquoi maintenant

Une directive ne lie pas les entreprises par elle-même. Chaque pays de l'UE l'inscrit dans son droit national, à son propre rythme. La Pologne, par exemple, l'a fait par une loi du 23 janvier 2026 modifiant sa loi sur le système national de cybersécurité (Dz.U. 2026 poz. 252), en vigueur depuis le 3 avril 2026. L'article 8 modifié de cette loi range la sécurité et la continuité de la chaîne d'approvisionnement des TIC parmi les mesures qu'une entreprise concernée doit mettre en place.

Le ministère polonais du Numérique accorde aux entreprises (en polonais) qui remplissaient déjà les critères à l'entrée en vigueur de la loi jusqu'au 3 octobre 2026 pour s'enregistrer et jusqu'au 3 avril 2027 pour mettre en œuvre leurs obligations. D'autres pays ont leurs propres dates. Où que se trouve votre client, le schéma est le même : à l'approche de son échéance, ses équipes sécurité et achats passent la liste des fournisseurs en revue.

Les questions que traitent votre site et votre messagerie

Une partie de chaque questionnaire porte sur des points que n'importe qui peut vérifier de l'extérieur en quelques minutes. Votre client ou son auditeur peut le faire sans vous demander : mieux vaut que vous connaissiez les réponses avant lui.

Chiffrement en transit. Généralement formulé « Les données sont-elles chiffrées en transit ? » ou « Quelles versions de TLS prenez-vous en charge ? ». Une bonne réponse : le site fonctionne uniquement en HTTPS, http:// redirige vers https://, le certificat est valide et les anciennes versions du protocole, TLS 1.0 et 1.1, sont désactivées. Le vérificateur de certificat SSL gratuit (en anglais) montre tout cela.

Authentification des e-mails. « Utilisez-vous SPF, DKIM et DMARC ? » Cette question revient souvent, car elle concerne l'usurpation de l'identité de votre entreprise. Une bonne réponse : les trois dans votre DNS, avec DMARC à p=quarantine ou p=reject. Un enregistrement p=none se contente d'observer et n'arrête rien. Passez votre domaine dans la vérification SPF, DKIM et DMARC (en anglais) et, si ces sigles sont nouveaux pour vous, cet article les explique.

Correctifs. « Comment gérez-vous les mises à jour de sécurité ? » « En combien de temps appliquez-vous les correctifs critiques ? » Votre site en dit plus que vous ne le pensez. WordPress et ses extensions affichent souvent leurs numéros de version dans le code de la page, et un scanner peut les confronter aux vulnérabilités connues. Si votre site fait tourner une extension avec une faille publiée, « nous appliquons rapidement les correctifs » ne résistera pas au premier contrôle.

Fichiers laissés en accès public. Les questions sur la protection des données et les sauvegardes ont aussi un versant extérieur. Y a-t-il un backup.zip, un export de base de données ou un fichier de configuration contenant des mots de passe à un endroit où tout le monde peut les télécharger ? Les robots essaient ces adresses sur chaque site qu'ils atteignent. Plus de détails dans la sauvegarde oubliée sur votre serveur.

En-têtes de sécurité. Rarement nommés, mais ils sont derrière les questions sur le durcissement des applications web. Un en-tête HSTS ou Content Security Policy manquant ne veut pas dire que le site est grand ouvert. Il montre en revanche si quelqu'un s'en occupe. La vérification des en-têtes de sécurité (en anglais) liste ce qui est présent et ce qui manque.

Signalement d'une vulnérabilité. Certains questionnaires demandent comment un tiers peut vous signaler un problème de sécurité. La réponse la plus simple est une adresse de contact sécurité publiée dans un fichier /.well-known/security.txt sur votre site.

Les questions auxquelles votre site ne peut pas répondre

Le reste est invisible de l'extérieur. Qui a un accès administrateur à votre site, à votre messagerie et à votre domaine, et s'il utilise une connexion à deux facteurs. Où sont vos sauvegardes et si quelqu'un en a déjà restauré une. Ce que vous faites après un incident et en combien de temps vous prévenez le client. Si votre personnel repérerait un e-mail d'hameçonnage.

Aucun scanner n'y aide. Des réponses courtes et vraies, avec un document à l'appui, si.

Ne cochez pas « oui » partout. Les réponses à un questionnaire finissent souvent dans le contrat sous forme de déclarations, et une réponse fausse est pire qu'un « en cours, terminé en décembre » honnête. Votre client a besoin de fournisseurs dont il peut gérer le risque. Il n'attend pas de fournisseurs sans aucun risque.

Préparer les preuves

Avant de répondre, créez un dossier, avec la date dans chaque nom de fichier.

1. Un rapport sur votre site et votre domaine. Il montre l'état du certificat, des enregistrements de messagerie, des en-têtes et des fichiers exposés à une date donnée. Si quelque chose a dû être corrigé, ajoutez un second rapport après la correction. Une paire avant et après en dit plus au client qu'un résultat isolé.
2. Votre résultat SPF, DKIM et DMARC. Une capture d'écran datée suffit.
3. Une page sur les mises à jour. Qui met à jour le site et vos autres systèmes, à quelle fréquence, et en combien de temps les correctifs critiques sont appliqués.
4. Une page sur les sauvegardes. Où elles sont conservées, à quelle fréquence elles tournent, et quand quelqu'un en a restauré une pour la dernière fois.
5. Une liste des accès. Qui détient des comptes administrateur pour le site, la messagerie, le registraire de domaine et l'hébergement, et si chacun de ces comptes a une connexion à deux facteurs.
6. Un contact incident. Nom, e-mail et numéro de téléphone de la personne responsable, et en combien de temps vous prévenez le client d'un incident qui le touche.

Rédigez les points 3 à 6 avec la personne qui s'occupe de votre site et de votre informatique. Si vous ne savez pas comment engager cette conversation, les cinq questions à la fin de cet article sont un bon début.

Répétez le contrôle du site chaque trimestre et après tout changement important. Votre client reviendra avec un autre questionnaire, et un rapport vieux de deux ans ne prouve rien.

Que faire cette semaine

Si le questionnaire est déjà sur votre bureau :

1. Vérifiez votre site et votre domaine de l'extérieur. Cela prend quelques minutes, et le résultat peut modifier certaines de vos réponses.
2. Corrigez ce qui est rapide : faire passer DMARC de p=none à quarantine, retirer les fichiers de sauvegarde du dossier web, forcer HTTPS, désactiver les anciennes versions de TLS. Avec SPF et DKIM déjà fonctionnels, ce sont en général des heures de travail, pas des semaines.
3. Décrivez le reste honnêtement : ce qui fonctionne, ce qui est en cours et pour quand ce sera fait.

Vous pouvez faire la première étape avec ShieldWave. Saisissez votre adresse : en 90 secondes environ, il vérifie de l'extérieur le certificat, les en-têtes, SPF, DKIM et DMARC, les versions de logiciels et les fichiers exposés, puis explique le résultat en langage clair avec un descriptif prêt pour votre développeur. Le premier contrôle est gratuit, et une analyse complète ponctuelle avec le rapport complet pour votre dossier coûte 9 $.