TPRM pour équipes techniques : évaluer la sécurité de vos fournisseurs

Votre équipe utilise une nouvelle librairie open source. Le RSSI demande "vous avez évalué le risque fournisseur ?". Vous répondez "c'est open source, y'a pas de fournisseur". Sauf que le mainteneur unique vient de passer la main à un inconnu, et le package a 50 millions de téléchargements par mois.

Le TPRM (Third-Party Risk Management) n'est plus un sujet réservé aux achats ou à la GRC. Chaque fois qu'une équipe intègre un SaaS, une API, une librairie ou un prestataire ayant accès à ses systèmes, elle introduit un risque tiers dans son système d'information.

Ce que vous allez apprendre

Ce qu'est le TPRM et pourquoi les équipes techniques sont concernées
Comment évaluer rapidement un fournisseur ou composant externe
Les questions techniques essentielles à poser et les preuves à demander
Comment scorer et prioriser vos fournisseurs selon leur criticité

Prérequis

Notions de base sur la supply chain security
Compréhension des enjeux de sécurité applicative

Qu'est-ce que le TPRM (Third-Party Risk Management) ?

Définition simple

Le TPRM (Third-Party Risk Management) est l'ensemble des pratiques permettant d'identifier, évaluer et gérer les risques liés aux tiers avec lesquels vous travaillez :

Fournisseurs SaaS : les services cloud que vous intégrez (Auth0, Stripe, Datadog, etc.)
Librairies et packages : les dépendances open source ou propriétaires
Prestataires : infogérants, développeurs externes, ESN
APIs tierces : services d'enrichissement de données, paiement, notification

Pourquoi les équipes techniques sont concernées

Traditionnellement, le TPRM était géré par les équipes achats ou GRC. Mais la réalité a changé :

Avant	Maintenant
L'achat d'un logiciel passe par les achats	Un `npm install` suffit pour ajouter une dépendance
Le contrat cadre le risque	Le code open source n'a pas de contrat
On évalue avant d'acheter	On découvre les dépendances transitives après
Quelques fournisseurs stratégiques	Des centaines de dépendances par projet

Le problème : les équipes techniques prennent des décisions d'intégration (SaaS, packages, APIs) sans toujours évaluer le risque fournisseur associé.

Les risques concrets d'une mauvaise gestion des tiers

Le tableau ci-dessous associe chaque famille de risque à un incident public qui l'a matérialisée. Lisez-le en cherchant votre propre équivalent : la colonne « Exemple réel » sert à mesurer si le scénario est plausible chez vous, pas à raconter l'histoire du secteur. Notez que quatre risques sur six ne sont pas des attaques : l'abandon de maintenance, la faille héritée et la rupture de service arrivent bien plus souvent qu'une compromission volontaire, et ce sont pourtant ceux qu'on oublie de traiter.

Risque	Exemple réel	Impact
Compromission fournisseur	SolarWinds (2020)	Supply chain attack via mise à jour
Abandon de maintenance	left-pad (2016)	Casse de milliers de builds
Transfert de propriété	Polyfill.io (2024)	Injection de code malveillant
Faille non corrigée	Log4Shell dans une dépendance transitive	Vulnérabilité critique héritée
Non-conformité	SaaS non RGPD-compliant	Sanctions réglementaires
Rupture de service	Panne d'un SaaS critique	Indisponibilité de votre application

Approche pratique inspirée du NIST 800-161

Le NIST SP 800-161 Rev. 1 propose un cadre de pratiques de Cyber Supply Chain Risk Management (C-SCRM), orienté principalement vers les agences fédérales américaines. Ce n'est pas un "framework clé en main" directement transposable, mais ses principes restent pertinents pour structurer votre démarche.

Pour les équipes techniques, ces principes se traduisent en 4 actions opérationnelles : inventorier, évaluer, décider, suivre.

Les 4 actions opérationnelles du C-SCRM

Ces quatre actions forment une boucle, pas une checklist qu'on coche une fois. Le schéma les présente dans l'ordre d'exécution, et la colonne Fréquence du tableau donne l'information la plus importante : seul Identifier tourne en continu, les trois autres se déclenchent sur événement ou sur calendrier. Une démarche qui s'arrête après l'évaluation initiale laisse un inventaire figé qui se périme en quelques mois, au rythme des changements de mainteneurs et des rachats de fournisseurs.

