Ressources · 07

Risque tiers numérique : évaluer un fournisseur critique

Relier preuves, dépendances, sous-traitants, continuité et réversibilité avant de confier un service ou des données sensibles.

Mis à jour le 5 novembre 2026 · 7 min

Illustration · scène fictive

Ce que ce guide permet

Distinguer un fournisseur utile d’un tiers réellement critique
Vérifier au-delà du questionnaire déclaratif
Voir les dépendances en chaîne
Préparer une sortie praticable

Contrôle express

Quel service s’arrête si ce tiers devient indisponible ?
Quelles données peut-il lire, transformer ou exporter ?
Quels sous-traitants sont indispensables ?
La restauration a-t-elle été démontrée ?
Peut-on récupérer les données dans un format exploitable ?

Méthode pas à pas

01
Classer la criticité
Reliez chaque tiers aux processus, données, utilisateurs, obligations et délais de reprise. Une dépense élevée n’est pas toujours critique ; une petite API peut l’être.
Livrable : fiche service, impact et propriétaire.
02
Demander des preuves proportionnées
Ciblez architecture, accès, incidents, sauvegardes, tests, certifications utiles et exceptions. Une attestation ne remplace pas la compréhension du périmètre qu’elle couvre.
Livrable : dossier de preuves et points à clarifier.
03
Cartographier la chaîne
Identifiez hébergeurs, processeurs de données, composants SaaS et dépendances géographiques. Recherchez les concentrations communes entre plusieurs fournisseurs.
Livrable : carte des dépendances et concentrations.
04
Tester les scénarios
Évaluez indisponibilité, compromission, perte de données, changement de propriétaire et fin de contrat. Associez à chaque scénario un signal, une décision et une solution de repli.
Livrable : scénarios de rupture et mesures compensatoires.
05
Aligner contrat et opération
Vérifiez que délais de notification, accès aux preuves, sous-traitance, restitution, suppression et assistance de sortie sont applicables dans la réalité.
Livrable : clauses et contrôles opérationnels.
06
Décider et surveiller
Formulez acceptation, remédiation ou refus avec un responsable, une échéance et une preuve de clôture. Réévaluez après un changement majeur ou un incident.
Livrable : décision conditionnelle et plan de suivi.

Comprendre · essayer · décider

Réversibilité SaaS : de la copie au service utilisable

Exercice fictif : une équipe reprend 400 dossiers et 60 pièces jointes chez un autre prestataire. Le critère choisi exige des contenus complets, des droits corrects et un parcours métier sans appel à l’ancien service.

Le test se déroule sur des données et des comptes fictifs dans un environnement autorisé. Un fichier récupéré ne démontre ni la reprise des relations entre objets, ni celle des droits ou des automatisations.

Quatre preuves à distinguer

Élément	Observation dans l’exercice	Contrôle à conserver
Dossiers rapprochés	400 / 400	Comparer identifiants, relations et champs utiles ; le nombre seul ne suffit pas.
Pièces jointes lisibles	58 / 60	Retrouver les deux pièces manquantes et vérifier leurs liens aux dossiers.
Droits d’accès	Un client lit le dossier d’un autre	Rejouer un accès autorisé et un refus attendu avec les identités de test.
Parcours métier	Une étape utilise encore l’ancienne API	Achever la tâche sur la cible sans cette dépendance à l’ancien service.

Faire varier le scénario

Qu’est-ce qui changerait la décision ?

Chaque variante repart du cas initial. Les critères sont ceux de cet exercice, sans note universelle de qualité d’un fournisseur.

Fixer le périmètre
Lister objets attendus, relations, rôles et tâche à réussir.
Reconstituer sur la cible
Consigner pertes, transformations et dépendances restantes.
Faire constater le résultat
Garder version, date, responsable et preuves des tests réussis ou échoués.

Variantes fictives : aucune migration réelle n’est effectuée ici.

Les 60 pièces sont lisibles : est-ce suffisant ?

Nouvel élément: Les deux pièces manquantes sont récupérées.
Conséquence pour la décision: Non : l’accès croisé et l’ancienne API restent à corriger.

Le total est bon, mais les identifiants changent ?

Nouvel élément: Les 400 lignes sont présentes, mais leurs relations ne sont plus résolues.
Conséquence pour la décision: Exiger une table de correspondance et tester les liens ; le total ne prouve pas la fidélité.

