NIS2 sous-traitants : une TPE de moins de 50 salariés n’est généralement pas concernée directement par la directive, mais elle peut l’être commercialement si elle fournit une entreprise régulée. Concrètement, attendez-vous à des questionnaires sécurité, des clauses contractuelles et des preuves simples : sauvegardes, gestion des accès, mises à jour, plan de réponse aux incidents. Le vrai sujet, c’est l’effet cascade dans la chaîne de fournisseurs.
NIS2 sous-traitants : pourquoi l’effet cascade existe
La directive européenne NIS2, adoptée le 14 décembre 2022 sous le nom Directive (UE) 2022/2555, remplace l’ancienne directive NIS de 2016. Elle est entrée en vigueur le 16 janvier 2023 et les États membres devaient la transposer dans leur droit national au plus tard le 17 octobre 2024.
Son objectif est simple à comprendre : relever le niveau de cybersécurité des organisations jugées essentielles ou importantes pour l’économie et la société. Cela couvre notamment certains secteurs numériques, industriels, sanitaires, énergétiques, financiers ou de transport, selon des critères de taille et d’activité.
Le point qui change tout pour les fournisseurs se trouve dans l’article 21. Les entités régulées doivent gérer la sécurité de leur chaîne d’approvisionnement, c’est-à -dire la sécurité liée à leurs prestataires directs, leurs éditeurs, leurs hébergeurs, leurs infogéreurs, leurs agences web ou leurs fournisseurs de services numériques.
Autrement dit, même si votre entreprise n’entre pas dans le périmètre direct de NIS2, votre client peut devoir vérifier que vous ne devenez pas son point faible. C’est moins une obligation réglementaire directe qu’une condition de confiance et parfois de marché.
Les TPE sont-elles concernées par NIS2 ?
En France, d’après les informations publiées par l’ANSSI et MesServicesCyber en 2026, les « entités importantes » incluent notamment des organisations qui emploient au moins 50 personnes ou dépassent 10 millions d’euros de chiffre d’affaires et de bilan annuel, lorsqu’elles relèvent des secteurs visés. Une TPE de 12 personnes qui développe un site, une API ou une application pour un client concerné n’est donc pas automatiquement soumise à NIS2.
Mais cette frontière est trompeuse. Le Centre national de cybersécurité irlandais, dans sa FAQ NIS2, explique clairement qu’une organisation peut être affectée indirectement lorsqu’elle appartient à la chaîne de fournisseurs d’une ou plusieurs entités NIS2. Ce n’est pas une transposition magique de la directive vers tous les petits prestataires. C’est une conséquence de la gestion du risque fournisseur.
La France, au 8 juillet 2026, n’avait pas encore notifié ses mesures nationales de transposition à la Commission européenne, qui a d’ailleurs renvoyé la France, l’Irlande, l’Espagne et les Pays-Bas devant la Cour de justice de l’Union européenne pour ce retard. L’ANSSI indique toujours que la transposition française est en attente et propose un service de pré-enregistrement.
Ce retard ne doit pas rassurer à tort. Les grands donneurs d’ordre, les ETI et les entreprises régulées préparent déjà leurs achats, leurs contrats et leurs audits internes. Sur les projets que nous menons, nous voyons souvent la cybersécurité passer d’un sujet technique traité en fin de parcours à un critère de sélection dès l’appel d’offres.
Ce que vos clients peuvent vous demander dès maintenant
Le règlement d’exécution (UE) 2024/2690 du 17 octobre 2024 fixe des exigences techniques et méthodologiques pour certaines entités numériques, notamment sur la politique de sécurité de la chaîne d’approvisionnement. Même lorsqu’il ne s’applique pas directement à votre entreprise, il influence les pratiques d’achat.
Dans la pratique, les exigences prennent souvent trois formes : un questionnaire sécurité, des clauses contractuelles, puis des demandes de preuves. Les plateformes spécialisées comme NISD2.eu signalent en 2026 que de nombreuses équipes achats européennes créent leurs propres questionnaires fournisseurs fondés sur les exigences NIS2 liées au risque fournisseur.
Un questionnaire peut demander si vous utilisez une authentification multifacteur, comment vous sauvegardez les données, qui a accès aux environnements de production, comment vous gérez les correctifs de sécurité, ou encore en combien de temps vous prévenez un client en cas d’incident. Rien d’exotique. Mais si rien n’est documenté, répondre proprement devient vite long.
Pour un site WordPress, par exemple, la question n’est pas seulement « le site est-il à jour ? ». Elle devient : qui applique les mises à jour, sous quel délai, avec quelle sauvegarde avant intervention, quelle journalisation (historique des actions), quel hébergement, quel pare-feu applicatif ? Pour approfondir ce point précis, un cadrage dédié existe sur les impacts de NIS2 sur un site WordPress.
- Une clause de notification d’incident sous 24 à 72 heures selon la gravité et le contrat.
- Une obligation de chiffrement des accès d’administration et des sauvegardes sensibles.
- Une limitation des comptes partagés, encore trop fréquents dans les petites structures.
- Une exigence de preuve : capture de configuration, politique interne, registre des accès, rapport de scan.
- Une clause de sous-traitance en cascade, si vous-même déléguez l’hébergement, le support ou le développement.
Budget, délais : l’ordre de grandeur réaliste pour une petite structure
Le piège classique consiste à chercher une « conformité NIS2 » complète alors que votre TPE n’est pas dans le périmètre direct. À ce budget, mieux vaut viser un socle de sécurité prouvable : des mesures simples, tenues dans le temps, que vous pouvez expliquer à un client sans improviser.
Les coûts varient selon votre système d’information, mais le marché français donne quelques repères. Une petite structure qui part de zéro peut souvent obtenir un premier niveau sérieux en quelques semaines, à condition de rester pragmatique.
| Action | Délai courant | Budget indicatif en France | Intérêt pour un client NIS2 |
|---|---|---|---|
| Audit sécurité léger d’un site ou d’une application | 3 à 10 jours | Autour de 1 500 à 5 000 € HT | Identifier les failles évidentes avant questionnaire ou renouvellement de contrat |
| Mise en place MFA, gestion des accès, durcissement basique | 1 à 3 semaines | Autour de 1 000 à 4 000 € HT | Réduire le risque de compromission par mot de passe volé |
| Politique de sauvegarde et restauration testée | 1 à 2 semaines | Autour de 800 à 3 000 € HT | Prouver la capacité à reprendre après incident ou ransomware |
| Documentation fournisseur : procédures, preuves, réponses types | 1 à 3 semaines | Autour de 1 500 à 6 000 € HT | Répondre plus vite aux achats et limiter les clauses floues |
| Test d’intrusion ciblé sur application exposée | 1 à 3 semaines | Autour de 4 000 à 12 000 € HT | Apporter une preuve plus robuste sur un service critique |
Ces montants ne remplacent pas un devis. Ils donnent un ordre de bataille. Honnêtement, un test d’intrusion complet ne se justifie que si l’application manipule des données sensibles, expose une API critique ou devient dépendante d’un grand compte ; pour un simple site vitrine, l’argent sera souvent mieux investi dans l’hébergement, les mises à jour, les sauvegardes et la surveillance.
Les choix techniques comptent aussi. Un hébergement mutualisé basique peut suffire à un petit site institutionnel, mais il sera difficile à défendre pour un portail client connecté à un système métier. OVHcloud, Scaleway, AWS, Microsoft Azure ou Google Cloud peuvent convenir selon le besoin, à condition de configurer correctement les accès, les journaux, les sauvegardes et les responsabilités contractuelles.
Que demander à ses propres sous-traitants ?
L’effet cascade ne s’arrête pas à vous. Si vous êtes agence, éditeur SaaS, prestataire informatique ou intégrateur, vos propres fournisseurs entrent dans l’équation : hébergeur, freelance, outil d’emailing, prestataire de maintenance, solution de paiement, support externalisé.
La bonne approche n’est pas d’envoyer un questionnaire de 120 questions à tout le monde. C’est contre-productif. Classez plutôt vos fournisseurs selon le risque : accès aux données personnelles, accès administrateur, accès au code, accès à la production, dépendance à la disponibilité du service.
Un freelance qui intervient sur une maquette Figma publique ne présente pas le même niveau de risque qu’un administrateur disposant d’un accès SSH (accès serveur sécurisé) à la production. Même logique pour une API mobile : si elle donne accès à des comptes utilisateurs ou à des données métier, le contrôle doit être plus sérieux. Les risques liés aux interfaces sont souvent sous-estimés ; un point utile est détaillé dans cette analyse sur la sécurité des API mobiles.
Le minimum défendable tient en quelques exigences : authentification multifacteur, comptes nominatifs, suppression des accès à la fin de la mission, sauvegardes vérifiées, chiffrement des échanges, procédure d’alerte en cas d’incident. Côté agence, le réflexe est de demander des preuves légères mais concrètes, plutôt qu’une déclaration générale du type « nous sommes sécurisés ».
Le piège que les non-techniciens ignorent : la preuve
Beaucoup d’entreprises ont de bonnes pratiques informelles. Le dirigeant sait que les sauvegardes existent, que le développeur met à jour le site, que l’hébergeur est sérieux. Le problème apparaît quand un client demande une preuve datée, lisible et opposable.
Une preuve peut être simple : une procédure d’une page, une capture d’écran de MFA activée dans Microsoft 365 ou Google Workspace, un export de sauvegarde, un rapport de mise à jour WordPress, une attestation d’hébergement, un registre des incidents même vide. Sans ces éléments, votre réponse repose sur la confiance orale. Dans un processus achats, c’est faible.
Autre piège : accepter des clauses trop larges. Certaines demandes imposent au fournisseur de garantir une conformité NIS2 complète, même s’il n’est pas concerné directement et n’a pas la maîtrise de tout le système. Il faut reformuler. Vous pouvez vous engager sur des mesures précises, des délais de notification, un périmètre technique, des responsabilités partagées. Pas sur l’impossible.
Le RGPD, applicable depuis 2018, a déjà habitué les entreprises à cette logique de sous-traitance documentée. NIS2 ajoute une couche sécurité plus opérationnelle : continuité, vulnérabilités, incidents, fournisseurs. Les deux sujets se croisent souvent, surtout lorsqu’un site web ou une application traite des données personnelles.
Construire un socle de sécurité acceptable sans surpayer
Le Référentiel Cyber France (ReCyF) version 2.5, publié par l’ANSSI le 17 mars 2026, propose 20 objectifs de sécurité comme base de travail pour NIS2. Pour une petite entreprise hors périmètre direct, il peut servir de boussole, pas de checklist à appliquer mécaniquement dans toute sa profondeur.
Commencez par les risques les plus probables. Les mots de passe faibles, les comptes partagés, les extensions non mises à jour, les sauvegardes jamais testées et les accès conservés après le départ d’un prestataire causent plus de dégâts que des scénarios très sophistiqués. Simple. Mais exigeant à tenir.
Sur une application mobile, la sécurité ne se limite pas à l’App Store ou au Play Store. Il faut vérifier les secrets embarqués, les appels API, la gestion de session, les journaux, les bibliothèques tierces. Avant publication, une checklist de sécurité applicative mobile permet déjà d’éviter des failles visibles et coûteuses.
Les passkeys, standardisées par la FIDO Alliance et prises en charge progressivement par Apple, Google et Microsoft, peuvent aussi réduire le risque lié aux mots de passe pour certains usages. Elles ne remplacent pas une gouvernance des accès, mais elles peuvent être pertinentes pour des portails clients ou des interfaces sensibles. Le sujet est à évaluer avec réalisme, notamment via ce guide sur les passkeys pour site web.
Un bon socle pour une TPE fournisseur tient souvent en six chantiers : inventaire des services exposés, MFA sur les comptes critiques, sauvegardes testées, mises à jour suivies, procédure d’incident, documentation fournisseur. Ce n’est pas spectaculaire. C’est précisément pour cela que ça marche.
Cadrer ce type de projet en amont évite la plupart des mauvaises surprises : exigences impossibles, budget mal placé, délai sous-estimé, responsabilité floue avec les prestataires. Un regard extérieur aide surtout à distinguer ce qui protège vraiment l’activité de ce qui ne fait qu’alourdir le dossier.
FAQ sur NIS2 et les sous-traitants
Une TPE de moins de 50 salariés doit-elle être conforme à NIS2 ?
En général, non, sauf cas particulier lié à son activité ou à une future règle nationale. En revanche, elle peut devoir répondre à des exigences contractuelles si elle fournit une entité essentielle ou importante.
Un client peut-il imposer des clauses NIS2 Ã son fournisseur ?
Oui, dans la limite du contrat et du périmètre réel de prestation. Il vaut mieux accepter des engagements précis sur les mesures de sécurité, les preuves et les délais d’alerte plutôt qu’une promesse générale de conformité.
Quel document préparer pour répondre à un questionnaire NIS2 fournisseur ?
Préparez une fiche sécurité de 2 à 5 pages : hébergement, sauvegardes, MFA, gestion des accès, mises à jour, sous-traitants, notification d’incident. Ajoutez quelques preuves simples et datées.
NIS2 remplace-t-elle le RGPD pour les sous-traitants ?
Non. Le RGPD traite principalement des données personnelles, tandis que NIS2 vise la cybersécurité et la continuité des services. Les deux se complètent lorsqu’un prestataire manipule des données clients ou utilisateurs.