SOC Agentique — asp-forge · N°1
Cet article ouvre une série de trois consacrée à asp-forge, un lab de Security Operations Center agentique entièrement auto-hébergé, conçu comme banc d’essai pour évaluer l’apport concret des modèles de langage dans le triage d’alertes. Cible : DevSecOps et analystes SOC qui s’interrogent sur l’industrialisation des LLM dans une chaîne de réponse aux incidents, sans dépendre d’un fournisseur cloud.
Le problème : la fatigue d’alertes ne se résout pas par plus d’analystes Tout SOC un peu sérieux remonte plusieurs centaines à plusieurs milliers d’événements par jour depuis ses outils — Wazuh sur les serveurs, T-Pot sur les honeypots exposés, les EDR sur les postes, les WAF en bordure.
SOC Agentique — asp-forge · N°2
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.
SOC Agentique — asp-forge · N°3
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.
