Triage des alertes : les six étapes, et où partent vraiment les heures
Les six étapes du triage : dédoublonner, regrouper, cadrer, trancher, agir, consigner. Où partent réellement les heures, ce qu'une machine doit prendre en charge, et ce qui exige encore une personne.
Le triage des alertes, c'est transformer un flux d'alertes brutes en une courte liste de sujets qui méritent le temps d'un analyste, puis trancher chacun d'entre eux. Concrètement, cela fait six étapes : dédoublonner, regrouper les alertes liées en un seul incident, cadrer le périmètre et l'impact, décider si c'est un vrai ou un faux positif, décider quoi faire, et écrire pourquoi. Ce qu'il faut savoir avant d'acheter quoi que ce soit : les deux premières étapes sont mécaniques et absorbent l'essentiel du temps. C'est cette part-là qu'une machine doit prendre en charge.
Tout le reste relève du jugement, et c'est pour ce jugement que vous avez recruté vos analystes. La plupart des outils font l'inverse : ils automatisent le verdict, la seule chose dont une personne doit répondre, et laissent le rapprochement à un analyste N1 qui a trois consoles ouvertes.
Votre mardi, décrit avant qu'on parle de nous
Une stack de détection produit des alertes. Un outil de ticketing les enregistre. Entre les deux, quelqu'un ouvre la console EDR, l'IdP et le SIEM, voit passer le même hostname dans les trois, et décide de tête si cela fait un incident ou trois.
Cette décision-là n'est écrite nulle part, n'est mesurée nulle part, et se répète des centaines de fois par semaine.
Elle ne survit à aucune passation de poste, et c'est celle qui lâche le plus souvent à 3 h du matin, parce qu'elle repose entièrement sur la part du parc qu'un analyste fatigué a en tête à cet instant.
Les six étapes du triage, et à qui revient chacune
| # | Étape | La question qu'elle tranche | Qui doit la faire |
|---|---|---|---|
| 1 | Dédoublonner | Ai-je déjà vu exactement la même chose ? | la machine, entièrement |
| 2 | Regrouper | Ces alertes forment-elles un seul incident ? | la machine, et elle montre son raisonnement |
| 3 | Cadrer | Qu'est-ce que cela a touché d'autre, et jusqu'où cela peut aller ? | la machine rassemble, l'analyste juge |
| 4 | Verdict | Est-ce réel ? | l'analyste, avec un premier avis argumenté |
| 5 | Action | On fait quoi, et dans quel délai ? | l'analyste ; toute action destructive passe par une personne |
| 6 | Consigner | Pourquoi avons-nous décidé cela ? | la machine l'écrit, l'analyste en répond |
Lisez la colonne de droite comme un cahier des charges. Les étapes 1 et 2 sont le premier tri : une seule bonne réponse, qui ne dépend pas de votre métier, et une machine qui les traite correctement rend des heures à toute l'équipe.
Les étapes 4 et 5 sont celles où une escalade vers le N2 se justifie : elles dépendent de choses qu'aucun éditeur ne connaît de votre organisation, et une machine qui prétend les prendre en charge vous vend un risque.
Étapes 1 et 2 : celles qui vous coûtent une journée par semaine sans que cela se voie
L'étude State of the SOC (2026) de Microsoft et Omdia, commanditée par un éditeur, relève que deux tiers des équipes SOC perdent environ un cinquième de leur capacité hebdomadaire en corrélation manuelle. Un cinquième de semaine, c'est une journée par analyste, passée à rapprocher des alertes à la main.
Le dédoublonnage est la partie facile. Le même événement arrive deux fois parce que deux capteurs l'ont vu, parce que deux fenêtres de collecte se chevauchent, ou parce qu'une livraison a été rejouée. Rien de tout cela n'a d'intérêt, et rien de tout cela ne devrait atterrir dans une file.
Le regroupement est la partie coûteuse, et il rate de deux façons qui n'ont rien à voir entre elles.
La première, c'est le burst : une règle part des centaines de fois en quelques minutes — un brute force, un agent mal configuré, le passage d'un scanner. Sans regroupement, c'est le backlog d'une matinée. Des centaines d'échecs d'authentification en criticité faible, ce n'est pas des centaines d'incidents ; ce n'est pas non plus une seule ligne en criticité faible. C'est un incident, à coter pour ce que ce volume veut dire, chaque répétition comptée.
La seconde, c'est l'inverse : trois alertes qui n'ont l'air de rien parce qu'elles viennent de trois outils différents, et qui sont en réalité une seule intrusion. Le signal le plus fort dont disposent la plupart des parcs, c'est la concordance entre les sources — et aucun outil pris seul ne peut la voir, puisqu'aucun ne voit les deux autres.
C'est ce travail que fait notre moteur de corrélation avant qu'un humain n'ouvre quoi que ce soit. Neuf contrôles indépendants examinent chaque alerte et doivent s'accorder sur un seul verdict : comment les entités se comportent, si l'attaque progresse vraiment, si plusieurs sources concordent indépendamment, si l'enchaînement correspond à un scénario connu — un phishing suivi d'une prise de contrôle de compte, par exemple —, si un pattern bénin connu explique l'ensemble. L'analyste ouvre un dossier qui sait déjà quelles alertes lui appartiennent, et pourquoi.
Étape 3 : le périmètre et l'impact
Cadrer, c'est demander ce que la chose a touché d'autre. Quels autres hôtes ce compte a atteints, si cette adresse est réapparue ailleurs dans la semaine, si cette technique appartient à quelque chose de déjà ouvert.
L'étape se divise nettement en deux. Rassembler le contexte est mécanique — des recherches, des rapprochements, de l'historique — et un analyste qui le fait à la main fait de la saisie. Juger le contexte ne l'est pas : savoir si un compte de service qui touche quatre serveurs est normal dépend de ce à quoi sert ce compte, et personne, en dehors de chez vous, ne le sait.
La machine doit donc arriver avec le périmètre déjà constitué : les entités concernées, la position dans la kill chain, la concordance ou non des sources, et — avec le module Threat Intelligence — ce que l'extérieur sait des indicateurs. L'analyste garde son attention pour la partie que lui seul peut traiter.
Étape 4 : le verdict, et le plafond dont il hérite
Le triage ne tranche que sur ce qui lui parvient. CardinalOps a lu les métadonnées de configuration de SIEM réellement en production pour son rapport State of SIEM Detection Risk (2025) : les détections couvrent 21 % des techniques MITRE ATT&CK là où les données déjà collectées permettraient d'en couvrir 90 %, et 13 % des règles existantes sont cassées sans que personne le sache. Ces deux chiffres fixent le plafond de n'importe quel processus de triage : une alerte qui ne part jamais ne peut pas être triée, et une règle qui part pour rien crée du travail sans qu'il y ait de verdict à rendre.
La couverture de détection se travaille en ingénierie de détection, pas en triage. Aucun processus de triage ne relève le plafond dont il hérite, et ceux qui peuvent le relever ne sont pas ceux qui traitent la file.
Sous ce plafond, qualifier une alerte relève du jugement, et le verdict doit être argumenté plutôt qu'annoncé. SIROC, notre analyste IA et le module Advanced AI, expose d'abord les explications innocentes et les preuves des deux côtés, et ne s'engage sur un verdict qu'à la fin. Les éléments précis qu'il cite sont ensuite recoupés avec les alertes réellement rattachées au dossier : un verdict que les preuves du dossier ne soutiennent pas voit son niveau de confiance abaissé devant l'analyste, il n'est pas transmis comme un fait.
C'est l'ordre qui compte. Un analyste peut superviser un raisonnement. Personne ne peut superviser une conclusion.
Étape 5 : décider quoi faire
Un verdict n'est pas une issue. Il reste à peser l'impact métier et à choisir entre surveiller, confiner et couper un processus dont l'activité dépend — et la troisième option a un coût que votre organisation n'a pas forcément envie de payer un vendredi à 3 h du matin.
L'automatisation a sa place ici, mais étroite : les étapes répétables et réversibles qui suivent toujours un verdict donné, réunies dans un playbook de réponse, avec le module Automations. Les actions destructives — isoler un hôte, bloquer une adresse — s'arrêtent toujours sur une validation avant action qu'une personne doit donner, et aucun playbook ne peut abaisser ce seuil.
La position officielle de Gartner est qu'il n'y aura jamais de SOC autonome. Nous la partageons, et nous ne vendons pas de SOC autonome. La machine classe, explique et propose ; une personne décide et en répond.
C'est ce que veut dire la supervision humaine sur ces six étapes : la machine prend les étapes 1, 2 et 6, jamais les étapes 4 et 5.
Étape 6 : écrire le pourquoi, celle que tout le monde saute
Six mois après un incident, personne ne demande ce qui s'est passé : les logs répondent. On vous demande pourquoi vous avez conclu que ce n'était rien, ou pourquoi vous avez escaladé. Cette réponse-là vit d'habitude dans la tête d'un analyste qui a changé d'employeur depuis.
Chaque dossier doit donc garder une trace de décision lisible : quels signaux ont pesé, comment le verdict a été rendu, et ce qu'il aurait fallu de différent pour qu'il change. Écrite au fil du traitement du dossier, pas comme un second travail en fin de poste. Quand elle l'est, le reporting que votre comité de direction, votre auditeur ou votre régulateur finira par réclamer est déjà là — c'est l'argument pour traiter le SOC comme un système de décision plutôt que comme un système de monitoring.
Ce qui exige encore une personne, honnêtement
Savoir si le compte de service qui touche quatre serveurs à 2 h du matin est une intrusion, ou la migration que quelqu'un a planifiée sans prévenir. Savoir si cet hôte peut être sorti du réseau en pleine clôture comptable, ou si la coupure coûte plus cher que le risque. Savoir si un dossier ambigu justifie de réveiller l'astreinte. Personne, en dehors de chez vous, ne peut répondre à ces questions, et la responsabilité de la réponse ne se délègue à aucun logiciel.
Nous n'avons ni qualification ANSSI ni CSPN, aucun rapport de pentest réalisé par un tiers, nous ne proposons pas de SLA, et nous sommes en pré-GA, sans aucun client à ce jour. Nous ne publions aucun chiffre de précision de triage qui nous soit propre, parce qu'il n'existe aucun comparatif crédible entre éditeurs et qu'un chiffre que personne ne peut vérifier vaut moins que pas de chiffre du tout. Jugez l'affirmation sur votre propre semaine d'alertes.
Ce que cela change pour vous
La séquence ne bouge jamais. Ce qui bouge, c'est qui fait quelle étape, et la part du temps que consomme la moitié mécanique. Seculogik se place au-dessus de la stack de détection que vous exploitez déjà — les stacks open source comme ClickHouse, Elastic, OpenSearch et Wazuh, les plateformes du marché comme Splunk, Microsoft Sentinel, CrowdStrike, Microsoft Defender et Cortex XDR, ou un connecteur que nous développons si le vôtre manque — et retire les étapes 1, 2 et 6 à vos analystes, tout en rendant les étapes 3, 4 et 5 plus rapides à bien faire.
La licence est accordée par déploiement et par an, sans compteur sur les alertes que vous envoyez. La séquence est la même que vous protégiez un seul parc ou, avec l'édition MSSP, plusieurs clients depuis un seul écran.
Si cette arithmétique ressemble à votre semaine, la suite, c'est la mécanique : comment The Verdict Layer transforme des alertes en dossiers, puis en décisions, et ce que votre analyste voit au bout. Si vous préférez la voir à l'épreuve de vos propres alertes, demandez une démonstration.