L’IA générative au service des analystes sécurité

8 mars 2025 · Mis à jour le 11 septembre 2026

L’essentiel en bref

Un modèle génératif est utile là où le volume est élevé et le contexte répétitif : lignes de journaux, code source, sorties d’outils
Dans notre recherche, des LLM associés à MobSF et Semgrep ont classé des vulnérabilités d’applications Android selon l’OWASP Mobile Top 10
Sur des journaux Suricata et Sysmon, le délai jusqu’à un constat qualifié a nettement baissé ; les attaques fortement obfusquées, elles, sont passées au travers
Trois limites à traiter avant le premier pilote, pas après : les faux positifs, le coût au volume, et la sortie de vos données vers un tiers
Coller un extrait de journal ou un rapport d’audit dans un modèle en ligne, c’est une question de sous-traitance au sens de l’article 28 du RGPD — pas un détail d’outillage
La conclusion n’a pas bougé : le modèle absorbe le volume, l’analyste garde le jugement

L’intelligence artificielle déplace les lignes en cybersécurité, et l’une des évolutions les plus concrètes tient à l’appui que les modèles génératifs apportent aux analystes. Notre recherche, publiée sous le titre Using Generative AI Models to Support Cybersecurity Analysts, a porté sur une question simple : qu’est-ce qu’un grand modèle de langage (LLM) fait réellement gagner dans un flux de travail de sécurité, et où s’arrête-t-il ?

Cet article en résume le dispositif, les résultats et surtout les limites. Il ajoute ce que la version anglaise ne pouvait pas traiter : la question que pose tout RSSI français dès la deuxième réunion, à savoir ce que deviennent les journaux et les rapports que l’on soumet à un modèle hébergé par un tiers.

Ce que l’IA générative change dans le travail de l’analyste

Un analyste travaille sur une masse de données qu’aucun humain ne peut parcourir intégralement : journaux d’événements, configurations, résultats d’un audit de vulnérabilités, analyses de logiciels malveillants, sorties d’une dizaine d’outils qui se recouvrent partiellement. Les outils classiques collectent et normalisent très bien. L’interprétation, elle, reste manuelle, et c’est là que partent les heures.

Le modèle génératif déplace ce rapport sur quatre points :

automatiser le dégrossissage des journaux de sécurité, pour faire remonter les anomalies plus vite
décrire et classer plus efficacement les vulnérabilités trouvées dans une application
appuyer un test d’intrusion en pesant en amont les chemins d’exploitation plausibles
ajouter du contexte à partir de référentiels établis comme l’OWASP Mobile Top 10 et MITRE ATT&CK

Le mot qui manque à cette liste est remplacer. Un modèle qui classe une ligne de journal ne décide pas qu’il y a incident. Il formule une proposition accompagnée d’une justification, et cette proposition vaut exactement ce que vaut l’analyste qui la confronte à l’environnement réel.

Notre recherche : deux cas concrets

L’étude s’est concentrée sur deux usages où un LLM peut retirer du travail mesurable à un spécialiste.

1. Détecter les vulnérabilités des applications Android

Nous avons monté une chaîne associant des LLM à des outils de sécurité éprouvés — MobSF (Mobile Security Framework) et Semgrep — pour examiner des applications Android. Plutôt que de nous en remettre à la seule analyse statique, nous avons utilisé l’analyse contextuelle du modèle pour :

parcourir le code source de l’application
repérer les défauts de sécurité à l’aide de règles définies à l’avance
classer les constats selon le référentiel OWASP Mobile Top 10

Constat principal : les LLM ont amélioré à la fois la vitesse et la précision de la détection, tout en introduisant des faux positifs. La vérification humaine est restée nécessaire dans tous les cas.

Cela recoupe ce que nous observons en mission sur un test d’intrusion d’application mobile : un outil qui remonte deux cents constats vaut moins qu’un auditeur qui en conserve douze et sait expliquer, pour chacun, ce qu’un attaquant en ferait. Notre travail sur les méthodologies OWASP est construit sur cette réduction-là.

2. Analyser les journaux de sécurité pour qualifier un incident

