Risque de 4ème partie : le point aveugle de la gestion fournisseur

Qu'est-ce que le risque de quatrième partie ?

Votre due diligence porte sur vos fournisseurs directs — ceux avec qui vous avez signé un contrat, à qui vous avez envoyé un questionnaire, dont vous suivez la criticité. Mais chacun de ces fournisseurs dépend à son tour de ses propres prestataires : un hébergeur cloud, un sous-traitant de paiement, une plateforme de support client externalisée, un cabinet de maintenance IT. Ces entités — les 4èmes parties — n'ont aucun lien contractuel avec vous, et pourtant leur défaillance ou leur compromission peut affecter directement le service que votre fournisseur vous rend, ou la sécurité des données que vous lui avez confiées.

Le risque de 4ème partie (fourth-party risk) est structurellement plus difficile à gérer que le risque fournisseur direct, pour une raison simple : vous n'avez ni relation contractuelle, ni levier de négociation, ni accès direct à cette entité. Votre seule voie d'action passe par votre fournisseur direct, à qui il faut demander de rendre visible sa propre chaîne de sous-traitance — une démarche qui n'est ni systématique, ni toujours bien accueillie commercialement.

Ce risque s'est révélé de manière spectaculaire dans plusieurs incidents majeurs de ces dernières années : des compromissions massives où l'entreprise victime finale n'avait même pas connaissance de l'existence du sous-traitant technique à l'origine de la faille, plusieurs niveaux en amont de sa relation contractuelle directe.

Pourquoi ce risque reste-t-il structurellement sous-évalué ?

L'effort de due diligence s'arrête, par défaut, au premier niveau. La plupart des processus de gestion fournisseur, même matures, s'arrêtent à l'évaluation du fournisseur direct. Interroger systématiquement chaque fournisseur sur sa propre chaîne de sous-traitance demande un effort supplémentaire que peu d'organisations formalisent — faute de temps, de méthode, ou simplement parce que la question ne se pose pas avant qu'un incident ne la révèle.

Les fournisseurs eux-mêmes n'ont pas toujours cette visibilité en interne. Un fournisseur peut lui-même mal connaître l'étendue de sa propre chaîne de sous-traitance technique, en particulier pour des services cloud composés de multiples couches d'infrastructure. Demander la transparence à un tiers qui ne l'a pas en interne relève de la gageure.

Il n'existe pas de levier contractuel automatique. Sans clause explicite exigeant du fournisseur qu'il déclare et encadre ses propres sous-traitants — avec transfert des mêmes garanties de sécurité — rien n'oblige structurellement à cette transparence. Le RGPD impose ce principe pour les sous-traitants de données personnelles (article 28), mais son application reste inégale en pratique.

L'incident chez un sous-traitant de rang 2 est rarement notifié à temps. Même quand une clause contractuelle existe, la remontée d'information depuis le sous-traitant de rang 2 vers le fournisseur direct, puis vers l'entreprise finale, ajoute des délais — chaque maillon supplémentaire ralentit la détection et la réaction.

Comment étendre la cartographie sans étendre le contrat ?

La gestion du risque de 4ème partie ne peut pas reposer sur les mêmes mécanismes que le risque fournisseur direct — elle exige une approche adaptée à l'absence de lien contractuel.

1. Documenter la chaîne déclarée, même sans levier contractuel direct. L'objectif réaliste n'est pas d'auditer chaque sous-traitant de rang 2 comme un fournisseur direct, mais d'obtenir de chaque fournisseur critique une déclaration structurée de ses propres dépendances significatives — hébergement, paiement, support, infrastructure critique.

2. Prioriser par criticité du fournisseur direct, pas de manière exhaustive. Documenter la chaîne de sous-traitance de tous les fournisseurs, sans distinction, n'est ni réaliste ni utile. L'effort doit se concentrer sur les fournisseurs déjà classés critiques, où une défaillance de rang 2 aurait un impact direct sur une activité essentielle.

3. Imposer contractuellement la transparence et la notification. Pour les relations les plus sensibles, la clause contractuelle doit exiger non seulement la déclaration des sous-traitants significatifs, mais aussi leur notification en cas de changement et leur obligation d'alerte en cas d'incident touchant l'un d'eux — un principe déjà consacré par le RGPD pour les sous-traitants ultérieurs.

4. Traiter tout incident déclaré par un fournisseur comme potentiellement issu de sa propre chaîne. Sur le plan opérationnel, il est souvent plus efficace de traiter chaque incident remonté par un fournisseur avec la question systématique « est-ce chez lui, ou chez l'un de ses propres prestataires ? », plutôt que d'attendre une cartographie exhaustive préalable — la vigilance sur l'origine réelle de l'incident est souvent le déclencheur le plus concret de la démarche.

5. Relier la chaîne déclarée à la cartographie de concentration existante. Si plusieurs fournisseurs directs déclarent dépendre du même sous-traitant en amont, cette information doit remonter dans l'analyse de concentration globale — un SPOF de rang 2 peut être plus dangereux qu'un SPOF de rang 1, précisément parce qu'il reste invisible plus longtemps.

Comment CISAPP donne-t-il de la visibilité sur cette chaîne ?

CISAPP ne prétend pas éliminer le risque de 4ème partie — aucun outil ne le peut sans lien contractuel direct — mais structure les mécanismes qui permettent de le documenter et d'y réagir.

Une fiche fournisseur qui capture le contexte déclaré, pas seulement le contrat. Chaque fiche fournisseur dans CISAPP conserve un historique et des notes de contexte permettant de documenter les dépendances significatives déclarées par le fournisseur — hébergeur, sous-traitant technique critique — au même endroit que le reste de son dossier de due diligence, plutôt que dans un email perdu.

Le registre RGPD pour les sous-traitants de données personnelles. Le module registres de traitement RGPD (/gdpr/registries) documente explicitement les sous-traitants et leurs propres transferts, conformément à l'article 28 — la chaîne de sous-traitance sur les données personnelles est donc nativement tracée, avec les destinataires et transferts associés à chaque activité de traitement.

Des incidents reçus qui révèlent la chaîne réelle au moment où elle compte. La fonctionnalité d'incidents reçus (propagation cross-organisation) permet de recevoir la notification d'un incident déclaré par un fournisseur — y compris lorsque la cause racine remonte à l'un de ses propres prestataires. C'est souvent le moment où la chaîne de 4ème partie devient concrète et exploitable, plutôt qu'un exercice théorique de cartographie exhaustive.

Une cartographie de concentration qui absorbe l'information au fur et à mesure. Quand une dépendance de rang 2 partagée entre plusieurs fournisseurs directs est identifiée — via due diligence, incident ou déclaration contractuelle — elle peut être documentée au niveau de l'activité ou du risque concerné, et vient enrichir la cartographie de concentration globale plutôt que de rester une information isolée.

Le risque de 4ème partie ne se résout pas avec un audit — il se pilote avec de la documentation continue, de la priorisation, et une réactivité rapide au moment où il se matérialise. CISAPP donne aux équipes risque et sécurité un endroit unique pour capturer ce contexte étendu, plutôt que de le laisser dispersé entre emails, contrats et mémoire individuelle.