Points clés
- La sécurité des projets est une responsabilité partagée entre plusieurs acteurs : direction de projet, RSSI, équipes IT, MOA/MOE et prestataires — sans clarification explicite, elle appartient à personne.
- Le chef de projet est le premier responsable de l'intégration de la sécurité dans son projet — pas le RSSI qui n'en est qu'un conseiller et un valideur.
- Les responsabilités de sécurité des prestataires doivent être définies contractuellement, pas présupposées — c'est le principe de la chaîne de responsabilité étendue.
- En cas d'incident lié à un projet mal sécurisé, la responsabilité remonte jusqu'aux décideurs qui ont approuvé les compromis de sécurité — pas uniquement aux équipes opérationnelles.
L'une des causes les plus fréquentes de lacunes sécuritaires dans les projets est l'ambiguïté des responsabilités : qui est responsable de s'assurer que le projet est sécurisé ? Dans de nombreuses organisations, la réponse implicite est "le RSSI" — ce qui est incorrect et contre-productif. Le RSSI est un expert, un conseiller et un valideur, mais la responsabilité opérationnelle de la sécurité d'un projet appartient à son chef de projet et, en ultime recours, à la direction qui l'a approuvé.
Cette clarification de la responsabilité n'est pas seulement théorique — elle a des implications pratiques directes sur les comportements d'arbitrage : un chef de projet qui comprend qu'il est personnellement responsable de la sécurité de son projet prend des décisions différentes de celui qui considère la sécurité comme le problème de quelqu'un d'autre.
La responsabilité du chef de projet
Le chef de projet est responsable de s'assurer que son projet intègre les exigences de sécurité définies par l'organisation, de solliciter les expertises nécessaires (RSSI, architecte sécurité), de budgéter les activités de sécurité, et de ne pas faire de compromis sécuritaires sans avoir informé les parties concernées et obtenu les approbations appropriées. Cette responsabilité doit figurer dans la charte de projet, dans les objectifs du chef de projet et dans les critères d'évaluation de sa performance.
Le rôle du RSSI : conseil, validation et escalade
Le RSSI définit les exigences de sécurité que les projets doivent satisfaire, fournit l'expertise pour les évaluations de risques, valide les choix d'architecture de sécurité et escalade vers la direction les risques qui dépassent le niveau d'acceptabilité défini. Il n'est pas responsable de la sécurité des projets à la place de leurs chefs de projet — son rôle est d'enabler et de superviseur, pas d'exécutant.
Cette distinction de rôle est importante pour la gouvernance : si le RSSI est considéré comme le seul responsable de la sécurité des projets, il n'a ni les ressources ni le mandat pour assumer cette responsabilité pour l'ensemble du portefeuille de projets de l'organisation — créant une situation où tout le monde croit que quelqu'un s'occupe de la sécurité pendant que personne ne s'en occupe vraiment.
La responsabilité des prestataires
Les prestataires qui participent à des projets (intégrateurs, consultants, développeurs offshore) ont des responsabilités de sécurité qui doivent être définies contractuellement : obligations de respecter les politiques de sécurité de l'organisation, de ne pas introduire de vulnérabilités connues dans le code livré, de sécuriser leurs propres systèmes qui accèdent aux environnements du client, et de notifier rapidement tout incident de sécurité les affectant qui pourrait avoir des conséquences pour le client.
En l'absence de ces définitions contractuelles, les responsabilités des prestataires sont présupposées — avec des ambiguïtés qui se révèlent lors des incidents quand il s'agit de déterminer qui est responsable de quoi.
La responsabilité des décideurs qui approuvent les compromis
Lorsqu'un chef de projet soumet un compromis de sécurité à l'approbation de sa hiérarchie — "nous acceptons ce risque pour tenir le délai" — la personne qui approuve ce compromis partage la responsabilité des conséquences si le risque accepté se matérialise. Cette responsabilité, qui remonte jusqu'aux niveaux les plus élevés de la hiérarchie selon la criticité des décisions, est le mécanisme qui transforme les décisions de sécurité projet en décisions de direction.
Études de cas
FACC — Responsabilité du comité exécutif pour un défaut de gouvernance projet
La condamnation du PDG et du CFO de FACC après la fraude au président de 50 millions d'euros a établi que les décideurs sont responsables de l'absence de processus de sécurité adéquats dans leurs organisations — pas uniquement les employés opérationnels qui ont commis l'erreur. Ce précédent, applicable à la sécurité des projets, illustre que la responsabilité des compromis de sécurité remonte jusqu'aux niveaux de la direction qui ont les décisions de gouvernance.
Contractualisation de la sécurité prestataires — Bonnes pratiques sectorielles
Plusieurs grandes organisations financières et industrielles ont développé des cadres contractuels standardisés pour les prestataires IT, définissant précisément les responsabilités de sécurité de chaque partie. Ces cadres, qui incluent des droits d'audit, des obligations de notification d'incidents, des exigences de formation et des responsabilités en cas de violation, transforment les relations avec les prestataires d'une confiance implicite en un cadre de responsabilité explicite. Les organisations qui ont formalisé ces cadres documentent une réduction des incidents liés aux prestataires dans leurs projets.
RACI de sécurité dans les projets — Résultats documentés
Des organisations qui ont intégré un RACI (Responsible, Accountable, Consulted, Informed) de sécurité dans leurs templates de cadrage de projets documentent une réduction des situations d'ambiguïté sur les responsabilités — et une amélioration correspondante de l'intégration des activités de sécurité dans les projets. Ce RACI, discuté et validé au lancement de chaque projet, assure que chaque partie prenante comprend son rôle dans la sécurité du projet et ne peut pas plaider l'ignorance de ses responsabilités en cas d'incident.
États-Unis — SEC et la responsabilité des CISO pour les décisions de sécurité projet
La SEC a engagé des poursuites contre le CISO de SolarWinds pour des déclarations prétendument trompeuses sur les pratiques de sécurité de l'entreprise dans ses projets. Bien que l'issue finale de cette affaire reste à déterminer, les poursuites illustrent une tendance à la responsabilisation personnelle des dirigeants sécurité pour les décisions de gouvernance des projets. Cette tendance change la dynamique d'arbitrage : un RSSI qui sait que les décisions de sécurité projet peuvent engager sa responsabilité personnelle adopte un positionnement différent dans les discussions de gouvernance.
Union européenne — NIS2 et la responsabilité des dirigeants
La directive NIS2 introduit une responsabilité personnelle des membres des organes de direction pour les manquements aux obligations de sécurité des organisations — incluant potentiellement les décisions de gouvernance des projets qui ont conduit à des incidents. Cette responsabilité personnelle des dirigeants, nouvelle dans le cadre réglementaire européen, est un levier significatif pour que les décisions de sécurité projet remontent effectivement au niveau exécutif et soient traitées avec la sérieux qu'elles méritent.
Singapour — PDPA et responsabilité des organisations pour les projets impactant les données personnelles
La PDPA (Personal Data Protection Act) singapourienne établit une responsabilité claire des organisations pour les incidents de données personnelles résultant de projets insuffisamment sécurisés — sans permettre de se défausser sur les prestataires ou sur les équipes opérationnelles. Cette responsabilité organisationnelle non diluable incite les dirigeants singapouriens à s'assurer que les projets impactant les données personnelles sont encadrés avec les exigences de sécurité appropriées dès leur conception.