Les 4 piliers du C-SCRM : Identifier, Évaluer, Répondre, Suivre

Pilier	Ce que vous faites	Fréquence
Identifier	Lister tous vos tiers (SaaS, packages, prestataires)	Continue
Évaluer	Scorer chaque tiers selon des critères de risque	À l'onboarding + périodique
Répondre	Décider : accepter, atténuer, ou refuser le risque	Selon évaluation
Suivre	Revoir périodiquement, réagir aux incidents	Trimestriel/Annuel

Étape 1 : Inventorier vos tiers

Les 5 catégories de tiers à tracker

Cette découpe existe parce que chaque catégorie se recense avec un outil différent : un SBOM pour les packages, la facturation ou le SSO pour les SaaS, les comptes d'accès pour les prestataires. Commencez par les catégories que personne ne suit dans votre organisation, en général les APIs tierces et l'infrastructure externe : ce sont les deux où les équipes découvrent le plus de dépendances oubliées, souvent introduites lors d'un prototype resté en production.

SaaS et services cloud

Les services que vous utilisez directement ou intégrez dans vos applications :
- Authentification (Auth0, Okta, Keycloak SaaS)
- Paiement (Stripe, PayPal, Adyen)
- Monitoring (Datadog, New Relic, Sentry)
- Communication (Twilio, SendGrid)
- Stockage (AWS S3, GCS, Azure Blob)
APIs tierces

Les services que vous appelez via API :
- Enrichissement de données (Clearbit, FullContact)
- Géolocalisation (Google Maps, HERE)
- Vérification (email, téléphone, identité)
Librairies et packages

Vos dépendances directes et transitives :
- Packages npm, PyPI, Maven, Go modules
- SDKs fournisseurs
- Frameworks (React, Django, Spring)
Prestataires techniques

Les humains et organisations qui accèdent à vos systèmes :
- ESN et développeurs externes
- Infogérants
- Consultants sécurité
- Support niveau 3 de vos fournisseurs
Infrastructure externe

