Le logiciel d'analyse de risque cybersécurité propulsé par l'IA

C'est une démarche structurée qui part du périmètre à protéger (métiers, données, systèmes), identifie les sources de risque et les scénarios de compromission plausibles, puis évalue chacun selon sa vraisemblance et son impact avant de décider du traitement : réduire, transférer, éviter ou accepter. Le livrable n'est pas une liste de vulnérabilités techniques mais un ordre de priorité assumé par la direction, à revoir dès que le contexte change.

En France, la référence est EBIOS Risk Manager, la méthode publiée par l'ANSSI : cinq ateliers qui partent du cadrage et du socle de sécurité, passent par les sources de risque puis les scénarios stratégiques et opérationnels, et se terminent par le traitement du risque. L'ISO/IEC 27005 ne concurrence pas EBIOS RM : c'est une norme de lignes directrices, non certifiable, qui décrit le processus sans imposer de méthode. Le vrai critère de choix reste le lecteur du livrable : un auditeur, un régulateur et un comité de direction n'attendent pas le même niveau de détail.

Aucun texte unique ne s'applique à toutes les organisations, mais beaucoup y sont conduites indirectement. La directive NIS2 demande aux entités concernées des mesures de gestion des risques fondées sur une approche tous risques. Le règlement DORA impose aux entités financières un cadre de gestion du risque lié aux technologies de l'information et de la communication. L'ISO/IEC 27001 exige une appréciation du risque documentée. Et le RGPD impose une analyse d'impact lorsqu'un traitement est susceptible d'engendrer un risque élevé pour les droits et libertés des personnes.

Les référentiels ne fixent pas de périodicité chiffrée : l'ISO/IEC 27001 demande de réaliser l'appréciation du risque à intervalles planifiés et lorsque des changements significatifs sont prévus ou surviennent. En pratique, la revue annuelle suffit rarement, car le contexte bouge plus vite qu'elle : nouveau fournisseur critique, migration cloud, fusion, incident majeur. Réévaluer en continu les seuls scénarios touchés par un changement coûte bien moins cher que de tout remettre à plat une fois par an, et garde le registre des risques utilisable entre deux revues.

Au minimum : le périmètre et les critères d'appréciation retenus, les scénarios de risque avec leur évaluation avant et après mesures, les décisions de traitement et le nom de qui les a acceptées. Une démarche ISO/IEC 27001 y ajoute un plan de traitement du risque et une déclaration d'applicabilité qui justifie aussi bien les mesures retenues que celles écartées. Sans ces éléments datés et rattachés à une version du périmètre, le document se périme à la première évolution du système.

Un tableur sait porter une matrice de risques, pas l'historique des décisions qui l'ont produite. Il perd le lien entre un scénario, la mesure qui le réduit et la preuve que cette mesure existe, ne garde pas trace de qui a modifié quoi, et se duplique en versions divergentes dès que plusieurs équipes y touchent. Un outil dédié conserve ce fil, le met à jour quand le périmètre change et laisse à l'auditeur une piste vérifiable. Vailor y ajoute l'IA pour la part répétitive : lire les documents du projet et préremplir l'analyse, que vos experts valident.

Non, et ce n'est pas l'objectif. L'IA absorbe le travail répétitif : lire les documents d'architecture, retrouver les mesures déjà en place, proposer des scénarios de menace, préparer les tableaux d'évaluation. Chaque proposition doit rester vérifiable, rattachée à sa source et modifiable par l'analyste. Le jugement reste humain, parce que c'est lui qui engage l'organisation : accepter un risque résiduel, arbitrer un budget de remédiation, décider qu'un scénario est hors périmètre. Un auditeur demande toujours qui a validé une décision, jamais quel modèle l'a suggérée.