Chef sécurité de projet : intégrer la cybersécurité dès la conception des projets

Qu’est-ce qu’un chef sécurité de projet ?

Commençons par lever l’ambiguïté que porte l’intitulé : le chef sécurité de projet n’est pas nécessairement le chef du projet. Son rôle consiste à garantir que la sécurité est correctement prise en compte dans un projet informatique ou métier porté par quelqu’un d’autre.

Le responsable de projet cybersécurité pilote un projet dont la sécurité est l’objet. Le chef sécurité de projet sécurise un projet dont l’objet est tout autre.

Le Panorama des métiers de la cybersécurité de l’ANSSI décrit ce profil sous l’intitulé « Chef sécurité de projet », dans la famille « Conception et maintien d’un SI sécurisé ». Il retient comme équivalent anglais Project security leader, et cite « Responsable de l’intégration de la sécurité dans les projets » et « Project security manager » parmi les titres équivalents.

L’ANSSI apporte une précision utile : certaines de ces missions peuvent être prises en charge par le chef de projet lui-même, qui s’appuie alors ponctuellement sur des experts du domaine. Autrement dit, la fonction existe toujours ; c’est le fait qu’elle soit portée par une personne dédiée qui varie selon les organisations.

Sur quels projets intervient-il ?

• Une nouvelle application métier
• Une migration vers le cloud
• L’ouverture d’un nouveau site industriel
• Une application mobile destinée aux clients
• L’exposition d’une API à des partenaires
• La souscription d’un nouveau service SaaS
• Un projet d’infrastructure ou de refonte réseau
• Un projet IoT ou d’objets connectés industriels
• Un portail client ou un espace personnel

La sécurité dès la conception, étape par étape

Le principe de security by design est souvent cité et rarement détaillé. Voici comment il se traduit concrètement dans le cycle d’un projet, et à quel moment le chef sécurité de projet intervient.

1. 1. Expression du besoin

   Comprendre ce que le projet veut faire, pour qui, avec quelles données. Intervenir ici coûte quelques heures ; intervenir six mois plus tard coûte une refonte.

2. 2. Classification

   Quelle est la sensibilité des données traitées, quelle est la criticité du service pour l’activité ? C’est cette réponse qui détermine le niveau d’exigence, pas une politique appliquée uniformément.

3. 3. Exigences de sécurité

   Formuler des exigences précises, vérifiables et proportionnées. Une exigence que personne ne sait tester ne sera jamais respectée.

4. 4. Analyse de risques

   Identifier les scénarios redoutés, leurs conséquences métier et leur vraisemblance. L’ANSSI cite explicitement cette activité parmi les missions du poste.

5. 5. Architecture

   Vérifier que les solutions techniques et fonctionnelles proposées répondent aux exigences identifiées, en s’appuyant si nécessaire sur un architecte sécurité.

6. 6. Choix des contrôles

   Définir les mesures de sécurité complémentaires permettant de traiter les risques résiduels, en arbitrant entre efficacité, coût et impact sur les utilisateurs.

7. 7. Développement

   Suivre la sécurité des développements le cas échéant, en s’appuyant sur les pratiques et l’outillage de l’équipe AppSec lorsqu’elle existe.

8. 8. Tests

   Tests de sécurité, revue de configuration, parfois test d’intrusion selon la criticité. Collecter les preuves qui figureront au dossier.

9. 9. Acceptation du risque

   Selon les organisations, homologation formelle ou décision documentée d’acceptation. Une personne identifiée décide, en connaissance des écarts subsistants.

10. 10. Mise en production

    Bascule maîtrisée, avec les mesures compensatoires convenues et les échéances de traitement des écarts acceptés.

11. 11. Transfert à l’exploitation

    Documentation, procédures, points de vigilance. Sans ce transfert, les mesures de sécurité se dégradent silencieusement dans les mois qui suivent.

L’étape 2 est celle que l’on saute le plus souvent, et c’est la plus coûteuse à sauter : sans classification, on applique soit trop de sécurité à un projet anodin, soit pas assez à un projet critique.

Ses livrables

Ce métier produit de l’écrit. Ces documents ne sont pas de la bureaucratie : ce sont eux qui permettront, en cas d’incident, de savoir ce qui avait été identifié, ce qui avait été décidé et par qui.

1. Les exigences de sécurité

   Précises, vérifiables, proportionnées à la classification retenue. Elles servent aussi de base contractuelle avec un fournisseur.

2. L’analyse de risques du projet

   Scénarios redoutés, impacts métier, mesures de traitement, risques résiduels assumés.

3. Le dossier de sécurité

   Document de synthèse rassemblant la classification, les exigences, l’architecture retenue, les contrôles et les preuves.

4. L’avis sécurité

   Position formalisée sur la capacité du projet à être mis en service, avec ses réserves.

5. Le plan d’actions

   Ce qui doit être traité, par qui, à quelle échéance, notamment pour les écarts acceptés temporairement.

6. Le suivi des vulnérabilités

   Constats issus des tests, priorisation, suivi de correction jusqu’à clôture.

7. Les dérogations

   Écarts explicitement acceptés, par une autorité identifiée, avec une date de réexamen.

8. Les preuves de tests

   Éléments démontrant que les contrôles ont été vérifiés et non simplement déclarés.

L’évaluation des fournisseurs et des tiers