Les composants d'infrastructure que vous ne gérez pas :
- CDN (Cloudflare, Fastly)
- DNS (Route53, Cloudflare DNS)
- Registres de packages (npm, Docker Hub)
- CA (Let's Encrypt, DigiCert)

Template d'inventaire des tiers

Un inventaire efficace doit capturer non seulement les données de base, mais aussi le type d'accès accordé et la capacité à sortir du tiers si nécessaire.

Nom	Catégorie	Données exposées	Criticité	Type d'accès	Substituable ?	Plan de sortie ?	Propriétaire	Dernière revue
Auth0	SaaS Auth	Identifiants utilisateurs	Critique	API + Admin	Non	Oui	Équipe Identity	2026-01-15
Stripe	SaaS Paiement	Données bancaires	Critique	API	Non	Non	Équipe Billing	2026-02-01
lodash	Package npm	Aucune	Basse	Code	Oui	N/A	Équipe Frontend	-
axios	Package npm	Données transitant	Moyenne	Code	Oui	N/A	Équipe Frontend	-
Acme Consulting	Prestataire	Accès prod	Haute	Admin prod	Oui	Non	CTO	2025-12-01

Étape 2 : Évaluer le risque de chaque tiers

Matrice de scoring simplifié

Le scoring combine deux dimensions, notées chacune de 1 à 4 :

Impact : que se passe-t-il si ce tiers est compromis ou indisponible ?
Maturité sécurité : quelles garanties le tiers apporte-t-il, et sait-on les vérifier ?

La maturité joue le rôle de la probabilité dans une matrice de risque classique : plus elle est faible, plus l'incident est vraisemblable. Ces deux notes se combinent ensuite en un score unique qui sert uniquement à prioriser, pas à décider seul.

Scoring d'impact (1-4)

L'impact se juge sur ce que le tiers peut atteindre, jamais sur sa taille ni sur son prix. Un utilitaire gratuit qui s'exécute dans votre pipeline de build avec un jeton d'écriture vaut un 4, pendant qu'un SaaS facturé plusieurs milliers d'euros qui ne voit que des données publiques reste à 2. En cas d'hésitation entre deux niveaux, retenez le plus élevé : une note d'impact trop basse fait sortir le tiers du radar pour des mois.

Score	Impact	Critères
4 - Critique	Perte de données sensibles, interruption majeure	Accès à des données clients, credentials, prod
3 - Élevé	Dégradation significative	Accès à des données internes, staging
2 - Moyen	Impact limité	Données non sensibles, dév/test
1 - Faible	Négligeable	Pas de données, pas d'accès système

Scoring de maturité sécurité (1-4)

La maturité se note sur les preuves obtenues, pas sur les intentions affichées. La différence entre un 3 et un 2 tient à un seul critère : disposez-vous d'un document daté et opposable, ou seulement d'une page marketing ? Le niveau 1 est réservé aux tiers qui ne répondent pas ou qui refusent de communiquer : l'absence de réponse est une information en soi, et elle pèse aussi lourd qu'un incident non résolu.

Score	Maturité	Indicateurs
4 - Mature	Excellent	SOC 2 Type II, ISO 27001, pentest récent, SBOM fourni
3 - Bon	Satisfaisant	Certifications en cours, pratiques documentées
2 - Basique	Insuffisant	Pas de certification, pratiques opaques
1 - Faible	Préoccupant	Pas de réponse, incidents passés non résolus

Calcul du score de risque

La formule inverse volontairement la maturité (5 - Maturité) pour qu'un tiers exemplaire ne fasse jamais tomber le score à zéro : un tiers parfaitement mature garde un score égal à son impact, donc reste visible dans l'inventaire. Le résultat s'échelonne de 1 à 16 et n'a aucune valeur absolue : il sert à ordonner votre liste de tiers, pas à produire un indicateur communicable au comité de direction.

Score de risque = Impact × (5 - Maturité)

Score	Niveau	Action
12-16	Critique	Bloquer ou mitiger immédiatement
8-11	Élevé	Plan d'actions sous 30 jours
4-7	Moyen	Surveillance renforcée
1-3	Faible	Suivi standard

Exemple de scoring

Ces quatre lignes montrent le résultat le plus contre-intuitif de la méthode : le petit prestataire ressort devant Auth0 et devant le SaaS analytics, alors qu'il coûte le moins cher et qu'il n'apparaît dans aucun schéma d'architecture. Il cumule un accès de production et une maturité faible, la combinaison exacte que le score cherche à faire remonter. C'est pour cette raison qu'un inventaire limité aux fournisseurs contractualisés passe systématiquement à côté du risque le plus élevé.

Tiers	Impact	Maturité	Score	Niveau
Auth0	4	4	4	Moyen
Nouveau SaaS Analytics	3	2	9	Élevé
Package npm populaire	2	3	4	Moyen
Petit prestataire	4	2	12	Critique

Criticité métier et substituabilité

Le scoring impact × maturité ne capture pas tout. Deux tiers avec le même score peuvent présenter des profils de risque très différents selon leur criticité métier et leur substituabilité. Un SaaS peu mature mais facilement remplaçable n'a pas le même profil qu'un SaaS mature mais impossible à remplacer rapidement.

Critère	Question à se poser	Impact sur la décision
Substituabilité	Peut-on changer de fournisseur en moins de 30 jours ?	Si non → risque accru même si maturité OK
Concentration	Ce tiers est-il point unique de défaillance (SPOF) ?	Si oui → prévoir plan de continuité
Réversibilité	Les données et configurations sont-elles exportables ?	Si non → lock-in = risque stratégique
Couplage technique	L'intégration est-elle profonde ou périphérique ?	Profonde → coût de migration élevé

Étape 3 : Questionnaire d'évaluation pour tiers critiques

Ce questionnaire compte 20 questions réparties en 5 domaines. Chaque ligne associe une question à la preuve attendue : c'est cette seconde colonne qui fait le travail. Une question posée sans preuve exigée produit une réponse rassurante et invérifiable. Envoyez le questionnaire par écrit, gardez les réponses datées, et considérez qu'une question éludée vaut une réponse négative.

Authentification et accès

Ce domaine détermine qui peut entrer chez le fournisseur et à quelle vitesse vous pouvez couper un accès. La question 4, sur la révocation, est celle qu'on oublie le plus souvent alors qu'elle conditionne votre réaction en cas de départ d'un administrateur ou de fuite d'un jeton. Un fournisseur qui ne sait pas révoquer une clé d'API en moins d'une heure vous impose son propre délai de réaction.

#	Question	Preuve attendue
1	Supportez-vous SSO (SAML/OIDC) ?	Documentation technique
2	L'authentification MFA est-elle disponible/obligatoire ?	Screenshot console admin
3	Comment gérez-vous les accès API (OAuth, API keys rotatives) ?	Documentation API
4	Quel est le processus de révocation d'accès ?	Procédure documentée

Sécurité des données

Les questions 5 à 8 suivent le cycle de vie de la donnée : où elle atterrit, comment elle est protégée, qui la consulte, et ce qu'elle devient à la fin du contrat. La question 7 est la plus révélatrice, parce que le chiffrement au repos ne protège pas des accès légitimes du support technique du fournisseur. La question 8 sert votre réversibilité : sans procédure de purge écrite, vos données survivent au contrat.

#	Question	Preuve attendue
5	Où sont stockées physiquement les données ?	Documentation localisation
6	Les données sont-elles chiffrées au repos et en transit ?	Attestation technique
7	Qui a accès aux données clients (support, dev, ops) ?	Politique d'accès
8	Comment les données sont-elles supprimées à la fin du contrat ?	Procédure de purge

Développement sécurisé

Ce bloc mesure si le fournisseur applique chez lui ce que vous cherchez à mettre en place chez vous. La question 11 est décisive : votre fournisseur hérite lui aussi de dépendances transitives, et son risque devient le vôtre. La question 12 sur le SBOM reste souvent sans réponse positive en 2026, mais un refus argumenté vaut mieux qu'un silence, et un fournisseur qui accepte de le fournir vous permet de croiser ses composants avec vos propres alertes de vulnérabilités.

#	Question	Preuve attendue
9	Avez-vous un SDLC sécurisé documenté ?	Documentation processus
10	Réalisez-vous des tests de sécurité (SAST, DAST, pentest) ?	Rapport anonymisé
11	Comment gérez-vous les vulnérabilités de vos dépendances ?	Politique SCA
12	Fournissez-vous un SBOM de vos produits ?	Fichier SBOM

Gestion des incidents

Ces quatre questions préparent le jour où le fournisseur sera compromis. Cherchez un délai chiffré et contractuel en réponse à la question 13 : « rapidement » ne vous permet pas de tenir vos propres obligations de notification, notamment les 72 heures du RGPD qui courent à partir du moment où vous avez connaissance de la violation. La question 15 mérite d'être posée même si vous connaissez la réponse : la façon dont un fournisseur parle de ses incidents passés en dit plus long que le contenu du plan qu'il vous envoie.

#	Question	Preuve attendue
13	Quel est votre délai de notification en cas d'incident ?	SLA documenté
14	Avez-vous un plan de réponse aux incidents ?	Extrait du plan
15	Avez-vous subi des incidents de sécurité ces 24 mois ?	Disclosure si applicable
16	Comment communiquez-vous les vulnérabilités de vos produits ?	Page security advisories

Conformité et certifications

Une certification n'est pas une garantie de sécurité : c'est la preuve qu'un auditeur externe a vérifié un périmètre déclaré à une date donnée. Réclamez donc systématiquement le périmètre et la date de validité, pas seulement le logo. Un certificat ISO 27001 dont le champ d'application couvre le siège social mais pas la plateforme que vous consommez ne vous apporte rien, et c'est un cas fréquent chez les éditeurs qui ont grossi par acquisitions.

#	Question	Preuve attendue
17	Avez-vous une certification ISO 27001, SOC 2, ou équivalent ?	Certificat valide
18	Réalisez-vous des audits de sécurité externes réguliers ?	Attestation d'audit
19	Comment assurez-vous la conformité RGPD ?	DPA signé
20	Avez-vous une politique de responsabilité en cas de breach ?	Clause contractuelle

Questions spécifiques pour les packages open source

Pour les dépendances open source, le questionnaire classique ne s'applique pas : il n'y a personne à qui l'envoyer, et aucune obligation de réponse. L'évaluation devient une observation de signaux publics, que vous collectez vous-même sur le dépôt et le registre. Les seuils de la troisième colonne sont des ordres de grandeur à ajuster selon l'écosystème : un projet Go stable peut rester six mois sans commit sans que cela pose problème, alors qu'un package npm exposé au navigateur devient suspect bien plus vite.

Critère	Comment vérifier	Seuil recommandé
Mainteneurs actifs	Nombre de contributeurs avec commits récents	> 2 mainteneurs actifs
Fréquence de mise à jour	Date du dernier commit/release	< 6 mois
Couverture vulnérabilités	CVE ouverts sans correctif	0 CVE critique ouverte
Score OpenSSF	OpenSSF Scorecard	> 7/10
Dépendances transitives	Nombre et qualité des sous-dépendances	Audit récursif
Licence	Compatibilité avec votre projet	License approuvée
Adoption	Stars, downloads, utilisateurs majeurs	Communauté active

Questions spécifiques pour les SaaS

Pour les services SaaS, ces cinq questions complètent le questionnaire général. Elles ne portent pas sur la sécurité au sens strict mais sur la dépendance opérationnelle que vous créez : disponibilité, stabilité de l'API, isolation entre clients. La question sur la dépréciation d'API est celle qui coûte le plus cher quand elle n'est pas posée, parce qu'un fournisseur qui casse ses interfaces tous les six mois vous impose une charge de maintenance permanente que personne n'a budgétée.

Question	Pourquoi c'est important
Quel est votre SLA de disponibilité ?	Impact sur votre propre SLA
Quelle est votre politique de dépréciation d'API ?	Maintenance de votre intégration
Proposez-vous des environnements de test isolés ?	Sécurité de vos tests
Comment gérez-vous le multi-tenancy ?	Isolation entre clients
Quelle est votre couverture régionale (RGPD, localisation) ?	Conformité

Étape 4 : Preuves acceptables vs insuffisantes

La qualité des preuves varie selon le type de tiers. Un SOC 2 Type II est pertinent pour un SaaS, mais n'a pas de sens pour un projet open source maintenu par des bénévoles.

Preuves pour les fournisseurs contractuels (SaaS, prestataires)

Les preuves se classent selon qui les a produites. Une preuve vérifiable vient d'un tiers indépendant, une preuve déclarative vient du fournisseur lui-même. Le premier tableau donne cette hiérarchie, le second la décline en cas concrets. Passez le plus de temps possible sur la frontière entre les niveaux 3 et 4 : c'est là que se trouve la majorité des dossiers réels, et c'est là que la tentation de se contenter d'un questionnaire rempli est la plus forte.

Niveau	Type de preuve	Confiance
1 - Vérifiable	Rapport d'audit externe (SOC 2 Type II, ISO 27001)	5/5
2 - Documenté	Rapports de pentest, politiques signées, DPA	4/5
3 - Déclaratif	Questionnaire rempli, attestation du fournisseur	3/5
4 - Indirect	Ratings publics (SecurityScorecard, BitSight)	2/5
5 - Aucune	"Faites-nous confiance"	1/5

Domaine	Preuve acceptable	Preuve insuffisante
Chiffrement	TLS configuré + cipher suites documentées	"Oui, on chiffre"
Accès	Logs d'audit + politique RBAC	"Seuls les admins ont accès"
Pentest	Rapport anonymisé avec date et scope	"On fait des tests"
Incidents	Page publique de security advisories	"On n'a jamais eu de problème"
MFA	Screenshot de la config obligatoire	"C'est disponible"

Preuves pour les composants open source

Pour l'OSS, les preuves traditionnelles ne s'appliquent pas. Concentrez-vous sur les signaux de maturité du projet :

Signal	Source	Confiance
SBOM + provenance signée	Artefact avec signatures SLSA	5/5
Security policy publique	SECURITY.md, process de disclosure	4/5
OpenSSF Scorecard > 7	scorecard.dev, deps.dev	3/5
Historique de releases	Régularité, changelogs, CVE corrigés rapidement	3/5
Mainteneurs identifiables	Profils publics, affiliation connue	2/5
Popularité seule	Stars GitHub, downloads npm	1/5

Étape 5 : Décider et agir

Arbre de décision

Une fois le score calculé, l'arbre ci-dessous guide la décision. Pour les risques élevés (≥8), trois options s'offrent à vous : mitiger le risque par des contrôles compensatoires, le transférer (assurance, clause contractuelle), ou refuser le tiers si aucune mitigation n'est acceptable.

Arbre de décision TPRM : du score de risque aux actions (accepter, surveiller, évaluer options)

Actions de mitigation typiques

Ces six actions se combinent : sur un tiers critique, on en applique rarement une seule. Les quatre premières sont techniques et dépendent de vous seul, donc applicables immédiatement. Les deux dernières passent par un contrat ou par un travail de documentation, avec des délais qui se comptent en semaines. Commencez par les techniques pour réduire l'exposition tout de suite, puis engagez les négociations sans bloquer l'intégration dessus.

Action	Quand l'appliquer	Exemple
Isolation réseau	Tiers peu de confiance	VPN dédié, réseau séparé
Limitation des données	Données sensibles exposées	Pseudonymisation, filtrage
Monitoring renforcé	Tout tiers critique	Alertes sur comportements anormaux
Backup externe	Dépendance à un seul fournisseur	Mirroring, cache local
Clause contractuelle	Risque financier	SLA, pénalités, assurance
Plan de sortie	Dépendance forte	Documentation de migration

Contrôles compensatoires côté équipe

Quand un tiers n'est pas parfait (et aucun ne l'est), c'est à vous de réduire le risque par des contrôles compensatoires. Ces mesures ne corrigent pas les faiblesses du tiers, mais limitent votre exposition.

