NIS2 et PME : comment les grands comptes évaluent le risque de leurs fournisseurs

Un contrat fournisseur arrive au renouvellement. Jusqu’ici, les échanges portaient surtout sur les niveaux de service, l’assurance, le RGPD ou les conditions tarifaires. Cette fois, une annexe sécurité accompagne le dossier. Elle demande comment sont protégés les comptes administrateurs, sous quel délai le client sera informé d’un incident, comment sont traitées les vulnérabilités, quels sous-traitants interviennent dans le service et quelles preuves peuvent être fournies sur les sauvegardes ou les audits.

La PME vérifie son périmètre réglementaire et conclut qu’elle n’est pas directement assujettie à NIS2. Pourtant, le questionnaire reste à remplir.

C’est là que le sujet devient intéressant : pour une PME, NIS2 peut produire des effets très concrets sans qu’elle soit elle-même directement soumise à la directive. En effet, NIS2 demande aux organisations concernées de mieux maîtriser le risque créé par leur chaîne d’approvisionnement. Dès lors, la question n’est plus seulement de savoir si le fournisseur possède un firewall, un EDR ou une sauvegarde. Le donneur d’ordre doit d’abord comprendre ce que cette relation lui fait réellement prendre comme risque.

Autrement dit, il doit regarder ce qu’il ouvre au fournisseur, ce qu’il lui confie, ce dont il dépend chez lui et ce qui pourrait se passer si ce fournisseur était compromis.

Les produits de cybersécurité viennent après. Ils sont une réponse à un risque identifié dans la relation, pas le point de départ de l’évaluation.

NIS2 ne transforme pas le fournisseur en liste de cases à cocher. Elle transforme la relation fournisseur en surface de risque à évaluer.

NIS2 ne part pas des outils, elle part de la relation de confiance

L’article 21 de la directive NIS2 impose aux entités concernées de mettre en place des mesures de gestion des risques en matière de cybersécurité. Parmi ces mesures figure explicitement la sécurité de la chaîne d’approvisionnement, y compris les relations entre l’entité et ses fournisseurs ou prestataires de services directs.

Ce point change profondément la manière de lire le risque fournisseur.

En effet, un fournisseur n’est pas critique parce qu’il est petit, parce qu’il n’est pas certifié ou parce qu’il utilise telle ou telle technologie. Il devient critique lorsque la relation qu’on lui a accordée ouvre un chemin vers un actif important, une donnée sensible ou un service dont l’entreprise ne peut pas se passer.

Prenons deux PME de vingt salariés. La première livre du matériel. Elle n’a aucun accès au SI de son client, ne traite aucune donnée et n’administre aucun service. Sa propre cybersécurité reste importante, mais le risque qu’elle introduit directement chez son client est limité.

La seconde, en revanche, maintient les firewalls du groupe. Elle dispose de comptes privilégiés, utilise un outil de télémaintenance et peut intervenir sur plusieurs sites. Elle n’est pas plus grande que la première. Toutefois, si elle est compromise, la relation commerciale peut devenir un chemin technique vers le système d’information du donneur d’ordre.

La différence entre ces deux fournisseurs n’est donc pas leur taille ni le nombre d’outils de sécurité qu’ils possèdent. C’est ce que la relation permet de faire, de voir ou d’interrompre.

C’est précisément ce que l’article 21, paragraphe 3, demande de regarder lorsqu’il évoque les vulnérabilités propres à chaque fournisseur, la qualité globale de ses produits et services et ses pratiques de cybersécurité. La logique est donc bien celle d’une évaluation du risque fournisseur.

Cette lecture rejoint d’ailleurs le principe d’une architecture de cybersécurité cohérente. On ne choisit pas un contrôle parce qu’il figure dans une liste. On le choisit parce qu’un scénario de risque identifié justifie son existence.

Avant le questionnaire, il faut comprendre ce que le fournisseur peut réellement affecter

Une fois ce principe posé, le raisonnement devient beaucoup plus simple. Avant de demander des preuves ou des certifications, il faut reconstruire la relation.

L’accès détermine jusqu’où le fournisseur peut aller

