Points clés
- Les erreurs les plus fréquentes dans la gestion des risques projet ne sont pas techniques : elles sont organisationnelles — mauvaise évaluation de l'impact des changements, absence de revues de sécurité aux jalons, tests de sécurité réduits sous pression de délai.
- L'erreur de périmètre — sous-estimer quels systèmes sont affectés par un projet — est particulièrement coûteuse et fréquente lors des migrations et intégrations.
- Le traitement de la sécurité comme liste de contrôle finale plutôt que comme dimension continue produit des projets qui "passent" les audits mais ont des problèmes réels en production.
- Des templates de gestion des risques projet sécurisés, adaptés à la taille et à la criticité de chaque projet, réduisent structurellement ces erreurs.
Les erreurs dans la gestion des risques des projets IT ont une géographie prévisible : elles se concentrent dans les phases de conception (quand les risques ne sont pas encore évalués), lors des transitions (quand les équipes sont sous pression et que la sécurité est sacrifiée), et à la fin des projets (quand les tests de sécurité sont raccourcis pour tenir les délais).
Ces erreurs ne résultent pas d'ignorance — la plupart des chefs de projet et des équipes savent qu'elles constituent des risques. Elles résultent de pressions organisationnelles et de l'absence de mécanismes qui rendraient les bonnes pratiques non optionnelles. Les corriger exige des changements dans ces mécanismes, pas uniquement dans la conscience des équipes.
L'erreur de périmètre : sous-estimer les systèmes affectés
La sous-estimation du périmètre des systèmes affectés par un projet est l'une des erreurs les plus coûteuses et les plus fréquentes. Un projet de migration d'une application peut sembler limité mais affecter en réalité des dizaines de systèmes qui dépendent de l'application migrée — via des APIs, des flux de données, des processus d'authentification. Ces dépendances non anticipées créent des expositions lors de la migration qui ne figuraient pas dans l'évaluation initiale des risques.
Un inventaire systématique des dépendances des systèmes concernés — qui devrait être la première étape de tout projet de transformation — est souvent sauté ou conduit superficiellement, créant une vision incomplète du périmètre réel qui sous-tend toute la gestion des risques projet.
Les tests de sécurité raccourcis en fin de projet
Les tests de sécurité (tests d'intrusion, revues de code, analyses de vulnérabilités) sont les premiers à être réduits lorsqu'un projet est en retard — car ils sont perçus comme moins urgents que les tests fonctionnels, et parce que leurs résultats peuvent forcer une extension de délai que personne ne souhaite annoncer. Ce raccourci est l'un des plus documentés dans les post-mortems de projets ayant subi des incidents de sécurité en production.
Instaurer une règle organisationnelle que les tests de sécurité ne peuvent pas être supprimés pour tenir un délai — que le délai doit être revu plutôt que les tests supprimés — est une décision de gouvernance de la direction générale qui n'est pas toujours populaire mais qui prévient des incidents coûteux.
La gestion des tiers dans les projets
Les projets IT font appel à des prestataires, des intégrateurs, des éditeurs de logiciels et des fournisseurs cloud dont la sécurité est souvent insuffisamment évaluée lors de leur sélection et dont les accès sont insuffisamment contrôlés pendant le projet. Chaque tiers avec un accès aux systèmes dans le cadre d'un projet est une extension de la surface d'attaque de l'organisation — dont la sécurité dépend désormais du plus faible maillon de cette chaîne étendue.
La documentation des décisions de sécurité
Les décisions de sécurité prises pendant un projet — notamment les risques acceptés et les mesures compensatoires définies — sont rarement documentées de manière à être réutilisables lors des évolutions ou des audits futurs. Cette absence de mémoire des décisions de sécurité projet signifie que chaque évolution future du système repart de zéro dans l'évaluation des risques, et que les auditeurs ne peuvent pas vérifier que les risques identifiés ont bien été traités conformément aux décisions initiales.
Études de cas
Equifax 2017 — Vulnérabilité non patchée dans un système de transformation
La vulnérabilité Apache Struts exploitée dans la compromission d'Equifax existait dans un système utilisé pour la gestion d'un projet de transformation interne — un système qui n'était pas dans le périmètre de surveillance habituel parce qu'il était considéré comme temporaire ou de faible criticité. Cette erreur de périmètre, combinée à un processus de patch management qui ne couvrait pas les systèmes de projet, a créé la fenêtre d'exploitation. La compromission a exposé les données de 147 millions d'Américains.
Tests de sécurité absents — Incident e-gouvernement européen
L'ENISA a documenté un incident dans un système e-gouvernement européen où des tests de sécurité avaient été supprimés pour permettre le respect d'une deadline politique. La vulnérabilité non découverte (injection SQL dans un formulaire public) a été exploitée quelques semaines après la mise en production, exposant les données personnelles de milliers de citoyens. L'enquête post-incident a révélé que les tests de sécurité supprimés auraient détecté la vulnérabilité en moins d'une heure — un coût de prévention infiniment inférieur au coût de l'incident.
Intégrateur compromis comme vecteur — Secteur industriel
Un groupe industriel européen a subi une compromission via son intégrateur ERP pendant la phase de déploiement d'un nouveau système. L'intégrateur, dont la sécurité propre était insuffisante, a servi de pivot d'attaque — les attaquants ont compromis l'intégrateur, puis utilisé ses accès légitimes aux systèmes du client pour s'installer dans l'infrastructure. L'absence d'évaluation de la sécurité de l'intégrateur et de surveillance de ses accès pendant le projet a rendu cette attaque possible.
États-Unis — NIST SP 800-64, sécurité dans le cycle de vie des systèmes
Le NIST SP 800-64 (Security Considerations in the System Development Life Cycle) documente les pratiques de gestion des risques à chaque phase des projets IT, incluant des listes de contrôle spécifiques pour les erreurs les plus fréquentes. Ce guide, régulièrement cité dans les enquêtes post-incident pour documenter les standards que les organisations auraient dû suivre, fournit un cadre de référence pour structurer la gestion des risques des projets IT de manière à prévenir les erreurs les plus documentées.
France — ANSSI, guide de maîtrise du risque dans les systèmes d'information
L'ANSSI a publié des méthodologies de maîtrise du risque (EBIOS Risk Manager) adaptées à la gestion des risques des projets IT, incluant des modules spécifiques pour les projets de transformation. Ces méthodologies documentent les erreurs les plus fréquentes identifiées lors des interventions de l'ANSSI et proposent des contre-mesures structurées. Leur adoption progressive dans les administrations et les opérateurs d'importance vitale illustre comment une méthodologie standardisée peut réduire la fréquence des erreurs récurrentes dans la gestion des risques projet.
Corée du Sud — ISMS-P et les exigences de sécurité projet
Le standard coréen ISMS-P (Information Security Management System — Personal information) impose des exigences spécifiques sur la gestion de la sécurité pendant les projets de développement et de transformation des systèmes d'information, incluant des revues de sécurité obligatoires, des tests de pénétration avant mise en production et une documentation des décisions de sécurité prises pendant le projet. Ces exigences, auditées par la KISA (Korea Internet & Security Agency), ont conduit à une amélioration mesurable de la sécurité des projets dans les organisations certifiées ISMS-P.