Déclarer ses outils : comment un 1,5B passe de 6 % à 94,5 % Résumé exécutif Mes agents-outils tournent sur Qwen 2.5 3B + LoRA, sur CPU, sans GPU. En voulant réévaluer si ce socle était encore le bon en 2026, j’ai construit un banc d’exactitude d’appel d’outil : 214 cas figés, 40 fonctions OPNsense, plus 14 cas où la bonne réponse est de ne rien appeler. Le premier chiffre m’a arrêté net.
Entraîner le refus : 43 % → 93 %, et ce que ça coûte ailleurs Résumé exécutif Les deux premiers articles de cette série se terminaient sur la même réserve : « aucun LoRA n’a été mesuré ». Le second poussait plus loin — le refus ne se corrige pas par l’invite, il faut l’entraîner — en le présentant comme une hypothèse à éprouver. Elle est éprouvée. 228 exemples de refus et vingt-deux minutes de GPU font passer le taux de refus correct de 42,9 % à 92,9 %, et les demandes dangereuses de 0/6 à 6/6, sans rien coûter à la sélection de fonction.
TL;DR J’ai dépensé 3,10 € de Claude Sonnet 4.6 (via OpenRouter) pour générer un corpus de distillation de 293 paires destiné au fine-tune d’un LoRA SOC. Sur ces 293 paires, 94 % étaient du bruit ambient SSH (sessions PAM, sshd auth success) et seulement 3 % du signal d’attaque réel (FIM sur fichiers sensibles). Le piège est subtil : plus l’attaquant qu’on utilise pour générer le corpus est scriptable (SSH-driven), plus il génère lui-même du bruit qui contamine le dataset.
Deuxième volet de la série asp-forge. Après les choix structurants posés dans le premier article, on entre dans le cœur du système : comment plusieurs agents LLM collaborent sur une même alerte, et pourquoi cette collaboration est organisée en cascade plutôt qu’en agent unique. Pourquoi une cascade et pas un seul agent ? L’instinct premier, quand on dispose d’un LLM 3 milliards de paramètres qui raisonne correctement, est de lui confier l’intégralité de la décision : alerte en entrée, verdict en sortie.
Troisième et dernier volet de la série asp-forge. Après l’architecture (article 1) et le pipeline cascade (article 2), il reste la question qui intéresse vraiment l’ingénieur : qu’est-ce qui s’est mal passé, qu’est-ce qui a surpris, et qu’est-ce qu’on garde pour la suite ? Pas de success story édulcorée — on partage les pièges réels. Bug LoRA dynamique : une discipline de version pinning Premier piège qui a coûté plusieurs jours de débogage.
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.
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.
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.
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.
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.
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.
Du Modèle au Système : Orchestration & Validation “Bare-Metal” Entraîner un adaptateur LoRA performant (Article 3) est une étape cruciale, mais en cybersécurité, un modèle isolé n’est qu’un composant passif. Pour qu’il soit réellement utile et sûr, l’expert doit être intégré dans un système d’orchestration capable de planifier des actions, de gérer des dépendances complexes, et surtout, de prouver son efficacité sur du matériel réel. Pour transformer nos modèles en agents opérationnels, nous utilisons deux piliers technologiques : LangGraph pour le cerveau cognitif et Hyper-V pour la validation sur le terrain (Façon de parler).