Contrôle	Ce que vous faites	Exemple concret
Réduction des privilèges	Limiter les accès accordés au tiers	Scopes OAuth minimaux, compte dédié sans admin
Segmentation réseau	Isoler le tiers du reste de l'infra	VPC dédié, egress filtering, proxy sortant
Filtrage des données	Ne pas envoyer plus que nécessaire	Pseudonymisation, minimisation, tokenisation
Vérification d'intégrité	Contrôler ce qui entre dans votre build	Lockfiles, signatures, attestations SLSA
Résilience	Survivre à une défaillance du tiers	Cache local, mirroring, fallback provider
Surveillance continue	Détecter les anomalies rapidement	Alertes sur advisories, changements de mainteneur

Signaux faibles à surveiller sur l'open source

Au-delà du score Scorecard, certains signaux doivent déclencher une revue approfondie. L'affaire Polyfill.io (2024) illustre parfaitement ces risques : après un changement de propriétaire, le code a été modifié pour injecter du contenu malveillant sur des millions de sites.

Signal d'alerte	Comment le détecter	Action recommandée
Mainteneur principal changé	Historique git, annonces	Revue du nouveau mainteneur
Transfert de namespace/repo	npm unpublish + republish, GitHub transfer	Analyse approfondie
Baisse d'activité puis release soudaine	Historique des commits	Inspecter le diff de la release
Package populaire, peu de mainteneurs	Contributors sur GitHub	Prévoir alternative ou fork
postinstall scripts suspects	package.json, npm audit	Bloquer ou auditer
Obfuscation, dépendances surprenantes	Inspection du code	Refuser ou isoler
Absence de SECURITY.md	Racine du repo	Privilégier alternatives mieux documentées

