#03 - Proof of Concept : 4 Mesures de Sécurité issues du Terrain
Contexte
L’utilisation de plus en plus important du mode agile
Les DSI généralisent l’usage de l’agile pour accélérer leurs projets informatiques et renforcer la collaboration avec les métiers. Cette méthode, initialement centrée sur le développement logiciel, devient un standard organisationnel. Selon une étude du Project Management Institute (PMI, Pulse of the Profession 2021), 71 % des organisations déclarent utiliser régulièrement des approches agiles dans leurs projets, illustrant une adoption désormais largement majoritaire. Bon même si en pratique, le mode Agile est un peu surexploité, mais l’idée est bien là, présente quasiment à chaque fois.
Déploiement rapidement de nouvelle solutions avec le concept de POC
Le Proof of Concept (POC) est devenu une pratique courante pour tester rapidement de nouvelles solutions avant tout déploiement. Selon CloudMyLab – Managed POC Solution: Unleashing Business Benefits (2024), les environnements POC permettent de réduire les risques de déploiement de 78 % et d’accélérer le time-to-market de 45 %. En pratique, on retrouve aussi le terme de Proof Of Value.
L’IA et les agents accentuent la pression sur le go to market des équipes
Les projets IA express, souvent menés en quelques semaines, subissent une pression croissante pour aller vite. Selon McKinsey (State of AI, mars 2025), 78 % des organisations utilisent désormais l’IA dans au moins une fonction métier, accentuant cette dynamique de rapidité dans les déploiements. Et du coup, on se retrouve avec des LLM déployées sur des PC portables, par des apprentis.
Problèmes
La cybersécurité pas consultés sur ces petits projets rapides
Dans les projets rapides, notamment autour de l’IA ou des POC, les équipes cybersécurité sont rarement consultées. Cette absence pose un problème concret : du code est développé, des interconnexions sont mises en œuvre et parfois mises en production sans validation préalable. Or, les POC ne sont que rarement totalement isolés des systèmes existants, ce qui crée un risque direct d’exposition ou de contournement des règles de sécurité de l’organisation.
Des POC qui deviennent le cœur du réacteur
De nombreux POC, lorsqu’ils sont jugés réussis, finissent directement exploités et connectés à la production. Au lieu de construire une infrastructure dédiée, les données réelles, y compris sensibles, sont utilisées dans l’environnement initial. Ce glissement du POC vers le MVP se fait souvent sans phase de sécurisation ni validation des architectures. En conséquence, un dispositif temporaire, conçu pour tester rapidement une idée, devient le cœur opérationnel avec des vulnérabilités de sécurité non traitées.
L’absence totale de mesures de sécurité
Dans le cadre de POC menés en urgence, la vitesse prime souvent sur toute autre considération. Les équipes travaillent « en mode rapide », parfois de manière improvisée, pour livrer une preuve de faisabilité dans des délais très courts. Dans ce contexte, les mesures de sécurité élémentaires sont ignorées : pas de gestion des accès, mot de passe de type 123, permissions très ouvertes sur l’accès aux données, ports ouverts.. Ces choix accélèrent le delivery mais laissent des vulnérabilités critiques dès les premières étapes.
Mesures de Sécurité
Sensibilisation des Chef de projet / Product Owner
La mise en place de mesures techniques ne suffit pas si les responsables de projets ne sont pas sensibilisés. Les chefs de projet et Product Owners jouent un rôle central dans les phases de conception et de déploiement. Si la sécurité n’est pas intégrée dès le POC, les mêmes erreurs se répètent et finissent par atteindre la production. Sans leur adhésion, les règles de cybersécurité restent théoriques et peu appliquées.
Il est essentiel d’identifier en amont les POC présentant des problèmes de sécurité, puis de co-construire avec les chefs de projet un ensemble de règles claires et validées. Ces règles doivent être intégrées dans la gouvernance projet avant tout déploiement. Une sensibilisation spécifique peut ensuite être organisée, ciblant directement les équipes concernées, afin d’ancrer les bonnes pratiques dans leur quotidien.
Dans le secteur médical, un POC a été déployé avec le mot de passe « plateforme123 ». La solution est passée en production sans modification, exposant sur Internet des données de santé sensibles. Cette erreur aurait pu être évitée avec une validation préalable et un accompagnement adapté des chefs de projet.
Définir des Minimum Security Users stories
Les Proof of Concept (POC) sont conçus pour aller vite, parfois en seulement quelques jours. Dans ce contexte, il est irréaliste d’imaginer un accompagnement cybersécurité complet, car il prendrait autant de temps que la conception elle-même. Pourtant, ignorer la sécurité à ce stade entraîne des failles qui se retrouvent directement en production, avec des impacts bien plus coûteux à corriger.
Une solution consiste à définir un socle de règles minimales de sécurité applicables à tous les POC, sous forme de Minimum Security User Stories. Ces règles concernent en priorité la gestion des identifiants, les droits d’accès et les flux critiques. Elles doivent être simples, claires et validées en concertation avec le DPO pour intégrer également les contraintes réglementaires. Ainsi, chaque POC démarre avec un niveau de sécurité de base, sans alourdir inutilement le processus.
Par exemple, nous avons accompagné une société spécialisée dans la transformation numérique et l’innovation pour l’élaboration de cinq Basic Security User Stories. Ces règles de sécurité de base ont été rendues obligatoires dans tous les POC et projets. Pour rappel, ce modèle est disponible dans le Kit RSSI de CyberLead, mentionné en bas de cet article.
Mini analyse de risques flash actualisés fréquemment
Adapter les mesures de sécurité au contexte réel d’un projet est indispensable. Un outil manipulant uniquement des données publiques n’expose pas la même surface d’attaque qu’une plateforme traitant des données sensibles. Sans ajustement régulier, certaines équipes appliquent des contrôles excessifs et contraignants, tandis que d’autres laissent passer des risques majeurs sans les traiter.
La réponse consiste à mettre en place des analyses de risques « flash », rapides et ciblées. Ces évaluations sont effectuées en peu de temps et réactualisées à chaque jalon significatif du projet, qu’il s’agisse d’un sprint, d’une livraison ou d’un rituel interne. Elles permettent d’intégrer la sécurité dans le rythme normal du delivery, sans en freiner la dynamique.
Nous avons par exemple accompagné un projet de firmware de surveillance de la consommation électrique en entreprise. Les évolutions trimestrielles, pilotées en Agile Train Release avec PI Planning, imposaient de réévaluer systématiquement les risques à chaque cycle pour rester aligné avec les nouvelles fonctionnalités.
Test de Sécurité avant passage en mode MVP
L’un des problèmes récurrents vient des POC développés avec un niveau de sécurité très faible et qui, pour des raisons opérationnelles, finissent par évoluer en pilotes ou en Minimum Viable Product. Ce qui n’était qu’un brouillon technique entre alors en production, souvent en urgence, avec des failles de sécurité majeures non traitées. Cette bascule non anticipée expose directement l’organisation à des risques évitables.
Pour éviter ce scénario, il est essentiel de prévoir en amont des tests de sécurité avant tout passage en mode MVP. Ces tests peuvent prendre la forme de scans de vulnérabilités pour couvrir rapidement l’essentiel, et, pour les projets les plus critiques, de tests d’intrusion confiés à des prestataires spécialisés. L’objectif est de bloquer la mise en production de modules comportant des défauts de sécurité connus.
Nous avons par exemple accompagné une société exploitant une plateforme de pilotage de bornes de recharge électrique. À chaque ajout de module, des tests clients étaient réalisés, puis complétés systématiquement par un test d’intrusion externe, garantissant que les nouvelles fonctionnalités respectaient un niveau de sécurité minimal avant leur mise en production.
RESSOURCES CYBERLEAD
KIT DOCUMENTAIRE RSSI
Nous partageons avec notre communauté un ensemble de templates prêts à l’emploi pour structurer et piloter efficacement la cybersécurité de votre organisation : PSSI, gestion des dérogations, questionnaires fournisseurs, inventaire des applications critiques, analyses de risques flash, dashboards, PCA/PCI, et plans d’action incidents.
