L’IA au Service de l’Infrastructure : Extension IaC & Vision Future

Dans les articles précédents, nous avons exploré comment lora-factory transforme les APIs d’outils de sécurité en agents intelligents. Pour conclure cette série, nous allons voir comment cette même technologie s’étend à un pilier fondamental de l’informatique moderne : l’Infrastructure as Code (IaC).

Le pipeline de l’Usine à LoRAs est par nature modulaire. Au lieu d’ingérer une spécification OpenAPI, nous avons appris au moteur à ingérer des patterns de code Ansible (YAML) et Terraform (HCL). L’objectif est de créer des agents capables non seulement de commander un firewall, mais aussi de configurer l’infrastructure sous-jacente de manière sécurisée, répétable et robuste.

1. L’Innovation : L’Héritage Technique des LoRAs (PEFT)

L’un des défis majeurs de l’IaC est la spécialisation par dessus des bases communes. Un expert AWX (Ansible Tower) doit d’abord maîtriser les fondamentaux d’Ansible Core. Recommencer l’entraînement de zéro pour chaque outil est inefficace. Pour résoudre cela, nous avons implémenté un système d’héritage de poids LoRA via la bibliothèque PEFT (Parameter-Efficient Fine-Tuning).

Le Mécanisme d’Héritage Technique

Nous entraînons d’abord un “LoRA Parent” sur un dataset massif d’Ansible standard (syntaxe, modules systemd, file, template). Ensuite, pour créer l’expert AWX :

1. Chargement du Parent : Nous chargeons le modèle de base avec l’adaptateur Ansible Core.
2. Apprentissage Différentiel : Nous ajoutons une nouvelle couche d’adaptateur spécifique aux modules awx.awx (Job Templates, Credentials, Inventaires).
3. Gains Opérationnels : Cette approche réduit le temps d’entraînement de 30% car le modèle “connaît” déjà la syntaxe YAML et les structures de base d’Ansible.

{
  "base_model_name_or_path": "mistral-nemo-12b",
  "peft_type": "LORA",
  "target_modules": ["q_proj", "v_proj"],
  "parent_adapter_path": "models/ansible_core_v2",
  "child_adapter_output": "models/awx_specialist"
}

2. La Sécurité par le Code (Security-as-Code)

Le modèle ne se contente pas de générer du YAML ou du HCL fonctionnel. Il est entraîné à agir comme un linter de sécurité proactif. Durant sa phase de génération de traces (Article 2), nous l’avons nourri d’exemples contrastés : une version “Naive” vs une version “Secured”.

La Correction de Sécurité en Temps Réel

Requête de l’utilisateur : “Installe Apache sur le serveur web.”

L’agent ne se contente pas de poser le paquet via apt. Il injecte automatiquement des couches de sécurité critiques :

# OUTPUT : Secured LoRA-Factory Ansible Playbook
- name: Setup Apache (Hardened)
  hosts: webservers
  tasks:
    - name: Ensure apache2 is installed
      ansible.builtin.apt:
        name: apache2
        state: present
    - name: Disable directory listing for security
      ansible.builtin.lineinfile:
        path: /etc/apache2/apache2.conf
        regexp: 'Options Indexes FollowSymLinks'
        line: 'Options -Indexes +FollowSymLinks'  # ✅ Désactivation Indexes
    - name: Configure UFW to allow only HTTPS
      community.general.ufw:
        rule: allow
        port: '443'  # ✅ Principe de moindre privilège
        proto: tcp

L’agent explique (via son format ReAct) pourquoi il a choisi cette structure sécurisée, citant les bonnes pratiques de sécurité.

3. L’Intelligence Contextuelle : RAG & MITRE ATT&CK

Pour que l’IA puisse prendre des décisions de sécurité pertinentes, elle doit avoir accès à une base de connaissances vivante. lora-factory intègre un moteur de RAG Agentique avec une couche de validation appelée Self-Grading.

Le “Self-Grading” du RAG

Avant d’injecter un document dans le contexte du modèle, l’agent effectue trois tests de validation :

1. Relevance Check : Le document répond-il vraiment à la question technique ?
2. Date Validity : Une documentation technique de firewall datant de 2018 est rejetée au profit d’une spécification de 2024.
3. Conflict Resolution : Si deux documentations se contredisent, l’agent privilégie la source “Autorité” (ex: la spécification OpenAPI générée en Article 1).

4. Retour du Terrain : cyber-agent-engine comme Héritier Opérationnel