Quand l'évaluation technique ne suffit pas

L'évaluation technique est nécessaire mais pas suffisante pour les tiers critiques. Certains aspects relèvent du contrat et doivent être négociés avec les équipes achats, juridiques ou le RSSI.

Besoin	Pourquoi c'est important	Qui négocie
Clause de notification d'incident	Être informé rapidement en cas de breach	Juridique / RSSI
DPA (Data Processing Agreement)	Conformité RGPD pour les données personnelles	DPO / Juridique
SLA de disponibilité	Impact sur votre propre engagement client	Achats / Produit
Droit d'audit	Pouvoir vérifier les pratiques du fournisseur	RSSI / Conformité
Clause de réversibilité	Pouvoir récupérer vos données et migrer	Achats / Tech
Engagement de localisation	Savoir où sont traitées les données	DPO / RSSI

Qualification rapide d'un tiers en 10 minutes

Vous devez valider rapidement un SaaS ou une librairie ? Voici la procédure express pour une première qualification.

Identifier le type de tiers

SaaS, package, API, prestataire ? Cela détermine les preuves à demander.
Évaluer l'exposition

Quelles données ou quels accès lui confie-t-on ? Personnel, financier, credentials, admin ?
Déterminer la criticité

Est-ce critique pour la prod ou le métier ? Une panne bloque-t-elle les utilisateurs ?
Chercher les preuves minimales
- SaaS : SOC 2, ISO 27001, page de sécurité publique ?
- OSS : Scorecard > 7, mainteneurs identifiables, releases régulières ?
Évaluer l'isolation possible