Le second cas portait sur des journaux réseau et système issus de Suricata (IDS/IPS) et de Sysmon (supervision Windows). L’objectif était de corréler des alertes avec des menaces réelles, d’écarter une partie du bruit et de rattacher les événements retenus au référentiel MITRE ATT&CK.

Constat principal : l’analyse assistée a nettement raccourci le délai nécessaire pour identifier et classer une menace, mais les modèles ont buté sur les attaques fortement obfusquées ou construites en plusieurs étapes.

Il faut mesurer ce que contiennent ces données. Un journal Sysmon expose par construction des éléments identifiants : noms de comptes, postes de travail, horodatages. Qui y applique un modèle traite des données à caractère personnel. Nous tenons donc une ligne constante, en recherche comme en mission : les résultats sont restitués de façon agrégée, et aucun collaborateur n’est identifié ni évalué individuellement. Une analyse de journaux vérifie si vos moyens de détection et de réaction fonctionnent, pas si un salarié a mal cliqué.

Ce que le modèle fait bien, et ce qu’il rate

La recherche a ouvert de l’espace, pas un blanc-seing. Trois limites méritent d’être traitées avant le premier pilote.

Limite	Ce qui se passe mal	Ce que vous mettez en face
Faux positifs	Le modèle interprète de travers une ligne de journal ou un fragment de code et produit des alertes sans objet — ou, plus gênant, classe un événement réel comme du bruit	Une étape de vérification humaine sur chaque constat, et une mesure de la justesse par catégorie plutôt qu’en moyenne générale
Coût au volume	Faire passer de gros jeux de données dans un LLM coûte cher, et les volumes de journaux croissent plus vite que les budgets	Un filtrage préalable par des règles classiques, le modèle n’intervenant que sur le reliquat
Traitement des données et attaques contre le modèle	Journaux et code source quittent votre environnement ; par ailleurs, prompt injection et empoisonnement des données sont des techniques d’attaque réelles contre le modèle lui-même	Un cadre de sous-traitance écrit et une minimisation effective des données, puis le test de l’intégration elle-même comme surface d’attaque

La dernière ligne n’est pas théorique. Dès qu’un modèle accède à vos données ou déclenche une action dans votre environnement, il devient un composant doté de droits — donc quelque chose qui se teste. C’est l’objet d’une prestation distincte chez nous : le test d’intrusion des intégrations IA et LLM.

Ne collez pas vos journaux ni vos rapports dans un modèle tiers

C’est le point sur lequel une équipe française se fera reprendre en premier, et c’est aussi le plus facile à traiter si on s’en occupe au début.

Lorsque vous soumettez un extrait de journal, un fichier de configuration, du code source client ou un rapport de test d’intrusion à un service de modèle en ligne, vous ne faites pas « une recherche ». Vous transmettez des données à un tiers qui les traite pour votre compte. Si ces données comportent des éléments à caractère personnel — et un journal d’authentification en comporte presque toujours —, ce tiers agit comme sous-traitant au sens de l’article 28 du RGPD. Trois conséquences pratiques :

Un contrat écrit est nécessaire. L’article 28 impose que le traitement par un sous-traitant soit régi par un contrat définissant l’objet, la durée, la nature et la finalité du traitement, ainsi que les obligations du sous-traitant.
Un sous-traitant ultérieur ne se recrute pas en silence. Si vous intervenez vous-même comme sous-traitant de votre client — ce qui est le cas d’un prestataire d’audit —, vous ne pouvez pas faire appel à un autre sous-traitant sans l’autorisation préalable, écrite, du responsable de traitement. Ajouter un fournisseur de modèle au milieu d’une mission sans en parler au client, c’est exactement cela.
La minimisation s’applique aussi au presse-papiers. Le principe de minimisation du RGPD ne connaît pas d’exception pour les outils d’aide. Si le modèle n’a pas besoin des noms de comptes pour reconnaître un schéma d’attaque, ils n’ont rien à faire dans la requête.

