Les conséquences d’un manque de responsabilisation interne

L'absence de responsabilisation crée un vacuum où chacun suppose que quelqu'un d'autre gère un risque. La clarification via RACI, sans culture de sanction mais avec accountability réelle, s'étend aux fournisseurs et sous-traitants.

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

Points clés

  • L'absence de responsabilisation en sécurité crée un vacuum où chacun suppose que quelqu'un d'autre a la charge d'un risque — jusqu'à l'incident qui révèle que personne ne l'avait.
  • La responsabilisation ne signifie pas la sanction systématique — elle signifie que chaque acteur sait précisément ce dont il est responsable en matière de sécurité.
  • Le modèle RACI appliqué à la sécurité clarifie les responsabilités et supprime les ambiguïtés qui permettent les oublis.
  • La responsabilisation des fournisseurs et sous-traitants est un prolongement indispensable de la responsabilisation interne.
Cas US SolarWinds (2020) — L'enquête post-incident a révélé que la sécurité du processus de build — le point d'injection du code malveillant — était partagée entre plusieurs équipes sans qu'aucune ne soit explicitement désignée comme responsable de la sécurité de ce processus critique. Ce vacuum de responsabilité a permis à une vulnérabilité de rester invisible pendant des mois.

Le vacuum de responsabilité en sécurité

Dans les organisations sans responsabilisation claire en sécurité, un phénomène récurrent se produit : chaque acteur suppose que quelqu'un d'autre a la charge d'un risque particulier. L'équipe infrastructure suppose que l'équipe sécurité surveille les journaux d'accès. L'équipe sécurité suppose que l'équipe développement a réalisé les revues de code. L'équipe développement suppose que les opérations ont configuré les accès correctement. Le résultat est une protection fragmentée avec des angles morts que personne ne couvre explicitement.

Ce phénomène — connu en psychologie sociale comme la "diffusion de responsabilité" — est particulièrement dangereux en sécurité parce que les angles morts ne deviennent visibles que lors d'un incident. Contrairement aux processus opérationnels où un angle mort crée un ralentissement perceptible, un angle mort en sécurité peut rester invisible pendant des années.

La responsabilisation sans culture de la sanction

La responsabilisation en sécurité est souvent mal comprise comme un mécanisme de sanction. Cette confusion est contre-productive : une culture dans laquelle les erreurs de sécurité sont systématiquement sanctionnées crée des comportements de dissimulation qui amplifient les risques plutôt que de les réduire. Les incidents qui auraient pu être signalés et traités tôt sont cachés pour éviter les conséquences personnelles, jusqu'à ce qu'ils deviennent incontrôlables.

La responsabilisation sécurisée signifie que chaque acteur sait précisément ce dont il est responsable, dispose des ressources et des autorités nécessaires pour exercer cette responsabilité, et est évalué sur sa capacité à gérer le risque — pas à l'éviter ou à le cacher. Elle est compatible avec une culture du signalement proactif des erreurs, car signaler une erreur est perçu comme l'exercice de la responsabilité, pas comme une confession d'échec.

Le RACI comme outil de clarification

La matrice RACI (Responsible, Accountable, Consulted, Informed) appliquée aux processus de sécurité est un outil simple et efficace pour éliminer les ambiguïtés de responsabilité. Elle définit pour chaque processus sécurité (gestion des vulnérabilités, réponse à incident, gestion des accès, gestion des fournisseurs) qui est opérationnellement responsable (R), qui en rend compte (A — unique), qui doit être consulté (C) et qui doit être informé (I).

L'exercice de construction d'une matrice RACI pour les processus sécurité critiques révèle systématiquement des ambiguïtés — des processus avec plusieurs "A" (ce qui signifie en pratique aucun), des processus sans "R" identifié, des stakeholders qui pensaient être "C" quand ils n'étaient pas dans la matrice. Ces ambiguïtés, une fois explicitées, peuvent être corrigées avant l'incident qui les rendrait visibles autrement.

Cas EU British Airways (2018) — La compromission des données de paiement de 500 000 clients via un script malveillant injecté dans les pages de paiement a mis en évidence un vacuum de responsabilité sur la sécurité des dépendances JavaScript tierces. Aucune équipe n'avait été explicitement désignée comme responsable de la surveillance de l'intégrité du code tiers chargé sur les pages de paiement.

La responsabilisation des fournisseurs

La responsabilisation interne ne s'arrête pas aux frontières de l'organisation. Pour les fournisseurs et sous-traitants qui ont accès aux systèmes ou aux données de l'organisation, des exigences de responsabilité équivalentes doivent être formalisées contractuellement et vérifiées. Les clauses de sécurité dans les contrats de prestation — SLA de sécurité, obligation de notification des incidents, droit d'audit — sont le prolongement externe de la responsabilisation interne.

La chaîne de sous-traitance est souvent le maillon faible : des incidents majeurs ont été initiés par des prestataires de niveau deux ou trois (prestataires des prestataires) dont les pratiques de sécurité n'avaient jamais été évaluées par l'organisation cliente finale. La responsabilisation s'étend aux fournisseurs critiques, avec une profondeur proportionnelle à l'accès et à la sensibilité des données manipulées.

Cas Asie Air India (2021) — La fuite de données de 4,5 millions de passagers a eu pour origine la compromission d'un prestataire de système de réservation (SITA). L'absence de responsabilisation formelle du prestataire sur les délais de notification et les standards de protection a allongé le délai entre la compromission et l'information des passagers concernés.
WhatsApp