Peut-on limiter l'accès, filtrer les données, prévoir un fallback ?

Sortie de la qualification rapide

La qualification rapide produit une décision d'aiguillage, pas un verdict définitif. Trois sorties sur quatre autorisent l'intégration ; seule la dernière la bloque. Le résultat le plus utile est « Revue approfondie » : il permet de dire non à l'immédiat sans dire non au projet, et de renvoyer vers le questionnaire complet plutôt que vers un arbitrage émotionnel. Notez la décision et sa date dans l'inventaire, c'est ce qui vous évitera de refaire le même débat six mois plus tard.

Résultat	Critères	Action
Go	Impact faible, preuves OK, substituable	Intégrer sans délai
Go avec mitigations	Impact moyen, preuves partielles	Intégrer avec contrôles compensatoires
Revue approfondie	Impact élevé, preuves insuffisantes	Questionnaire complet, validation RSSI
No go	Impact critique, pas de preuves, pas d'isolation possible	Refuser ou chercher alternative

Intégrer le TPRM dans vos processus

Dans le cycle de développement

Un TPRM qui vit dans un tableur meurt en trois mois. Les trois moments ci-dessous sont ceux où la démarche s'ancre dans des gestes déjà existants : l'ajout d'une dépendance, l'exécution de la CI/CD, la revue périodique. Le point le plus rentable est le deuxième, parce qu'il est automatique et ne dépend pas de la discipline de l'équipe. Les deux autres demandent une décision humaine et se dégradent dès que la charge augmente.

