Le risque de la chaîne d’approvisionnement est un programme, pas une liste d’audit

La liste des fournisseurs était verte avant l’audit. Puis l’accès administrateur d’un sous-traitant de l’hébergeur ERP est apparu dans un système de tickets qui ne figurait ni dans le contrat ni dans le registre. NIS2 et DORA n’exigent pas une archive de questionnaires cochés, mais un processus qui maintient en permanence la synchronisation des contrats, des données et des accès.

Lié :TrapDoor : Attaque sur la chaîne d’approvisionnement de npm, PyPI et Crates  /  DORA et NIS2 : Pourquoi les audits bancaires se heurtent

Ce que le paragraphe 30 exige vraiment pour la chaîne d’approvisionnement

Qu’est-ce que le Third-Party-Risk-Management ? Le Third-Party-Risk-Management est le processus continu par lequel une organisation identifie, évalue, sécurise contractuellement et surveille les risques de sécurité de ses prestataires de services, de ses fournisseurs de logiciels et de leurs sous-traitants. Il s’étend de l’onboarding au contrôle continu jusqu’à l’offboarding.

Le paragraphe 30 alinéa 2 numéro 4 BSIG mentionne explicitement la sécurité de la chaîne d’approvisionnement comme mesure obligatoire. L’accent est mis sur les relations avec les prestataires directs. L’intégralité de la chaîne jusqu’à la matière première n’est pas concernée. C’est la bonne nouvelle pour le Mittelstand : il s’agit des partenaires contractuels directs ayant accès aux systèmes ou aux données.

La nouvelle moins confortable figure à l’alinéa 1 et dans le texte européen. Les mesures doivent être adaptées, proportionnées et efficaces, et une obligation de documentation s’y ajoute. L’article 21 de NIS2 exige une gestion continue des risques pour tous les systèmes de réseaux et d’information utilisés par l’exploitation. Le considérant 85 de la directive nomme explicitement le cloud, la sécurité gérée et les logiciels. Un répertoire créé une fois par an ne couvre pas cette obligation.

DORA transforme le registre en obligation permanente

Ceux qui travaillent dans le secteur financier connaissent la norme plus stricte. DORA s’applique de manière contraignante depuis le 17 janvier 2025. Pour les entreprises financières, il prévaut en tant que droit plus spécifique à la place des obligations NIS2 en matière de chaîne d’approvisionnement. Les deux régimes ne s’appliquent pas en parallèle à la même entreprise. L’article 28 laisse l’entière responsabilité à l’entreprise financière, même lorsque la prestation est externalisée.

Le registre des informations n’est pas un Excel que l’on remplit une seule fois. Il est tenu au niveau de l’établissement et du groupe, déclaré annuellement à l’autorité de supervision et doit pouvoir être présenté intégralement sur demande. Avant tout contrat pour une fonction critique, une due diligence est requise, ainsi qu’une analyse des risques de concentration et des stratégies de sortie. L’article 30 prescrit des contenus contractuels précis : dispositions relatives aux sous-traitants, localisation du traitement des données, droits d’audit et obligations de notification en cas de modifications substantielles.

La gravité avec laquelle l’autorité prend cela au sérieux apparaît le 18 novembre 2025. Les autorités européennes de supervision EBA, EIOPA et ESMA ont publié la première liste de prestataires tiers IKT critiques : 19 fournisseurs, dont plusieurs grands prestataires cloud et SAP. Ces prestataires sont désormais placés sous supervision directe de l’UE. Le risque de la chaîne d’approvisionnement est régulé au niveau du système, bien au-delà du contrat individuel.

Pourquoi le questionnaire annuel ne comble pas la faille

J’ai un jour archivé un questionnaire fournisseur avec une coche verte pour l’ISO 27001 et considéré le dossier comme clos. Quatre mois plus tard, le prestataire a changé de sous-traitant d’hébergement. Le questionnaire était encore vert, la réalité ne l’était plus. C’est précisément cet écart temporel qui pose problème.

Le texte réglementaire vise un cycle. Un contrôle unique ne lui suffit pas. Le paragraphe 30 numéro 6 exige une évaluation de l’efficacité, l’article 30 de DORA exige une surveillance continue pour les contrats critiques. Tous les fournisseurs n’ont pas besoin du même niveau de profondeur. Un tiering selon l’accès aux systèmes, la sensibilité des données et la dépendance à la disponibilité distingue les partenaires Tier A de la longue liste de prestataires non critiques.

S’y ajoute un problème de données. Une enquête sectorielle sur le Third-Party-Risk-Management de 2026 indique que seule une minorité des programmes est pleinement intégrée à l’Enterprise-Risk-Management et encore moins d’organisations jugent élevée leur qualité de données. Les valeurs exactes varient selon la méthodologie. Le constat demeure : sans un registre propre, aucune décision de tiering fiable n’est possible. Sans rattachement à l’ERM, le risque reste coincé dans un ticket d’approvisionnement au lieu de figurer dans le rapport trimestriel de la direction.

Le tableau suivant oppose les deux approches.

Cinq piliers pour transformer le contrôle en programme

Un programme viable n’a pas besoin d’une grande plateforme, il lui faut des propriétaires clairs pour chaque étape du processus. Cinq piliers suffisent pour démarrer.

Policy et tiering. Une matrice de criticité selon l’accès, les données et la disponibilité définit qui est Tier A et à quelle fréquence il est contrôlé. Le propriétaire est le département Risk ou le CISO, mis en œuvre par un responsable TPRM.