En premier lieu, il faut regarder ce que le fournisseur peut atteindre techniquement. Possède-t-il un compte utilisateur, un compte administrateur, un VPN, une API, un certificat, un accès de télémaintenance ou un poste utilisé pour intervenir chez le client ?

Cette question paraît triviale. Pourtant, elle change complètement la criticité d’un prestataire. Un fournisseur sans accès technique peut être important commercialement sans constituer une voie d’entrée directe vers le SI. À l’inverse, un petit prestataire qui dispose d’un compte administrateur permanent possède déjà une partie de la confiance technique du client.

Plus l’accès est puissant, persistant et difficile à surveiller, plus la relation mérite d’être traitée comme un élément de l’architecture de sécurité.

Les données indiquent ce que le fournisseur peut exposer

Il faut ensuite examiner ce que le fournisseur détient ou peut consulter. Héberge-t-il des données métier, des journaux, des sauvegardes, des secrets d’authentification ou des configurations techniques ?

En effet, une compromission ne produit pas toujours un rebond vers le réseau du client. Elle peut aussi provoquer une fuite de données ou révéler suffisamment d’informations pour préparer une attaque plus ciblée.

Ainsi, un prestataire qui n’a aucun accès au réseau peut malgré tout devenir critique s’il conserve des données sensibles ou des secrets techniques importants.

La dépendance mesure ce que le client perd si le fournisseur tombe

La troisième dimension est opérationnelle. Que se passe-t-il si le fournisseur devient indisponible pendant plusieurs heures ou plusieurs jours ?

Une application cesse-t-elle de fonctionner ? Une agence perd-elle sa connectivité ? La téléphonie est-elle interrompue ? L’entreprise peut-elle continuer en mode dégradé ou le service s’arrête-t-il immédiatement ?

Un fournisseur devient critique dès lors que sa défaillance entraîne une rupture que le client ne sait pas absorber.

Cette question est essentielle, car elle fait entrer la continuité d’activité dans l’évaluation. Un prestataire peut être parfaitement sécurisé et rester un point de fragilité si aucune alternative n’existe lorsqu’il devient indisponible.

La propagation révèle ce qui se passe si le fournisseur est lui-même compromis

Enfin, il faut poser la question la plus inconfortable : si le fournisseur est attaqué, l’attaquant peut-il profiter de la relation de confiance existante pour atteindre le client ?

C’est ici que la chaîne d’approvisionnement devient un sujet de cybersécurité à part entière. Un accès distant légitime, une API, un compte privilégié ou un outil d’administration peuvent devenir des vecteurs lorsqu’ils sont détournés.

Le risque fournisseur se lit donc à travers quatre dimensions : l’accès, les données, la dépendance et la capacité de propagation.

Relation avec le fournisseur	Accès	Données	Dépendance	Risque potentiel pour le client
Livraison de matériel sans administration	Aucun	Aucune	Faible	Limité
Éditeur SaaS métier	Applicatif	Données métier	Forte si l’application est critique	Élevé
Prestataire informatique avec comptes privilégiés	Administration	Potentiellement larges	Variable	Très élevé
Hébergeur d’une application critique	Infrastructure	Données et sauvegardes	Très forte	Très élevé
Agence ou conseil sans accès technique	Messagerie et documents	Limitée	Faible	Intermédiaire

Ce tableau permet d’éviter deux erreurs fréquentes. La première consiste à envoyer le même questionnaire à tous les fournisseurs. La seconde consiste à juger leur maturité cyber sans regarder ce que le client leur a réellement confié.

Une bonne évaluation ne cherche pas à savoir si le fournisseur est “bon en cybersécurité” dans l’absolu. Elle cherche à savoir s’il maîtrise le risque précis créé par la relation.

C’est également pour cette raison qu’un hébergeur, un mainteneur réseau et un éditeur SaaS ne devraient pas recevoir exactement les mêmes exigences. Le premier devra surtout démontrer sa capacité de continuité et de restauration. Le second devra expliquer ses accès privilégiés et leur traçabilité. Le troisième devra documenter la gestion des vulnérabilités, l’accès aux données et la façon dont il informe ses clients en cas d’incident.

