Analyste SOC IA : ce qu'il faut exiger avant de lui faire confiance

Un analyste SOC IA, c'est un logiciel qui lit les alertes et les dossiers que votre stack de détection produit déjà, et qui fait le premier tri qu'un analyste N1 ferait : ce qui s'est probablement passé, et pourquoi. Savoir s'il mérite ce travail ne dépend presque pas du modèle qui tourne derrière.

Cela se joue sur six propriétés que vous pouvez tester en un après-midi : est-ce qu'il montre les hypothèses anodines qu'il a écartées, est-ce que chaque valeur qu'il cite se retrouve dans vos propres alertes, que fait-il quand les preuves ne soutiennent pas son verdict, où partent vos données, pouvez-vous interdire tout modèle en cloud, et qui doit valider une action destructive.

La plupart des évaluations n'abordent aucun de ces points, parce que la plupart des démonstrations sont construites pour montrer un verdict. Or le verdict est ce qu'un analyste IA produit de moins intéressant. Des avis, votre équipe en a déjà ; ce qui manque à l'analyste d'astreinte à trois heures du matin, c'est une raison défendable d'agir sur l'un d'eux.

À quoi sert un analyste SOC IA

Il ne détecte pas. La détection, vous l'avez déjà achetée : un SIEM ou un XDR qui remonte les alertes, une file de tickets où s'entasse le backlog, et quelqu'un qui les rapproche à la main.

C'est cette dernière étape qui coûte cher. Pour son rapport State of SIEM Detection Risk 2025, CardinalOps a analysé des configurations de SIEM en production : les détections en place couvrent 21 % des techniques MITRE ATT&CK, alors que les données déjà ingérées permettraient d'en couvrir 90 %, et 13 % des règles existantes sont cassées sans que personne ne le sache. Microsoft et Omdia, dans leur State of the SOC 2026 — une étude commanditée par un éditeur —, rapportent que deux tiers des équipes SOC perdent près d'un cinquième de leur capacité hebdomadaire en corrélation manuelle.

Deux problèmes cohabitent là-dedans, et un seul relève d'un analyste IA. Les règles de détection manquantes ou cassées, c'est de l'ingénierie de détection : aucun modèle ne les écrira à votre place. La corrélation manuelle, en revanche, c'est la moitié qu'un logiciel peut prendre.

Ce qu'un analyste SOC IA doit donc vous retirer des mains, c'est la part N1 : lire les alertes d'un dossier, proposer ce qui les relie, le qualifier, et dire ce qui suffirait à le contredire. L'escalade et la décision d'agir, elles, restent à vos analystes.

Un outil qui score chaque alerte isolément, sans le dossier autour d'elle, ne fait que la partie facile du triage. Et ce regroupement doit être déterministe et explicable avant même qu'un modèle n'entre en jeu : c'est le rôle du moteur de corrélation.

Six choses à exiger d'un analyste SOC IA

Exigence	La défaillance que cela évite
Les hypothèses anodines qu'il a écartées	Un verdict péremptoire qui n'a jamais envisagé la réponse banale
Chaque valeur citée traçable jusqu'à une alerte du dossier	Une invention qui a toutes les apparences de la précision
Un niveau de confiance qui baisse ouvertement quand les preuves sont minces	Une certitude qui tient debout sans les faits censés la porter
Le droit de répondre « preuves insuffisantes »	Un outil sommé de trancher, et qui tranche donc à chaque fois
Un modèle qui tourne on-prem, et un seul interrupteur sur ce qui sort	Vos données d'incident qui partent sans que personne ne l'ait décidé
Une validation avant action sur tout ce qui est destructif, et une trace d'exécution	Une erreur automatisée à l'échelle du parc

Prenez-les dans l'ordre : les trois premières portent sur la qualité du raisonnement, les trois suivantes sont les garde-fous.

Montrez-moi les hypothèses anodines que vous avez écartées

Un verdict rendu sans alternative n'est qu'une intuition mise en forme. Demandez les alternatives explicitement : quelles explications anodines ont été envisagées, et quelle preuve a permis d'écarter chacune d'elles.

