Points clés
- Tant que la sécurité n'est pas un critère de décision au même titre que le coût, le délai et la fonctionnalité, elle sera systématiquement sacrifiée lors des arbitrages sous contrainte.
- Intégrer la sécurité dans les critères de décision projet exige de la traduire en termes compréhensibles par les décideurs : coût du risque, impact potentiel, délai de remédiation.
- Les critères de validation de chaque jalon doivent inclure des dimensions sécuritaires non optionnelles — pas des "nice to have" mais des conditions de passage au jalon suivant.
- La direction générale qui définit explicitement la sécurité comme critère de décision projet donne un mandat clair qui change les comportements d'arbitrage à tous les niveaux.
Dans la gouvernance de la plupart des projets, trois critères dominent les décisions : le coût (est-on dans le budget ?), le délai (est-on dans les temps ?) et la fonctionnalité (livre-t-on ce qui était prévu ?). La sécurité n'est pas un quatrième critère de même rang — elle est traitée comme une contrainte à satisfaire minimalement, une case à cocher dans un formulaire de conformité, ou un sujet dont la responsabilité est déléguée à une équipe IT qui n'a pas le mandat d'influencer les décisions de pilotage.
Ce positionnement structural de la sécurité dans la gouvernance projet explique à lui seul la majorité des incidents post-déploiement liés à des projets. Le corriger exige une décision explicite de la direction générale sur le statut de la sécurité dans les critères de décision.
Traduire la sécurité en langage de décision
La première condition pour que la sécurité devienne un critère de décision réel est qu'elle soit exprimée dans un langage compréhensible par les décideurs — pas uniquement par les spécialistes. Une vulnérabilité CVSS 9.8 dans un système critique est difficile à arbitrer pour un directeur de projet non technique ; "cette vulnérabilité peut permettre à un attaquant d'accéder à l'ensemble de la base de données clients, avec un risque estimé à 5 millions d'euros selon notre calcul de risque" est un argument qui entre dans un arbitrage budgétaire.
Développer la capacité à traduire les risques de sécurité en termes financiers et stratégiques est une compétence clé du RSSI qui veut que la sécurité soit prise en compte dans les décisions de pilotage des projets.
Des critères de validation aux jalons non optionnels
L'intégration de la sécurité dans les jalons de décision projet passe par la définition de critères de passage non optionnels — des conditions dont la non-satisfaction bloque le passage au jalon suivant, comme c'est le cas pour des critères budgétaires ou fonctionnels. Ces critères peuvent inclure : l'existence d'une évaluation des risques à jour, la réalisation des tests de sécurité planifiés, la mise en oeuvre des mesures correctives identifiées lors des revues précédentes, et la documentation des risques acceptés avec leur plan de remédiation.
Le rôle du RSSI dans les comités de pilotage
Le RSSI (ou un représentant de la sécurité) dans les comités de pilotage des projets significatifs est une condition de facto pour que la sécurité soit un critère de décision réel. Sans représentation sécurité dans les instances de décision, la sécurité est abordée uniquement lorsqu'un problème est identifié — pas comme dimension permanente de l'évaluation du projet. Cette présence n'est efficace que si le représentant sécurité a un mandat réel pour influencer les décisions et pas uniquement pour "informer" le comité.
La gouvernance de la sécurité projet : un mandat de direction
L'intégration de la sécurité dans les critères de décision projet n'est pas une transformation opérationnelle que les équipes peuvent conduire seules — c'est une décision de gouvernance qui doit être prise et maintenue par la direction générale. Elle se traduit dans les politiques de gouvernance des projets, dans les mandats des comités de pilotage, dans les critères d'évaluation des chefs de projet, et dans les comportements de la direction elle-même lorsqu'elle arbitre entre délai et sécurité.
Études de cas
Goldman Sachs — Sécurité comme critère de validation des projets technologiques
Goldman Sachs a formalisé la sécurité comme critère de validation obligatoire dans son processus de gouvernance des projets technologiques, incluant des revues de sécurité aux jalons majeurs et une condition de "security sign-off" avant toute mise en production significative. Cette approche, documentée dans des publications sur la gouvernance IT des institutions financières, a produit une amélioration mesurable de la posture de sécurité des systèmes de la banque tout en maintenant sa cadence de déploiement — démontrant que la sécurité intégrée tôt ne ralentit pas les projets, elle évite les retards liés aux incidents post-déploiement.
Programme gouvernemental — Sécurité comme condition d'approbation budgétaire
Plusieurs administrations publiques européennes ont intégré dans leurs processus d'approbation budgétaire des projets IT une condition de présentation d'une évaluation des risques de sécurité et d'un budget sécurité identifié. Cette condition, gérée par les DSI centraux en coordination avec les RSSI, a produit une augmentation du nombre de projets incluant une ligne sécurité dans leur budget — illustrant comment une condition administrative transforme un sujet optionnel en obligation de fait.
Intégration au tableau de bord du comité exécutif — Résultats documentés
Des organisations qui ont intégré des indicateurs de sécurité projet dans le tableau de bord mensuel présenté au comité exécutif — pourcentage de projets avec évaluation des risques à jour, pourcentage de projets avec tests de sécurité planifiés, nombre de vulnérabilités "critiques" en attente de correction dans les projets en cours — documentent une amélioration significative de l'attention portée à la sécurité projet par les équipes. La visibilité au niveau exécutif transforme la dynamique d'arbitrage à tous les niveaux de l'organisation.
États-Unis — Executive Order 14028 et la sécurité dans les projets logiciels
L'Executive Order 14028 sur la cybersécurité, signé en 2021, impose aux fournisseurs de logiciels au gouvernement fédéral américain d'intégrer des pratiques de sécurité dans leur cycle de développement — incluant des critères de sécurité dans leurs processus de validation de projets. Cet ordre exécutif, qui transforme une pratique recommandée en condition commerciale pour accéder au marché fédéral américain, a eu des effets sur l'ensemble de l'industrie logicielle — pas uniquement sur les fournisseurs gouvernementaux — en normalisant la sécurité comme critère de qualité des projets logiciels.
Union européenne — Cyber Resilience Act et obligations des éditeurs
Le Cyber Resilience Act européen impose aux fabricants de produits numériques d'intégrer la sécurité dans leurs processus de développement et de la démontrer lors de la mise sur le marché. Ces obligations transforment la sécurité d'un critère optionnel en condition légale de commercialisation — un changement structurel qui rend les investissements en sécurité projet non plus optionnels mais obligatoires pour les acteurs concernés.
Corée du Sud — Exigences de sécurité dans les marchés publics IT
La Corée du Sud a intégré des critères de sécurité dans ses processus d'appel d'offres publics IT, imposant aux soumissionnaires de démontrer l'intégration de pratiques de sécurité dans leurs méthodologies de projet et de fournir des plans de tests de sécurité dans leurs propositions. Cette approche, qui conditionne l'accès au marché public à des engagements de sécurité projet, a eu un effet d'entraînement sur les pratiques du secteur privé coréen — les pratiques développées pour les projets publics étant progressivement adoptées pour les projets privés.