Prestataires, BPO, MSP : vos sous-traitants sont le vrai périmètre de votre sécurité

Un email de phishing sur un agent de support externalisé en Inde : voilà comment 13 millions de tickets clients Adobe et l'intégralité des soumissions HackerOne de l'éditeur se sont retrouvés dans les mains d'un acteur malveillant. Personne n'a piraté Adobe. Quelqu'un a piraté le sous-traitant d'Adobe. La différence semble technique. Elle est en réalité fondamentale — et elle révèle l'angle mort le plus sous-estimé de la sécurité des systèmes d'information en 2026.

Le périmètre sécurité est une illusion comptable

Pendant vingt ans, la cybersécurité d'entreprise a été construite autour d'un modèle simple : il y a un dedans et un dehors. Le dedans, c'est le réseau de confiance, les actifs maîtrisés, les utilisateurs connus. Le dehors, c'est Internet, l'ennemi, l'inconnu. Entre les deux, un pare-feu, un VPN, un annuaire Active Directory. Le budget sécurité s'est structuré autour de cette frontière : on défend le périmètre.

Ce modèle était déjà en crise avant le COVID. Le travail à distance, la migration cloud et la prolifération des API l'ont achevé entre 2020 et 2023. En 2026, la plupart des RSSI que je rencontre ont intégré intellectuellement la fin du périmètre réseau. Ils parlent de Zero Trust, de microsegmentation, d'identité comme nouveau périmètre. Très bien. Mais il existe un autre périmètre dont personne ne parle vraiment : le périmètre organisationnel.

Votre organisation, en 2026, ne s'arrête plus à vos murs. Elle s'étend à votre prestataire de support client installé à Bangalore, à votre MSP qui administre vos serveurs à distance depuis Lyon, à votre éditeur de logiciel RH qui synchronise votre annuaire toutes les nuit, à votre cabinet de conseil qui a accès à votre SharePoint pour livrer ses rapports, à votre sous-traitant industriel qui se connecte à votre réseau OT pour la maintenance préventive. Chacun de ces acteurs détient un accès partiel mais réel à vos systèmes. Chacun a son propre niveau de maturité sécurité — souvent bien en deçà du vôtre. Et chacun est une surface d'attaque que vous ne maîtrisez pas.

Le rapport Verizon Data Breach Investigations Report 2025 (DBIR) est sans appel : 62 % des incidents touchant des grandes organisations comportaient un vecteur tiers ou sous-traitant. Ce chiffre était de 29 % en 2022. En trois ans, la compromission par la chaîne d'approvisionnement a plus que doublé en proportion. Ce n'est pas un accident. C'est la conséquence logique d'un modèle d'entreprise qui externalise de plus en plus de fonctions critiques tout en investissant de moins en moins dans la gouvernance sécurité de ces partenaires.

La vraie question n'est plus "mon périmètre réseau est-il protégé ?" Elle est "quel est le niveau de sécurité du maillon le plus faible de mon écosystème de partenaires ?" Et dans la plupart des organisations que j'audite, la réponse à cette question est : on ne sait pas.

Ce que "prestataire avec accès" signifie vraiment en termes d'exposition

Commençons par un inventaire honnête. Dans une ETI de taille moyenne — 500 à 2000 salariés — combien d'entités externes ont un accès régulier ou permanent à vos systèmes ? Quand je pose cette question en début de mission, les RSSI donnent généralement un chiffre entre 10 et 20. Quand on fait l'inventaire réel, on arrive systématiquement entre 40 et 80. Parfois plus.

Ces accès se répartissent en plusieurs catégories, chacune avec ses propres risques. Premièrement, les accès directs aux systèmes : comptes Active Directory, VPN dédiés fournisseurs, accès RDP ou SSH pour la maintenance, comptes dans vos applications métier (ERP, ITSM, CRM). Ces comptes existent souvent depuis des années, parfois avec des mots de passe qui n'ont jamais changé, parfois sans MFA. Quand le prestataire change d'employé, le compte suit rarement.

Deuxièmement, les accès fonctionnels délégués : l'agent de support qui peut ouvrir des tickets au nom de vos utilisateurs, l'intégrateur qui a des droits d'administration sur votre ITSM, le prestataire RH qui peut modifier des attributs dans votre annuaire. Ces accès sont légitimes dans leur usage initial. Ils deviennent dangereux quand personne ne vérifie qu'ils correspondent encore à une nécessité opérationnelle réelle.

Troisièmement, les accès indirects par synchronisation ou API : votre fournisseur cloud qui synchronise des données via une API avec une clé qui n'expire jamais, votre éditeur SaaS qui fait des backups de vos données dans son infrastructure, votre solution de monitoring qui aspirera vos logs vers ses serveurs. Ces accès sont souvent invisibles dans les inventaires car ils ne correspondent pas à un "compte utilisateur" au sens classique.