L'ordre compte davantage que les acheteurs ne le croient. Un analyste qui pose sa conclusion puis rassemble des arguments est en train de se justifier ; un modèle qui écrit son verdict en premier fait exactement la même chose, et tout ce qui suit est taillé pour soutenir une réponse déjà choisie. Exigez que les hypothèses et les preuves — à charge comme à décharge — arrivent avant le verdict : votre analyste doit voir l'argumentation se construire, pas une conclusion qu'on habille après coup.

Testez ensuite sur un dossier sans intérêt — le genre qui constitue l'essentiel de ce qu'une équipe clôt en faux positif. Prenez un scan de vulnérabilités planifié, un job de sauvegarde, un administrateur qui fait son travail d'administrateur.

Un bon analyste SOC IA nomme l'explication anodine en premier et vous dit ce qui aurait pu la disqualifier. Un mauvais transforme une fenêtre de maintenance en récit d'intrusion, parce que c'est la forme de texte qu'il a le plus lue.

Chaque valeur qu'il cite doit se retrouver dans vos alertes

La défaillance dangereuse, ce n'est pas la réponse vague. C'est la réponse précise : un nom de machine, une adresse IP, un chemin de fichier, tous plausibles, aucun présent dans le dossier.

Exigez une vérification mécanique, pas une vérification à la charge de l'analyste. Chaque élément précis de l'argumentation doit pointer vers une alerte réellement rattachée au dossier, et toute affirmation qui ne pointe vers rien doit être signalée à l'écran.

Si l'éditeur vous répond que les analystes le remarqueront, ils ne le remarqueront pas. La fatigue des alertes, c'est exactement l'état dans lequel un nom de machine plausible passe sans être vérifié — et remarquer, c'est le travail dont vous cherchez à les décharger.

C'est aussi pourquoi la source compte moins que le dossier. Que les alertes viennent de Splunk, Microsoft Sentinel, CrowdStrike, Microsoft Defender, Cortex XDR, Elastic, OpenSearch, ClickHouse ou Wazuh, la vérification des preuves reste la même opération : est-ce que l'affirmation figure dans ce que le dossier contient réellement ?

Un analyste IA qui ne lit que les alertes d'un seul éditeur n'est pas une couche de triage. C'est l'enfermement fournisseur de cet éditeur, avec un modèle de langage par-dessus.

Demandez ce qui se passe quand les preuves ne suivent pas

Tout analyste SOC IA finira par tomber sur un dossier où l'argumentation ne tient pas. La vraie question, c'est ce qu'il fait à ce moment-là, et il n'y a que trois réponses possibles.

Il reste péremptoire. Le pire des trois, et le plus courant : l'assurance est une propriété du style d'écriture, pas des preuves.
Il nuance en douce. Un peu mieux, et tout aussi inutile : une réserve enterrée au troisième paragraphe n'est pas un signal.
Il déclasse ouvertement. Le verdict et son niveau de confiance sont revus à la baisse devant l'analyste, avec la raison écrite noir sur blanc.

Exigez la troisième, et exigez qu'il ait le droit de s'abstenir. Un outil sommé de produire un verdict sur chaque dossier en produira un sur chaque dossier, y compris là où la réponse honnête est que les preuves ne sont pas au rendez-vous. Chez nous, c'est ce que fait SIROC : un verdict non étayé est déclassé de façon visible, et l'analyste sait pourquoi.

Où partent les données, et le droit d'interdire tout modèle en cloud

Posez trois questions, et attendez des propriétés plutôt que des promesses.

Peut-il tourner entièrement chez vous ? Pas un endpoint privé chez l'hébergeur d'un tiers, mais un modèle sur votre propre matériel, sur des CPU ordinaires, sans clé d'API à acheter. Si la seule architecture proposée fait sortir vos données d'incident, alors « nous n'entraînons pas sur vos données » est la meilleure garantie que vous obtiendrez — et c'est une promesse, pas une propriété.

Pouvez-vous interdire purement et simplement les appels vers le cloud ? Il faut un interrupteur unique, réglé une fois pour tout le déploiement, qu'aucun réglage en dessous ne puisse contourner. Une préférence par utilisateur n'est pas un contrôle.

