Pourquoi la confiance contractuelle ne suffit plus en matière de sécurité

Points clés La confiance contractuelle — fondée sur des clauses de sécurité dans un contrat — n'est pas un mécanisme de protection suffisant contre le risque ti

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

Points clés

  • La confiance contractuelle — fondée sur des clauses de sécurité dans un contrat — n'est pas un mécanisme de protection suffisant contre le risque tiers.
  • Un contrat définit des obligations et des sanctions ; il ne garantit pas que ces obligations sont respectées ni que les pratiques de sécurité du prestataire sont réellement à la hauteur.
  • Target a subi sa violation de 2013 malgré l'existence d'une clause de conformité PCI-DSS dans son contrat avec Fazio Mechanical, le prestataire HVAC vecteur de l'attaque.
  • Verizon DBIR 2023 indique que seuls 34 % des organisations vérifient réellement les pratiques de sécurité de leurs prestataires au-delà de la revue contractuelle.
  • DORA impose un programme de surveillance continue des prestataires ICT critiques, allant bien au-delà de la simple revue contractuelle.

La confiance contractuelle est une illusion confortable. Elle offre une protection juridique — la possibilité d'invoquer des pénalités contractuelles ou des clauses de responsabilité après un incident — mais elle n'offre aucune protection opérationnelle avant l'incident. Un contrat ne détecte pas les vulnérabilités chez un prestataire, ne surveille pas ses pratiques de sécurité, et n'empêche pas les attaquants d'exploiter ses failles.

La maturité dans la gestion du risque tiers se mesure précisément à la capacité à aller au-delà de la confiance contractuelle : à évaluer réellement les pratiques de sécurité des prestataires, à surveiller les changements dans leur posture de sécurité, et à intervenir lorsque des signaux d'alerte sont détectés.

Les limites des clauses contractuelles de sécurité

Les clauses contractuelles de sécurité sont nécessaires mais insuffisantes. Elles définissent les obligations mais ne créent pas les capacités de vérification. Un prestataire peut s'engager contractuellement à respecter ISO 27001, à chiffrer les données, à notifier les incidents dans les 72 heures — et ne pas tenir ces engagements sans que l'organisation cliente le sache. Sans mécanismes de vérification — audits, certifications, questionnaires de sécurité, tests de pénétration — les clauses contractuelles de sécurité sont des obligations sur le papier, pas des protections opérationnelles.

DORA reconnaît explicitement cette limite en imposant aux entités financières de réaliser des évaluations de sécurité de leurs prestataires ICT critiques, au-delà de la simple revue contractuelle.

Le concept de confiance vérifiée

La confiance vérifiée (Trust but Verify, popularisé dans le contexte des relations diplomatiques et adapté à la cybersécurité) est le principe fondateur d'une gestion mature du risque tiers. Il ne s'agit pas de refuser de faire confiance aux prestataires — ce qui rendrait toute externalisation impossible — mais de ne pas fonder cette confiance uniquement sur des déclarations ou des contrats. La confiance vérifiée repose sur des preuves objectives : certifications de sécurité auditées par des tiers, rapports SOC 2 Type II, questionnaires de sécurité vérifiés, tests d'intrusion réalisés par des experts indépendants.

Les plateformes de gestion du risque tiers (TPRM — Third Party Risk Management) automatisent une partie de cette vérification en agrégeant les données de sécurité des prestataires depuis des sources multiples : bases de données de vulnérabilités, dark web, certifications, historiques d'incidents.

L'évolution vers le Zero Trust tiers

Le modèle Zero Trust, appliqué aux relations tiers, repose sur le principe qu'aucun accès accordé à un prestataire ne doit être considéré comme définitivement sûr. Les accès doivent être limités au strict nécessaire (least privilege), surveillés en temps réel, et révocables immédiatement. Cette approche, recommandée par NIST SP 800-207 (Zero Trust Architecture), impose une révision profonde de la manière dont les organisations gèrent les accès de leurs prestataires à leurs systèmes.

Études de cas
États-Unis — Target/Fazio Mechanical (2013)
Le contrat entre Target et Fazio Mechanical contenait une clause de conformité PCI-DSS. Fazio Mechanical était donc contractuellement tenue de respecter les standards de sécurité des données de paiement. Cette clause n'a pas empêché la compromission des identifiants de Fazio via un maliciel de vol de credentials, ni leur utilisation pour accéder au réseau de Target. La conformité contractuelle déclarée et la conformité opérationnelle réelle étaient deux réalités différentes — sans mécanisme de vérification, Target ne pouvait pas connaître cette différence.
Europe — Capgemini Data Exposure (2020)
Un repository Git de Capgemini, laissé publiquement accessible, a exposé des credentials, des clés API et des données clients de plusieurs organisations européennes pour lesquelles Capgemini intervenait en tant que prestataire IT. Cet incident illustre le risque d'une confiance contractuelle sans vérification : les clients de Capgemini avaient des contrats de confidentialité et de sécurité, mais aucun mécanisme de surveillance des pratiques de gestion des secrets du prestataire n'était en place.
Asie — Wipro Supply Chain Attack (2019)
Wipro, l'un des plus grands prestataires IT indiens, a subi une compromission par phishing avancé permettant aux attaquants d'utiliser ses systèmes pour attaquer ses clients via des accès distants légitimes. Plusieurs clients de Wipro — dont des institutions financières et des entreprises de commerce de détail — ont été impactés avant que l'incident ne soit détecté et contenus. Les clients touchés avaient fait confiance à Wipro sur la base de contrats de sécurité sans mécanismes de surveillance en temps réel des accès du prestataire.
WhatsApp