Du management de projet à la sécurité : ce qui se transfère vraiment

Les chefs de projet qui envisagent une transition vers la cybersécurité supposent souvent qu'ils commencent de zéro. Ce n'est pas le cas. Les soft skills qui vous ont rendu efficace dans la gestion de projets — gestion des parties prenantes, suivi des risques, coordination des incidents — s'appliquent directement au travail de sécurité. Ce qui manque, c'est la base technique, et cet écart peut être comblé en 12 à 18 mois si vous y allez méthodiquement.

Ce qui se transfère vraiment

Si vous avez géré un projet avec un registre des risques, vous comprenez déjà la logique fondamentale d'une évaluation des risques de sécurité : identifier l'actif, estimer la probabilité et l'impact, décider d'un traitement (accepter, atténuer, transférer, éviter). Les équipes de sécurité utilisent exactement le même cadre, appliqué à des systèmes au lieu de livrables. Le Risk Management Framework de NIST et la norme ISO 27005 sont des versions formalisées de ce qu'un chef de projet certifié PMP fait déjà intuitivement.

La gestion des incidents est un autre domaine de chevauchement. Diriger une war room lors d'une panne en production est structurellement similaire à en diriger une lors d'un événement de rançongiciel : quelqu'un doit gérer les communications, quelqu'un doit suivre la chronologie, quelqu'un doit prendre des décisions sous pression sans informations complètes. Les équipes de sécurité appellent cela incident command ; vous le reconnaissez peut-être comme de la gestion de crise avec un vocabulaire différent.

La supervision des fournisseurs et des contrats se transfère également bien. La gestion des risques tiers — examiner les fournisseurs SaaS, consulter les rapports SOC 2, négocier les clauses de sécurité dans les contrats — est un créneau croissant au sein des rôles GRC (gouvernance, risque et conformité), et cela récompense quelqu'un qui sait déjà lire un contrat et gérer une relation fournisseur.

L'écart technique que vous ne pouvez pas ignorer

C'est là que la plupart des transitions PM vers la sécurité stagnent : vous ne pouvez pas gérer un SOC, examiner un rapport de test de pénétration ou délimiter un plan de correction des vulnérabilités sans comprendre ce qui est dessous. Vous avez besoin d'une connaissance pratique des réseaux (TCP/IP, DNS, comment un firewall filtre réellement le trafic), des bases de la ligne de commande Linux et de la façon dont les vulnérabilités du Top 10 OWASP fonctionnent en pratique, pas seulement comme des points sur une diapositive.

Cela ne signifie pas devenir pentesteur. Cela signifie être capable de lire une sortie de scan Nessus ou Qualys et de comprendre pourquoi un patch manquant sur le port 445 importe, ou pourquoi une instance Redis non authentifiée exposée à Internet est un événement grave. Passez du temps avec un home lab : lancez quelques machines virtuelles dans VirtualBox, installez pfSense comme firewall, lancez Wireshark contre votre propre trafic. Les concepts s'assimilent plus vite quand vous avez cassé quelque chose vous-même.

Les certifications qui ont du sens pour ce parcours

Évitez de sauter directement à OSCP ou quoi que ce soit de lourd en sécurité offensive — c'est une piste différente. Avec un parcours PM, la séquence qui fonctionne généralement est :

1. CompTIA Security+ — vous donne le vocabulaire et les concepts fondamentaux couvrant les réseaux, les menaces et les contrôles.
2. CISM ou CRISC (ISACA) — ces certifications s'orientent vers la gouvernance et les risques, ce qui joue sur vos forces existantes et est souvent plus pertinent pour les rôles de GRC ou de gestionnaire de programme de sécurité que les certifications techniques.
3. CISSP — à terme, une fois que vous avez une exposition pratique ; elle requiert de toute façon cinq années d'expérience pertinente pour la certification complète, donc c'est un objectif à mi-parcours, pas un point de départ.

Évitez d'accumuler des certifications en substitut à l'expérience. Un responsable du recrutement pour un rôle de Security Program Manager veut voir que vous pouvez parler intelligemment d'un processus de tri des alertes SIEM, pas que vous ayez quatre acronymes après votre nom.

Où vous allez vraiment atterrir en premier