Pourquoi un incident chez un prestataire impacte directement l’organisation

Points clés Un incident chez un prestataire se propage à l'organisation cliente via les accès partagés, les données traitées, les intégrations système et les ob

M
Mehdi SARIAK
24 mai 2026 7 min de lecture 31 lectures

Points clés

  • Un incident chez un prestataire se propage à l'organisation cliente via les accès partagés, les données traitées, les intégrations système et les obligations réglementaires.
  • Les impacts directs incluent la perturbation des services dépendants du prestataire, l'exposition des données confiées et les obligations de notification réglementaire associées.
  • La panne CrowdStrike de juillet 2024 a impacté 8,5 millions de systèmes dans des organisations qui n'avaient elles-mêmes aucune défaillance de sécurité interne.
  • L'organisation cliente peut être tenue de notifier ses propres régulateurs et clients en cas d'incident chez un prestataire ayant affecté ses données.
  • DORA impose aux entités financières de notifier un incident ICT significatif même lorsque cet incident est survenu chez un prestataire tiers.

Lorsqu'un prestataire subit un incident, les organisations qui lui font confiance ne sont pas simplement des victimes collatérales passives. Elles ont des responsabilités actives : identifier l'étendue de l'impact sur leurs propres systèmes et données, activer leurs plans de continuité, et respecter leurs obligations de notification réglementaire — même si elles n'ont elles-mêmes commis aucune faute.

Cette réalité illustre l'un des principes fondamentaux de la gestion du risque tiers : la responsabilité de l'organisation cliente ne s'arrête pas aux frontières contractuelles. Elle s'étend à l'ensemble des conséquences d'un incident prestataire sur ses propres opérations, ses clients et sa conformité réglementaire.

Les canaux de propagation d'un incident prestataire

Un incident chez un prestataire se propage vers l'organisation cliente via plusieurs canaux. Les accès directs : si le prestataire a compromis les identifiants lui permettant d'accéder aux systèmes de l'organisation, l'attaquant peut utiliser ces accès pour progresser vers des cibles internes. Les données partagées : si l'organisation a confié des données de clients ou des données sensibles au prestataire, leur exposition lors d'un incident engage les obligations de notification de l'organisation. Les intégrations système : si les systèmes de l'organisation communiquent avec ceux du prestataire via des API ou des échanges de données automatisés, un prestataire compromis peut injecter des données corrompues dans ces flux.

Les obligations réglementaires en cas d'incident prestataire

Les obligations réglementaires de l'organisation cliente ne sont pas suspendues parce que l'incident origine chez un prestataire. RGPD : si des données personnelles confiées au prestataire sont exposées, l'organisation reste responsable du traitement et doit notifier la CNIL dans les 72 heures. DORA : si un prestataire ICT subi un incident affectant les fonctions critiques d'une entité financière cliente, celle-ci doit notifier ses régulateurs. NIS2 : les entités essentielles doivent notifier les incidents significatifs affectant leurs services, y compris ceux causés par des prestataires.

Ces obligations impliquent que l'organisation dispose d'un processus de surveillance des incidents chez ses prestataires critiques et d'une capacité à évaluer rapidement l'impact de ces incidents sur ses propres obligations réglementaires.

La préparation à l'impact d'un incident prestataire

Les plans de continuité d'activité doivent inclure des scénarios d'indisponibilité ou de compromission des prestataires critiques. Ces scénarios doivent prévoir : la bascule vers des prestataires alternatifs ou des capacités internes de secours, l'isolation des intégrations avec le prestataire compromis, et les procédures de communication vers les clients et les régulateurs. La préparation à ces scénarios ne peut pas commencer pendant l'incident : elle doit être réalisée en amont, lors des phases de planification de la continuité.

Études de cas
États-Unis — Change Healthcare Ransomware (2024)
L'attaque ransomware contre Change Healthcare (filiale d'UnitedHealth Group) en février 2024 est considérée comme la plus dévastatrice de l'histoire du secteur de la santé américain. Change Healthcare traite 15 milliards de transactions médicales par an pour 900 000 prestataires de santé. L'interruption de ses services pendant plusieurs semaines a provoqué des ruptures de trésorerie dans des milliers de pharmacies et cabinets médicaux, qui ne pouvaient plus traiter les remboursements d'assurance. Le coût estimé pour UnitedHealth Group dépasse 1,6 milliard de dollars.
Europe — ION Trading Ransomware (2023)
ION Trading, prestataire de logiciels de trading de dérivés, a subi une attaque ransomware en janvier 2023 qui a perturbé les opérations de clearing de nombreuses institutions financières clientes en Europe et aux États-Unis. ABN AMRO, Macquarie et d'autres banques ont dû revenir à des processus manuels pour certaines transactions pendant plusieurs jours. L'incident a conduit les régulateurs financiers européens à accélérer la mise en œuvre des exigences DORA sur la résilience des prestataires ICT critiques.
Asie — SITA Data Breach (2021)
SITA, prestataire IT pour l'industrie aéronautique mondiale, a subi une violation de données affectant les systèmes de traitement des données de passagers de nombreuses compagnies aériennes. Air India, Singapore Airlines, Malaysia Airlines, Finnair et d'autres compagnies ont dû notifier leurs clients de l'exposition potentielle de leurs données de fidélité — non pas parce qu'elles avaient été directement attaquées, mais parce qu'elles avaient confié des données à SITA. Chaque compagnie a dû gérer ses propres obligations de notification réglementaire.
WhatsApp