L'affaire Adobe est l'illustration parfaite du scénario de type 1 : un agent BPO avec un compte légitime dans le système de helpdesk. Son accès était justifié, documenté, nécessaire à son travail. Mais son poste de travail, sa boîte email, sa formation anti-phishing — rien de tout cela n'était sous le contrôle d'Adobe. Résultat : un phishing banal a suffi à ouvrir l'accès à 13 millions de tickets et aux soumissions bug bounty de l'un des éditeurs logiciels les plus importants au monde.

Ce type de scénario n'est pas exceptionnel. C'est la norme. SolarWinds en 2020, Kaseya en 2021, Okta en 2022 (compromis via son sous-traitant Sykes/SITEL), et maintenant Adobe en 2026 : à chaque fois, le vecteur initial n'est pas une faille dans l'infrastructure de la victime principale, mais une compromission dans son écosystème de partenaires. Les attaquants ont compris avant nous que le sous-traitant est la porte d'entrée optimale — moins surveillé, moins protégé, mais avec des accès souvent très étendus.

L'anatomie d'une compromission par la chaîne d'approvisionnement

Pour comprendre pourquoi ce vecteur est si efficace, il faut décortiquer ce que voit un attaquant quand il cherche à compromettre une grande organisation. Mettons-nous dans la peau d'un groupe criminel organisé dont l'objectif est d'accéder aux données clients ou aux systèmes internes d'une entreprise du CAC 40.

Option A : attaque directe. Cibler l'infrastructure exposée de l'entreprise — ses serveurs web, ses VPN, ses équipements réseau. En 2026, ces surfaces sont généralement bien monitorées, patchées relativement vite, protégées par des solutions EDR/XDR performantes. Le temps moyen de détection d'une intrusion directe est désormais de 16 jours selon le rapport Mandiant M-Trends 2025, contre 205 jours en 2018. Les chances de succès diminuent, le coût de l'attaque augmente.

Option B : attaque par la chaîne de sous-traitants. Identifier les prestataires qui ont des accès légitimes à la cible principale. Évaluer leur niveau de sécurité. Cibler le plus faible. Un BPO offshore, un cabinet de conseil spécialisé, un MSP régional : ces entités ont souvent des budgets sécurité 10 à 50 fois inférieurs à ceux de leur client grand compte, peu ou pas de SOC, des EDR basiques, et des politiques de phishing insuffisantes. Leur temps moyen de détection dépasse encore 90 jours dans la majorité des cas.

La comparaison est sans appel. Les attaquants ont fait ce calcul depuis longtemps. La compromission par la chaîne d'approvisionnement n'est pas une innovation tactique récente : elle est simplement devenue le chemin de moindre résistance à mesure que les cibles primaires ont renforcé leur sécurité directe.

L'anatomie type d'une telle attaque se déroule en quatre phases. Phase 1 : la reconnaissance. L'attaquant cartographie l'écosystème de partenaires de sa cible — souvent via LinkedIn (qui liste les prestataires), les appels d'offres publics, les mentions de sous-traitants dans les rapports annuels ou les sites carrières des BPO eux-mêmes qui listent fièrement leurs clients. Phase 2 : la compromission du sous-traitant. Phishing ciblé sur un employé du prestataire qui a accès aux systèmes de la cible principale. Phase 3 : la collecte et le pivot. Depuis le compte compromis, l'attaquant accède aux données visibles, cartographie les accès disponibles, et cherche à pivoter vers des accès plus larges. Phase 4 : l'exploitation. Exfiltration de données, implantation de portes dérobées, ou déclenchement d'une attaque ransomware sur la cible principale.

Le délai entre les phases 2 et 4 peut être de quelques heures (opportuniste) à plusieurs mois (APT avec objectif de persistance à long terme). Dans le cas Adobe, rien ne permet d'affirmer que l'exploitation a été rapide — les données exfiltrées auraient pu être collectées progressivement sur plusieurs semaines sans déclencher d'alerte.

La cartographie du risque tiers : pourquoi vos questionnaires ne servent à rien

La réponse instinctive de la plupart des organisations au risque tiers, c'est le questionnaire. On envoie aux fournisseurs un formulaire de 50 à 200 questions sur leurs pratiques de sécurité. Ils répondent. On archive les réponses. On coche la case "fournisseur évalué". Et on recommence l'année d'après.

