Le contexte
3 h du matin, l'analyste SOC d'astreinte reçoit une alerte SIEM : pic anormal de requêtes vers un endpoint API critique, avec authentification réussie mais comportement déviant. La probabilité d'attaque est sérieuse. L'attaquant continue pendant que l'analyste enquête.
Reconstituer la timeline d'un incident de ce type exige aujourd'hui :
- Lire logs Loki (gateway, services applicatifs, base de données) sur la fenêtre de 4 heures suspectes
- Croiser avec les tickets Jira de la nuit (qui était d'astreinte ? une intervention prévue ?)
- Vérifier le canal Slack #ops (a-t-on déployé quelque chose ?)
- Inspecter les commits GitLab des dernières 48 h
- Contrôler les accès AD / privileges escalation sur la même fenêtre
Manuellement, en pleine nuit, c'est 2 à 3 jours de travail forensic pour produire la timeline propre. Pendant ce temps, l'attaquant continue ou efface ses traces.
Le mécanisme LMbox
L'analyste ouvre Claude Code (ou Cursor) connecté à la Box, et tape une seule requête :
Reconstitue la timeline complète des événements entre 02:14 et 03:47
sur le service /api/billing — corrèle Loki, Jira, Slack, GitLab et AD.
Identifie les points de bascule et les acteurs impliqués.
Sous le capot :
- Le routeur cascade détecte un long-context + analyse complexe → tier
frontier(Mistral Large 2 local pour les clients souveraineté pure, ou Bedrock Sonnet pour les autres). - Le serveur MCP appelle en parallèle
searchsur 6 connecteurs : Loki (logs), Jira, Slack, GitLab, ServiceNow (tickets ITSM), et AD (via un connecteur custom). Les requêtes sont scopées à la fenêtre temporelle indiquée. - Le tier
frontierreçoit les top-K classés de chaque source (≈ 50-100 chunks) et construit une timeline cohérente : événement → source → horodatage → acteur → impact estimé. - Citations exactes sur chaque ligne : l'analyste peut cliquer pour ouvrir le log original, le ticket, le commit, le message Slack.
- Réponse rendue en 60 à 120 secondes.
L'analyste a alors une vue chronologique propre, vérifiable, qu'il peut partager avec son CISO ou archiver pour le post-mortem RSSI. Il consacre les heures suivantes à la remédiation, pas à l'archéologie.
Le calcul de ROI
Pour un service avec un coût d'indisponibilité de 50 k€/h (typique d'un service B2B critique) :
| Métrique | Sans LMbox | Avec LMbox | Gain |
|---|---|---|---|
| MTTD (mean time to detect) | inchangé | inchangé | — |
| MTTI (mean time to investigate) | 180-720 min | 20-40 min | × 8-15 |
| MTTR (mean time to remediate) | 90-300 min | 90-300 min (inchangé — humain pilote) | — |
| Heures de downtime évitées par incident moyen | — | 2 à 8 h | 100-400 k€ |
Sur 4 incidents majeurs/an typiques d'une ETI tech : 400 k€ à 1,6 M€/an de pertes évitées.
Au-delà du downtime, les bénéfices secondaires : moins de burnout d'astreinte (l'analyste rentre se coucher 2 h plus tôt), meilleure documentation post-incident (les timelines générées par l'IA deviennent l'archive), montée en compétence des juniors (qui voient comment un Mistral Large 2 raisonne sur un incident).
Les pré-requis
- Loki opérationnel avec une rétention ≥ 90 jours sur les services critiques (sinon le forensic au-delà de 3 mois est aveugle)
- Connecteurs Jira, Slack, GitLab indexés et synchronisés en quasi-temps-réel (TTL ≤ 5 min sur ces sources)
- Mistral Large 2 local OU Bedrock EU configuré (le tier
mediumne suffit pas pour cette tâche — il manque de contexte pour relier 6 sources cohérentes) - Clé API ou OIDC scopée pour les connecteurs (pas de root creds)
- Charte d'usage IA pour le SOC validée par la direction (qui peut interroger quoi, sur quelles fenêtres, avec quelle traçabilité d'audit)
Le déploiement
- Semaine 1 : indexation initiale de Loki + Jira + Slack + GitLab + ServiceNow (≈ 6 mois d'historique). Validation que les requêtes MCP retournent les bonnes sources.
- Semaine 2 : 3 incidents passés rejoués comme exercice. L'analyste compare la timeline générée par l'IA avec la timeline qu'il avait reconstituée manuellement. Calibrage des prompts par catégorie d'incident (intrusion, dégradation perf, déploiement raté, etc.).
- Semaine 3-4 : déploiement sur les incidents réels en mode shadow (l'IA reconstruit en parallèle, l'analyste continue son flow normal et compare).
- Semaine 5+ : passage en mode first-line investigation (l'analyste lance l'IA en premier, puis valide).
Les limites & ce que ça ne fait pas
- L'IA ne décide pas de la remédiation. Couper le trafic, isoler un service, révoquer une clé : ça reste l'humain qui pilote, dans les SOPs existants.
- Si une source de données n'est pas indexée dans LMbox (ex : journalisation système d'un firewall propriétaire), l'IA ne la verra pas — il faut soit la connecter via un connecteur custom, soit que l'analyste la consulte en parallèle.
- L'IA ne fait pas du threat hunting proactif. Elle est réactive (incident déclenché → reconstitution). Le hunting reste un exercice humain ou un outil dédié.
- Sur les incidents très atypiques (zero-day, side-channel, supply chain), l'IA peut manquer le pattern parce qu'il n'existe pas dans son corpus d'entraînement. L'humain reste indispensable pour les cas qui sortent du connu.