TPRM : gestion des risques tiers, ce que NIS2 et DORA exigent de
vos fournisseurs

Le 5 juin 2023, British Airways, la BBC et Boots préviennent leurs salariés que leurs données de paie ont fuité. Aucune des trois n'a été attaquée. Leur prestataire de paie, Zellis, utilisait MOVEit Transfer, un logiciel de transfert de fichiers de l'éditeur Progress, et le groupe Cl0p exploitait depuis le 27 mai une injection SQL inconnue de tout le monde, référencée ensuite CVE-2023-34362. Vu du côté de la BBC, la chaîne ressemble vraisemblablement à ceci : un contrat avec Zellis, aucun avec Progress, pas un serveur MOVEit dans son propre inventaire, et pourtant 21 000 salariés qui se demandent lesquels d'entre eux sont concernés. Le risque est entré par un tiers, puis par le tiers de ce tiers, et c'est ce qu'un programme TPRM (third-party risk management, gestion des risques liés aux tiers) est censé voir venir.

Dans la pratique, la gestion des risques tiers se réduit le plus souvent à un questionnaire annuel, qui n'aurait rien changé chez Zellis : la question "utilisez-vous un logiciel de transfert de fichiers exposé sur Internet, et lequel ?" ne figure dans aucun modèle standard. Un dispositif de gestion des risques tiers ne se juge donc pas à l'épaisseur de ses formulaires, mais à ce qu'il sait de ses fournisseurs entre deux campagnes de questionnaires, et aux textes qu'il permet de tenir quand NIS2, DORA, le ReCyF de l'ANSSI ou un auditeur ISO 27001 viennent les réclamer.

TPRM : la gestion des risques tiers, du questionnaire au programme

Un programme de gestion des risques liés aux tiers enchaîne six étapes : recenser les tiers, les classer par criticité, les évaluer avant de signer, encadrer la relation par contrat, la surveiller pendant toute sa durée, et organiser la sortie. Le questionnaire de sécurité n'occupe que la troisième case. Ses limites, la portée réelle d'un certificat ISO 27001 ou d'un rapport SOC 2, et les questions qui discriminent vraiment sont traitées à part dans l'article sur le questionnaire sécurité fournisseur. Ici, on s'occupe des cinq autres cases, celles qui font la différence entre un dossier de conformité et une capacité à encaisser un incident chez un prestataire.

Le périmètre est plus large qu'on ne le dessine d'habitude : l'infogérant qui détient des comptes d'administration, l'éditeur SaaS qui héberge la base clients, le cabinet de paie, mais aussi l'éditeur d'un logiciel mis à jour automatiquement chez vous, et le sous-traitant de rang deux que vous ne connaissez pas. Une compromission qui arrive par l'un d'eux reste une attaque de la chaîne d'approvisionnement, que le vecteur soit un contrat ou une dépendance logicielle. Le pilier sur les attaques supply chain décrit les deux familles ; le TPRM répond à la première, et la seconde relève du SBOM, qu'aucun formulaire ne remplace.

Inventaire et classification : lesquels de vos tiers peuvent vous faire tomber