Onboarding-Assessment. La due diligence intervient avant le contrat. Après, l’accès est souvent déjà actif. Les preuves de sécurité, les questions de localisation et la vérification des conflits doivent être clarifiées avant l’activation de l’accès. L’article 28 de DORA en fait une obligation pour les fonctions critiques.

Surveillance continue. Maintenance du registre, re-certification selon le risque et un canal pour les notifications d’incidents du fournisseur. C’est ici que vit ou meurt le programme. Un changement de contrat chez le prestataire doit déclencher un signal. Une note discrète ne suffit pas.

Offboarding. Retrait des accès, restitution ou suppression des données et fin de contrat documentée. Le point aveugle le plus fréquent : les accès qui restent actifs après la fin du projet.

Quatrième partie et transparence logicielle. Les sous-traitants doivent figurer dans les champs du registre, les logiciels critiques nécessitent une nomenclature selon le principe du SBOM. Une telle nomenclature n’est pas une obligation normative explicite, mais elle aide à porter la gestion des vulnérabilités du paragraphe 30 numéro 5 BSIG jusqu’à la chaîne d’approvisionnement.

Au-dessus de tout se trouve la direction. Le paragraphe 38 BSIG l’oblige à la mise en œuvre et à la surveillance. Un programme TPRM sans revue visible par la direction est une feuille de couverture CISO sans valeur de gouvernance. Le prestataire de services avec accès à la salle serveurs est Tier A, même si les achats le classent uniquement sous services immobiliers. Ce sont précisément ces classements qui déterminent le risque.

Le point d’entrée : par où commencer cette semaine

Le passage du questionnaire au programme ne requiert pas un grand projet. Cinq étapes apportent de la structure sans bloquer l’activité. Premièrement : identifier les fournisseurs Tier A, c’est-à-dire tous ceux disposant d’un accès système ou de données critiques. Deuxièmement : confronter le registre à la réalité et compléter les sous-traitants manquants. Troisièmement : attribuer à chaque partenaire Tier A un propriétaire et un rythme de surveillance. Quatrièmement : vérifier les clauses contractuelles relatives aux droits d’audit, aux sous-traitants et aux obligations de notification. Cinquièmement : intégrer les risques fournisseurs comme entrées dans le registre des risques de l’entreprise, avec un rapport trimestriel à la direction.

Ce n’est pas un projet avec date de fin. C’est un mode opératoire. Celui qui l’a une fois établi réussit le prochain audit sans effort supplémentaire, car la preuve documentaire est un sous-produit de l’exploitation courante.

Questions fréquentes

Chaque question est verrouillée. Un appui la déverrouille.

Un répertoire de fournisseurs suffit-il pour la conformité NIS2 ?

Non. Le paragraphe 30 BSIG et l’article 21 de NIS2 exigent des mesures adaptées, efficaces et pilotées en continu. Un répertoire seul ne suffit pas. Un registre statique sans tiering, surveillance et évaluation de l’efficacité ne couvre pas l’obligation de gestion des risques.

Qu’est-ce qui distingue DORA des obligations de chaîne d’approvisionnement NIS2 ?

DORA s’applique depuis le 17 janvier 2025 dans le secteur financier et y prévaut. Il exige un registre formel des tiers IKT avec déclaration annuelle, stratégies de sortie et contenus contractuels détaillés conformément à l’article 30. NIS2 pose un cadre plus large, mais moins formalisé.

Devons-nous recenser les sous-traitants de nos prestataires ?

Dans le secteur financier oui, dès lors qu’ils touchent des fonctions critiques ou importantes. L’article 30 de DORA et les spécifications techniques du registre exigent des clauses de cascade et le recensement des sous-traitants pertinents. Sous NIS2, le paragraphe 30 numéro 4 vise principalement les prestataires directs ; l’obligation explicite de recensement des sous-traitants est une particularité de DORA.

À quelle fréquence devons-nous réévaluer les fournisseurs ?

Il n’existe pas de fréquence fixe valable pour tous. Le rythme dépend du tier : prestataires critiques avec accès système de façon serrée et déclenchée par les événements, prestataires de services non critiques moins souvent. Les déclencheurs sont les modifications de contrat, les changements de sous-traitants et les incidents de sécurité.

Qu’est-ce qu’un SBOM et pourquoi appartient-il au TPRM ?

Un SBOM est une nomenclature des composants logiciels d’un produit, souvent au format CycloneDX ou SPDX. Il indique quelles bibliothèques proviennent de la chaîne d’approvisionnement et soutient ainsi la gestion des vulnérabilités du paragraphe 30 numéro 5. Un SBOM n’est pas prescrit, mais il est devenu une pratique établie. Sans cette transparence, l’origine des logiciels reste un point aveugle.

Les choix de la rédaction

À lireTrapDoor : attaque coordonnée sur la chaîne d’approvisionnement contre npm, PyPI et Crates – ce queÀ lireDORA et NIS2 : Pourquoi les audits bancaires entrent en collisionÀ lirePME : le retard technique face à la NIS2

Plus du réseau MBF Media

Digital ChiefsG?opolitique et datacenters : ce que les DSI s?curisentMyBusinessFutureAI Act de l’UE à partir d’août 2026 : ce que les PME doivent étiqueter maintenantcloudmagazinXFS4IoT rencontre le Cloud : le distributeur automatique de billets devient une plateforme