Le SOC augmenté par l’IA : promesses, limites et le choix d’une IA souveraine locale

À jour au 31 octobre 2026. Cet article complète nos analyses sur l’AI Act et sur la sécurité des agents IA.

Volumes d’alertes en hausse, équipes sous tension, compétences rares : le SOC est l’un des terrains où l’on attend le plus de l’IA. Les promesses sont nombreuses. La réalité est plus nuancée : l’IA peut faire gagner un temps précieux aux analystes, à condition d’être bien choisie, bien encadrée et bien hébergée.

Ce que l’IA apporte vraiment

La synthèse d’alertes et d’incidents : un résumé lisible, une chronologie, les éléments clés mis en évidence, là où l’analyste devait parcourir des dizaines d’événements.
L’aide à la qualification : enrichissement des indicateurs, rapprochement avec le renseignement sur la menace, correspondance avec les tactiques et techniques de MITRE ATT&CK.
L’investigation en langage naturel : traduire une question d’analyste en requête dans le SIEM, puis en expliquer le résultat.
La rédaction : rapports d’incident, notes pour la cellule de crise, premières versions de règles de détection, toujours relues par un expert.
Le transfert de compétences : un assistant qui explique un événement ou une technique d’attaque aide les analystes débutants à monter en compétence.

L’ANSSI a d’ailleurs publié en 2025 une étude de marché consacrée à l’IA au service de la détection et de la réponse à incident. Elle distingue l’IA prédictive, surtout utilisée pour détecter, et l’IA générative, qui progresse pour la qualification des incidents, et souligne la question sensible de l’hébergement des modèles de langage.

Les limites à connaître

Les hallucinations : un modèle peut produire une explication plausible mais fausse. Chaque conclusion doit renvoyer aux éléments factuels sur lesquels elle s’appuie.
L’injection de requêtes par les journaux : un attaquant peut glisser des instructions dans des données qu’il contrôle et que le modèle lira, comme un objet de courriel, un nom de fichier ou un en-tête HTTP. Les journaux analysés sont des données non fiables (voir notre analyse Sécuriser les agents IA en entreprise).
La confidentialité : les journaux de sécurité contiennent des données personnelles, des informations sur l’architecture et parfois des secrets. Les envoyer à un service externe n’est pas anodin, au regard du RGPD comme du secret des affaires.
La dépendance : un SOC qui délègue tout à l’IA perd en compétences, et devient tributaire d’un fournisseur, de ses tarifs et de ses évolutions.
L’absence de mesure : sans indicateurs définis à l’avance, impossible de savoir si l’IA fait réellement gagner du temps ou simplement déplacer le travail.

Notre choix : une IA souveraine, exécutée localement

Chez Abakus Sécurité, nous avons fait le choix d’une IA souveraine qui s’exécute localement. Les modèles tournent dans un environnement maîtrisé, et interrogent directement les outils du SOC sans que les données de sécurité ne quittent cet environnement.

Concrètement, notre approche repose sur trois briques :

des modèles ouverts exécutés localement : des modèles de 35 milliards de paramètres (taille « 35B »), choisis et évalués selon les cas d’usage ;
des « skills » : des compétences spécialisées qui décrivent à l’assistant comment utiliser un outil donné du SOC (interroger le SIEM, consulter un incident, enrichir un indicateur), avec des droits limités à ce qui est nécessaire ;
un environnement local qui garde la maîtrise des données, des versions de modèles et de la traçabilité des échanges.

Ce choix répond directement aux limites décrites plus haut : les journaux restent dans l’environnement du SOC, le comportement des modèles ne change pas au gré des mises à jour d’un fournisseur, et chaque interaction peut être tracée et auditée.

Nous l’appliquons avec quelques principes simples :

la lecture seule par défaut : l’assistant consulte et propose, l’analyste décide et agit ;
des réponses sourcées : chaque conclusion renvoie aux événements, requêtes ou incidents qui la justifient ;
les contenus analysés traités comme non fiables, pour limiter les risques d’injection ;
une évaluation sur des cas réels avant chaque nouveau cas d’usage, nouveau modèle ou nouvelle skill.

Introduire l’IA dans le SOC, pas à pas

Choisir deux ou trois cas d’usage précis, par exemple la synthèse d’incidents ou l’aide à l’écriture de requêtes.
Définir les indicateurs avant de commencer : temps de qualification, taux de faux positifs traités, retour des analystes.
Décider de l’hébergement selon la sensibilité des données : exécution locale, cloud de confiance (qualification SecNumCloud de l’ANSSI) ou service public, avec une analyse de risques pour chaque option.
Commencer en lecture seule, avec validation systématique par un analyste.
Tracer les requêtes, les réponses et les décisions, et les rendre auditables.
Tester la robustesse : hallucinations, injection de requêtes, cas limites, sur des jeux de données réels anonymisés.
Étendre progressivement et former les analystes à travailler avec l’IA, sans perdre leur expertise.

L’IA ne remplace pas l’analyste : elle lui fait gagner du temps sur ce qui se répète, pour qu’il en consacre davantage à ce qui demande du jugement.

Sources

← Toutes les analyses