Une IA locale qui invente une règle de conformité : encadrer un modèle de langage

Le contexte

Dans le SIEM de l'entreprise, une PME de distribution d'une vingtaine de personnes, les alertes Wazuh étaient denses : identifiants de règles, journaux en anglais, à décoder en plein incident. J'ai ajouté un modèle de langage pour les expliquer en français, avec une contrainte : aucune alerte envoyée à un service d'IA externe.

Le modèle, llama3.2:3b, tournait sur place avec Ollama, sur le processeur : la machine n'avait pas de carte graphique. À partir du niveau 10, Wazuh transmettait l'alerte à n8n, un orchestrateur, qui interrogeait le modèle puis composait l'e-mail. La consigne : trois lignes au plus, en français, puis une seule action concrète. Le bilan quotidien passait aussi par le modèle, pour traduire les descriptions des règles, rédigées en anglais.

Le symptôme

Avec une première consigne simple, les descriptions courtes revenaient bien traduites. Sur le jargon réseau dense, le modèle complétait par des formules plausibles au lieu de signaler qu'il ne comprenait pas.

Un cas net : une description portant sur un paquet réseau hors séquence est revenue avec une règle de conformité inventée. Le texte d'origine n'en citait aucune. La phrase était plausible, et fausse.

Ce que le symptôme permet de comprendre

Ce n'est pas une panne. Un modèle de langage ne traduit pas comme un dictionnaire : il produit, mot après mot, la suite la plus probable du texte qu'on lui donne. Il n'a pas de réflexe « je ne sais pas ». Face à un jargon qu'il maîtrise mal, il comble le vide avec ce qui ressemble à un texte du même domaine. Un modèle de 3 milliards de paramètres, assez léger pour un processeur, a moins de connaissances sur lesquelles s'appuyer qu'un grand modèle.

• L'erreur ne se voit pas : une information inventée a la même forme qu'une information juste. Le lecteur n'a aucun indice pour les distinguer.
• Dans un outil de sécurité, une règle de conformité inventée peut orienter une décision : croire qu'une obligation est en jeu, ou chercher dans la mauvaise direction.

Il faut donc réduire les occasions d'inventer, puis détecter l'invention quand elle passe quand même.

Trois garde-fous

• Une consigne durcie. Traduction littérale stricte, interdiction d'ajouter une information absente du texte source. Le modèle reçoit une tâche fermée, pas une invitation à reformuler.
• Une température abaissée. La température règle la part de hasard dans le choix de chaque mot. Plus basse, elle pousse le modèle vers des formulations plus prévisibles.
• Un contrôle de longueur. Toute traduction plus longue que 2,2 fois l'original est rejetée. Une traduction fidèle reste proche de la longueur du texte source ; une traduction qui ajoute des informations s'allonge. Sur les cas observés, ce rapport de longueur trahissait bien les hallucinations.

Pseudo-code simplifié · contrôle de longueur (pas le script réel)

# Consigne : traduction littérale, rien d'absent du texte source
traduction = modele.traduire(description, temperature=basse)

# Le français est souvent un peu plus long que l'anglais, pas 2,2 fois plus
si longueur(traduction) > 2,2 × longueur(description) :
    rejeter la traduction

Le contrôle de longueur ne dépend pas du modèle : une consigne peut être mal suivie, une température basse réduit l'invention sans l'empêcher, une mesure de longueur se vérifie dans le code. Les signatures techniques, comme « ET SCAN Potential SSH Scan », restent en anglais, comme dans l'usage de la profession.

Une IA dans le SIEM reste une surface d'attaque

Le pipeline enrichissait l'alerte, il ne répondait pas : il ne bloquait aucune adresse, n'isolait aucune machine, ne désactivait aucun compte. Ce n'est pas un SOAR, et la décision restait humaine.

Cette limite compte. Une alerte contient des données qu'un attaquant contrôle en partie : un nom d'utilisateur, une adresse, une ligne de journal. Un modèle qui lit ces données peut être influencé par elles, comme par une consigne. Tant qu'il rédige un e-mail, une erreur reste un texte qu'une personne lit et juge. S'il pouvait agir, la même erreur deviendrait une action.

L'IA ajoute aussi des services sur la machine la plus sensible du réseau. J'avais installé l'orchestrateur et le modèle sur le serveur SIEM lui-même, et Ollama par un script téléchargé puis exécuté directement (curl | sh). Chaque service ajouté au SIEM est une surface d'attaque de plus. Sur un prochain déploiement, je placerais l'orchestrateur et le modèle sur une VM séparée, avec un compte limité à la lecture des alertes, et je lirais chaque script d'installation avant de l'exécuter.

Ce que j'en retiens

• Traiter la sortie d'un modèle comme une donnée à vérifier, pas comme un résultat : une hallucination a la forme d'une réponse juste. Un contrôle mesurable, même simple, protège mieux qu'une consigne de plus.
• Garder l'IA dans un rôle d'explication : elle résume, une personne décide. Un modèle qui lit des données en partie contrôlées par un attaquant ne doit pas pouvoir agir.
• Compter l'IA dans la surface d'attaque : un modèle et un orchestrateur sont des services comme les autres, à isoler, à limiter et à installer en connaissance de cause.