Cette approche a un défaut fondamental : elle mesure ce que le prestataire déclare, pas ce qu'il fait. Et dans mon expérience de terrain, l'écart entre les deux est systématiquement significatif — pas forcément par mauvaise foi, mais parce que remplir un questionnaire de sécurité ne demande aucune compétence technique réelle. Un responsable commercial peut répondre "oui" à la question "avez-vous un plan de réponse aux incidents ?" sans que ce plan ait jamais été testé, voire sans qu'il existe réellement dans un format opérationnel.

Une cartographie du risque tiers efficace repose sur cinq dimensions que les questionnaires ne capturent pas. La première est la nature et l'étendue réelle des accès : quels systèmes exactement peut accéder le prestataire, avec quel niveau de privilège, depuis quelles IP, à quelles heures ? Cette information se trouve dans vos propres logs, pas dans un questionnaire. La deuxième est la chaîne de sous-traitance du prestataire lui-même : votre BPO sous-traite-t-il à d'autres entités ? Avec quels accès délégués ? Le cas Adobe illustre parfaitement l'enjeu — un sous-traitant de troisième rang (l'employé du BPO) a accès aux données de la cible principale.

La troisième dimension est la réactivité réelle en cas d'incident : comment se déroule concrètement la notification si le prestataire détecte une compromission ? Qui appelle qui ? En combien de temps ? Ces procédures existent rarement sous une forme réellement testée. La quatrième est l'hygiène basique observable : MFA activé sur les comptes accédant à vos systèmes ? EDR déployé sur les postes des agents ? Ces éléments peuvent être vérifiés techniquement plutôt que déclarativement. La cinquième est l'historique d'incidents du prestataire — a-t-il déjà été compromis ? Comment a-t-il réagi ? Les informations publiques (rapports HAVE I BEEN PWNED, fuites documentées) donnent souvent une image plus fidèle que le questionnaire.

La bonne pratique est de tier vos fournisseurs par niveau de risque — accès critique aux données sensibles, accès aux systèmes internes, accès aux systèmes non critiques, pas d'accès direct — et d'appliquer des niveaux d'exigence et de contrôle différenciés. Un prestataire de Tier 1 (accès à vos données clients ou à votre infrastructure critique) mérite une évaluation annuelle approfondie avec vérification technique, pas un questionnaire. Un prestataire de Tier 3 (livraison de fournitures de bureau) n'a pas besoin d'une revue de sécurité.

NIS2 et DORA : ce que la réglementation impose — et ce que vous faites vraiment

La bonne nouvelle, c'est que le régulateur européen a pris conscience du problème. La mauvaise nouvelle, c'est que les obligations réglementaires sur le risque tiers sont souvent comprises de manière superficielle et appliquées de manière cosmétique.

La directive NIS2, dont la transposition française est en cours d'application depuis début 2025, impose aux entités essentielles et importantes de gérer les risques liés à leur chaîne d'approvisionnement. L'article 21 de la directive impose explicitement de prendre en compte la sécurité des fournisseurs dans la politique de sécurité de l'organisation. Les mesures requises incluent des politiques contractuelles de sécurité avec les prestataires, une évaluation des pratiques de sécurité des fournisseurs critiques, et des exigences minimales de sécurité dans les contrats.

DORA (Digital Operational Resilience Act), applicable depuis janvier 2025 aux entités financières européennes, va encore plus loin avec le concept de Third Party Service Providers (TPSP). DORA impose aux établissements financiers de maintenir un registre de leurs prestataires IT critiques, d'effectuer des évaluations de concentration (si un fournisseur est utilisé par trop d'entités financières simultanément), et de tester périodiquement la résilience de leurs dépendances tierces. L'Autorité Bancaire Européenne (ABE) publie régulièrement des lignes directrices sur la mise en œuvre de ces exigences.

Dans la pratique, ce que j'observe sur le terrain est décourageant. La majorité des organisations ont interprété ces exigences comme une obligation documentaire : produire un registre des fournisseurs, ajouter une clause de sécurité standard dans les contrats, envoyer un questionnaire annuel. La forme est là. Le fond manque. Personne ne vérifie que la clause contractuelle est effectivement respectée. Personne ne teste réellement la réactivité du prestataire en cas d'incident. Le registre des fournisseurs est souvent incomplet et rarement mis à jour.

L'ANSSI, dans ses recommandations sur la sécurité de la chaîne d'approvisionnement (guide PASSI publié en 2024), est pourtant très claire sur ce point : une clause contractuelle de sécurité sans mécanisme de vérification n'a aucune valeur opérationnelle. Elle peut avoir une valeur juridique en cas de litige post-incident, mais elle ne réduit pas le risque d'un centime. La réglementation NIS2 et DORA créent des obligations de résultat en matière de résilience opérationnelle — pas simplement des obligations de moyens documentaires.

