Un analyste SOC IA auto-hébergé : le modèle tourne sur vos machines
Un analyste SOC IA qui raisonne sur vos propres machines, sans GPU, sans que rien ne sorte. Où tourne le modèle par défaut, quel masquage s'applique avant le moindre appel cloud, et comment fermer la porte au cloud une bonne fois.
La plupart des analystes SOC IA sont des services hébergés : les données de vos dossiers — noms de machines, comptes utilisateurs, adresses IP, parfois le payload — sortent de votre parc pour alimenter le modèle d'un tiers. Pour un opérateur européen, l'évaluation s'arrête souvent là, quelle que soit la qualité du triage.
Un analyste SOC IA auto-hébergé prend le contre-pied de ce choix par défaut. SIROC raisonne avec un modèle local sous licence ouverte, sur du matériel que vous avez déjà, sans GPU, et rien ne sort de la machine sauf si vous en décidez autrement. C'est de cette moitié du sujet qu'on parle ici : où tourne le modèle, ce qui partirait si vous branchiez un modèle cloud, et comment fermer la porte complètement.
SIROC est l'analyste IA de The Verdict Layer, et c'est le module Advanced AI. Il prend en charge les dossiers que votre stack a déjà produits, et sur chacun il rend quatre choses : un verdict, un score de confiance, une recommandation et le raisonnement qui mène aux trois. C'est un avis que l'analyste suit ou écarte, pas un résumé — et c'est ce qui garde le N1 sur les dossiers qui méritent l'heure qu'on y passe.
Il lit ce que votre stack lui donne déjà : les plateformes du marché comme Splunk, Microsoft Sentinel, CrowdStrike, Microsoft Defender, SentinelOne et Cortex XDR, et les SIEM et stacks de données open source comme ClickHouse, Elastic / ELK, OpenSearch et Wazuh. Quand une source ne figure pas dans cette liste, nous développons le connecteur, ou vous poussez les événements dans le webhook générique et vous les mappez une fois pour toutes. Vos sondes, elles, ne bougent pas.
Si vous en êtes encore à comparer des analystes SOC IA plutôt qu'à décider où l'un d'eux doit tourner, la checklist de l'acheteur fait l'objet d'un autre texte : ce qu'il faut exiger d'un analyste SOC IA avant de lui faire confiance. La suite part du principe que vous avez déjà tranché : le raisonnement se fera sur votre infrastructure.
Le verdict vient en dernier, et c'est délibéré
Un analyste qui annonce sa conclusion avant de chercher ses raisons ne mène pas une enquête : il justifie après coup. C'est exactement ce que fait un modèle de langage qui écrit son verdict en premier — tout ce qui suit s'aligne sur une réponse déjà arrêtée, et ça se lit comme du raisonnement.
SIROC prend le problème dans l'autre sens. Il commence par les explications bénignes et par les preuves des deux côtés, et ne se prononce qu'à la fin. L'analyste voit l'argumentaire se construire, pas s'habiller après coup. Et quand il n'est pas d'accord, il peut pointer l'étape précise où ça a dérapé. C'est toute la différence entre un assistant que vous supervisez et un assistant auquel il faut croire.
Les preuves sont recoupées avec vos propres alertes
Une fois que SIROC a répondu, chaque élément qu'il cite est recoupé avec les alertes réellement attachées au dossier. Un verdict qui s'appuie sur une preuve absente du dossier est rétrogradé, à l'écran, devant l'analyste, avec le motif écrit noir sur blanc. L'IA n'a pas le droit d'être catégorique sur ce que vos données ne contiennent pas. Aucun contrôle de ce genre n'attrape toutes les hallucinations ; celui-là attrape les plus fréquentes, devant l'analyste, à chaque fois.
Ces alertes, c'est votre stack qui les produit déjà : un XDR ou un SIEM du marché d'un côté, la stack open source que vous exploitez vous-même de l'autre, et un connecteur que nous développons quand ni l'un ni l'autre ne convient. SIROC raisonne sur le dossier, jamais sur une sonde en particulier : l'argumentaire et la vérification des preuves sont donc identiques, quelle que soit la source qui a levé l'alerte.
Local par défaut : ce que ça change, concrètement, de tourner chez vous
SIROC tourne avec un modèle local sous licence ouverte, sur des processeurs ordinaires, sur votre propre machine. Pas de GPU, pas de clé d'API, aucune donnée qui sort. C'est le comportement par défaut, pas l'option haut de gamme.
Si vous voulez un modèle cloud plus gros pour certaines tâches, vous apportez votre clé et vous la rattachez tâche par tâche — un gros modèle sur le triage, un modèle moins cher sur les résumés. Quatre garde-fous encadrent le trajet vers le cloud.
- Souveraineté. C'est vous qui décidez si un appel IA a le droit de sortir de votre infrastructure. Le réglage se fait une fois pour tout le déploiement, et rien en dessous ne peut le desserrer.
- Consentement. Un administrateur valide un fournisseur avant qu'il ne devienne joignable.
- Masquage. Les secrets et les données personnelles sont retirés avant que quoi que ce soit ne parte : clés cloud, tokens, clés privées, coordonnées bancaires et, parce que nous vendons en France, SIRET et RIB. Le masquage préserve la cohérence de l'analyse sans que les valeurs réelles ne quittent la machine.
- Dépense. Un plafond de dépense, et un coupe-circuit qui arrête SIROC et oblige quelqu'un à le relancer.
Au-dessus de ces quatre garde-fous, un registre inaltérable consigne chaque appel vers le cloud avant qu'il ne parte : ce qui est sorti, où c'est allé, ce qui a été retiré au passage — jamais le contenu lui-même. Votre DPO peut l'exporter : ce qui a quitté vos machines est écrit quelque part, au lieu d'être reconstitué de mémoire. L'inférence locale, elle, n'y figure pas ; nous ne dirons donc jamais « chaque appel IA ». Nous disons : chacun de ceux qui sont sortis.
Autonomie encadrée : une action destructrice exige toujours une personne
Une recommandation n'est pas une action, et SIROC ne franchit pas ce pas tout seul. Exécuter une réponse de bout en bout — et pousser le ticket dans votre service desk —, c'est le module Automations, où chaque étape destructrice passe par une validation avant action.
Que SIROC prépare lui-même toute cette réponse, face à un schéma d'attaque qu'il reconnaît — variantes de ransomware, abus d'identifiants, dérive d'un compte interne —, c'est construit et désactivé : en développement, pas en production.
Ce qu'aucun réglage ne change, dans un sens comme dans l'autre : isoler une machine, réinitialiser des identifiants et le reste exigent une personne. Aucun playbook, aucune configuration ne peut les rendre automatiques. C'est ce que veut dire autonomie encadrée ici, et c'est pourquoi aucun analyste d'astreinte ne peut sortir l'humain de la boucle à trois heures du matin pour faire avancer la file.
Toutes les limites posées sur SIROC peuvent être resserrées, jamais desserrées. Des coupe-circuits arrêtent un modèle qui commence à mal se comporter. Un kill switch coupe SIROC sur l'ensemble du déploiement.
Sur l'édition MSSP — celle du SOC managé qui sert plusieurs clients —, c'est tout l'intérêt : vous proposez une réponse assistée par IA sans qu'un modèle touche jamais au parc d'un client de sa propre initiative.
Comment SIROC apprend de vos analystes
Ce sont les revues de vos analystes qui font progresser SIROC, et plus précisément leurs corrections. Un analyste qui bascule un verdict en faux positif sans dire pourquoi a clos un dossier et n'a rien appris à SIROC.
Vous décidez quelle part des décisions humaines passées SIROC a le droit de consulter, et chaque triage garde la trace de ce qu'il avait le droit de voir. C'est ce qui rend mesurable, et non supposée, la progression que vous présenterez à un comité de direction : vous pouvez dire ce que SIROC avait sous les yeux quand il a eu raison, et quand il s'est trompé. Le module SOC Reporting transforme cette trace en grilles de score et en dossiers de preuves, ceux qu'un comité ou un auditeur vous réclamera.
Où SIROC est assis aujourd'hui, et le poste qu'il n'a pas encore
Dans l'application, SIROC est un bouton sur un dossier : l'analyste lance un triage quand il en veut un, et regarde l'argumentaire se construire. C'est la moitié qui tourne.
L'autre moitié, c'est un poste à lui : un agent extérieur que vous payez déjà traite votre backlog au travers d'une passerelle encadrée qui lit les dossiers, lance un triage, soumet des verdicts et des revues. C'est construit et désactivé. Ça ne fait pas partie de ce que nous mettrions devant vous aujourd'hui, et mieux vaut le lire ici que le découvrir après signature.
La conception mérite d'être dite quand même, parce que c'est elle qui rend ce poste encadré plutôt qu'ouvert. C'est l'agent qui se connecte à la plateforme ; aucun port entrant n'est ouvert de notre côté. Chaque écriture passe par les autorisations et l'audit de la plateforme, chaque résultat est masqué en sortie, et si vous activez la souveraineté, la porte ne s'ouvre plus du tout. Brancher le modèle auquel vous faites déjà confiance ne devrait jamais vous enfermer chez un éditeur — le nôtre compris.
Le matériel dont un analyste SOC IA auto-hébergé a réellement besoin
SIROC tourne sur processeur, par conception : la plupart des SOC n'ont pas de GPU, et ne devraient pas avoir à en acheter un pour disposer d'un analyste qui montre son raisonnement. Une machine auto-hébergée, pas d'accélérateur, pas de clé à acheter.
Le volet agentique — SIROC qui prend lui-même les dossiers dans la file et va chercher des preuves supplémentaires avant de répondre — demande du matériel plus lourd, et il est en développement, pas en production.
Nous ne publions aucun chiffre de précision, parce qu'aucun comparatif inter-éditeurs n'existe pour lui donner du sens — en construire un est sur notre roadmap. Ce que nous disons, en revanche : SIROC argumente à découvert, il est recoupé avec vos propres données, il reste sur vos machines sauf décision contraire de votre part, et il n'agit jamais seul quand l'action est destructrice. 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. Nous sommes en pré-GA, sans aucun client à citer.
Un meilleur argumentaire suppose un meilleur contexte. Les flux et les IOC arrivent jusqu'au dossier via le module Threat Intelligence ; votre posture face aux vulnérabilités connues relève d'une discipline à part, le Vulnerability Operations Centre, inclus dans l'édition Client et non vendu en supplément. Voir les six modules et le travail que chacun vous enlève — puis, quand vous voudrez voir SIROC argumenter sur l'un de vos vrais dossiers, demandez une démonstration.