À partir de là, le questionnaire cesse d’être un formulaire générique. Il devient la traduction d’un risque déjà identifié.

Le contrat transforme ensuite ce risque en engagements

Une fois la relation comprise, le sujet quitte progressivement le registre de l’analyse pour entrer dans celui du contrat.

La directive NIS2 pose le principe général. Le règlement d’exécution européen 2024/2690, applicable à certaines catégories d’entités numériques, montre cependant à quoi ce principe peut ressembler lorsqu’il devient opérationnel.

Il faut être précis sur sa portée. Ce règlement ne s’applique pas à toutes les organisations couvertes par NIS2. Il concerne notamment les fournisseurs cloud, datacenters, services gérés, services de sécurité gérés, DNS, CDN, places de marché, moteurs de recherche, réseaux sociaux et certains prestataires de confiance. L’ENISA le rappelle dans sa guidance technique.

Toutefois, son intérêt dépasse son seul périmètre juridique, car il donne une forme très concrète à la notion de sécurité de la chaîne d’approvisionnement.

Ainsi, les contrats peuvent encadrer notamment :

• les exigences de cybersécurité applicables au fournisseur ;
• les compétences et la sensibilisation des personnes qui interviennent sur le service ;
• les conditions de notification d’un incident ;
• les audits ou l’accès à des rapports d’audit ;
• la gestion des vulnérabilités ;
• les règles applicables aux sous-traitants ;
• les obligations de restitution, de suppression ou de révocation en fin de contrat.

Cette liste n’est pas intéressante parce qu’elle ajouterait de nouvelles cases à cocher. Elle montre au contraire comment un risque identifié dans la relation devient une obligation vérifiable entre deux entreprises.

Par exemple, si un prestataire dispose d’un accès privilégié, le contrat peut demander que cet accès soit nominatif, protégé et rapidement révocable. Si le fournisseur héberge une donnée critique, le donneur d’ordre peut demander des garanties de restauration. Si un incident chez le prestataire peut atteindre le client, la notification devient un sujet contractuel.

Le contrat n’est donc pas le point de départ de la sécurité fournisseur. Il est l’endroit où l’analyse du risque se transforme en responsabilités, en délais et en preuves attendues.

Le fournisseur doit pouvoir raconter ce qui se passe avant, pendant et après un incident

À ce stade, le débat sur la présence d’un EDR, d’un firewall ou d’une solution de sauvegarde devient presque secondaire. La vraie question est de savoir si le fournisseur est capable de raconter, sans zone grise, ce qu’il ferait si la relation avec son client devenait le vecteur d’un incident.

Cette capacité peut se résumer en cinq verbes.

1. Prévenir : réduire la probabilité qu’un accès, un compte, un poste ou une donnée utilisés pour le service soient compromis.
2. Détecter : repérer suffisamment tôt qu’un comportement anormal affecte l’environnement du fournisseur ou la relation avec le client.
3. Contenir : pouvoir isoler un poste, révoquer un compte ou suspendre un accès avant que l’incident ne se propage.
4. Informer : savoir quels clients peuvent être touchés, qui les contacte et ce qui doit leur être communiqué.
5. Restaurer : remettre le service et les données dans un état fiable après l’incident.

Ce cadre évite de transformer l’article en catalogue de produits. En effet, un outil n’a de valeur que par la capacité opérationnelle qu’il apporte à l’un de ces cinq moments.

Ainsi, le MFA répond à un problème de prévention. Un EDR apporte de la détection et parfois du confinement. Un MDR ajoute une capacité humaine de qualification et de réaction. La sauvegarde répond à la restauration. Mais aucun de ces outils, pris isolément, ne répond à toute la question posée par la relation fournisseur.

Un fournisseur mature n’est pas celui qui peut réciter son catalogue de sécurité. C’est celui qui sait expliquer comment il protège la relation avant l’incident, comment il réagit pendant et comment il rétablit la confiance après.

C’est ici que les preuves comptent davantage que les déclarations

Cette logique change aussi complètement la manière de remplir un questionnaire fournisseur.

Une réponse comme « MFA activé » paraît rassurante, mais elle ne dit pas quels comptes sont concernés. « Tous nos postes sont protégés par EDR » ne dit pas qui surveille les alertes. « Nous sauvegardons tous les jours » ne dit pas quand une restauration a été réellement testée.

