Un SOC produit des décisions. La plupart des outils le traitent encore comme un système de surveillance.

Demandez à un analyste SOC ce qu'il a fait aujourd'hui : il vous répondra par un chiffre — alertes fermées, dossiers ouverts, tickets déplacés. Demandez-lui ce qu'il a décidé, et le silence s'installe. Ce silence est tout le problème, et c'est la raison pour laquelle nous appelons Seculogik The Verdict Layer, et non un SIEM, un SOAR ou un XDR.

La plateforme ne remplace rien de tout cela. Vos logs restent où ils sont, vos sondes restent vos sondes.

Seculogik se pose au-dessus de la stack de détection déjà en place — stacks open source comme ClickHouse, Elastic, OpenSearch ou Wazuh ; plateformes du marché comme Splunk, Microsoft Sentinel, CrowdStrike, Microsoft Defender, SentinelOne ou Cortex XDR ; ou une source qui vous est propre, pour laquelle nous développons le connecteur — et transforme le flot d'alertes en un petit nombre de dossiers qualifiés, chacun avec une explication lisible et une file qui dit quoi ouvrir ensuite. Sur votre propre infrastructure, sans facturation au volume.

Le monitoring répond à la mauvaise question

Un tableau de bord de monitoring répond à « que se passe-t-il ? », et il y répond très bien : le nombre d'alertes par gravité, une carte des adresses sources, une courbe d'événements par seconde. Chacun de ces chiffres décrit l'alerte ; aucun ne décrit un impact métier.

À 3 h 14, cette réponse ne sert plus à grand-chose : l'analyste de nuit, le peu d'attention qu'il lui reste, et plus de lignes que personne ne peut lire. La plupart des SOC sont petits — le SANS SOC Survey 2025 situe l'équipe type, au complet, entre deux et dix personnes, et 79 % d'entre eux tournent en 24/7 — donc les heures où une seule personne tient tout le parc sont précisément celles où un écran non hiérarchisé coûte le plus cher.

Un écran de décision répond à une autre question : « par quoi je commence ? » Il doit être hiérarchisé, court, et chaque ligne doit être actionnable au sens littéral : à un clic du dossier qu'elle désigne. Seculogik s'ouvre sur une file de décision découpée en quatre : en attente de triage, SLA menacé, risque élevé, critique sans responsable. Rien d'autre. Cette file se calcule à partir des faits de chaque dossier, de façon déterministe, jamais devinée par un modèle — la première chose qu'un analyste ouvre ne doit pas dépendre de la disponibilité d'une IA.

Le triage est une décision, et la plateforme le traite comme telle

La plupart des outils de gestion de dossier font avancer un dossier dès que quelqu'un l'ouvre. Ici, un dossier ne passe en investigation que lorsqu'une personne l'a trié — l'acte explicite, pour un N1, de décider qu'il mérite le temps d'un N2, ou de le clore en faux positif en disant pourquoi. Cela ressemble à une formalité. C'est en réalité ce qui sépare un backlog qui mesure l'attention d'un backlog qui mesure le jugement.

De cette seule règle dépend l'honnêteté de tous les chiffres en aval. Temps de prise en charge, temps de résolution, respect des SLA, le MTTR sur lequel on finira par vous juger : chacun mesure désormais une décision qu'un humain a réellement prise, et non un clic qui passait par là. Pour un RSSI qui rend des comptes à un conseil d'administration — ou, en édition MSSP, pour un prestataire qui rend des comptes aux clients qu'il sert — c'est la différence entre un indicateur défendable et un indicateur qui ne tient que tant que personne ne le conteste.

La décision doit survivre à la personne qui l'a prise

Six mois après un incident, la question n'est jamais « que s'est-il passé ? » : les logs y répondent. La question est « pourquoi avons-nous conclu que ce n'était rien ? », ou « pourquoi avoir escaladé ? » D'ordinaire, cette réponse survit à la relève et pas au-delà : elle est dans la tête de quelqu'un, et ce quelqu'un a changé de poste.

Chaque dossier conserve donc sa trace de décision, et sait vous la montrer : quels signaux ont pesé, comment le verdict a été obtenu, et ce qu'il aurait fallu de différent pour qu'il bascule.