lora-factory est une usine. cyber-agent-engine est son premier client industriel — un projet opérationnel qui exploite les agents LoRA dans un vrai SOC, sur du vrai matériel, face à de vrais incidents.

Ce retour d’expérience a produit plusieurs enseignements que les articles précédents ne pouvaient pas anticiper.

Leçon 1 : La mise à l’échelle du domaine nécessite toujours un réentraînement

Quand le périmètre d’un agent s’élargit — nouvelles fonctions ajoutées à une API, nouveaux modules Ansible, nouveau provider Terraform — la tentation est d’ajouter ces fonctions au system prompt ou à la documentation RAG et d’éviter un cycle d’entraînement.

Cette approche échoue systématiquement. L’agent continue d’invoquer les anciennes fonctions habituelles ou produit des appels mal formés sur les nouvelles. Le LoRA a appris une distribution sur les fonctions connues ; les nouvelles fonctions sont hors-distribution.

La règle est simple : tout ajout significatif de fonctions = nouvelle itération de génération de données + réentraînement. L’Usine à LoRAs est précisément conçue pour que ce cycle soit rapide et automatisable.

Leçon 2 : Au-delà du Tool Use — la NER de domaine

Un autre développement inattendu : certains besoins métier ne sont pas des appels d’outils, mais de la reconnaissance d’entités dans du texte non structuré (logs, alertes SIEM, rapports d’incidents).

Pour répondre à ce besoin, un modèle NER spécialisé (AnonyNER) a été développé en parallèle, entraîné avec spaCy sur des logs de sécurité annotés. Ce n’est plus du LoRA sur un LLM, mais du fine-tuning ciblé d’un modèle NER compact.

Cette expérience montre que le paradigme de l’usine — générer des données annotées de qualité → entraîner un modèle spécialisé → valider sur un jeu de test métier — s’applique bien au-delà des agents à outils. Les mêmes principes gouvernent la spécialisation de n’importe quelle architecture de modèle.

5. Vers un SOC Autonome : La Roadmap Technique

Cette série d’articles l’a montré : la barrière entre le développement logiciel et l’ingénierie de sécurité s’efface. lora-factory est la pierre angulaire de notre vision pour un SOC Autonome (Advanced Agentic SOC).

D’après notre AGENTS_ROADMAP.md, l’architecture cible déploie un essaim d’agents spécialisés orchestrés par un PilotAgent stratégique :

Exemple : Workflow d’Incident Response Automatisé

Une alerte SIEM déclenche la mission. Le PilotAgent orchestre :

1. InvestigatorAgent collecte le contexte brut (logs, timestamps)
2. ThreatIntelAgent enrichit les IOCs (IP, hashes, domaines)
3. AnalystAgent corrèle les événements + mapping MITRE ATT&CK
4. ThreatHunterAgent cherche des traces additionnelles dans le SIEM
5. ForensicsAgent collecte des preuves si l’incident est confirmé
6. ResponderAgent propose des actions de blocage (HITL obligatoire)
7. ReporterAgent génère le rapport post-incident (PDF, Markdown, DOCX)

Résultat attendu : réduction du MTTR de plusieurs heures à quelques minutes.

Prochaines Étapes Immédiates (Q1 2026)

• Cache multi-niveaux pour les réponses LLM et tool calls idempotents
• Amélioration de la délégation du PilotAgent (parallélisation intelligente)
• Intégration LangSmith pour le tracing et le debugging de prompts
• Notifications Slack/Teams pour les approbations asynchrones (HITL)

Conclusion de la Série

L’Usine à LoRAs démontre que la spécialisation des LLM n’est plus un luxe réservé aux géants du tech. En automatisant la génération de données (ReAct), en optimisant l’entraînement (Unsloth) et en validant sur du matériel réel (Hyper-V), nous rendons l’IA capable de gouverner l’infrastructure complexe de manière souveraine.

L’avenir n’est pas aux modèles géants “bons à tout faire”, mais à des essaims d’experts compacts, certifiés et orchestrés pour protéger nos systèmes critiques.

Navigation dans la série :

• Article 1 : L’Usine à Cerveaux — Automatiser la Spécialisation des LLM
• Article 2 : Apprendre à l’IA à “Réfléchir” — Le Moteur de Traces ReAct
• Article 3 : La Forge Technique — Optimiser l’Entraînement avec Unsloth & QLoRA
• Article 4 : Du Modèle au Système — Orchestration & Validation Bare-Metal

Merci d’avoir suivi cette aventure technique. L’usine est désormais opérationnelle, et le voyage ne fait que commencer.