De l'alerte à la décision.
Ce document traite de la couche de décision des opérations de sécurité : l'étage qui se situe entre le SIEM qui lève l'alerte et la personne qui doit agir.
La surcharge d'alertes n'est pas un problème de collecte. C'est dans le triage, la qualification et l'escalade que part la semaine d'un SOC, et c'est précisément la partie pour laquelle personne ne vous a jamais rien vendu.
Sept sections. Chaque chiffre porte le nom de qui l'a mesuré. La section six liste ce que nous n'avons pas : commencez par là si vous êtes pressé.
La surcharge d'alertes, en chiffres vérifiables.
Deux études publiées décrivent la même semaine, chacune par un bout. Aucune ne vient de nous, et toutes deux exposent leur méthode : c'est la seule raison pour laquelle nous les citons.
- CardinalOps, State of SIEM Detection Risk 2025. Mesuré dans les métadonnées de configuration de SIEM en production, et non déclaré dans un sondage : la couverture de détection atteignait 21 % des techniques MITRE ATT&CK, alors que les données déjà ingérées en permettraient 90 %.
- La même étude, sur la santé des règles. 13 % des règles en service sont cassées sans que personne le sache. Elles ne se déclenchent plus, rien ne signale qu'elles se sont tues, et la posture de détection se dégrade sans qu'aucune décision ait été prise.
- Microsoft et Omdia, State of the SOC 2026 — étude commanditée par un éditeur, à lire comme telle. Deux tiers des équipes SOC consacrent près d'un cinquième de leur semaine à corréler des alertes à la main.
Le parc est instrumenté. Les détections en service exploitent une fraction de ce que les données permettent déjà. Et près d'une journée par semaine part à relier les résultats entre eux, dans la tête de quelqu'un.
C'est cette dernière partie qui coûte cher. C'est du travail qualifié, il ne se démultiplie pas avec les effectifs, et c'est la journée qui ne part jamais en ingénierie de détection ni en threat hunting.
Aucun de ces chiffres ne dit que votre équipe travaille mal. Ils disent que ce travail est resté au seul endroit que personne ne peut inspecter, relire, ni transmettre à la relève. Plus sur l'écart de couverture →
Pourquoi plus de données ne règle rien.
Trois métiers distincts se vendent sous un seul mot. Les séparer explique pourquoi le budget augmente sans que le lundi matin change.
Ajouter une source fait progresser le premier métier et complique le troisième. Chaque nouveau flux augmente le nombre d'éléments qu'une personne doit rapprocher à la main.
Collecter davantage donne l'impression d'avancer, parce que cela s'achète au gigaoctet. La décision, elle, ne s'achète pas : personne ne la met au catalogue, et son coût tombe sur le planning des équipes plutôt que sur la facture.
- Collecte
- Rassembler les événements au même endroit. Problème résolu, marché concurrentiel : c'est ce que la plupart des éditeurs vous vendent réellement.
- Détection
- Écrire et maintenir les use cases qui transforment les événements en alertes. Un métier à dette mesurable : la couverture et la santé des règles se dégradent en silence.
- Décision
- Transformer les alertes en une courte liste actionnable : ce sur quoi une personne identifiée agira ce soir. Aujourd'hui : un humain, sans outil, de mémoire.
Le SIEM trouve. Le N1 qualifie ce qu'il peut et escalade le reste. Le ticketing enregistre qu'on vous a prévenu.
Entre l'escalade et le ticket, un analyste confirmé passe d'une console à l'autre et décide quelles quatorze alertes forment une seule intrusion, et laquelle porte un vrai impact métier.
Cette personne est votre couche de décision. Elle n'est ni documentée ni sauvegardée, et elle part en congés. Les six étapes du triage, et où passent les heures →
Ce qu'est une couche de décision des opérations de sécurité.
Une seule colonne vertébrale, la même dans tout le produit : les alertes deviennent des dossiers, et les dossiers portent des décisions. Les alertes viennent de la stack que vous exploitez déjà. Le dossier est ce sur quoi une personne travaille. La décision est ce qui reste au dossier.
Jugé de neuf façons, tranché une fois
Neuf contrôles indépendants examinent chaque alerte et doivent converger vers un verdict unique, au lieu qu'une règle tranche seule. Un contrôle qui se trompe n'emporte pas le dossier.
Entités communes · progression dans la kill chain · accord entre les sources · récurrence du même bruit · dérive lente · scénarios d'attaque connus · regroupement par attaquant · patterns bénins écartés · ce que vos analystes ont déjà tranché sur un dossier de cette forme.
Chaque dossier garde son raisonnement
Chaque dossier conserve le détail de sa décision : ce qui a pesé, comment le verdict s'est formé, et ce qui l'aurait fait basculer.
C'est la différence entre un scoring qu'il faut croire sur parole et un verdict qu'un analyste peut contester — et infirmer, au dossier, devant un auditeur.
- Des centaines de répétitions deviennent un seul dossier. Une rafale d'alertes de faible sévérité tient dans un dossier unique, évalué, au lieu de cent lignes que personne ne lit — et rien ne se perd si un composant redémarre pendant la rafale.
- La file est classée par impact métier. La position dans la kill chain avance à mesure que les preuves arrivent : un dossier qui débouche sur du ransomware change de rang. Classer par ordre d'arrivée, c'est laisser une intrusion réelle accumuler du dwell time derrière un faux positif.
- Chaque dossier a un responsable et une échéance. Pas une boîte partagée où l'urgence dépend de qui passe par là, et où le plus ancien est le moins visible.
- Les scénarios connus sont identifiés, pas réinventés. Du phishing à la compromission de compte, de l'exploit à la persistance, de l'exécution au ransomware, de l'identité à l'abus de privilèges dans le cloud.
- Les sources restent les vôtres. Splunk, Microsoft Sentinel, CrowdStrike, Defender, Cortex XDR, Elastic, OpenSearch, ClickHouse ou Wazuh — en pull, en push, ou lues là où les données se trouvent déjà, avec un connecteur développé sur demande.
Rien de tout cela ne remplace votre stack de détection, et rien ne vous demande de déplacer vos données. Comment un verdict est atteint, en détail →
Là où l'humain garde la main.
La catégorie vend désormais du SOC agentique, et ses propres leaders en publient eux-mêmes la limite : autonomie encadrée, supervision humaine, validation avant toute action destructrice.
Gartner écrit noir sur blanc qu'il n'y aura jamais de SOC autonome. Nous partageons cette position, et nous avons construit le produit comme si elle était vraie — pas comme une contrariété marketing.
L'IA argumente à découvert
SIROC, notre module d'analyste IA, pose ses hypothèses et les preuves de chacune. Ce qui arrive au dossier : un verdict de détection, son degré de confiance, une recommandation, et le raisonnement derrière les trois.
Et tout est recoupé avec le dossier
Chaque valeur qu'il cite est confrontée aux alertes du dossier lui-même. Un verdict que le dossier n'étaye pas est déclassé sous les yeux de l'analyste, au lieu d'être livré tel quel.
Les actions destructrices s'arrêtent devant un humain
Avec le module Automations, toute action destructrice attend une validation humaine. Ce garde-fou ne peut être levé par personne, nous compris.
Quand un analyste infirme un verdict proposé, c'est sa décision qui fait foi. Le désaccord est conservé, et il pèse la prochaine fois qu'un dossier de cette forme se présente.
La plupart des produits parlent de supervision humaine et montrent une fenêtre de confirmation que personne ne lit. Notre promesse est plus modeste : la machine rapproche et lit, puis remet une courte liste avec son raisonnement. Ce que SIROC fait, et ce qu'il refuse de faire →
Souveraineté, et ce qui sort des murs.
Chez la plupart des acheteurs européens, c'est la première question, pas la dernière. La réponse est courte : par défaut, rien ne sort.
- Le raisonnement tourne en local. Un modèle open source fonctionne sur du matériel standard, sur votre propre machine. Pas de GPU, pas d'appel sortant, pas de compte à ouvrir chez qui que ce soit.
- Un modèle cloud uniquement si vous apportez la clé. Vous choisissez le fournisseur et les tâches autorisées à l'appeler — une tâche à la fois, pas un interrupteur global que quelqu'un bascule une fois et oublie.
- Le masquage intervient avant le départ de l'appel. Les secrets et les données personnelles, SIRET et RIB compris, sont retirés en amont.
- Chaque appel sortant est inscrit au registre. Sa destination et ce qui en a été retiré, dans un enregistrement que rien ne peut modifier ensuite, exportable en entier pour votre auditeur.
- Plafonds de dépense et coupe-circuits. Une facture cloud ne peut pas s'emballer, et un fournisseur défaillant cesse d'être appelé au lieu de bloquer la file.
- La plateforme répond elle-même à la question. Interrogez votre déploiement : il produit son attestation de souveraineté — l'IA cloud est-elle autorisée ici, oui ou non — et c'est cela que vous remettez à l'auditeur, pas un courrier de notre part.
Un site isolé du réseau est un déploiement prévu, pas une exception que nous tolérons. Les mises à jour sont signées, vérifiées avant qu'un octet ne soit appliqué, et annulées automatiquement si le contrôle de santé qui suit échoue.
Les délais réglementaires partent du principe que vous savez déjà dire qui a décidé quoi, et quand. NIS2 impose une alerte précoce sous 24 heures, une notification sous 72 et un rapport sous un mois ; DORA commence à compter quatre heures après la classification.
Une couche de décision qui garde sa propre trace, c'est ce qui transforme ces échéances en simple extraction, au lieu d'une fouille dans les boîtes mail. Ce que la loi demande vraiment → · La page sécurité et confiance →
Ce que coûte l'évaluation — et ce que nous n'avons pas.
Le coût d'une évaluation, c'est une machine. Debian ou Ubuntu, Docker ou installation native, sans GPU, sur une infrastructure que vous contrôlez. Aucun compte à créer, aucune donnée à nous envoyer.
Facturé par déploiement, par an
Ni au gigaoctet, ni à l'événement, ni à l'endpoint, ni à l'utilisateur — ni au client servi. Une facture indexée sur le volume, c'est là que commence l'enfermement fournisseur. Chez nous, deux variables font le prix : l'édition que vous déployez et les modules que vous activez.
De vrais dossiers, sans frais, sans limite de durée
L'édition Free crée de vrais dossiers et une vraie file sur la stack open source qu'une équipe exploite peut-être déjà, sans limite de durée et sans relance commerciale — mais sans moteur de corrélation, qui est précisément ce que l'édition payante active.
En temps humain, comptez une après-midi : quelqu'un qui peut ouvrir un accès en lecture sur une source, et un analyste confirmé prêt à contester un verdict à voix haute. Rien d'autre n'est nécessaire pour se faire une opinion.
Ce que nous n'avons pas.
Cette liste est la raison pour laquelle le reste du document mérite d'être lu. Autant la trouver ici qu'au milieu d'un questionnaire achats.
- Aucun client à ce jour. Nous sommes en pré-GA. Ni logo, ni témoignage, ni référence, ni étude de retour sur investissement : il n'y a rien d'honnête à y mettre.
- Aucune qualification ANSSI, ni CSPN, ni SecNumCloud. Une évaluation de préparation figure à la feuille de route. Pas une affirmation.
- Aucun rapport de test d'intrusion tiers. Il sera commandé avec les premiers partenaires de conception, qui le recevront non expurgé. D'ici là, nous vous expliquons comment nous testons nous-mêmes.
- Aucun SLA. À la place, une ligne directe avec les ingénieurs qui construisent le produit, et un accord de partenariat de conception qui écrit noir sur blanc ce que cela couvre.
- Aucun chiffre de performance qui soit le nôtre. Aucun taux de précision de triage, aucun pourcentage de réduction des faux positifs, aucun gain de MTTR. Nous ne les avons mesurés sur le parc réel de personne : nous ne les publions donc pas.
- Ni SaaS, ni provisionnement en libre-service. Un déploiement, sur une infrastructure que vous contrôlez. C'est une limite assumée, pas une étape transitoire.
Un éditeur incapable de vous dire ce qui lui manque n'a pas fini de réfléchir à ce qu'il a. Ce qui est livré, ce qui vient, et ce que nous ne construirons pas →
Comment juger le triage des alertes SOC sur vos propres données.
N'évaluez pas cela sur le parc de démonstration d'un éditeur. La seule question qui vaille : ce que devient votre heure la plus bruyante. Une demi-heure suffit à le savoir.
Après le rejeu, posez une seule question à votre analyste confirmé : est-ce que cela lui aurait épargné le travail de rapprochement fait ce matin-là ?
Si la réponse est non, plus rien ne compte dans ce produit — ni l'architecture, ni la feuille de route, ni le prix.
Deux capacités méritent d'entrer dans la même séance si elles figurent sur votre liste. Le threat intel, versé au dossier d'un dossier en cours plutôt qu'un flux que personne ne lit.
Et la file des vulnérabilités, incluse dans l'édition payante plutôt que vendue à part. Les six modules →
Faites le test de trente minutes sur vos propres alertes.
Apportez une source, une heure chargée et vos questions les plus dures — celles de la section six comprises. Vous repartirez en sachant quelle édition vous convient et quels modules valent d'être activés.