Avant d'ajouter une dépendance
- Vérifier le score OpenSSF Scorecard
- Consulter la liste des packages approuvés/interdits
- Pour un nouveau SaaS : déclencher le processus d'évaluation
En CI/CD
- Bloquer les packages avec CVE critiques
- Alerter si une dépendance change de mainteneur
- Générer le SBOM à chaque release
Périodiquement
- Revoir les tiers critiques (trimestriel)
- Mettre à jour l'inventaire
- Vérifier les nouvelles certifications/incidents

Automatiser avec des outils

Aucun outil ne fait le TPRM à votre place : ils alimentent l'inventaire et déclenchent des alertes, la décision reste humaine. La ligne qui change le plus la vie d'une équipe est la première : sans SBOM généré à chaque build, l'inventaire des packages est reconstruit à la main et donc faux en permanence. Les solutions commerciales des deux dernières lignes n'ont d'intérêt qu'à partir de quelques dizaines de fournisseurs contractualisés ; en dessous, un tableur versionné dans un dépôt Git fait le travail.

Besoin	Outils
Inventaire packages	SBOM (Syft), Dependency-Track
Score open source	OpenSSF Scorecard, deps.dev
Vulnérabilités	Grype, Trivy, Snyk
Inventaire SaaS	CASB, solution TPRM (OneTrust, SecurityScorecard)
Questionnaires	Google Forms, Typeform, solutions TPRM

Cas pratique : évaluer un nouveau SaaS

Imaginons que votre équipe souhaite intégrer un nouveau service d'envoi d'emails transactionnels : EmailService.

Étape 1 : Qualification rapide (5 minutes)

Trois questions suffisent à trancher entre « on intègre » et « on évalue sérieusement ». La deuxième ligne est celle qui fait basculer le dossier : un service d'emails transactionnels transporte les liens de réinitialisation de mot de passe, donc un accès à sa console permet de prendre le contrôle de comptes utilisateurs sans jamais toucher à votre application. La mention « SOC 2 sur leur site » reste à ce stade une déclaration marketing, pas une preuve.

Question rapide	Réponse	Note
Données exposées ?	Emails, noms utilisateurs	Données personnelles
Criticité ?	Envoi de réinitialisation de MDP	Critique
Certifications visibles ?	SOC 2 sur leur site	À vérifier

Résultat : Tiers critique → évaluation complète nécessaire.

Étape 2 : Questionnaire (envoi + réception)