Tout s’ouvre, mais l’ancien connecteur reste actif ?

Nouvel élément: Contenus et droits sont réparés, mais le parcours dépend de l’ancien prestataire.
Conséquence pour la décision: Tester le remplacement du connecteur avant de déclarer cette dépendance levée.

Tous les contrôles du périmètre passent ?

Nouvel élément: Contenus, relations, droits et parcours sont vérifiés sans l’ancien service.
Conséquence pour la décision: Valider le périmètre testé avec ses preuves. Cela ne démontre pas la suppression des copies chez l’ancien prestataire.

Exemple d’application

Situation illustrative

Un service dépend d’un fournisseur d’envoi d’emails pour confirmer les commandes. L’équipe documente les accès, les données transmises, les alertes reçues et le délai acceptable en cas d’interruption.

Décision et preuve attendue

Le plan prévoit un contact d’escalade, une vérification de restauration et une solution de continuité testable plutôt qu’une simple clause contractuelle.

Indicateurs de pilotage

Indicateur	Ce qu’il mesure	Première action
Couverture	Tiers critiques avec propriétaire et dossier à jour	Traiter les services sans solution de repli
Preuves valides	Contrôles importants soutenus par une preuve récente	Demander les éléments qui peuvent changer la décision
Concentration	Services dépendant du même acteur ou de la même région	Préparer une alternative réaliste
Réversibilité	Temps et qualité mesurés pour récupérer le service et les données	Tester un export avant le besoin réel

Erreurs fréquentes

Envoyer le même questionnaire à tous les tiers
Confondre certification et absence de risque
Ignorer les sous-traitants du fournisseur
Négocier la sortie sans jamais la tester

Questions fréquentes

Faut-il auditer tous les fournisseurs ?

Non. Commencez par ceux dont la défaillance affecte un service essentiel, des données sensibles, une obligation ou une concentration déjà forte.

Une certification suffit-elle ?

Non. Elle peut constituer une preuve utile, mais son périmètre, sa date, ses exclusions et sa relation avec votre usage doivent être vérifiés.

À quelle fréquence revoir un tiers ?

Selon sa criticité et son rythme de changement, puis après incident, acquisition, changement majeur de service ou évolution importante de la sous-traitance.

VEX et applicabilité produit

Demander une déclaration d’applicabilité reliée au produit livré

Un fournisseur peut fournir une SBOM et un document VEX sans que leur portée corresponde à votre build. Le contrôle consiste à relier ces pièces, la vulnérabilité, la version livrée et les conditions explicites du statut.

Vérifier émetteur, identifiants produit, version, date et héritage des informations dans le document complet.
Demander les justifications de not_affected ou les actions d’affected ; conserver under_investigation comme une incertitude.
Réexaminer la déclaration lors d’une modification du build, des dépendances ou des hypothèses d’exécution.

Lire les statuts VEX et leurs conditions d’applicabilité →

Sources vérifiées le 2026-10-22 · OpenVEX · Specification v0.2.0

Signature et provenance du build

Demander des preuves de provenance interprétables

Une preuve fournisseur devient exploitable lorsque son contenu et son périmètre peuvent être rapprochés d’un produit livré. La confiance doit porter sur une identité et une plateforme autorisées, avec des attentes explicites sur le processus de production.

Identifier artefact, digest, format d’attestation et mode de distribution de la provenance.
Distinguer le niveau SLSA Build déclaré de l’évaluation réelle des exigences et de la confiance dans la plateforme.
Documenter les champs et dépendances non établis ; une liste vide ne démontre pas leur absence.

Lire la fiche de provenance avant déploiement →

Sources vérifiées le 2026-10-22 · SLSA 1.2 · Build: Verifying artifacts · SLSA 1.2 · Build: Provenance · SLSA 1.2 · Build: Track Basics · in-toto · Statement v1 · Sigstore · Verifying Signatures

Explorer le catalogue KEV de CISA

Demander une preuve au fournisseur

Un fournisseur peut utiliser plusieurs composants affectés sous un autre nom commercial. Demander la version, l’applicabilité déclarée et l’action réalisée, avec la référence CVE et une date. Une assurance générale de sécurité ne répond pas à ces questions.

