À retenir. L’article 21, paragraphe 2, point d), de la directive NIS 2 demande de traiter la sécurité de la chaîne d’approvisionnement, notamment les relations avec les fournisseurs et prestataires directs. L’article 21, paragraphe 3, invite à considérer leurs vulnérabilités particulières et la qualité de leurs produits et pratiques. Ce cadre n’impose pas un audit annuel de chaque fournisseur, une certification unique ni une clause de notification identique pour tous. Au 27 septembre 2026, la transposition française demeure en discussion ; les exigences contractuelles et les régimes déjà applicables continuent toutefois à produire leurs effets.
La tâche du responsable achats et du RSSI est de savoir quelle dépendance menace quel service, puis de choisir une preuve et une action adaptées. Une panne du DNS, un compte d’infogérance compromis et une fuite chez un prestataire de paie ne se gèrent pas de la même manière. La fiche de criticité fournisseur aide à séparer dépendance métier, substituabilité, accès privilégiés et données exposées ; elle mérite d’être conservée dans le dossier de décision.
1. Cadre NIS 2 : responsabilité de l’entité et relation directe
La directive place la gestion du risque chez l’entité essentielle ou importante pour les systèmes et services qu’elle utilise. Elle vise explicitement la sécurité des relations avec les fournisseurs et prestataires directs. Cela ne transforme pas automatiquement chaque fournisseur en EE ou EI ; son propre statut dépend de ses activités, sa taille et des exceptions. Le guide de qualification OIV/OSE/EE/EI aide à éviter cette confusion. Une entreprise hors champ direct peut néanmoins recevoir des obligations contractuelles fortes de son client.
L’article 22 organise des évaluations coordonnées de chaînes d’approvisionnement essentielles au niveau européen. Il ne crée pas une obligation d’audit uniforme de tous les rangs par chaque PME. Pour une entité cliente, le risque pertinent est concret : peut-elle maintenir un service si un prestataire tombe, et peut-elle détecter une compromission introduite par une mise à jour ou un accès distant ? Les mesures doivent rejoindre l’analyse de risques et le plan de continuité.
La Commission et l’ANSSI présentent encore la mise en œuvre française comme une transposition à venir. Les équipes peuvent préparer leurs preuves, mais ne devraient pas dire à un fournisseur qu’un article du projet français lui impose déjà une clause précise.
2. Cartographier les fournisseurs par service rendu
L’inventaire commence par les services essentiels à l’activité : hébergement, identité, DNS, télécommunication, paiements, sauvegarde, maintenance, logiciels critiques et chaîne industrielle. Pour chacun, notez la personne morale contractante, le service rendu, les systèmes atteints, les données accessibles, le propriétaire interne, les sous-traitants connus, la durée du contrat et le scénario de défaillance. Ajoutez les fournisseurs métiers hors IT qui contrôlent un flux indispensable, par exemple logistique ou énergie.
Évitez de confondre l’inventaire achats et l’inventaire des dépendances : un outil gratuit, un composant open source ou une API fournie par un partenaire peut ne pas figurer dans le grand livre. Interrogez les architectes, responsables métiers et exploitants. La cartographie SI permet de relier les services aux systèmes et aux partenaires techniques.
Exemple hypothétique : un établissement possède deux hébergeurs, mais les deux utilisent le même fournisseur d’identité. Les contrats semblent diversifiés ; le point de défaillance unique reste l’identité. La cartographie doit montrer cette dépendance transversale avant de discuter certification ou audit de chaque hébergeur.
3. Évaluer criticité, exposition et substituabilité
Un fournisseur est critique pour différentes raisons. L’un a un accès administrateur permanent, l’autre héberge des données sensibles, un troisième ne possède aucune donnée mais conditionne la disponibilité du service. Évaluez séparément impact métier, volume et sensibilité des données, privilèges, connectivité, capacité de substitution et délai de reprise. La fiche de criticité fournisseur aide à conserver pour chaque classement sa justification, la preuve examinée et l’action attendue.
Exemple hypothétique : le fournisseur A héberge une archive chiffrée répliquée ailleurs ; le fournisseur B gère le DNS d’un site de prise de rendez-vous et n’a aucune donnée personnelle. Le fournisseur B peut être prioritaire pour la continuité malgré une exposition moindre des données. Un classement fondé seulement sur le volume de données ferait manquer le risque principal.
Un score ne remplace pas l’arbitrage. Décrivez un scénario de panne ou de compromission, les mesures en place et le risque résiduel. Réévaluez lorsque le fournisseur obtient un nouvel accès, change de sous-traitant, subit un incident, perd une qualification ou modifie son implantation. La profondeur du contrôle suit ce risque ; elle n’est pas liée à un « Tier 1 » défini de façon universelle par NIS 2.
4. Choisir des preuves proportionnées
Pour un service peu critique, une description de l’architecture et une vérification contractuelle peuvent suffire. Pour un hébergeur central ou un prestataire d’administration, demandez une documentation ciblée : périmètre de certification, rapport d’audit expurgé, procédure d’incident, résultat de restauration, gestion des accès, continuité et liste des sous-traitants pertinents. Une certification ISO 27001 peut apporter une preuve sur son périmètre ; elle ne garantit pas que chaque application du client, ni le traitement de chaque vulnérabilité, a été audité.
Un questionnaire doit conduire à une décision. Si le fournisseur déclare « sauvegardes quotidiennes », demandez le dernier essai de récupération du service concerné ou la clause d’objectif de reprise. Si un rapport SOC 2 est fourni, vérifiez la période, les exceptions, le service inclus et les contrôles que le client doit lui-même mettre en place. Si la preuve n’est pas disponible, notez la limite et une mesure compensatoire, par exemple une sauvegarde indépendante ou une restriction d’accès.
Le ReCyF de l’ANSSI, document de travail de mars 2026, peut aider à structurer les questions, sans créer à lui seul une obligation française définitive. Une évaluation réussie révèle des actions chez le client autant que chez le fournisseur.
Quand un fournisseur important ne dispose pas d’un certificat couvrant le service, le plan d’assurance alternatif aide à demander une preuve directe, mener un entretien, réaliser un essai et documenter les limites de la décision.
5. Clauses contractuelles cyber : écrire ce qui sera utilisé
Une clause utile décrit le service protégé, les mesures attendues, les accès autorisés, la gestion des vulnérabilités, la continuité, la notification des incidents, la coopération lors d’une enquête, les preuves disponibles et la réversibilité. Elle précise qui reçoit l’alerte, par quel canal, avec quelles informations initiales et comment les faits seront complétés. Un délai contractuel peut être plus court que le délai légal du client, afin que celui-ci ait le temps de qualifier l’incident ; il doit rester réalisable et porter sur une définition claire d’événement.
Évitez la formule « le fournisseur garantit sa conformité NIS 2 » sans préciser son propre statut et le périmètre des prestations. Évitez aussi d’exiger automatiquement « alerte sous 24 heures pour toute anomalie » : un seuil trop large produit du bruit et peut retarder les alertes importantes. Définissez la gravité en fonction de l’impact sur le service, l’accès non autorisé, la perte de confidentialité ou l’indisponibilité. La politique de sécurité fournisseurs peut servir de cadre interne ; les clauses se négocient selon le contrat.
Exemple hypothétique : un prestataire d’identité s’engage à notifier sans retard injustifié tout incident ayant affecté l’authentification des utilisateurs du client, puis à fournir mises à jour et éléments techniques. Le client sait à qui transmettre les faits, comment couper une fédération compromise et quels journaux demander. Une pénalité financière générique ne remplace pas ces gestes.
6. Incident fournisseur : décider avant le rapport final
Lorsqu’un fournisseur signale un incident, le client doit établir quels services et données sont réellement exposés. Demandez l’heure de découverte, la période potentielle d’accès, les systèmes concernés, les mesures de confinement, la persistance d’accès du client et le prochain point. Révoquez ou restreignez les connexions à risque si nécessaire, puis consignez les effets métiers. L’absence de preuve d’exfiltration n’est pas la preuve d’absence de risque.
Le client garde ses propres analyses de notification : régime OIV ou OSE existant, futur NIS 2 le cas échéant, et RGPD en cas de violation de données personnelles. Une clause fournisseur de « signalement sous 24 heures » ne remplace pas la qualification des délais qui courent pour le client. Le playbook de crise cyber aide à coordonner direction, technique et juridique.
Exemple hypothétique : le prestataire de support annonce un vol d’identifiants mais ignore encore si le compte a été utilisé. Le client bloque le compte et les jetons, examine ses propres journaux et prévient la cellule de crise. Il ne doit ni déclarer publiquement une fuite certaine, ni attendre passivement la conclusion du prestataire avant de protéger ses systèmes.
7. Accès des prestataires et fin de contrat
Lorsqu’un service sort du portefeuille, la recette d’export et de suppression SaaS exige un contenu réutilisable et une preuve de fermeture, pas seulement une clause de réversibilité.
Les accès des tiers sont attribués à des personnes identifiées, limités dans le temps et au périmètre nécessaire. Les privilèges élevés méritent un chemin d’administration contrôlé, des journaux exploitables et une possibilité de coupure rapide. Le client doit savoir qui peut ouvrir une session, même lorsque le fournisseur travaille avec une équipe distante ou un sous-traitant. La revue régulière des comptes et la fermeture après intervention réduisent un risque fréquent que la certification du fournisseur ne couvre pas seule.
À la fin du contrat, planifiez l’export des données, le transfert des configurations et clés, la vérification de leur intégrité, le retrait des comptes et les preuves de suppression selon le service. Une réversibilité non testée peut échouer le jour où le fournisseur est indisponible ou contesté. Pour un service critique, faites un exercice limité : reconstituer une configuration DNS, restaurer une sauvegarde chez un autre hébergeur ou reprendre l’administration sans le prestataire.
La stratégie de sauvegarde et le PRA doivent inclure ces dépendances externes. Une copie détenue par le même fournisseur et utilisant le même compte d’administration peut ne pas constituer une véritable alternative.
8. Logiciels et composants : SBOM selon l’usage
Pour un logiciel critique, connaître les composants, versions et dépendances aide à répondre à une vulnérabilité publiée. Un SBOM peut faciliter cette recherche, surtout si le fournisseur maintient de nombreux composants, mais la directive NIS 2 n’en impose pas un à chaque fournisseur. Demandez d’abord comment le fournisseur identifie les composants affectés, reçoit les alertes, corrige et informe les clients. Un fichier SBOM jamais mis à jour peut créer une fausse assurance.
Côté client, tenez l’inventaire des applications et de leurs propriétaires. Lorsque surgit une faille, identifiez vite les produits exposés, les versions et les compensations possibles. Pour un composant open source, le risque dépend de son utilisation, de son exposition, de son maintien et de la capacité de mise à jour. Un composant peu populaire mais intégré au chemin d’authentification peut être plus critique qu’une bibliothèque très téléchargée utilisée hors production.
Exemple hypothétique : un éditeur fournit un SBOM mais ne peut dire si une version vulnérable est effectivement activée dans le produit livré. Le client demande l’analyse d’exploitabilité, la mesure temporaire et la date de correction. La preuve utile est la réponse à ce scénario, pas le format du fichier seul.
9. Sous-traitants de rang supérieur et concentration du risque
La carte des dépendances communes entre services SaaS permet de vérifier si plusieurs fournisseurs reposent sur la même identité, infrastructure ou région malgré des contrats distincts.
L’article 21 vise la relation directe ; cela ne signifie pas qu’il faut ignorer les dépendances de ce fournisseur. Demandez, lorsque le risque le justifie, les sous-traitants essentiels au service, les lieux ou fonctions sous-traitées, les conditions de changement et les garanties de continuité. Pour les données personnelles, l’article 28 RGPD impose des règles spécifiques sur les sous-traitants ultérieurs ; ces règles ne se substituent pas à l’analyse cyber de disponibilité et d’intégrité.
Un fournisseur peut s’appuyer sur le même service cloud que plusieurs autres contrats du client. La diversité apparente des fournisseurs ne protège alors pas d’une panne commune. Cartographiez les concentrations utiles sans exiger la divulgation irréaliste de toute la chaîne mondiale. Si une dépendance reste inconnue, mesurez le risque de ce manque d’information et préparez une option de secours.
Exemple hypothétique : trois logiciels métiers différents utilisent le même prestataire d’envoi de messages pour les codes de connexion. Une panne de ce prestataire empêche les trois services. La réduction du risque peut consister à prévoir des méthodes de secours et des procédures de vérification, plutôt qu’à auditer séparément les trois éditeurs sans voir le service commun.
10. Audit fournisseur : dossier et fréquence motivée
Un audit sur pièces commence par la carte du service et les preuves demandées ; un entretien permet d’éclaircir les écarts ; un test technique ou une visite se justifie lorsque le risque et le contrat l’exigent. Définissez dès le départ le périmètre, la confidentialité du rapport, les critères de constat et les délais de correction. Le client doit vérifier que les recommandations produisent des changements observables. Un refus d’audit sur place ne commande pas automatiquement une résiliation : analysez les preuves alternatives, le pouvoir de négociation et les mesures compensatoires.
La fréquence suit la criticité, le rythme des changements, les incidents et la qualité des preuves. Une revue après changement majeur de plateforme peut compter davantage qu’un contrôle annuel identique. La checklist d’audit NIS 2 aide à relier l’évaluation fournisseur aux autres risques de l’entité. Elle ne crée ni coût forfaitaire ni période réglementaire universelle.
11. Registre d’actions et arbitrage de direction
Pour chaque fournisseur critique, tenez une ligne lisible : service dépendant, scénario redouté, preuve reçue, lacune, mesure chez le fournisseur, mesure chez le client, responsable, échéance et résultat de vérification. Si le fournisseur refuse une information, consignez ce refus et décidez s’il est acceptable au regard du risque. Une certification, un rapport d’audit ou une clause ne doivent jamais clore automatiquement un risque sans examen du service concerné.
Présentez à la direction les concentrations et risques résiduels majeurs. Elle peut financer une seconde solution, accepter temporairement un risque avec une procédure de secours ou changer de fournisseur. Faites apparaître les coûts de migration et les délais réels ; la décision « remplacer immédiatement » peut être plus risquée qu’une réduction d’accès progressive. Les choix devraient rejoindre la PSSI et le budget de continuité.
12. Articulation avec RGPD, HDS, DORA et futur NIS 2
Le contrat de sous-traitance RGPD traite les données personnelles et les garanties exigées par l’article 28. Il ne couvre pas nécessairement la continuité d’un service sans données personnelles ni la sécurité d’un accès d’administration. L’HDS peut s’appliquer à l’hébergement de données de santé dans son champ légal ; il ne rend pas automatiquement SecNumCloud obligatoire. DORA crée des exigences particulières pour des entités financières et leurs risques de tiers TIC.
Dans le futur dispositif français NIS 2, l’entité devra démontrer que la chaîne d’approvisionnement est traitée comme un risque parmi d’autres, selon le texte finalement adopté. En attendant, sécuriser les accès et la continuité est utile en soi. Évitez la formule « fournisseur conforme NIS 2 » sans périmètre, date et base : elle mélange un statut éventuel, une mesure contractuelle et une appréciation de risque. Le guide des sanctions NIS 2 distingue ce qui relève de la directive et du droit français.
Questions fréquentes
Faut-il auditer tous les fournisseurs chaque année ?
La directive ne fixe pas cette règle générale. Classez les dépendances et choisissez l’étendue et le rythme du contrôle selon le risque, le changement et les preuves disponibles.
Un fournisseur de petite taille est-il dispensé de sécurité ?
Il peut être hors du champ direct ordinaire de NIS 2 tout en portant un risque majeur pour son client et en ayant des obligations contractuelles ou RGPD. La taille n’efface pas ces responsabilités.
Une certification suffit-elle ?
Non seule. Vérifiez le service couvert, la version du certificat, les exclusions, les rapports d’écart et les contrôles qui restent à la charge du client. Complétez par un test de continuité ou d’accès quand le risque l’exige.