Points clés
- La sécurité est systématiquement sous-représentée au lancement des projets pour des raisons structurelles : pression de délai, perception de coût additionnel, absence de compétences dans les équipes projet, et culture projet qui valorise les fonctionnalités.
- Le coût d'intégration de la sécurité augmente exponentiellement à mesure qu'un projet avance — corriger une faille dans les spécifications coûte 10 fois moins qu'en production.
- Le principe Security by Design — intégrer la sécurité dans la conception plutôt qu'en contrôle final — est connu mais sous-appliqué pour des raisons organisationnelles, pas techniques.
- Des changements dans la gouvernance des projets — validation sécurité aux jalons, RSSI impliqué dans les comités de pilotage, budget sécurité projet prédéfini — adressent les causes structurelles.
Il n'y a pas de mauvaise volonté dans l'absence de sécurité au lancement des projets — il y a des mécanismes structurels qui la produisent systématiquement, dans des organisations pourtant conscientes de l'importance de la sécurité. Comprendre ces mécanismes est la condition pour les corriger, car les exhortations à "penser sécurité dès le début" sans changer les structures qui s'y opposent ne produisent pas de résultats durables.
Les mécanismes structurels qui marginaliseraient la sécurité au lancement des projets incluent : les délais de décision qui ne laissent pas le temps d'une évaluation des risques sérieuse, les budgets projet qui n'incluent pas de ligne "sécurité", les équipes projet sans compétences sécuritaires internes, et une culture de valorisation des fonctionnalités qui traite la sécurité comme un coût sans bénéfice visible.
La règle du 1-10-100 : le coût croissant des corrections tardives
La règle du 1-10-100 en gestion de la qualité s'applique directement à la sécurité : corriger un problème de sécurité au stade des spécifications coûte 1 ; au stade du développement, 10 ; en production après déploiement, 100. Cette progression n'est pas exponentielle dans le sens mathématique strict, mais la direction de l'ordre de grandeur est documentée et robuste.
Intégré dans les argumentaires présentés aux directions de projet, ce ratio transforme la question de la sécurité d'un coût additionnel en un investissement qui réduit les coûts totaux. Un chef de projet informé de ce ratio prend des décisions différentes sur l'inclusion de ressources sécurité dans la phase de conception.
L'absence de compétences sécurité dans les équipes projet
Les équipes projet sont typiquement composées de chefs de projet, d'analystes fonctionnels, de développeurs et de consultants métier. Elles n'incluent généralement pas de compétences sécurité internes — sauf si l'organisation a explicitement décidé que chaque projet significatif doit inclure un référent sécurité. Cette absence de compétences n'est pas compensée par des formations génériques sur la sécurité : savoir que la sécurité est importante ne permet pas de conduire une analyse de risques projet ou de définir des exigences de sécurité fonctionnelles.
La culture projet : fonctionnalités versus sécurité
Les critères de succès d'un projet sont typiquement définis par les fonctionnalités livrées, les délais respectés et le budget tenu. La sécurité n'apparaît pas dans ces critères — sauf si elle est explicitement incluse dans la définition du succès au moment du cadrage. Cette absence structurelle dans les critères oriente naturellement les arbitrages vers les fonctionnalités et contre la sécurité lorsque des choix doivent être faits sous contrainte.
Inclure explicitement des critères de sécurité dans les définitions du succès projet — pas uniquement comme conditions de conformité mais comme dimensions de valeur — est une intervention structurelle qui réoriente les arbitrages sans nécessiter d'exhortations répétées.
Security by Design : des pratiques qui fonctionnent
Les organisations qui ont réussi à intégrer la sécurité dès le lancement des projets ont mis en place des mécanismes structurels : un processus de security intake obligatoire pour tout projet au-dessus d'un seuil de coût ou d'exposition, un référent sécurité dans chaque comité de pilotage de projet, un budget sécurité prédéfini dans les templates de budget projet, et des critères de sécurité dans les conditions d'approbation des jalons. Ces mécanismes ne nécessitent pas une culture parfaite — ils produisent les comportements souhaités indépendamment des résistances individuelles.
Études de cas
Microsoft SDL — Security by Design à grande échelle
Microsoft a développé son Security Development Lifecycle (SDL) en réponse à la lettre Trustworthy Computing de Bill Gates en 2002. Ce processus, qui intègre des activités de sécurité obligatoires à chaque phase du développement logiciel, a permis à Microsoft de réduire significativement le nombre de vulnérabilités dans ses produits. La clé du succès du SDL n'est pas uniquement technique — c'est l'obligation organisationnelle : les équipes ne peuvent pas passer au jalon suivant sans avoir complété les activités de sécurité requises. Cette obligation structurelle a rendu les bons comportements indépendants de la bonne volonté individuelle.
Ville de New York — Security by Design dans les projets IT municipaux
La ville de New York a intégré des exigences de Security by Design dans sa politique de gouvernance IT, imposant une évaluation des risques de sécurité comme condition d'approbation de tout projet IT dépassant un seuil de budget. Cette politique, développée après plusieurs incidents liés à des projets mal sécurisés, a produit une augmentation du coût initial des projets IT (de 3 à 5%) mais une réduction significative des incidents de sécurité post-déploiement — confirmant l'économie nette d'une intégration précoce.
Organisations régulées — DORA et l'intégration obligatoire de la sécurité dans les projets
Le règlement DORA (Digital Operational Resilience Act) européen impose aux institutions financières d'intégrer des exigences de sécurité et de résilience dans le cycle de vie de leurs projets IT, incluant des tests de sécurité avant mise en production et des évaluations de risques pour les changements significatifs. Ces exigences, applicables depuis janvier 2025, ont conduit de nombreuses institutions financières européennes à formaliser des processus de Security by Design qu'elles n'avaient pas encore structurés — illustrant comment la réglementation accélère l'adoption de pratiques connues mais sous-appliquées.
États-Unis — NIST SSDF (Secure Software Development Framework)
Le NIST a publié le Secure Software Development Framework (SSDF, SP 800-218) qui fournit un ensemble de pratiques fondamentales pour intégrer la sécurité dans le cycle de développement logiciel. Ce cadre, adopté comme exigence par les agences fédérales américaines et recommendé pour les fournisseurs de logiciels au gouvernement fédéral, représente la formalisation institutionnelle la plus avancée des pratiques de Security by Design — avec des implications pour l'ensemble des éditeurs de logiciels vendant aux États-Unis.
Union européenne — Cyber Resilience Act et Security by Design obligatoire
Le Cyber Resilience Act (CRA) européen, adopté en 2024, impose aux fabricants de produits numériques (logiciels et matériels connectés) d'intégrer la sécurité dès la conception (Security by Design) et de maintenir cette sécurité tout au long du cycle de vie du produit. Cette obligation légale, qui s'appliquera progressivement à partir de 2027, transforme le Security by Design d'une bonne pratique volontaire en obligation réglementaire avec des sanctions en cas de non-conformité — un changement majeur dans la gouvernance de la sécurité des projets de développement en Europe.
Singapour — CSA et le Security-by-Design dans les projets gouvernementaux
Le gouvernement singapourien a formalisé des exigences de Security by Design dans sa politique de gouvernance IT des projets publics, imposant des évaluations de risques de sécurité à chaque phase des projets significatifs. Cette politique, implémentée via des guidelines techniques de la GovTech (Government Technology Agency) et auditée par la CSA, a produit une amélioration mesurable de la posture de sécurité des systèmes gouvernementaux singapouriens — et est citée comme modèle par plusieurs administrations de la région ASEAN cherchant à renforcer la sécurité de leurs projets de transformation numérique.