La sécurité de votre organisation n’est pas plus solide que celle de son fournisseur le plus faible. Cela peut sembler banal, jusqu’au jour où des contrôles d’accès insuffisants chez un prestataire interrompent vos opérations, ou lorsqu’un régulateur vous demande pourquoi vous n’avez pas validé la résilience de vos partenaires critiques.

Des réglementations telles que NIS2 et DORA ont fait de la gouvernance des fournisseurs un sujet relevant des instances dirigeantes, non parce que les régulateurs apprécient la paperasserie, mais parce que les incidents de chaîne d’approvisionnement sont devenus trop fréquents et trop dommageables pour être considérés comme le problème de quelqu’un d’autre. Cet article propose un cadre pratique et sans détour pour dépasser les simples questionnaires fournisseurs. Il explique où commence réellement la majorité du risque tiers, comment détecter les concentrations avant qu’elles ne causent des dommages et pourquoi la planification de sortie est indispensable.

Le risque commence avant le contrat

Une part considérable du risque tiers est acceptée dès lors que les achats, le juridique et la sécurité ne participent pas à la même discussion. Trop de contrats sont signés alors que la sécurité n’intervient qu’en validation formelle, une fois les conditions commerciales verrouillées. Il en résulte des droits d’audit faibles, des clauses de notification d’incident vagues et aucune responsabilité opérationnelle claire.

La meilleure gouvernance des fournisseurs commence par les exigences que l’organisation est prête à faire respecter pendant la négociation, et non après. Une règle simple s’applique : si un fournisseur critique refuse une clause de droit d’audit, il s’agit d’une décision de risque qui doit avoir un responsable et une acceptation documentée, et non être ignorée.

Prenons l’exemple d’un industriel ayant signé un contrat pluriannuel avec un nouveau fournisseur d’ERP cloud sans intégrer d’exigences de sécurité dans le SLA. Lorsque la relation s’est dégradée, le fournisseur a refusé de communiquer des rapports d’audit critiques. La remédiation a coûté une somme à six chiffres et pris plusieurs mois. La leçon n’était pas que le fournisseur était difficile, mais que rien dans le contrat ne l’obligeait à coopérer.

Les clauses de droit d’audit, les délais de notification d’incident, les obligations de traitement des données et les conditions de sortie ne sont pas des compléments juridiques. Ce sont des contrôles de sécurité exprimés en langage commercial. S’ils ne figurent pas dans le contrat, ils n’existent pas.

La réalité de NIS2 : vous répondez de leur défaillance

Dans le cadre de NIS2, si un fournisseur critique est compromis et que votre service devient indisponible, le régulateur tiendra votre organisation responsable, et pas uniquement le prestataire. La directive est explicite : les entités essentielles et importantes doivent gérer les risques de sécurité posés par leurs fournisseurs et prestataires de services.

Il ne s’agit pas d’une attente générale de bonne conduite, mais d’une obligation de conformité assortie de conséquences en matière de contrôle et de sanction.

Une entreprise énergétique supposait que son prestataire de maintenance SCADA était sécurisé. Une analyse des écarts a révélé l’utilisation d’identifiants administrateurs partagés et non corrigés chez plusieurs clients. Le problème a été traité avant de devenir une notification de violation. C’est le niveau de validation active désormais attendu par les régulateurs. Demander « êtes-vous conforme ? » ne suffit pas. Il faut examiner des preuves et continuer à le faire régulièrement.

Le minimum que la plupart des organisations devraient appliquer à leurs fournisseurs critiques comprend :

  • Un questionnaire annuel de sécurité validé par des preuves et non par une simple auto-déclaration
  • Une clause de droit d’audit réellement utilisée
  • Des obligations de notification d’incident assorties de délais définis
  • Des preuves des tests effectués par le fournisseur et de ses capacités de résilience

Pour les fournisseurs les plus critiques, cette base n’est qu’un point de départ.

Ce qu’un bon registre des tiers doit réellement révéler

Répertorier les fournisseurs n’est qu’un début. La véritable valeur réside dans ce que le registre permet de mettre en évidence.

Pour un client bancaire, une simple liste de prestataires ne suffisait pas. Le registre a été enrichi et a révélé que 40 % du traitement des paiements critiques dépendait d’une seule région cloud située à Francfort. Cette visibilité a permis de concevoir une stratégie de bascule multirégion avant qu’une panne régionale n’affecte les clients. Le registre n’a pas dicté la solution, mais il a rendu l’exposition impossible à ignorer.

Un registre tiers mature indique :

  • Le risque de concentration : nombre de services critiques dépendant d’un fournisseur ou d’une zone géographique unique
  • Les options de sortie insuffisantes : relations dont il est pratiquement impossible de sortir
  • Les dépendances fragiles : fournisseurs constituant un point unique de défaillance pour un processus critique
  • Les lacunes de qualité contractuelle : protections contractuelles qui ne correspondent pas à la criticité de la relation

DORA impose aux entités financières de tenir un registre d’informations sur l’ensemble des accords contractuels conclus avec des prestataires tiers de services TIC. Le règlement précise le contenu attendu. Même hors du secteur financier, le principe demeure : si le registre ne permet pas d’identifier les risques, il ne s’agit que d’un tableur enrichi de quelques étapes supplémentaires.

La responsabilité partagée n’est pas une clause d’exonération

