Agents en Production · N°1
Dans la série LoRA Factory, nous avons construit une usine à agents spécialisés sur Phi-3.5-mini-instruct. Trois agents (OPNsense, WireGuard, CrowdSec), trois adapters LoRA, un pipeline d’entraînement automatisé.
Tout fonctionnait — jusqu’à ce que les limites du modèle de base se manifestent en production. Ce premier article de la série Agents en Production documente pourquoi et comment nous avons migré vers Qwen2.5-3B-Instruct.
Pourquoi changer de modèle de base ? Phi-3.5-mini est un excellent modèle compact.
Agents en Production · N°2
C’est le type de bug qu’on ne voit pas venir.
L’entraînement se termine normalement. La loss finale est bonne — 0.2532 pour OPNsense, comparable aux runs précédents. Pas d’anomalie dans les courbes. Le modèle a convergé.
Puis on lance la vérification fonctionnelle. Et le score tombe à zéro.
Score : 0/102 (0%) ❌ ADAPTATEUR NON VALIDÉ L’investigation La première réaction est de chercher un bug dans le script de vérification. On inspecte le chargement du modèle, l’application de l’adapter, le décodage.
Agents en Production · N°3
Après entraînement, la question n’est pas “quelle est la loss ?”, c’est “l’agent appelle-t-il la bonne fonction quand on lui donne une directive réelle ?”.
C’est cette distinction qui a motivé la construction d’un système de vérification comportementale, distinct et indépendant du pipeline d’entraînement.
Le format CAP v1 Le coordinateur communique avec les agents via un format structuré appelé CAP v1 (Coordinator-Agent Packet). C’est le format de production — ce que reçoit l’agent dans un déploiement réel.
Agents en Production · N°4
Les trois agents sont validés à 100%. La question devient : comment les servir simultanément sur un GPU de 12 Go déjà occupé par le coordinateur ?
Le problème du multi-agent sur GPU contraint L’architecture cible est simple :
Utilisateur │ ▼ Coordinateur (Qwen2.5-3B, port 3001) │ CAP v1 ├──→ OPNsense agent ├──→ WireGuard agent └──→ CrowdSec agent │ ▼ Tool-agent-server (port 3000) Le coordinateur et les agents-outils tournent sur le même GPU — une RTX 4070 Ti avec 12 Go de VRAM réels (11.
Fine-tuning NLP pour les logs · N°1
Fine-tuner un NER sur des logs serveur : méthodologie et choix du framework Un log serveur n’est pas du texte. C’est une séquence semi-structurée, produite par un démon, dans un format qui varie selon la version du logiciel, la configuration, et parfois l’humeur de l’admin qui a écrit le rsyslog.conf. Les modèles NLP généralistes — entraînés sur des corpus de presse et de Wikipedia — sont largement aveugles à ce type de données.
AnonyNER · N°1
Quand spaCy ne voit pas l’infrastructure : le problème NLP des logs de sécurité Avant d’envoyer des logs à un éditeur de logiciels pour investigation, à un LLM externe pour analyse, ou simplement de les archiver conformément au RGPD, une question s’impose : ces logs contiennent-ils des informations qui exposent mon infrastructure ?
La réponse est presque toujours oui. Et les outils NLP standards — aussi performants soient-ils sur le langage courant — sont largement aveugles aux entités spécifiques au domaine de la sécurité.
AnonyNER · N°2
Cartographier les logs disponibles : le problème du corpus pour l’anonymisation Entraîner un agent d’anonymisation pose un problème paradoxal : les données les plus utiles à l’entraînement sont précisément celles que personne ne partage. Les logs réels de production contiennent exactement les entités sensibles qu’on cherche à détecter — et c’est pour ça qu’ils restent dans les datacenters.
Cette contrainte a des conséquences directes sur la qualité des modèles. Cet article recense les corpus disponibles, leur niveau de sanitisation, leur densité en entités sensibles, et la façon dont on peut les compléter par des données synthétiques.
AnonyNER · N°3
Entraîner un NER sécurité : du corpus annoté au modèle en production Les entités de sécurité que spaCy standard ne détecte pas ne sont pas impossibles à apprendre — elles sont simplement absentes de ses données d’entraînement. La solution n’est pas de remplacer spaCy par un LLM lourd, mais d’entraîner le composant NER de spaCy sur des exemples spécifiques au domaine.
Ce chemin — annotation LLM-assistée → fine-tuning spaCy → modèle production léger — est à la fois robuste et déployable sans GPU.
AnonyNER · N°4
Recollect & Rank : quand un LLM désanonymise vos logs Une opération d’anonymisation réussie au sens technique — toutes les IPs masquées, tous les comptes remplacés par des tokens — peut échouer au sens de la confidentialité si le contexte restant permet de reconstruire ce qui a été masqué. Ce n’est pas une hypothèse théorique. Les outils pour y parvenir sont disponibles publiquement.
Le problème des quasi-identifiants La définition classique du PII (Personally Identifiable Information) couvre les données directement identifiantes : nom, numéro de sécurité sociale, adresse email.
AnonyNER · N°5
La session partagée : garantir la cohérence d’anonymisation sur un batch de logs Anonymiser un fichier de logs est résolu. Anonymiser un batch de fichiers de logs de manière cohérente — même entité, même token, partout — est un problème d’architecture non trivial que les outils standards ne résolvent pas.
C’est pourtant la condition minimum pour que les logs anonymisés restent exploitables par leur destinataire.
Le cas d’usage qui impose la contrainte L’infrastructure rencontre un problème critique.
LoRA Factory · N°1
L’Usine à Cerveaux : Automatiser la Spécialisation des LLM Dans le paysage actuel de la cybersécurité, la réactivité n’est plus une option ; c’est une question de survie. Un analyste SOC (Security Operations Center) moderne doit jongler entre une multitude d’interfaces : SIEM (Wazuh), plateformes d’orchestration (TheHive/Cortex), firewalls de nouvelle génération (OPNsense/Stormshield), et outils de threat intelligence (MISP).
L’idée d’un “Agent de Sécurité IA” capable d’unifier ces interfaces est séduisante, mais elle se heurte à un obstacle de taille : la précision technique absolue.
LoRA Factory · N°2
Apprendre à l’IA à “Réfléchir” : Le Moteur de Traces ReAct Dans l’article précédent, nous avons vu comment lora-factory transforme des spécifications OpenAPI en contrats techniques rigides via Pydantic. Aujourd’hui, nous plongeons dans le “carburant” de nos experts : la donnée synthétique de haute qualité.
Entraîner un modèle sur de simples couples “Question -> Appel API” est l’erreur la plus commune dans le monde du fine-tuning. Cela crée des modèles “parrots” (perroquets) qui s’effondrent dès que la requête utilisateur s’écarte du script nominal ou contient des ambiguïtés.
