Kantyra
Kantyra
Kantyra · 25-07-2026 · 13 min leestijd
Pendant des années, la gestion des fournisseurs en sécurité de l'information a été ce registre que l'on remplissait pour l'auditeur avant de ne plus y toucher pendant un an. Les chiffres montrent à quel point c'est devenu imprudent. Lorsque l'Agence de l'Union européenne pour la cybersécurité (ENISA) a disséqué vingt-quatre attaques de chaîne d'approvisionnement en 2021, 62 pour cent d'entre elles exploitaient la confiance que le client plaçait dans son fournisseur. L'attaquant entre par la partie que vous avez précisément laissée entrer. Avec la directive NIS2 et le règlement sur la résilience opérationnelle numérique (DORA), le temps du facultatif est en outre juridiquement révolu, car tous deux posent des exigences sur la maîtrise de votre chaîne. Il est donc temps d'organiser sérieusement le sujet. Mais c'est là que commence la confusion, car « gestion des fournisseurs » signifie trois choses différentes dans trois parties de l'organisation, et un quatrième terme plane au-dessus, le third party risk management (TPRM). Cet article les met côte à côte.
Prenez une organisation qui a externalisé sa paie. Avec ce seul fournisseur, trois conversations totalement différentes sont en cours, et chacune a son propre responsable, son propre rythme et son propre registre.
La première conversation appartient aux achats. Il y est question du contrat, du prix, de la durée, des conditions de livraison et de la question de savoir si l'organisation en a pour son argent. Ce métier s'appelle gestion des contrats ou vendor management, il vit dans un registre de contrats, et il connaît ses propres moments, à savoir l'appel d'offres, le renouvellement et la négociation. La question à laquelle répond cette conversation est de savoir si les accords sont justes et respectés.
La deuxième conversation appartient au service informatique. Dans l'Information Technology Infrastructure Library (ITIL) et l'ISO/IEC 20000, cela s'appelle supplier management, et il s'agit du service au quotidien. Les niveaux de disponibilité convenus sont-ils atteints, à quelle vitesse les incidents sont-ils pris en charge, comment se déroulent les changements et qui escalade quand cela tourne mal. Cette conversation vit dans l'environnement de gestion des services, à côté de la base de données de configuration (CMDB), et son rythme est celui de l'exploitation, donc hebdomadaire ou mensuel. La question est ici de savoir si le service fait ce dont les utilisateurs ont besoin.
La troisième conversation est celle de la sécurité de l'information, et elle pose une question fondamentalement différente. Quel risque court notre information du fait que ce fournisseur y accède, la traite ou l'héberge ? Qu'advient-il de la confidentialité, de l'intégrité et de la disponibilité de nos données si cette partie est compromise, tombe en panne ou fait faillite ? L'ISO/IEC 27001 y consacre quatre mesures, 5.19 à 5.22, de la politique et des clauses contractuelles à la surveillance des changements chez le fournisseur. Cette conversation a sa place dans votre système de management de la sécurité de l'information (SMSI), avec le responsable de la sécurité des systèmes d'information (RSSI) comme animateur du processus et un propriétaire par fournisseur.
Les trois conversations se ressemblent parce qu'elles concernent la même partie, mais elles diffèrent en tout ce qui compte. Les comprimer dans un seul registre donne une liste qui convient presque à tout le monde, donc à personne. Les laisser exister totalement séparées fait manquer les liens, car un renouvellement de contrat est précisément le moment d'imposer des exigences de sécurité, et une série d'incidents opérationnels est souvent le premier signal que quelque chose de structurel ne va pas chez le fournisseur. L'art consiste à laisser trois registres faire leur propre travail et à relier les moments.
Beaucoup de RSSI se demandent si le third party risk management est une discipline distincte qu'il faudrait encore mettre en place en plus du reste. La réponse courte est non. Le TPRM est le nom anglo-saxon du même champ de travail, avec deux différences d'accent qui méritent d'être connues.
La première différence tient au mot « third party ». C'est plus large que « fournisseur », car cela couvre aussi des parties qui n'envoient jamais de facture, comme les partenaires de chaîne, les franchisés, les intermédiaires et les services gratuits par lesquels transitent vos données. Pour votre image du risque, cette distinction est réelle : la plateforme sectorielle avec laquelle vous échangez des données n'est pas un fournisseur, mais elle mérite la même évaluation.
La seconde différence tient à la largeur de la notion de risque. Les programmes TPRM des grandes organisations regardent, au-delà de la sécurité de l'information, la continuité, la conformité, la santé financière et la réputation du tiers. La gestion des fournisseurs en sécurité de l'information est, dans cette lecture, le noyau sécurité du TPRM, et ce noyau est ce que l'ISO 27001 et NIS2 vous demandent. DORA se positionne un peu différemment. Le règlement se limite aux prestataires de services informatiques, mais exige au sein de ce groupe justement plus que la seule sécurité de l'information, car la continuité, le risque de concentration et une stratégie de sortie en font expressément partie. Seule la réputation reste, même sous DORA, un ajout volontaire.
La conclusion pratique est la même que pour les actifs dans un article précédent de cette série. Ne mettez pas en place deux processus. Tenez un seul registre des fournisseurs au niveau du risque, donnez à chaque partie un propriétaire et une criticité, et attachez à chaque ligne les attributs que chaque cadre demande. Que vous appeliez ensuite l'ensemble TPRM ou gestion des fournisseurs relève du style maison, pas du fond.
Le risque fournisseur est l'un des domaines où l'économie de la sécurité de l'information explique davantage que la technique. Kunreuther et Heal ont montré en 2003 ce qui se passe lorsque votre sécurité dépend des investissements des autres, une situation qu'ils ont appelée interdependent security. Leur analyse de théorie des jeux comporte des équilibres où personne n'investit, parce que la protection que vous achetez vaut peu tant que vos voisins ne font rien. Anderson et Moore ont exposé dans Science pourquoi la sécurité de l'information échoue si souvent économiquement plutôt que techniquement, car celui qui sécurise porte les coûts tandis qu'une partie du dommage retombe ailleurs. Ensemble, ces deux idées expliquent pourquoi la sécurité de la chaîne a pu rester un parent pauvre pendant des décennies, et pourquoi le législateur déplace les incitations avec NIS2 et DORA : le devoir de vigilance fait du risque de votre fournisseur votre responsabilité démontrable.
Le domaine lui-même est jeune. Boyson a décrit en 2014, sur la base d'un programme de recherche pluriannuel pour le National Institute of Standards and Technology (NIST) américain, le cyber supply chain risk management comme une discipline en construction, dans laquelle la plupart des organisations opéraient encore au coup par coup. Ghadge et ses collègues sont parvenus à une conclusion comparable dans leur revue systématique de la littérature, car la recherche sur le cyberrisque entre organisations s'est révélée rare comparée à la recherche à l'intérieur des murs, alors que ce sont précisément les interfaces qui portent le risque.
La recherche la plus proche de la pratique est récente. Slapničar, Vidmar et Tsen ont construit, à partir de 33 entretiens et d'une enquête auprès de 53 experts en sécurité, une théorie du processus d'évaluation des fournisseurs. Deux constats méritent l'attention. Premièrement, le processus fonctionne, car une évaluation structurée distingue les fournisseurs risqués des moins risqués. Deuxièmement, il ne fonctionne que si la profondeur de l'évaluation suit la criticité du fournisseur, parce que personne n'a la capacité d'évaluer chaque partie avec la même intensité. Envoyer des questionnaires sans différenciation produit des piles de formulaires sans réponse et aucune image du risque.
Une note sobre sur les certificats s'impose ici. Lins, Schneider et Sunyaev ont montré qu'un certificat est un instantané, car entre deux audits la réalité chez un service cloud peut considérablement bouger. Un certificat ISO 27001 de votre fournisseur est donc une exigence sensée et un bon point de départ, mais il ne remplace pas votre propre évaluation, et pour vos fournisseurs les plus critiques vous voudrez des preuves complémentaires, comme des résultats récents de tests d'intrusion ou un rapport d'assurance.
La directive NIS2 nomme la sécurité de la chaîne d'approvisionnement en toutes lettres comme composante obligatoire du devoir de vigilance, y compris les aspects de sécurité des relations avec les fournisseurs et prestataires directs. Les mesures doivent être proportionnées au risque, ce qui fait de la cotation de criticité de vos fournisseurs non pas un luxe administratif mais la justification de votre proportionnalité. L'organe de direction approuve les mesures et en répond.
DORA va considérablement plus loin pour les entités financières, mais uniquement pour les tiers qui fournissent des services informatiques ; l'externalisation hors informatique relève des orientations distinctes des autorités européennes de surveillance. Le chapitre V règle la gestion du risque lié aux prestataires tiers de services informatiques jusqu'au niveau du contrat, avec des clauses contractuelles prescrites, un article dédié au risque de concentration, une stratégie de sortie qui couvre aussi la défaillance ou le déclin du prestataire, et le registre d'informations sur tous les accords contractuels avec les prestataires de services informatiques, transmis à l'autorité de surveillance sur demande. Dans son périmètre, DORA exige donc expressément plus que la seule sécurité de l'information, car la continuité et la substituabilité pèsent tout autant. Les prestataires les plus critiques passent en outre sous surveillance européenne directe. Qui relève de DORA ne peut donc plus limiter la gestion des fournisseurs à une revue annuelle, car le registre lui-même devient un produit de surveillance.
Dans Kantyra, la gestion des fournisseurs en sécurité de l'information est un cycle continu de six étapes, et l'image le résume.
L'ordre est délibérément guidé par le risque, exactement comme le conseille la recherche de Slapničar et ses collègues : la criticité des étapes 1 et 2 détermine le poids des étapes 3 et 4, afin que votre capacité aille aux fournisseurs qui comptent vraiment.
Les six étapes traversent ainsi les quatre phases du modèle derrière Kantyra. Enregistrer et relier relèvent de Détecter, car c'est là que vous consignez les faits. Confronter, interroger et évaluer forment ensemble la phase Évaluer, dans laquelle naît le jugement sur le fournisseur. L'étape de surveillance appartient à Résoudre et à Démontrer : les tâches et signaux automatiques garantissent que les accords sont tenus, et les questionnaires, évaluations et historiques de revue consignés sont précisément la preuve qu'un auditeur ou une autorité de surveillance veut voir. La gestion des fournisseurs n'est donc pas de l'entretien de registre en phase de détection, mais un cycle à travers tout le modèle.
Si vous lisez ceci sans processus opérationnel, vous n'avez pas besoin de commencer par un registre complet de deux cents parties. Commencez par les dix fournisseurs dont la compromission ou la défaillance toucherait directement votre processus principal, et faites parcourir les six étapes à ces dix-là. Ensuite, le registre grandit de lui-même avec chaque achat et chaque analyse d'impact relative à la protection des données (AIPD) qui révèle un nouveau sous-traitant. La différence entre un parent pauvre et un processus qui fonctionne ne tient pas à la taille de la liste, mais à la question de savoir si quelqu'un, avec un nom, se sent responsable de chaque ligne.
Sources normatives, directement consultables :
Littérature scientifique :
In een demo van 30 minuten lopen we het model door aan de hand van jouw situatie.
Plan een demoCe que la science dit de la matrice des risques probabilité multipliée par impact, et comment travailler avec elle de manière responsable.
Pourquoi votre tableur NIS2 est un bon début mais pas encore une preuve, et comment arriver en trois étapes à un registre démontrable.