Le moteur de corrélation soumet chaque alerte à plusieurs contrôles indépendants — les entités impliquées, l'avancement dans la kill chain, l'accord ou le désaccord entre plusieurs sources, la ressemblance avec un scénario connu comme un phishing suivi d'une compromission de compte — et le dossier garde la trace de ceux qui concordaient, de ceux qui divergeaient, et de ce qui a fait pencher le verdict.

Quand l'analyste IA intervient, ses hypothèses et les preuves pour et contre sont conservées au même endroit. Un RSSI, un auditeur ou un régulateur peut relire, un an plus tard, pourquoi ce dossier existe, sans rien réexécuter et sans avoir à retrouver l'analyste qui l'a clos.

Les chiffres doivent porter leurs preuves

L'objet le plus dangereux dans un SOC, c'est un tableau de bord propre qui est en réalité aveugle. Un zéro à l'écran a deux sens possibles : rien ne s'est produit, ou rien n'a été examiné. Un tableau de bord incapable de trancher entre les deux est pire que pas de tableau de bord du tout, parce qu'il rassure.

D'où une règle simple, que la plateforme s'impose : un zéro doit être explicable. Chaque chiffre d'un rapport porte la preuve qui l'a produit.

Une mesure qu'aucune donnée réelle ne permet de calculer le dit — données insuffisantes — au lieu d'afficher un blanc rassurant ou une extrapolation. Un rapport de vulnérabilités annonce quelle part du parc il a réellement couverte avant de vous dire à quel point le reste est sain.

Et les dossiers de preuves de conformité du module SOC Reporting — NIST CSF, ISO 27001, RGPD, DORA, NIS2 — portent en page de garde qu'il s'agit de signaux de couverture auto-évalués, et non des attestations : ce n'est pas le jour où vous en remettez un à un régulateur qu'il faut découvrir qu'il surestimait.

Pour un acheteur, c'est la différence entre un rapport qu'on transmet et un rapport qu'on doit assortir de réserves.

L'IA recommande. L'humain décide et reste responsable.

Un centre de décision qui héberge une IA a une obligation de plus, et le marché a déjà un mot pour elle : l'autonomie encadrée. L'IA ne doit pas devenir le décideur en silence.

SIROC, notre analyste IA (module Advanced AI), ne propose un verdict — assorti d'un niveau de confiance et du raisonnement qui l'a produit — qu'après avoir listé les explications bénignes et les preuves des deux côtés ; vous voyez son argumentation avant sa conclusion. Les preuves citées sont ensuite recoupées avec les alertes du dossier lui-même, et un verdict que ces alertes ne soutiennent pas est revu à la baisse devant l'analyste, au lieu d'être présenté comme un fait.

Même discipline côté réponse. Les actions destructrices — isoler une machine, par exemple — sont toujours soumises à une validation humaine avant action, et aucun playbook du module Automations ne peut abaisser ce seuil. L'IA peut les proposer, les mettre en file et les expliquer ; c'est une personne qui donne le feu vert. Le reste suit vos règles : par défaut un modèle local sous licence open source, sur votre propre machine, votre clé cloud si vous préférez, et chaque appel sortant vers le cloud inscrit dans un registre inviolable que vous pouvez auditer.

C'est cette discipline que recouvre le mot cyberdécision. Non pas que la machine décide plus vite, mais que la supervision humaine soit une propriété de la trace et non un slogan : chaque décision — humaine ou assistée — est explicite, hiérarchisée, adossée à des preuves, et encore lisible quand la personne qui l'a prise n'est plus là.

Ce que cela change pour un acheteur

Si vous évaluez Seculogik, ne demandez pas combien d'alertes la plateforme affiche. Demandez plutôt combien de décisions elle a produites sur une semaine de votre télémétrie, si chacune s'explique d'elle-même, et si la file a bien envoyé l'analyste sur le bon dossier en premier. Ces trois questions, c'est le produit.

La mécanique qui répond à ces trois questions est décrite ici : comment fonctionne The Verdict Layer — alertes → dossier → décisions — et ce que l'analyste a sous les yeux à l'arrivée.