IA et analyse de risque cyber : ce qu'elle peut faire, et ce qu'elle ne doit pas faire

Mis à jour le 9 octobre 2026

Ce qu'un assistant d'IA fait bien

Un assistant d'IA, ici un modèle de langage utilisé pour lire et rédiger, est utile sur les tâches de lecture et de mise en forme qui consomment l'essentiel du temps hors séance. Chaque usage ci-dessous suppose que le résultat soit relu par quelqu'un qui connaît le périmètre.

Extraire des documents existants (dossiers d'architecture, fiches projet, contrats, PSSI) une première liste de biens supports, de flux et de prestataires, à confirmer en atelier.
Proposer un brouillon de valeurs métier et d'événements redoutés à partir de la description des processus, que le groupe de travail corrige au lieu de partir d'une page blanche.
Contrôler la cohérence d'une étude : événements redoutés sans scénario, mesures sans responsable ni échéance, biens supports cités dans un scénario mais absents de la cartographie.
Établir des correspondances entre le socle de sécurité et un référentiel (ISO/IEC 27001, ReCyF, exigences sectorielles), à vérifier exigence par exigence.
Reformuler une synthèse technique pour une direction, ou résumer l'état de la menace sur un secteur à partir de sources fournies.

Ce qu'il ne peut pas faire

Les limites tiennent à la nature des décisions en jeu autant qu'à la technique.

Accepter un risque. NIS2 (article 20) charge les organes de direction d'approuver les mesures ; DORA (article 5) donne à l'organe de direction la responsabilité ultime ; le ReCyF (mesure 16.3) demande à l'entité de valider l'analyse et d'accepter les risques résiduels. Aucune de ces décisions ne se délègue à un outil.
Connaître ce qui n'est écrit nulle part : une dépendance informelle, un prestataire qui garde un accès oublié, un processus contourné en pratique. C'est précisément ce que les ateliers font émerger.
Garantir l'exhaustivité. Un modèle propose ce que ses entrées et son entraînement suggèrent ; l'absence d'un scénario dans sa réponse ne prouve pas son absence dans la réalité.
Calibrer la gravité. Le coût de deux jours d'arrêt d'une chaîne de production est un jugement métier, pas une inférence.
Coter une vraisemblance sans faits. Une cote doit reposer sur des éléments observables (droits d'accès, vulnérabilités, capacités de détection) ; une cote générée sans eux n'est pas défendable.
Être cru sur parole. Un modèle de langage peut produire une affirmation plausible et fausse, y compris une référence normative inexistante.

Cinq règles pour un usage défendable devant un auditeur

Un auditeur ne demandera pas si une IA a été utilisée, mais d'où vient chaque élément de l'analyse et qui l'a validé. Ces règles permettent de répondre ; elles ne supposent aucun outil particulier et peuvent être tenues avec un tableur et une procédure de relecture.

Traçabilité : chaque élément proposé par l'outil renvoie au document et au passage dont il est tiré. Un élément sans source est traité comme une hypothèse à confirmer.
Statut explicite : tout contenu généré reste un brouillon tant qu'une personne nommée ne l'a pas validé ; la validation est datée et attribuée.
Journalisation : on peut reconstituer qui a proposé, modifié et validé chaque élément, et avec quelle version de l'outil.
Séparation : les livrables distinguent ce qui a été décidé en atelier de ce qui a été suggéré par l'outil et repris.
Contrôle par échantillon : sur chaque étude, une partie des propositions est vérifiée contre les sources, et le taux d'erreur constaté est noté. C'est une mesure de fiabilité propre à votre contexte, qu'aucune plaquette ne fournit.

Les données : la question qui conditionne tout

Une analyse de risque contient ce qu'une organisation a de plus sensible sur sa sécurité : cartographie, vulnérabilités, chemins d'attaque, mesures manquantes. Le cahier des charges du label EBIOS RM impose d'ailleurs aux logiciels labellisés de permettre l'apposition d'une mention de protection sur l'analyse. Avant tout usage d'un assistant d'IA, il faut donc savoir où vont les documents et les échanges : hébergement, fournisseur du modèle, durée de conservation, éventuelle réutilisation pour l'entraînement, sous-traitants.

Plusieurs architectures existent : modèle appelé chez un fournisseur externe, modèle hébergé par l'éditeur, modèle déployé dans l'infrastructure du client, y compris sans connexion externe. Le choix dépend de la sensibilité des études et des contraintes réglementaires qui s'appliquent au périmètre. Pour sécuriser le système d'IA lui-même, l'ANSSI a publié le 29 avril 2024 des recommandations de sécurité pour un système d'IA générative (35 recommandations, de l'entraînement au déploiement).

L'AI Act au 9 octobre 2026

Le règlement (UE) 2024/1689 sur l'intelligence artificielle est entré en vigueur le 1er août 2024, avec une date générale d'application fixée au 2 août 2026. Le règlement (UE) 2026/1744 du 8 juillet 2026 (omnibus numérique sur l'IA, publié au Journal officiel le 24 juillet 2026) a reporté les obligations des systèmes à haut risque : au 2 décembre 2027 pour ceux de l'annexe III, au 2 août 2028 pour ceux de l'annexe I. Il a aussi réécrit l'article 4 : fournisseurs et déployeurs prennent des mesures pour favoriser la maîtrise de l'IA par leur personnel, sans être tenus de garantir un niveau donné pour chaque individu.

Un assistant de rédaction d'analyse de risque n'apparaît pas en tant que tel dans les huit domaines de l'annexe III, que l'omnibus n'a pas modifiée : biométrie ; infrastructures critiques (systèmes utilisés comme composants de sécurité dans la gestion et l'exploitation d'infrastructures numériques critiques, du trafic routier ou de la fourniture d'eau, de gaz, de chauffage ou d'électricité) ; éducation ; emploi ; accès aux services essentiels ; répression ; migration ; justice et processus démocratiques. Un outil qui aide à analyser des risques n'est pas, en principe, un composant de sécurité de l'exploitation ; la qualification reste à faire au cas par cas avec votre service juridique. Dans la plupart des usages, ce sont donc les obligations générales qui comptent. La maîtrise de l'IA (article 4) pèse sur le fournisseur et sur le déployeur. Les obligations de transparence de l'article 50, applicables depuis le 2 août 2026, pèsent surtout sur le fournisseur : informer les personnes qu'elles interagissent avec un système d'IA, et marquer les contenus générés, texte compris, dans un format lisible par machine, sauf fonction d'assistance à la rédaction courante ou absence de modification substantielle des données fournies ; pour ce marquage, les systèmes mis sur le marché avant le 2 août 2026 ont jusqu'au 2 décembre 2026. Côté déployeur, l'obligation de signaler un texte généré vise le texte publié pour informer le public sur des questions d'intérêt public, ce qui n'est pas le cas d'une analyse de risque interne.

Analyser le risque de l'IA elle-même

Un assistant d'IA branché sur vos analyses est un bien support : il mérite sa place dans votre propre étude EBIOS RM. Deux scénarios méritent d'être examinés en priorité. D'abord l'injection d'instructions : un document fourni par un tiers (offre de prestataire, contrat) peut contenir un texte conçu pour orienter les propositions de l'outil. Ensuite l'exfiltration : un outil qui lit vos analyses concentre des informations de grande valeur pour un attaquant. L'ANSSI et ses partenaires ont publié le 7 février 2025 une analyse de haut niveau des risques cyber liés à l'IA, « Développer la confiance dans l'IA par une approche par les risques cyber », utile pour construire ces scénarios.

Questions à poser à un éditeur

Ces questions valent pour tout outil qui intègre de l'IA dans une analyse de risque. Demandez des réponses écrites et, quand c'est possible, une démonstration sur vos propres documents.

Quel modèle est utilisé, qui l'opère, et où sont traités les documents et les requêtes ?
Les données des clients servent-elles à entraîner ou à ajuster un modèle ? Où l'engagement est-il écrit dans le contrat ?
Combien de temps les documents, requêtes et réponses sont-ils conservés, et peut-on obtenir leur suppression ?
Peut-on désactiver entièrement l'IA, par étude ou pour toute l'organisation, sans perdre de fonctions de la méthode ?
Chaque proposition indique-t-elle sa source, et l'utilisateur peut-il ouvrir le passage cité ?
Comment distingue-t-on, dans l'outil et dans les exports, un contenu proposé d'un contenu validé ?
Quel taux d'erreur l'éditeur a-t-il mesuré, sur quel jeu de test, et peut-on le reproduire ?
Comment l'outil se protège-t-il contre l'injection d'instructions par un document importé ?
Quelles mesures l'éditeur propose-t-il pour la maîtrise de l'IA par les utilisateurs (article 4 de l'AI Act) ?
Que deviennent les études si l'on change de fournisseur de modèle ou d'outil : export complet, formats ouverts ?
L'outil peut-il fonctionner dans un environnement isolé si la sensibilité du périmètre l'exige ?

En résumé

L'IA réduit le temps passé à lire, recopier et vérifier la cohérence ; elle ne réduit pas le besoin d'ateliers, ni la responsabilité de ceux qui décident. Un usage défendable repose sur trois éléments vérifiables : la source de chaque proposition, la validation humaine datée, et la maîtrise des données. Pour le choix d'un outil, voir Choisir un logiciel EBIOS RM ; pour la méthode elle-même, EBIOS RM atelier par atelier.