Le rapport d’audit pose le même problème, augmenté d’un second : il décrit des faiblesses exploitables chez un client identifiable. Le secret des affaires et l’engagement de confidentialité signé avant la mission suffisent à trancher, indépendamment du RGPD.

La règle que nous appliquons est simple à énoncer et vérifiable : aucune donnée client, aucun extrait de rapport et aucun élément de preuve ne sont soumis à un service d’IA tiers. Les usages génératifs que nous conservons portent sur des contenus publics, des jeux de test que nous produisons nous-mêmes, ou s’exécutent sur une instance que nous maîtrisons. Haxoris est un prestataire européen ; les données d’audit restent dans l’Union européenne, et la liste des sous-traitants est communiquée avant le démarrage, pas après.

Le cadre applicable en France

L’IA ne crée pas d’obligation nouvelle qui remplacerait les précédentes. Elle change en revanche le trajet de vos données et la liste des questions qu’un client ou un auditeur vous posera.

Le seul texte européen qui nomme expressément le contrôle périodique est l’article 32, paragraphe 1, point d) du RGPD : lorsque cela est approprié, les mesures de sécurité incluent « une procédure visant à tester, à analyser et à évaluer régulièrement l’efficacité des mesures techniques et organisationnelles ». Notez la formulation : ce qui est demandé, c’est de démontrer l’efficacité. Déployer un outil d’IA n’est pas une démonstration ; le contrôle de ce qu’il produit en est une. Et introduire un LLM dans la chaîne de détection élargit mécaniquement le périmètre de ce qui doit être évalué.

En cas de violation de données à caractère personnel — par exemple parce que des journaux identifiants ont été transmis à un fournisseur de modèle sans base contractuelle —, la notification à la CNIL intervient dans les 72 heures au titre de l’article 33 du RGPD. La CNIL est aussi l’autorité qui publie des recommandations pratiques sur le développement et l’usage des systèmes d’IA ; c’est la première source à consulter avant d’arbitrer un usage interne. De son côté, l’ANSSI a publié des recommandations de sécurité consacrées aux systèmes d’IA générative, utiles pour cadrer l’architecture avant d’ouvrir le débat sur les modèles.

Le règlement (UE) 2024/1689 sur l’intelligence artificielle s’ajoute à cet ensemble et s’adresse principalement aux fournisseurs et aux déployeurs de systèmes d’IA. Il ne remplace pas le RGPD : les questions de base légale, de sous-traitance et de minimisation continuent de se poser dans les mêmes termes.

Enfin, le fondement du travail de test lui-même n’a pas changé. L’accès non autorisé à un système de traitement automatisé de données est réprimé par les articles 323-1 et suivants du code pénal. Ce qui rend une intervention licite, c’est un mandat écrit et un périmètre défini contractuellement — y compris lorsque la cible est un agent conversationnel que vous avez vous-même mis en production. Nos tests d’intrusion sont réalisés sur cette base, sans exception.

Cet article est informatif et ne constitue pas un conseil juridique. L’application des textes cités dépend de votre secteur, de votre taille et de votre rôle dans la chaîne de traitement. Dernière vérification : 11 septembre 2026.

Testez l’intégration, pas seulement le modèle

La suite du sujet est déjà visible. Modèles affinés sur des données de sécurité, agents capables d’enchaîner des actions, pipelines RAG branchés sur la documentation interne : chacun de ces montages augmente l’utilité de l’outil et sa surface d’attaque en même temps.

Les classes de défauts qui apparaissent alors ne figurent dans aucune base de vulnérabilités publiées, parce qu’elles dépendent de votre implémentation : prompt injection directe et indirecte, jailbreak, fuite d’informations par le contexte, empoisonnement des données, outils et serveurs MCP exposés avec des droits trop larges. Un scan de vulnérabilités ne les voit pas ; un test d’intrusion conduit sur l’intégration les cherche explicitement. Nous avons détaillé ce déroulé dans un article dédié : test d’intrusion des intégrations LLM.