Associer chaque engagement à un produit et une version.
Conserver la preuve de déploiement ou la justification d’inapplicabilité.
Prévoir une réévaluation lors d’une nouvelle notice ou d’un changement de composant.

Consulter le catalogue et sa méthode →

CISA KEV · 2026.11.04 · Consultation documentaire : 2026-11-05

Explorer les résultats du NIST CSF 2.0

Examiner une relation fournisseur au-delà de l’attestation

GV.SC rassemble des résultats de gestion du risque de chaîne d’approvisionnement cyber. L’examen doit porter sur le service acheté et ses dépendances, pas seulement sur l’organisation qui émet une présentation.

GV.SC-04 : connaître et hiérarchiser les fournisseurs selon leur criticité.
GV.SC-05 : intégrer les exigences pertinentes aux contrats et autres accords.
GV.SC-08 : inclure les tiers concernés dans la préparation, la réponse et la reprise.
GV.SC-10 : prévoir les activités de fin de relation et leurs responsabilités.

Explorer les résultats et les preuves à examiner →

NIST CSWP 29 · CSF 2.0 · 2024-02-26 · 2026-10-22

RDAP : enregistrement, rôles et données masquées

Le domaine d’un fournisseur est une piste à recouper

La revue RDAP complète une due diligence documentaire : elle aide à examiner l’enregistrement et ses événements, mais ne prouve ni l’identité légale du prestataire ni son contrôle effectif au moment de la décision.

Rapprocher le domaine du dossier fournisseur et des sources indépendantes.
Distinguer registrar, titulaire déclaré et prestataires techniques.
Examiner les dates avec leur libellé exact et documenter les points non confirmés.

Ouvrir le dossier RDAP et le lecteur local →

IETF · RFC 9083 · RDAP JSON Responses · June 2021 · §§4–5, 9–10

Extensions : permissions et accès

Une extension est aussi une dépendance du poste

L’accès d’une extension peut couvrir une session métier tout en dépendant d’un éditeur et d’un composant natif. Compléter la revue fournisseur avec le manifeste de la version testée et les réglages réellement appliqués.

Relier identifiant, version et source de distribution au fournisseur évalué.
Comparer permissions requises, options accordées et sites observés ; conserver la preuve de chacun de ces états.
Documenter le changement d’éditeur, de permissions ou de composant natif comme déclencheur de réexamen.

Consulter le répertoire et les exemples de manifestes →

Microsoft Learn · Manage Microsoft Edge extensions using group policies · Enterprise policy documentation consulted 2026-10-23

Supports : assainissement et preuves

Comparer la promesse d’effacement aux preuves du fournisseur

Une clause « données supprimées » peut couvrir une opération applicative, des copies ou une fin de vie de supports. Demander un périmètre explicite et le rapprochement entre les éléments confiés au prestataire et les éléments effectivement traités.

Identifier la méthode, la technique, l’outil et le support concernés par chaque attestation.
Demander séparément les résultats de vérification et la décision de validation.
Pour le cloud, examiner frontière chiffrée, gestion des clés et copies selon les responsabilités contractuelles.

Lire les méthodes, les repères de preuve et les situations commentées →

NIST · SP 800-88 Rev. 2 · Guidelines for Media Sanitization · Final · 2025-09-26 · consulted 2026-10-23

CSP : directives, replis et parcours

Décrire les ressources du tiers avant d’assouplir CSP

Un ajout de script peut aussi charger des images, ouvrir une connexion ou intégrer un cadre. Recensez ces besoins par parcours et examinez chaque politique reçue plutôt que de réunir toutes les origines en une autorisation globale.

Distinguer chargement d’un iframe et droit d’intégrer votre propre page.
Lire le repli effectif pour scripts, workers et connexions.
Tester le besoin documenté du tiers sans ajouter un joker pour faire disparaître une erreur.

Lire les replis CSP et explorer les huit scénarios →

W3C · Content Security Policy Level 3 · Mike West, Antonio Sartori · Working Draft · 2026-09-16 · work in progress · §2.2.1, §3, §6.8.3–6.8.4, §8.1

Références officielles

Date de consultation des références : 23/10/2026. La méthode et la fiche de travail proposent des contrôles à adapter à votre contexte ; elles ne constituent pas une certification.