Trop d’organisations migrent vers AWS, Azure ou Google Cloud en supposant que le fournisseur prend tout en charge. Le modèle de responsabilité partagée est précis. AWS sécurise le cloud ; l’organisation reste responsable de ce qu’elle y place : données, configuration, accès, surveillance et sauvegardes.

Un client a subi une fuite de données parce qu’il pensait que son fournisseur SaaS sauvegardait les données de configuration. Les conditions générales précisaient explicitement que cette responsabilité incombait au client. Personne ne les avait lues avec suffisamment d’attention. Les hypothèses se sont transformées en exposition.

Un modèle clair de gouvernance du cloud supprime cette ambiguïté. Il faut documenter qui est responsable de la journalisation, de la restauration, de la gestion des accès et de la réponse aux incidents, puis tester le dispositif. Une hypothèse non documentée et une hypothèse documentée mais jamais testée sont tout aussi dangereuses lors d’un incident réel.

La planification de sortie fait partie de la résilience

Une dépendance n’est pas véritablement maîtrisée lorsqu’aucune voie de sortie crédible n’existe. Cela concerne aussi bien les fournisseurs cloud que les services managés, les plateformes logicielles et les cabinets spécialisés.

Lors d’un projet de préparation à DORA pour un assureur, une question simple a été posée au fournisseur du système central de gestion des polices : « Si vous faites faillite demain, comment récupérons-nous nos données dans les 48 heures ? » Aucun processus automatisé d’exportation n’existait. Il aurait fallu plusieurs semaines, voire davantage, pour récupérer les données dans un format exploitable. Un dépôt mensuel des données sous séquestre a été imposé comme condition de renouvellement du contrat.

Si les contrats avec les fournisseurs critiques ne comportent pas de clause de sortie décrivant des étapes concrètes — format des données, délai, partie responsable et coût —, l’organisation n’est pas résiliente. Elle est captive et ne découvrira l’ampleur de cette dépendance que lorsqu’il sera trop tard pour négocier.

La planification de sortie ne signifie pas que l’on s’attend à l’échec des relations. Elle consiste à conserver la capacité d’agir lorsque cela se produit.

L’intégration des fournisseurs transforme les exigences en réalité

Une politique fournisseurs n’a de valeur que si le processus d’intégration la fait respecter. De nombreuses organisations disposent de politiques solides sur le papier mais de contrôles d’entrée faibles en pratique. Le moment où un nouveau prestataire demande un accès est souvent celui où les exigences disparaissent silencieusement sous la pression commerciale.

Dans une entreprise financière, un processus a été conçu pour qu’aucun fournisseur ne puisse être créé dans le système de gestion des identités avant l’examen de son rapport SOC 2 Type II, la vérification et l’enregistrement de ses coordonnées d’incident dans l’outil GRC, ainsi que la confirmation de ses obligations de classification des données. Au cours du premier mois, ce dispositif a empêché trois fournisseurs à haut risque d’accéder au réseau.

Des points de contrôle pratiques sur la création des accès, la confirmation du traitement des données, l’examen des preuves et l’enregistrement des contacts d’incident transforment une bonne politique en un contrôle réel. Sans ces contrôles, l’intégration se limite à un courriel de bienvenue.

La prolifération du SaaS est un problème de GRC, pas seulement d’inventaire informatique

Des départements marketing souscrivent à des outils au moyen de cartes d’entreprise sans qu’aucune analyse de sécurité ne soit réalisée. Au fil du temps, le nombre de plateformes non gouvernées augmente, tout comme l’exposition.

Des listes de clients ont déjà été téléversées pour entraîner des modèles publics d’apprentissage automatique parce que personne n’avait vérifié les conditions d’utilisation du fournisseur. Le marketing n’en avait pas conscience, l’informatique n’avait aucune visibilité et l’équipe GRC n’avait pas été informée. Les données étaient déjà publiques au moment où le problème a été identifié.

La prolifération du SaaS entraîne une dérive des accès, une propriété des données mal définie, des conditions contractuelles non examinées et une exposition cachée aux fournisseurs. C’est un sujet de GRC, car les risques concernent la gouvernance — responsabilité, traitement des données, supervision des tiers et réponse aux incidents — et pas uniquement la technique.

Si le parc SaaS croît plus vite que la capacité de supervision, il faut commencer par un exercice de découverte. On ne peut pas gouverner ce dont on ignore l’existence.

Conclusion et prochaines étapes

Le risque tiers n’est plus une tâche administrative de conformité. Il se situe au cœur de la résilience opérationnelle et constitue, au titre de NIS2 et de DORA, une obligation juridique directe pour un large éventail d’organisations européennes.

En intégrant la sécurité aux achats avant la signature des contrats, en appliquant des contrôles stricts lors de l’intégration, en maintenant un registre qui révèle les risques de concentration et de sortie, et en supervisant l’environnement cloud et SaaS, la chaîne d’approvisionnement cesse d’être une vulnérabilité pour devenir un écosystème géré et résilient.

Prochaine étape : téléchargez gratuitement la Liste de contrôle d’audit des contrats fournisseurs pour NIS2 et DORA. Aucun formulaire d’accès par courriel : le téléchargement est direct et le document est conçu pour être utilisé.

Pour examiner d’abord votre modèle actuel de gestion des risques tiers, contactez GRCForce pour un bref échange de diagnostic.