L'inventaire se croise à partir de trois sources, parce qu'aucune n'est complète seule : la comptabilité fournisseurs (qui a été payé), les annuaires et journaux d'accès (qui détient un compte, un VPN, une clé d'API), et la surface exposée (quel service tiers est branché sur votre domaine, quel script externe se charge sur votre portail client). La comptabilité rate la relation de fait, comme le matériel prêté par la maison mère à une filiale. Les accès ratent le SaaS payé par carte bancaire par une direction métier. La surface exposée rate tout ce qui n'est pas sur Internet.

Le critère de tri est ensuite le dommage possible, pas le montant facturé. Un prestataire à 800 € par mois qui détient un compte d'administration sur votre Active Directory pèse plus lourd qu'une agence à 50 000 € par an qui ne voit que des communiqués de presse. Quatre questions classent : quelles données le tiers manipule-t-il, quel privilège détient-il chez vous, peut-il interrompre votre activité, et en combien de temps est-il remplaçable. La dernière est celle qu'on oublie, et la seule que DORA a jugé utile de nommer dans un article dédié, le risque de concentration.

La concentration se regarde à deux échelles. La première est le fournisseur qu'on ne sait pas remplacer : l'article 29 de DORA demande de vérifier, avant de signer pour une fonction critique, si le prestataire n'est pas facilement substituable et si plusieurs contrats critiques ne s'empilent pas chez le même prestataire. La seconde est invisible dans votre inventaire : dix de vos tiers dépendent peut-être du même hébergeur ou du même logiciel de transfert de fichiers. C'est le scénario MOVEit, et c'est pour cela que le même article demande d'évaluer les chaînes de sous-traitance "potentiellement longues ou complexes".

Due diligence proportionnée : demander, prouver, observer

Sans proportionnalité, l'évaluation n'a pas lieu. Un questionnaire de deux cents lignes envoyé aux trois cents tiers de l'inventaire produit trois cents réponses que personne ne lit. Le même questionnaire réservé aux quinze tiers critiques, avec une preuve jointe pour chaque réponse qui engage (le certificat et son champ d'application, la date du dernier test d'intrusion, le plan de continuité), produit quinze dossiers qu'on peut instruire. DORA le formule à l'article 28, paragraphe 4 : avant de conclure, l'entité "fait preuve de toute la diligence requise" et vérifie que le prestataire "présente les qualités requises". Le texte ne dit pas comment, et c'est heureux, parce que la méthode dépend du niveau.

Trois sources se complètent, chacune avec son angle mort. Le déclaratif dit ce que le fournisseur veut bien dire. La preuve documentaire (certificat, rapport SOC 2) dit ce qu'un auditeur a constaté, sur un périmètre et à une date qu'il faut lire. L'observation externe dit ce que le fournisseur expose sur Internet aujourd'hui, à quiconque s'y connecte : versions de TLS acceptées, certificats expirés, sous-domaines oubliés, interfaces d'administration ouvertes, technologies annoncées dans les bannières, identifiants de ses salariés présents dans des fuites publiques. Cette troisième source ne demande pas l'accord du fournisseur, elle est passive, et elle se rafraîchit seule. C'est le terrain d'un EASM appliqué à un domaine qui n'est pas le vôtre.

Les clauses contractuelles qui servent le jour de l'incident

Un contrat de prestation se lit une fois à la signature et une fois pendant l'incident. Les clauses ci-dessous sont celles qu'on regrette à la seconde lecture. DORA en fait une liste obligatoire pour le secteur financier à l'article 30, et je la prends comme référence parce qu'elle est la plus précise des textes en vigueur, mais aucune de ces clauses n'a besoin d'être une banque pour être utile.

La clause de sous-traitance est celle qui aurait compté dans l'affaire Zellis, et elle repose sur un droit que presque personne n'exerce. Le RGPD exige, à l'article 28, paragraphe 2, une autorisation écrite préalable, spécifique ou générale, avant tout recrutement d'un autre sous-traitant et, dans le cas d'une autorisation générale, l'information du responsable de traitement sur tout ajout ou remplacement pour qu'il puisse s'y opposer ; le paragraphe 4 répercute les mêmes obligations en cascade (texte sur le site de la CNIL). Combien de vos contrats exploitent ce droit d'opposition ? Le plus souvent, la liste des sous-traitants ultérieurs est une annexe qu'on ne relit jamais, et sa mise à jour arrive par un courriel que personne ne rapproche de l'inventaire.

Suivi continu contre questionnaire annuel

Le défaut du questionnaire annuel tient à son rythme. L'organisation d'un fournisseur, ses certifications, ses contrats bougent lentement, et une revue par an les suit correctement. Sa surface exposée change en jours : un sous-domaine part en production, un certificat expire, une interface d'administration s'ouvre pendant une migration, un script tiers apparaît sur le portail que vos clients utilisent. Faire porter les deux par le même cycle annuel revient à être aveugle onze mois sur douze sur la partie qui bouge. Dans l'affaire MOVEit, tout s'est joué en neuf jours.

La méthode qui tient consiste à désynchroniser. Le déclaratif et le contractuel se revoient une fois par an et à chaque événement. L'observable se surveille en continu, avec une alerte quand la surface d'un tiers critique change, et une réévaluation complète déclenchée par un fait précis : incident public chez le fournisseur, rachat, changement d'hébergeur, sous-traitant absent de l'annexe. C'est la logique du module supply chain security de l'EASM own2pwn : on déclare les domaines de ses tiers critiques, l'observation passive tourne toute seule et le changement remonte dans l'interface. Ça ne vaut ni audit du fournisseur ni preuve de conformité, autant le dire tel quel. En revanche, aucune autre source d'information sur lui ne se met à jour sans qu'on ait à la lui demander.

Reste à écrire ce qui se passe en cas d'écart, et qui décide. Un programme qui n'a jamais conduit à refuser un fournisseur, à imposer un délai de correction ou à activer une clause de résiliation n'est pas un programme, c'est une collection de fichiers. Sur le "qui", NIS2 a tranché à l'article 20 : les organes de direction approuvent les mesures de gestion des risques, en supervisent la mise en œuvre et peuvent être tenus responsables de la violation de l'article 21, chaîne d'approvisionnement comprise.

Ce que NIS2, DORA, le ReCyF et l'ISO 27001 exigent, article par article

Les quatre textes ne disent pas la même chose avec la même force. NIS2 pose une obligation de moyens peu détaillée, DORA une liste prescriptive pour le secteur financier, le ReCyF une déclinaison française avec des moyens acceptables de conformité, et l'ISO 27001 quatre contrôles qu'un auditeur voudra voir documentés. Le tableau donne les numéros exacts, vérifiés sur les textes publiés.

NIS2 : une obligation sur vous, muette sur la méthode

L'article 21, paragraphe 2, point d) de la directive (UE) 2022/2555 range "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" parmi les mesures minimales. Le paragraphe 3 précise ce que l'entité doit regarder : "les vulnérabilités propres à chaque fournisseur et prestataire de services direct et la qualité globale des produits et des pratiques de cybersécurité de leurs fournisseurs et prestataires de services, y compris leurs procédures de développement sécurisé". Rien sur la forme : un questionnaire peut suffire, mais un questionnaire contredit par ce que le fournisseur expose ne démontrera pas qu'on a tenu compte de ses vulnérabilités. Le cadre général et le régime de sanctions occupent l'article sur la directive NIS2.

DORA : la version prescriptive, pour le secteur financier

Le chapitre V du règlement (UE) 2022/2554, dit DORA, intitulé "Gestion des risques liés aux prestataires tiers de services TIC", s'applique depuis le 17 janvier 2025. Son article 28 rappelle d'abord que les entités financières "restent à tout moment pleinement responsables" de leurs obligations, contrat ou pas, puis impose au paragraphe 3 le registre d'informations, tenu "au niveau de l'entité et aux niveaux sous-consolidé et consolidé", distinguant les contrats qui soutiennent des fonctions critiques ou importantes ; l'entité déclare au moins une fois par an à l'autorité ses nouveaux accords TIC (nombre, catégories de prestataires, types de contrats, services fournis) et lui remet le registre complet à sa demande. L'article 31 confie aux autorités européennes de surveillance, via leur comité mixte, la désignation des prestataires tiers critiques, placés sous un superviseur principal : un texte européen supervise directement le fournisseur, et plus seulement son client. Le reste du règlement, dont le test d'intrusion fondé sur la menace, est détaillé dans l'article consacré au règlement DORA.

ReCyF : la déclinaison française, encore adossée à un projet de loi

Le Référentiel de cybersécurité France (ReCyF, version 2.5 du 17 mars 2026) traduit NIS2 en vingt objectifs de sécurité, les objectifs 16 à 20 étant réservés aux entités essentielles. L'objectif 3, "Maîtrise de l'écosystème", s'applique aux importantes comme aux essentielles : une liste à jour des prestataires et fournisseurs informatiques "avec lesquels il existe une relation de droit ou de fait", avec le périmètre de chaque prestation, et des processus, "notamment par la voie contractuelle", pour s'assurer que ces prestations respectent les obligations de l'entité. Les moyens acceptables de conformité sont concrets : cartographie de l'écosystème avec les interconnexions (3.A.1), point de contact par entrée (3.A.2), assurances contractuelles comme un plan d'assurance sécurité ou une charte de télémaintenance (3.B.1), vérification périodique pouvant s'appuyer sur des audits (3.B.2). Le détail objectif par objectif est dans notre article sur le ReCyF de l'ANSSI.

ISO 27001 : quatre contrôles, et un auditeur qui veut des traces

L'Annexe A de l'ISO/IEC 27001:2022 consacre quatre contrôles aux fournisseurs, de 5.19 à 5.22 : la sécurité dans les relations fournisseurs, son traitement dans les accords, la chaîne d'approvisionnement TIC, et le suivi et la revue des services fournis. Un auditeur y cherche une politique, des critères de sélection, des clauses et des comptes rendus de revue datés ; le 5.21 bascule côté technique dès qu'il s'agit de composants logiciels intégrés. La lecture thème par thème des 93 contrôles occupe l'article sur l'ISO 27002, et la place du TPRM dans une gouvernance d'ensemble, avec les rôles et les registres qu'il alimente, dans le pilier sur la GRC en cybersécurité.

MOVEit et SolarWinds : ce qu'un programme TPRM aurait changé, et pas changé

Contre un zero-day chez un éditeur, un dispositif de gestion des risques tiers ne peut pas grand-chose, et prétendre l'inverse serait vendre du vent. Dans le cas MOVEit, la note conjointe CISA et FBI du 7 juin 2023 date le début de l'exploitation au 27 mai, par le dépôt d'un web shell baptisé LEMURLOOT sur des instances MOVEit Transfer exposées sur Internet. La CVE est publiée le 2 juin et entre le jour même au catalogue des vulnérabilités exploitées de la CISA. Le 5 juin, Zellis confirme qu'un "petit nombre" de ses clients sont touchés. Le décompte tenu par Emsisoft atteignait, au 28 juin 2024, 2 773 organisations et plus de 95 millions de personnes, dont une part, qu'Emsisoft ne quantifie pas, touchées par l'intermédiaire d'un prestataire plutôt qu'en direct.

Aucun questionnaire n'aurait vu venir l'injection SQL. Le reste du dispositif, lui, aurait changé la suite. Savoir que son prestataire de paie échange ses fichiers via MOVEit Transfer mettait un client de Zellis en position d'appeler le 2 juin, au lieu d'apprendre la nouvelle le 5. Une instance MOVEit Transfer exposée porte une bannière et des chemins reconnaissables, qu'on peut donc repérer sur le domaine d'un tiers sans attendre qu'il en parle. Et une clause de notification chiffrée, assortie d'une assistance écrite, transforme une attente polie en obligation contractuelle. Rien de tout cela n'empêche l'intrusion ; tout cela raccourcit le délai entre l'exploitation et votre première décision.

SolarWinds illustre l'autre famille, l'éditeur dont la mise à jour est le vecteur. Le document 8-K déposé par SolarWinds le 14 décembre 2020 compte environ 33 000 clients Orion sous maintenance et "moins de 18 000" susceptibles d'avoir installé une version contenant le code malveillant, distribuée entre mars et juin 2020. La veille, la directive d'urgence 21-01 de la CISA ordonnait aux agences fédérales de déconnecter ou d'éteindre les produits Orion des versions 2019.4 à 2020.2.1 HF1. Le questionnaire de SolarWinds, à l'époque, aurait coché toutes les cases. Ce qui aurait servi, c'est de savoir en moins d'une heure si vous aviez Orion, quelle version, sur quel segment, et qui avait le droit de le débrancher un dimanche soir. De l'inventaire et de la gouvernance, plus que de la due diligence.

À retenir

• Le TPRM couvre six étapes, inventaire, classification, due diligence, contrat, suivi, sortie. Le questionnaire n'en est qu'une, et il ne remplace ni l'inventaire ni le suivi.
• On classe par dommage possible (données, privilèges, capacité d'interruption, substituabilité), pas par montant facturé, et l'effort de diligence doit changer d'un niveau à l'autre.
• Les clauses qui comptent sont celles du jour de l'incident : délai de notification chiffré, droit d'audit, sous-traitance en cascade encadrée, localisation, réversibilité. DORA en fait une liste à l'article 30.
• Le déclaratif se revoit une fois par an, la surface exposée d'un tiers critique se surveille en continu, et une réévaluation complète se déclenche sur événement.
• NIS2 (art. 21.2 d et 21.3) pose une obligation sur vous, pas sur le fournisseur ; DORA (chapitre V) la rend prescriptive pour la finance ; le ReCyF (objectif 3) la décline en France mais reste adossé à une loi non promulguée au moment de la rédaction (septembre 2026) ; l'ISO 27001 la tient par les contrôles 5.19 à 5.22.
• Un programme qui n'a jamais refusé un fournisseur ni activé une clause n'est pas un programme. Décidez avant le premier questionnaire ce qui se passe si la réponse est mauvaise.

Un tiers critique dont la seule information disponible date du dernier questionnaire est un angle mort, pas une relation maîtrisée. La partie observable, elle, se met sous surveillance en une après-midi : le module supply chain security de l'EASM suit les domaines que vous déclarez et remonte ce qui change. Pour discuter d'un périmètre ou confronter un fournisseur précis à ce qu'il expose, la page contact est le plus court chemin.

Questions fréquentes sur le TPRM