La ligne que nous tenons tient en une phrase : laissez le modèle traiter le volume, gardez le jugement humain. Un LLM excelle à ramener dix mille lignes de journaux à quinze candidats. Il est mauvais pour estimer ce que ces quinze candidats signifient pour votre environnement, vos partenaires et vos obligations de notification. Cette pesée est précisément le travail pour lequel vous mandatez un prestataire ; c’est aussi ce qu’il faut vérifier avant d’en choisir un, comme nous l’expliquons dans comment choisir un prestataire de test d’intrusion.

Pour lire la recherche complète (en anglais) :

Publication de recherche

À mesure que l’IA devient un outil courant pour les équipes sécurité, c’est l’équilibre entre automatisation et expertise humaine qui déterminera si nous restons à la fois rapides et justes face aux attaques.

Questions fréquentes

L’IA générative peut-elle remplacer un analyste sécurité ?

Non. Un modèle génératif produit une proposition assortie d’une justification, pas une décision. Il réduit dix mille lignes de journaux à quinze candidats, ce qui est précieux ; il ne sait pas ce que ces quinze candidats signifient dans votre environnement, pour vos partenaires et au regard de vos obligations de notification. La qualification d’un incident reste un acte humain, et c’est aussi ce qui la rend opposable.

Peut-on coller des journaux ou un rapport de test d’intrusion dans un modèle en ligne ?

Pas sans cadre contractuel. Des journaux Windows contiennent des noms de comptes, des postes et des horodatages : ce sont des données à caractère personnel. Les transmettre à un fournisseur de modèle revient à faire intervenir un sous-traitant au sens de l’article 28 du RGPD, ce qui suppose un contrat écrit et, pour un sous-traitant ultérieur, l’autorisation préalable du responsable de traitement. Un rapport d’audit pose le même problème, augmenté du secret des affaires.

Qu’est-ce qu’un LLM apporte concrètement à l’analyse de journaux ?

Il raccourcit le délai entre une alerte brute et un constat qualifié. Dans nos essais sur des journaux Suricata et Sysmon, le modèle corrélait des alertes dispersées, écartait une partie du bruit et rattachait les événements retenus à des techniques du référentiel MITRE ATT&CK. Le gain porte sur le tri et la mise en contexte, pas sur la découverte d’attaques inconnues : les scénarios fortement obfusqués ou multi-étapes lui échappaient.

Pourquoi un LLM produit-il des faux positifs sur du code ou des journaux ?

Parce qu’il raisonne sur la vraisemblance d’une suite de texte, pas sur l’exécution réelle du programme ou du réseau. Un fragment de code qui ressemble à un défaut connu sera signalé même lorsqu’un contrôle situé en amont le neutralise. Le risque symétrique est plus gênant : un événement réel classé comme du bruit. C’est pourquoi chaque constat produit par un modèle passe par une vérification humaine avant d’entrer dans un rapport.

Une intégration LLM doit-elle être testée comme le reste du système d’information ?

Oui. Dès qu’un modèle accède à vos données ou déclenche une action, il devient un composant doté de droits, avec sa propre surface d’attaque : prompt injection, jailbreak, empoisonnement des données, fuite d’informations par le contexte, serveurs MCP et outils exposés. Ces classes de défauts ne figurent dans aucune base de vulnérabilités publiées, puisqu’elles dépendent de votre implémentation.

L’IA générative répond-elle à l’article 32 du RGPD ?

Non par elle-même. L’article 32, paragraphe 1, point d) du RGPD vise une procédure permettant de tester, d’analyser et d’évaluer régulièrement l’efficacité des mesures techniques et organisationnelles. Déployer un outil d’IA n’est pas une preuve d’efficacité ; c’est une mesure de plus, qui élargit d’ailleurs le périmètre à évaluer. Ce qui répond à l’article 32, c’est le contrôle documenté de ce que ces mesures produisent réellement.

Vous envisagez d’insérer un LLM dans votre chaîne de détection, ou vous en avez déjà un en production ? Décrivez le périmètre en quelques lignes et demandez un devis : nous vous dirons ce qu’un test d’intrusion des intégrations LLM couvrirait, ce qu’il ne couvrirait pas, et sous quel délai. Le contre-audit après correction est inclus.

Menu