Et si vous autorisez un modèle en cloud, qu'est-ce qui sort exactement ? Exigez le masquage des secrets et des données personnelles avant l'appel, et un registre de chaque appel sortant dont toute altération se voit : ce qui est parti, où c'est allé, ce qui a été retiré — un registre que votre DPO puisse exporter. Le souvenir ne fait pas preuve.

Demandez ensuite deux limites : un plafond de dépense, et un coupe-circuit qui arrête le modèle jusqu'à ce qu'une personne le relance.

Nos propres engagements figurent sur la page sécurité et confiance, y compris ce que nous n'avons pas : aucun rapport de test d'intrusion tiers, aucune certification, aucun SLA.

Une personne valide chaque action destructive

Isoler une machine, réinitialiser des identifiants, bloquer une adresse au périmètre : ce sont les actions qui transforment un verdict erroné en panne. Exigez une validation avant action sur chacune d'elles, puis allez plus loin : exigez qu'aucune configuration ne puisse lever cette obligation.

Exigez aussi une trace d'exécution : ce qui a été exécuté, sur la validation de qui, et ce que cela a modifié. La supervision humaine n'est pas une intention, c'est un enregistrement que quelqu'un peut relire le lendemain matin.

Les éditeurs appellent cela l'autonomie encadrée. L'expression recouvre deux choses très différentes : un réglage qu'on a activé pour vous, et un plafond que personne ne peut relever. Demandez lequel des deux on vous vend, et demandez ce qui le fait tenir.

Si la réponse est une case à cocher dans un écran d'administration, le contrôle vaut ce que vaut l'administrateur le moins rigoureux que vous emploierez dans les trois ans qui viennent.

Gartner a raison : aucun SOC ne sera jamais autonome

La position officielle de Gartner tient dans son titre : There Will Never Be an Autonomous SOC — il n'y aura jamais de SOC autonome. Nous partageons cet avis, et nous l'écrivons noir sur blanc dans nos propres documents.

Et les éditeurs de SOC agentique publient le même refus. Chez CrowdStrike, la FAQ de Charlotte AI demande si l'outil se substitue aux analystes SOC humains, et répond non. Palo Alto, lui, titre une section de sa page agentique Maintain Absolute Control Over Agent Autonomy — gardez le contrôle total sur l'autonomie des agents.

Traitez donc agentique comme une description de la plomberie, pas comme une promesse sur les effectifs — et traitez ce refus comme un critère d'achat, pas comme une réserve.

Un éditeur qui vous vend un SOC sans analystes vous vend un problème de responsabilité : au titre de NIS2 et DORA, ce sont les décisions de votre organisation qui déclenchent les délais de notification, et « c'est le modèle qui l'a classé » n'est une défense aux yeux de personne.

L'objectif utile, ce n'est pas moins d'analystes. C'est moins de dossiers qui exigent un analyste, et une argumentation écrite attachée à chacun de ceux qui en exigent un — c'est aussi ce qui survit à une passation de consignes, là où un avis oral ne survit pas.

Comment mener l'évaluation en un après-midi

Apportez trois de vos propres dossiers : un vrai positif que vous avez déjà traité, un faux positif sans intérêt, et un dossier qui était réellement ambigu sur le moment.

Demandez le raisonnement avant le verdict sur les trois, et vérifiez que le dossier sans intérêt est bien qualifié comme tel.
Retirez un élément de preuve du dossier ambigu et relancez-le. Le verdict doit bouger, et l'outil doit dire ce qui l'a fait bouger.
Coupez l'accès Internet sortant et relancez les trois. Ce qui fonctionne encore, c'est ce que vous achetez vraiment.
Demandez, devant toute la salle, ce qu'il faudrait pour qu'une action destructive devienne automatique. Chronométrez la réponse.

Nous sommes en pré-GA : aucun client à vous montrer, et aucun chiffre de précision qui nous soit propre, parce qu'il n'existe aucun benchmark inter-éditeurs qui en rendrait un significatif. Ce que nous pouvons faire, c'est mettre SIROC devant vos propres dossiers et le faire juger sur ces quatre tests.

Pour le détail de sa façon d'argumenter et de la manière dont il est encadré, lisez SIROC : un analyste IA qui argumente à découvert — puis demandez une démonstration et apportez le dossier le plus retors que vous ayez.