Un signal d'alarme concret : si votre organisation subit une compromission via un prestataire tiers et que vous ne pouvez pas démontrer à l'ANSSI que vous avez effectivement évalué les pratiques de sécurité de ce prestataire (pas juste envoyé un questionnaire), vous êtes exposé à des sanctions significatives. La CNIL et l'ANSSI ont toutes deux indiqué que les incidents de type supply chain seraient traités avec une attention particulière dans leurs contrôles post-2025.

Construire une gouvernance du risque tiers qui tient la route

Assez de diagnostic. Voilà ce que je recommande concrètement aux organisations qui veulent sortir du théâtre de la conformité et construire une vraie résilience face au risque tiers.

Première étape : faire l'inventaire exhaustif et honnête. Pas un inventaire des fournisseurs au sens comptable, mais un inventaire des entités externes qui ont un accès technique ou fonctionnel à vos systèmes et données. Cela inclut les sous-traitants de sous-traitants si vos contrats le permettent (et souvent, les prestataires délèguent à d'autres entités que vous ne connaissez pas). Cet inventaire doit être maintenu en temps réel — dans un outil dédié ou, a minima, dans un tableur avec un propriétaire responsable de sa mise à jour. La durée de vie d'un inventaire non maintenu est de six mois avant de devenir plus dangereuse qu'utile.

Deuxième étape : tierer vos fournisseurs par risque réel. Risque réel = combinaison de la sensibilité des données accessibles et de la criticité des systèmes accessibles. Quatre tiers suffisent dans la plupart des cas. Tier 1 : accès à des données sensibles (données clients, données RH, données financières) ou à des systèmes d'infrastructure critiques. Tier 2 : accès à des systèmes internes mais sans données sensibles directes. Tier 3 : accès limité, cloisonné, à des environnements non critiques. Tier 4 : aucun accès direct à vos systèmes. L'effort de gouvernance doit être concentré sur les Tiers 1 et 2.

Troisième étape : définir des exigences minimales différenciées par tier, et les rendre contractuellement opposables. Pour un Tier 1 : MFA obligatoire sur tous les comptes accédant à vos systèmes (vérifiable techniquement), EDR déployé sur les postes des agents, plan de réponse aux incidents avec obligation de notification en moins de 4 heures, audit de sécurité annuel par un tiers indépendant dont vous recevez le résumé. Pour un Tier 2 : MFA obligatoire, politique de mot de passe vérifiable, notification d'incident en moins de 24 heures. Ces exigences doivent figurer dans les contrats avec des pénalités réelles en cas de non-respect — pas juste des engagements de moyens.

Quatrième étape : ne pas se contenter du contrat. Vérifier techniquement que les exigences sont respectées. Pour les Tier 1, cela signifie concrètement : vérifier dans vos propres logs que les connexions des prestataires respectent les règles définies (MFA, plages horaires autorisées, IP sources attendues), effectuer des tests de phishing ciblés sur les équipes du prestataire qui accèdent à vos systèmes (avec accord contractuel préalable), et inclure le prestataire dans vos exercices de simulation d'incident une fois par an.

Cinquième étape : avoir un plan de sortie. C'est la recommandation la plus souvent ignorée. Si un prestataire de Tier 1 est compromis, combien de temps vous faudra-t-il pour révoquer tous ses accès ? Avez-vous la liste à jour de tous les comptes et API keys associés à ce prestataire ? Avez-vous testé la procédure de révocation en conditions réelles ? Dans la majorité des organisations que j'audite, la réponse à ces trois questions est : non, non, et non. Ce qui signifie qu'en cas d'incident, la fenêtre d'exposition durera des jours, pas des heures.

Conclusion : ce que vous devriez faire cette semaine

L'affaire Adobe n'est pas une anomalie. C'est un signal. Le prochain incident majeur lié à votre SI ne viendra probablement pas d'une attaque frontale contre votre infrastructure. Il viendra de l'un de vos 60 prestataires avec accès — celui dont vous avez archivé le questionnaire de sécurité sans jamais vérifier qu'il avait le MFA activé sur les comptes qui se connectent à vos systèmes.

Cette semaine, faites une chose concrète : demandez à votre équipe IT la liste de tous les comptes VPN et accès distants actifs appartenant à des entités externes. Vérifiez lesquels ont le MFA activé. Désactivez ceux qui n'ont plus d'usage opérationnel démontré. Ce seul exercice, dans les organisations que j'accompagne, révèle systématiquement entre 15 et 40 % de comptes prestataires obsolètes ou sans MFA. C'est votre surface d'attaque réelle. Commencez là.