En d’autres termes, une affirmation de sécurité décrit une intention ; une preuve permet au client de mesurer si cette intention existe réellement dans l’exploitation quotidienne.

Le bon dossier fournisseur n’est donc pas un classeur de politiques générales. Il rassemble des éléments capables de démontrer les points critiques de la relation.

Sujet	Réponse déclarative	Preuve plus utile
MFA	« MFA activé »	Périmètre des comptes protégés et exceptions connues
Comptes privilégiés	« Accès sécurisés »	Comptes nominatifs, rôles, procédure de révocation
EDR	« Tous les postes sont protégés »	Taux de couverture et dernier état de supervision
Vulnérabilités	« Correctifs réguliers »	Processus de qualification et exemple de correction suivie
Sauvegardes	« Sauvegarde quotidienne »	Dernier test de restauration et objectifs RPO/RTO
Incident	« Procédure existante »	Contacts d’escalade, rôles et critères de notification
Sous-traitants	« Prestataires de confiance »	Liste des tiers qui participent réellement au service
Fin de contrat	« Données supprimées »	Processus de révocation, restitution et suppression

Cette différence est importante, car elle révèle immédiatement les zones où la sécurité n’est encore qu’une hypothèse.

Ainsi, une protection EDR démontre qu’un outil de détection existe. Toutefois, si personne ne sait qui qualifie l’alerte ni qui peut isoler le poste, la capacité de réponse reste incomplète. Un service MDR peut alors combler un manque opérationnel lorsqu’une PME ne dispose pas des ressources nécessaires pour traiter les événements.

De la même manière, une sauvegarde ne devient une preuve de résilience que lorsqu’une restauration a été exécutée dans des conditions suffisamment proches du réel.

Le niveau de confiance du client vient donc moins de la quantité de documents fournis que de la cohérence entre ce que le fournisseur promet, ce qu’il fait et ce qu’il peut démontrer.

L’incident révèle si la relation avait réellement été comprise

C’est lorsque l’incident survient que toute cette logique cesse d’être théorique.

Imaginons un prestataire informatique qui administre plusieurs clients à distance. Un matin, son propre compte d’administration est compromis. Aucune attaque n’est encore visible chez ses clients.

S’il connaît précisément ses relations, il peut immédiatement répondre à trois questions. Quels clients ce compte permettait-il d’atteindre ? Quels accès doivent être suspendus ? Qui doit être prévenu ?

S’il ne le sait pas, l’équipe commence alors à reconstruire dans l’urgence une cartographie qui aurait dû exister avant l’incident.

En effet, le même identifiant peut ouvrir plusieurs environnements. Le même outil de télémaintenance peut desservir plusieurs sites. Le même poste d’administration peut contenir des secrets ou des configurations concernant plusieurs entreprises. À cet instant, la cartographie du risque fournisseur devient directement un outil de réponse à incident.

C’est aussi pourquoi le règlement 2024/2690 prévoit, pour les entités auxquelles il s’applique, la possibilité d’encadrer contractuellement la notification des incidents qui présentent un risque pour la sécurité des systèmes du client.

Le fournisseur doit donc être capable de détecter son propre incident, mais également de comprendre à qui cet incident peut se propager par les relations de confiance qu’il détient.

Cette logique rejoint notre guide consacré au confinement d’une cyberattaque. Là encore, le problème n’est pas de couper le plus possible, mais d’identifier rapidement la frontière entre ce qui reste digne de confiance et ce qui ne l’est plus.

Puis apparaît le fournisseur du fournisseur

Même une relation bien cartographiée peut pourtant cacher une autre dépendance.

Le prestataire informatique utilise un outil de télémaintenance. L’éditeur SaaS s’appuie sur une plateforme cloud. L’hébergeur dépend d’un opérateur. La société de sécurité sous-traite une partie de son SOC. Le fournisseur visible n’est donc pas toujours le dernier maillon de la chaîne.

