Cas réel
Incidents IT avec V8 + Ollama

Contexte : 120 alertes/jour non triées

La DSI d'un établissement de santé recevait en moyenne 120 alertes par jour dans son système de monitoring (Zabbix + logs applicatifs). Sans tri automatique, les équipes passaient 2h/jour à classifier manuellement les incidents — dont 70% étaient des faux positifs ou des alertes de faible priorité. AutomationSequence V8 + Ollama a réduit ce temps à 15 minutes de supervision.

Un LLM local qui classe des incidents IT n'est pas un gadget — c'est un premier niveau de triage qui libère les équipes pour les vrais problèmes. En environnement HDS, le LLM reste sur le réseau interne.

Architecture de la solution

# Pipeline d'automatisation des incidents
Zabbix/Logs
  → WebhookListen (AutomationSequence)
    → Séquence : incident_triage.asenc
      ├── Étape 1 : lire le log/alerte
      ├── Étape 2 : classification LLM (Ollama llama3:8b)
      ├── Étape 3 : si critique → ticket JIRA automatique
      ├── Étape 4 : si P1 → escalade Teams + SMS astreinte
      └── Étape 5 : toutes les 18h → rapport PDF quotidien

Étape 1 : détection des logs critiques

[
  {
    "type": "file_read",
    "path": "/var/log/app/{{date_today}}.log",
    "encoding": "utf-8",
    "output_var": "raw_log"
  },
  {
    "type": "text_filter",
    "data": "{{raw_log}}",
    "patterns": ["ERROR", "CRITICAL", "FATAL", "ORA-", "Connection refused"],
    "context_lines": 3,
    "output_var": "error_lines"
  },
  {
    "type": "condition",
    "if": "len({{error_lines}}) == 0",
    "then_actions": [{"type":"stop", "reason":"Aucune erreur détectée"}]
  }
]

Étape 2 : classification LLM

{
  "type": "llm_classify",
  "model": "llama3:8b",
  "text": "{{error_lines|join:\n}}",
  "categories": [
    "P1_critique",     // service down, perte de données
    "P2_majeur",       // dégradation significative
    "P3_mineur",       // impact limité
    "P4_faux_positif"  // alerte non significative
  ],
  "prompt_prefix": "Tu es expert en support IT hospitalier. Classe cet extrait de log par priorité d'incident. Réponds uniquement par le nom de la catégorie.",
  "temperature": 0.1,
  "output_var": "priority",
  "confidence_var": "priority_confidence"
}

Étape 3 : création ticket JIRA

{
  "type": "condition",
  "if": "{{priority}} in ['P1_critique', 'P2_majeur'] and {{priority_confidence}} > 0.7",
  "then_actions": [
    {
      "type": "llm_extract_json",
      "model": "llama3:8b",
      "prompt": "Extrais du log suivant : titre de l'incident (max 80 chars), composant affecté, impact estimé, actions recommandées. Réponds en JSON. Log: {{error_lines|join:\n|sample:20}}",
      "output_var": "incident_details"
    },
    {
      "type": "http_post",
      "url": "https://jira.intranet/rest/api/2/issue",
      "auth_vault": "JIRA_AUTH",
      "body": {
        "fields": {
          "project":     {"key": "IT"},
          "summary":     "[{{priority}}] {{incident_details.titre}}",
          "description": "Composant: {{incident_details.composant}}\nImpact: {{incident_details.impact}}\nActions: {{incident_details.actions}}",
          "priority":   {"name": "{{priority}}"},
          "issuetype":  {"name": "Incident"}
        }
      },
      "output_var": "jira_ticket"
    }
  ]
}

Étape 4 : escalade conditionnelle

{
  "type": "condition",
  "if": "{{priority}} == 'P1_critique'",
  "then_actions": [
    {
      "type": "teams_send",
      "webhook_vault_key": "TEAMS_WEBHOOK_ASTREINTE",
      "card": {
        "title": "🔴 INCIDENT P1 — Action immédiate requise",
        "facts": [
          {"label":"Ticket JIRA", "value":"{{jira_ticket.key}}"},
          {"label":"Composant",  "value":"{{incident_details.composant}}"},
          {"label":"Confiance IA","value":"{{priority_confidence|round:2}}"}
        ],
        "color": "attention"
      }
    }
  ]
}

Étape 5 : rapport PDF quotidien

# Séquence séparée déclenchée par CRON à 18h
# CRON: "0 18 * * 1-5"
[
  {
    "type": "oracle_query",
    "query": "SELECT * FROM incidents_log WHERE date_trunc='day' AND trunc_date=TRUNC(SYSDATE)",
    "output_var": "incidents_du_jour"
  },
  {
    "type": "llm_generate",
    "model": "llama3:8b",
    "template": "Rédige un résumé exécutif des incidents IT du jour pour la direction. Données: {{incidents_du_jour|sample:50}}. Format: résumé (3 phrases), incidents critiques, tendances, recommandations.",
    "output_var": "rapport_texte"
  },
  {
    "type": "pdf_create",
    "template": "templates/rapport_incidents.html.j2",
    "vars": {"contenu": "{{rapport_texte}}", "stats": "{{incidents_du_jour|stats}}"},
    "output": "rapports/incidents_{{date_today}}.pdf",
    "output_var": "pdf_path"
  },
  {
    "type": "smtp_send",
    "to": ["dsi@chu-exemple.fr", "direction@chu-exemple.fr"],
    "subject": "Rapport incidents IT — {{date_today}}",
    "attachments": ["{{pdf_path}}"]
  }
]

Chiffres après 3 mois

• Temps de triage : 2h/jour → 15 minutes de supervision humaine.
• Précision LLM : 91% de classification correcte (vs 100% humain, 94% sur les P1/P2 critiques).
• Faux positifs non traités : 70% des alertes classées P4 ignorées automatiquement, 0 incident réel manqué.
• Tickets JIRA créés automatiquement : 847 en 3 mois, dont 12% nécessitaient une correction manuelle du titre.
• Rapport PDF : 63 rapports générés, 100% livrés avant 18h05.
• Alertes Cortex XDR : 0 (Ollama tourne en local, aucune requête réseau suspecte).

Conclusion

L'automatisation du triage d'incidents avec AutomationSequence V8 + Ollama démontre que l'IA locale peut prendre en charge des décisions de classification répétitives avec une fiabilité suffisante pour le premier niveau de support. La clé du succès : un score de confiance minimum (0.7) avant de créer un ticket, et un rapport quotidien qui permet aux équipes de valider la pertinence des décisions automatiques. En environnement HDS, l'aspect "100% local" du LLM Ollama a été le critère décisif pour l'acceptation du projet.