C’est une part du métier explicitement citée par l’ANSSI, et elle a pris une importance considérable avec la généralisation des services externalisés.

La fiche ANSSI mentionne l’évaluation des fournisseurs et des tiers lors de la souscription des contrats, et la vérification de la mise en œuvre d’un plan d’assurance sécurité selon la nature des solutions et des prestations fournies.

Ce que cela recouvre concrètement

• Quelles données le fournisseur traitera-t-il, et où seront-elles hébergées ?
• Quels engagements de sécurité figurent réellement au contrat, par opposition à la plaquette commerciale ?
• Le fournisseur dispose-t-il de certifications ou de qualifications pertinentes, et sur quel périmètre exact ?
• Quelles obligations de notification en cas d’incident chez le fournisseur ?
• Quelles conditions de réversibilité si l’entreprise change de prestataire dans trois ans ?
• Quels droits d’audit, et sont-ils exerçables en pratique ?

Le moment compte autant que le contenu : une exigence de sécurité formulée avant la signature a un poids que la même exigence n’aura plus jamais après. Un chef sécurité de projet arrivé après la contractualisation constate, il ne négocie plus.

Chef sécurité de projet, responsable de projet cyber, architecte, AppSec, RSSI

1. Chef sécurité de projet

   Garantit la prise en compte de la sécurité dans un projet dont l’objet est autre. Périmètre large, profondeur moyenne, mandat lié au projet.

2. Responsable de projet cybersécurité

   Pilote un projet dont la cybersécurité est l’objet principal. Responsable du budget, du planning et du résultat du projet.

3. Architecte cybersécurité

   Définit les modèles de référence et arbitre les choix structurants pour l’ensemble du système d’information, au-delà d’un projet.

4. AppSec Engineer

   Travaille sur le code et les pratiques de développement. Périmètre plus étroit, profondeur bien plus grande sur la partie applicative.

5. RSSI

   Décide du niveau de risque acceptable et tranche les arbitrages que le chef sécurité de projet fait remonter.

Sur un projet applicatif d’ampleur, ces cinq rôles interviennent tous : l’architecte fixe la cible, le chef sécurité de projet formalise les exigences et suit les écarts, l’AppSec traite le code, le chef de projet tient le calendrier, et le RSSI tranche si un écart significatif doit être accepté.

Les qualités attendues

Ce métier se joue sur une tension permanente : le projet a un calendrier et un budget, la sécurité a des exigences. Le chef sécurité de projet vit dans cette tension sans pouvoir la trancher seul.

• Sens du proportionné : exiger ce qui est justifié par la classification, pas le maximum théorique
• Diplomatie : obtenir sans autorité, auprès d’équipes dont la sécurité n’est pas la priorité
• Anticipation : intervenir au bon moment, c’est-à-dire tôt
• Clarté d’écriture : une exigence ambiguë n’est jamais respectée
• Écoute : comprendre la contrainte du projet avant d’imposer une mesure
• Courage : formaliser un risque que le projet préférerait ne pas voir écrit
• Pragmatisme : préférer une mesure compensatoire appliquée à une exigence idéale ignorée
• Organisation : suivre plusieurs projets à des stades différents sans en perdre

Le piège classique : devenir le service qui dit non. Un chef sécurité de projet contourné n’a plus aucune utilité, et les projets trouvent toujours un moyen de le contourner.

Reconversion : une passerelle naturelle

L’ANSSI l’indique explicitement : le métier est accessible à partir d’une expérience préalable en gestion de projet informatique. C’est une porte d’entrée réaliste vers la cybersécurité.

Profils pertinents

• Chefs de projet IT, qui maîtrisent déjà le cycle et les interlocuteurs
• Architectes, qui comprennent les choix techniques et leurs conséquences
• Consultants, à l’aise avec la formalisation et la restitution
• Ingénieurs cybersécurité souhaitant se rapprocher des projets et des métiers
• Administrateurs expérimentés ayant accompagné des déploiements
• Profils GRC cherchant une dimension plus opérationnelle

Trajectoires fréquentes

Le point commun de ces parcours : ils apportent déjà la moitié du métier. Un chef de projet sait faire avancer des gens ; il doit apprendre le risque. Un ingénieur sécurité connaît le risque ; il doit apprendre à formaliser et à négocier.

Où exerce-t-on ce métier ?

La fonction se formalise surtout là où le flux de projets est important et où une traçabilité est exigée — secteurs régulés, opérateurs de services essentiels, organisations soumises à NIS2. Ailleurs, elle est portée à temps partagé par un ingénieur sécurité ou un profil GRC.

Avantages et contraintes du métier

• Impact réel : on évite des problèmes plutôt que de les constater
• Grande variété de projets, de technologies et d’interlocuteurs
• Vision transversale : métiers, IT, fournisseurs, conformité
• Passerelle naturelle vers l’architecture, la GRC ou le poste de RSSI
• Reconversion accessible depuis la gestion de projet
• Peu d’astreintes, rythme aligné sur les projets

• Tension permanente entre exigences de sécurité et calendrier projet
• Aucune autorité hiérarchique sur les équipes concernées
• Risque d’être perçu comme un point de blocage
• Sollicitation souvent trop tardive, quand les choix sont déjà figés
• Charge rédactionnelle importante
• Responsabilité morale des écarts acceptés, sans pouvoir de décision