C’est précisément à ce moment que le raisonnement NIS2 prend toute sa profondeur. Le risque ne s’arrête pas à l’entreprise avec laquelle le contrat est signé. Il suit les dépendances nécessaires pour rendre réellement le service.

Pour une PME, la question pratique devient donc : quels tiers participent effectivement à la prestation vendue au client ?

Cela peut inclure un hébergeur, un opérateur, un outil d’authentification, une solution de sauvegarde, une plateforme de télémaintenance, un éditeur ou un prestataire de support. Or certains de ces acteurs possèdent eux-mêmes des accès, des données ou un rôle critique dans la continuité du service.

La cartographie doit donc aller juste assez loin pour comprendre où se trouvent les dépendances qui pourraient affecter le client. Il ne s’agit pas d’inventorier l’intégralité de l’écosystème numérique mondial, mais d’identifier les maillons dont la compromission ou l’indisponibilité aurait un effet réel sur la prestation.

C’est aussi un sujet de cyber-résilience. Un fournisseur devient vraiment critique lorsque son indisponibilité ou sa compromission ne peut pas être absorbée sans dégrader fortement le service rendu.

La dernière étape consiste à ne promettre dans le contrat que ce qu’on sait tenir

Une fois les accès, les données, les dépendances et les capacités de réponse connus, le contrat peut être relu avec beaucoup plus de lucidité.

Une obligation de notification « immédiate » semble rassurante. Cependant, elle devient irréaliste si personne n’a défini les incidents concernés, le décideur ou le contact côté client. De même, un engagement de correction des vulnérabilités n’a de valeur que si l’entreprise dispose d’une méthode pour les qualifier et suivre leur remédiation.

Enfin, un droit d’audit doit rester compatible avec la confidentialité des autres clients et avec le périmètre réel de la prestation. Quant aux obligations de suppression en fin de contrat, elles doivent tenir compte des sauvegardes et des politiques de rétention.

La bonne réponse n’est donc ni de refuser toutes les exigences, ni de les accepter pour rassurer le client. Elle consiste à faire coïncider l’engagement contractuel avec la capacité opérationnelle réelle.

La mauvaise réponse à NIS2 consiste à promettre plus que ce que l’organisation sait faire. La bonne consiste à réduire l’écart entre le contrat et la réalité technique.

Pour une PME, le meilleur point de départ est la relation client la plus sensible

Une PME n’a pas besoin de lancer un grand programme de conformité pour tirer parti de cette logique. Elle peut commencer beaucoup plus simplement.

En premier lieu, il faut identifier les clients pour lesquels la relation technique est réellement sensible. Ensuite, pour chacun d’eux, il faut documenter les accès, les données, les dépendances et les sous-traitants impliqués. Enfin, il faut vérifier que l’entreprise sait prévenir, détecter, contenir, informer et restaurer dans le scénario le plus crédible.

Quelques questions suffisent alors à faire apparaître les écarts majeurs :

• les comptes utilisés pour administrer ou accéder au service sont-ils nominatifs, protégés par MFA et révocables rapidement ?
• les anciens accès sont-ils supprimés de manière fiable ?
• les postes et serveurs utilisés pour fournir le service sont-ils correctement protégés et supervisés ?
• les vulnérabilités critiques sont-elles qualifiées puis suivies jusqu’à leur correction ?
• les sauvegardes nécessaires au service ont-elles été restaurées récemment ?
• un incident interne peut-il être relié rapidement aux clients potentiellement concernés ?
• les sous-traitants qui participent réellement à la prestation sont-ils connus ?
• la fin du contrat déclenche-t-elle effectivement la suppression des accès, secrets et données qui n’ont plus à être conservés ?

Cette liste n’est pas une checklist NIS2 officielle. Elle sert à vérifier si la relation client est réellement maîtrisée.

Par conséquent, si un accès critique n’est pas protégé par MFA, si personne ne traite les alertes ou si une restauration n’a jamais été testée, la priorité apparaît naturellement. Une offre de cybersécurité opérée pour PME trouve alors sa place comme réponse à un écart identifié, et non comme un catalogue de produits à déployer au nom de NIS2.

NIS2 peut finalement transformer la cybersécurité en argument commercial

Revenons au contrat du début.