Le questionnaire de 20 questions part au contact commercial, qui le relaie à son équipe sécurité. Adressez-le par écrit, avec une date de réponse attendue, et demandez les pièces jointes en même temps que les réponses : un fournisseur qui promet le rapport de pentest « sur demande » et ne l'envoie jamais vous fait perdre trois semaines. Comptez entre cinq et quinze jours ouvrés pour un retour complet chez un éditeur structuré.

Étape 3 : Analyse des réponses

L'analyse ne consiste pas à compter les réponses positives mais à isoler les écarts. Les deux points d'attention ci-dessous, la MFA facultative et l'absence de SBOM, ne sont pas de même nature : le premier est une faiblesse actionnable que le fournisseur peut corriger sur votre tenant, le second est une limite structurelle que vous compensez par votre propre surveillance. Cette distinction détermine ce qui part en négociation et ce qui part en plan de suivi.

Critère	Réponse	Évaluation
SSO/OIDC	Oui avec SAML2	OK
MFA obligatoire	Disponible mais pas obligatoire	À négocier
SOC 2 Type II	Certifié, rapport disponible	OK
RGPD/DPA	DPA standard fourni	OK
SBOM	Non fourni	À suivre
Notification breach	72h contractuel	OK
Pentest récent	Oui, rapport anonymisé fourni	OK

Étape 4 : Scoring et décision

Le fournisseur est sérieux, et le score reste pourtant élevé : c'est le comportement attendu de la formule, puisque l'impact plafonne à 4 dès qu'un tiers touche à des mécanismes d'authentification. Un score élevé ne signifie donc pas « mauvais fournisseur », il signifie « surveillance et contreparties ». Les trois mitigations retenues sont volontairement modestes et négociables : elles doivent tenir dans le cycle d'achat, pas le bloquer.

Impact : 4 (données sensibles, credentials)
Maturité : 3 (SOC 2, bon mais pas parfait)
Score : 4 × (5-3) = 8 → Élevé

Décision : Accepter avec mitigations :

Négocier MFA obligatoire pour les admins
Demander clause de notification breach < 48h
Planifier revue dans 12 mois

Quand dire non : exemple de refus

Une démarche TPRM qui n'a jamais produit de refus n'est pas une démarche, c'est une formalité. Le cas ci-dessous réunit le motif qui justifie un no go : non pas une faiblesse identifiée, mais l'impossibilité de vérifier quoi que ce soit. Face à un tiers qui refuse de fournir des preuves, aucun contrôle compensatoire ne s'applique, puisque vous ne savez pas contre quoi vous vous protégez.

Un autre fournisseur d'emails (MailCheap) présentait ce profil :

Critère	Réponse
SOC 2 / ISO 27001	"En cours" depuis 2 ans
MFA admin	"Disponible mais pas obligatoire"
Rapport de pentest	Refus de communiquer
Notification breach	"On vous préviendra" (pas de SLA)
Localisation des données	"Multiples datacenters" (pas de précision)
DPA	Refus de signer un DPA personnalisé

Score : Impact 4, Maturité 1 → Score 16 → Critique

Décision : Refus. Aucune mitigation ne compense l'absence de preuves sur un tiers qui accède à des données sensibles et à des mécanismes d'authentification. L'équipe a choisi un fournisseur plus mature (Resend) malgré un coût supérieur.

À retenir

Les 5 points essentiels de ce guide :

Le TPRM concerne les équipes techniques, dès qu'on fait npm install, on intègre un tiers
Inventorier d'abord, vous ne pouvez pas protéger ce que vous ne connaissez pas (SaaS, packages, prestataires)
Scorer selon impact × maturité, priorisez les efforts sur les tiers critiques et peu matures
Demander des preuves, pas des déclarations, un rapport SOC 2 vaut mieux qu'un "oui on sécurise"
Automatiser où possible, SBOM, Scorecard, alertes CVE doivent être dans la CI/CD

Prochaines étapes

OpenSSF Scorecard

Évaluez automatiquement la sécurité des projets open source Lire le guide Scorecard

SaaSBOM

Documentez vos dépendances SaaS dans un format standard Voir le guide XBOM

NIS2 et fournisseurs

Comprenez les obligations NIS2 sur la gestion des tiers Lire le guide NIS2

Clauses cyber

Les exigences de gouvernance et les clauses attendues sur vos contrats fournisseurs Voir les exigences gouvernance et contractuel