Deux fournisseurs proposent le même service. Le premier renvoie un questionnaire rempli de réponses générales. Il possède les outils habituels, mais peine à expliquer qui traite les alertes, quels accès sont révocables ou quel sous-traitant intervient réellement dans la prestation.

Le second n’est pas nécessairement plus grand ni certifié. Toutefois, il sait décrire ses accès, montrer ses dépendances, présenter ses contacts d’escalade, donner la date de son dernier test de restauration et expliquer comment il informerait le client si un incident survenait.

Pour le donneur d’ordre, la différence est considérable.

Le second fournisseur est plus facile à évaluer parce que la relation de confiance qu’il propose est lisible. Les chemins de risque sont connus, les responsabilités sont identifiées et les preuves existent.

C’est probablement l’effet le plus intéressant de NIS2 pour les PME qui travaillent avec de grands comptes. La directive ne crée pas les dépendances entre entreprises. Elles existaient déjà. Elle oblige surtout à les rendre visibles, puis à démontrer qu’elles sont maîtrisées.

Et c’est précisément à cet endroit que la contrainte réglementaire peut se retourner en avantage commercial : une PME capable d’expliquer clairement pourquoi elle constitue un maillon fiable devient plus simple à intégrer dans la chaîne de confiance de ses clients.

Questions fréquentes sur NIS2 et les PME fournisseurs

Une PME fournisseur d’un grand compte soumis à NIS2 devient-elle elle-même soumise à NIS2 ?

Non, pas automatiquement. L’assujettissement direct dépend du secteur, de l’activité, de la taille de l’entité et des autres critères prévus par le cadre NIS2. En revanche, le client peut imposer à son fournisseur des exigences de cybersécurité dans le cadre de sa propre gestion du risque fournisseur.

Quelles exigences NIS2 un grand compte peut-il faire descendre vers ses fournisseurs ?

Les exigences découlent du risque créé par la relation avec le fournisseur. Elles peuvent porter sur les accès, l’authentification, la notification d’incident, les vulnérabilités, la sous-traitance, les audits, la continuité, les sauvegardes ou la fin de contrat.

NIS2 impose-t-elle une checklist de produits de cybersécurité aux fournisseurs ?

Non. NIS2 impose une logique de gestion du risque, pas un catalogue universel de produits. Les outils techniques doivent être choisis en fonction des accès, des données, des dépendances et des scénarios d’incident associés à la prestation.

Que doit préparer une PME avant de répondre à un questionnaire NIS2 fournisseur ?

La PME doit d’abord qualifier la relation avec le client avant de chercher à remplir le questionnaire. Elle doit identifier les accès techniques, les données, les dépendances, les sous-traitants et les scénarios dans lesquels son propre incident pourrait affecter le client. Les preuves viennent ensuite.

Une certification ISO 27001 est-elle obligatoire pour un fournisseur d’une entité NIS2 ?

Non. NIS2 n’impose pas automatiquement ISO 27001 à tous les fournisseurs. Un donneur d’ordre peut néanmoins demander une certification, un rapport d’audit ou d’autres éléments de preuve lorsqu’ils sont pertinents pour apprécier le risque associé à la prestation.

Pourquoi un petit prestataire peut-il être considéré comme critique par un grand compte ?

La criticité dépend moins de la taille du fournisseur que de ce que la relation lui permet d’atteindre ou d’interrompre. Un petit prestataire qui possède un accès administrateur, traite des données sensibles ou intervient sur un service difficile à remplacer peut représenter un risque supérieur à celui d’un fournisseur beaucoup plus important sans accès au système d’information.

Sources et références

• Directive (UE) 2022/2555, article 21, mesures de gestion des risques et sécurité de la chaîne d’approvisionnement
• Règlement d’exécution (UE) 2024/2690, notamment section 5 sur la sécurité de la chaîne d’approvisionnement
• ENISA, NIS2 Technical Implementation Guidance
• ANSSI, comment savoir si la directive NIS2 s’applique à mon entité ?
• ANSSI, quelles sont les exigences de cybersécurité prévues par NIS2 ?
• IT for Business, juillet-août 2026, « La cybersécurité bute sur son dernier kilomètre », pages 15-16.