La fatigue des alertes est un problème d'arithmétique, pas de moral

On présente en général la fatigue des alertes comme un problème de moral, à un pas de l'épuisement professionnel : des analystes qui s'usent, l'attention qui baisse, quelqu'un qui finit par démissionner. Présentée comme ça, elle appelle des réponses qui s'adressent au moral — faire tourner les équipes, améliorer la qualité de vie au travail, offrir une console plus agréable. Aucune ne change le chiffre, parce que la fatigue des alertes relève de l'arithmétique. Trois quantités décident si une file est tenable, et le jour où elles ne s'équilibrent plus, aucune bonne volonté ne comble l'écart.

La bonne question n'est donc pas « comment rendre tout ça moins pénible ? » mais « combien d'heures nous manque-t-il, et sur quel terme peut-on agir ? ». Posez-la honnêtement et les deux réponses classiques du secteur — recruter, faire plus de tuning — ne résistent pas au calcul, tandis qu'une troisième l'emporte pour une raison qui n'a rien à voir avec l'effort fourni.

Les trois nombres derrière la fatigue des alertes

Tout se ramène à ces trois chiffres, et vous pouvez les renseigner pour votre propre SOC cet après-midi.

Le chiffre	D'où il vient	Comment il évolue
Alertes qui arrivent jusqu'à un humain, par semaine	votre stack de détection, une fois appliquées la déduplication et la suppression du bruit que vous faites déjà	augmente avec le parc, les sources et le nombre de règles
Minutes que prend un vrai triage	passer d'une console à l'autre, vérifier la machine, relire l'historique	à peu près fixe, et rien ne le fait bouger
Heures analystes disponibles, par semaine	l'effectif, moins les astreintes, les réunions, les projets, les congés	augmente lentement, une personne entière à la fois

Multipliez les deux premiers, comparez au troisième. Prenons quatre cents alertes dans la semaine à un quart d'heure pièce — vos chiffres à vous, pas les nôtres — soit cent heures de triage. Une équipe de quatre qui tient aussi les astreintes, va en réunion et avance sur des projets n'a pas cent heures devant elle. L'écart n'est pas une impression : c'est un nombre.

Cet écart ne disparaît jamais, il se déplace. Il devient des alertes fermées sans avoir été lues, une file traitée du plus récent au plus ancien parce que c'est le seul ordre qu'un cerveau fatigué arrive à tenir, et un backlog dont tout le monde a tacitement convenu de ne pas parler, transmis d'une passation de poste à la suivante.

Dans les lignes que personne n'ouvre, le dwell time d'une intrusion continue de courir. La chasse aux menaces est la première chose qu'on arrête, parce que c'est le seul travail sans file d'attente derrière lui. La fatigue, c'est le symptôme que vos équipes vous remontent. L'arithmétique, c'est la cause.

Pourquoi le recrutement ne résout pas l'équation

Recruter agit sur le troisième chiffre, c'est-à-dire sur le terme le plus lent et le plus cher à faire bouger. Le SANS SOC Survey 2025 montre que le SOC complet le plus courant compte entre deux et dix personnes, et que 79 % des SOC tournent en 24/7. Dans le bas de cette fourchette, les astreintes consomment toute l'équipe avant même qu'une alerte soit triée : la contrainte, c'est la couverture horaire, pas la capacité de premier tri. Le recrutement suivant part donc dans le planning, pas dans la file du N1.

Un second effet dégrade la somme avant de l'améliorer. Un N1 qui arrive se forme auprès des N2 déjà en place, donc les premiers mois coûtent des heures à des gens qui en manquent déjà. Pendant ce temps, le premier chiffre continue de monter tout seul : chaque nouvelle source, chaque pack de détection ajouté, chaque acquisition fait arriver du volume sans demander l'autorisation.

Recruter, c'est une addition face à une croissance composée. À faire quand vous en avez les moyens, certainement ; mais ne comptez pas dessus pour combler l'écart. C'est la même arithmétique que dans comment un petit SOC fait le travail d'un grand, vue depuis l'effectif plutôt que depuis la file.

Pourquoi le tuning n'y suffit pas non plus, et pourquoi il reste indispensable

Le tuning s'attaque au bon terme : il fait baisser le volume qui arrive, c'est-à-dire le chiffre que l'on multiplie par les deux autres. C'est donc le levier le moins cher dont vous disposez, et il faut continuer à l'actionner. Une règle qui se déclenche cent fois par semaine sur une tâche de sauvegarde connue et bénigne, c'est une heure de la vie de quelqu'un ; la couper, c'est une heure récupérée.

Mais il est borné, et il entre en concurrence directe avec votre couverture. CardinalOps a analysé les métadonnées de configuration de SIEM en production pour son State of SIEM Detection Risk 2025 : des détections pour 21 % des techniques MITRE ATT&CK, là où les données déjà ingérées permettraient d'en couvrir 90 %, et 13 % des règles existantes cassées sans que personne s'en aperçoive.

Mettez ce constat en face de l'arithmétique et l'impasse saute aux yeux : la réponse honnête à 21 % de couverture, c'est de l'ingénierie de détection — écrire davantage de règles — et chaque règle ajoutée pousse le premier chiffre vers le haut. Une heure passée à supprimer du bruit est une heure qui ne comble pas un trou de couverture. Les deux chantiers tirent en sens inverse.

En plus, le tuning se périme. Une suppression, c'est une décision prise sur un parc qui change ensuite. Des machines sont réinstallées, un service déménage, et ce que vous aviez fait taire au printemps dernier n'est plus ce qui se déclenche — le silence recouvre désormais quelque chose que vous voudriez voir. C'est de la maintenance à durée de vie limitée, pas un correctif qui tient dans le temps.

Continuez donc le tuning. Cessez simplement d'y voir la réponse : il agit règle par règle, quand l'arithmétique porte sur la file entière.

Le seul terme qui divise

Voici le terme que tout le monde oublie. La charge de travail, ce n'est pas le nombre d'alertes. C'est le nombre de décisions distinctes qu'un humain doit prendre.

Dix alertes qui décrivent une seule intrusion, ce sont dix triages si un humain les rencontre une par une, et un seul si quelque chose les a rapprochées avant qu'il n'ouvre la première. Même télémétrie, mêmes détections, un ordre de grandeur d'écart en heures. Ce rapprochement est le seul levier de la somme qui divise, au lieu d'ajouter ou de retrancher.

La déduplication n'est pas le même levier. Elle supprime les répétitions d'une même alerte ; le rapprochement réunit dans un seul dossier des alertes différentes qui décrivent une seule intrusion — et seul le second fait baisser le nombre de décisions.

Aujourd'hui, dans la plupart des SOC, il se fait à la main et tard : un analyste reconnaît le même hostname dans trois consoles et décide de mémoire si les alertes vont ensemble. L'étude State of the SOC de Microsoft et Omdia, commanditée par un éditeur, établissait en 2026 que deux tiers des équipes SOC perdent environ un cinquième de leur capacité hebdomadaire en corrélation manuelle. Ce cinquième-là, ce n'est pas de l'investigation. C'est du rapprochement, refait à chaque fois, par des humains, une fois que les alertes ont déjà été ouvertes séparément et comptées séparément.

Mettez le rapprochement en amont de l'humain et l'arithmétique change de forme. Le débit d'arrivée reste exactement où il était ; le nombre de décisions, lui, s'effondre.

À quoi ça ressemble quand le rapprochement passe en premier

C'est le travail d'une couche de décision posée au-dessus de la stack de détection que vous exploitez déjà — stacks open source comme ClickHouse, Elastic, OpenSearch ou Wazuh, plateformes du marché comme Splunk, Microsoft Sentinel, CrowdStrike, Microsoft Defender, SentinelOne et Cortex XDR, avec un connecteur que nous développons si le vôtre manque à l'appel. Seculogik ne remplace ni vos sondes ni votre entrepôt de logs : il lit ce qu'ils produisent et décide quelles alertes relèvent du même incident avant qu'un humain n'en ouvre une seule. Alertes → dossier → décisions.

Trois propriétés comptent pour le calcul :

• Neuf contrôles indépendants doivent converger vers un seul verdict, si bien qu'un dossier arrive avec un niveau de confiance et une justification écrite, pas seulement avec une étiquette, et le moteur de corrélation consigne ce qui a pesé et ce qui aurait changé la conclusion.
• Un burst d'alertes n'est plus un backlog. Des centaines de répétitions de faible gravité deviennent un seul dossier, évalué pour ce que ce volume veut réellement dire, au lieu de centaines de lignes séparées que personne n'atteindra jamais.
• La file est ordonnée de façon déterministe, avec une échéance et un responsable : ce que l'analyste ouvre en premier est choisi par les faits du dossier, pas par sa position dans le scroll. C'est la couche de verdict.

L'analyste IA du module SIROC travaille ensuite sur ce qui a survécu à ce rapprochement, et sur rien d'autre. La position officielle de Gartner est qu'il n'y aura jamais de SOC autonome, et nous la partageons. SIROC travaille sous supervision humaine : la machine propose un verdict, un humain décide, et toute action destructrice attend une validation explicite.

La mesure à faire, et celle que nous ne truquerons pas

Si vous évaluez une solution sur cette base, mesurez la bonne quantité. Pas les alertes affichées, pas les événements par seconde, pas un dashboard avec une courbe qui descend — et pas le MTTR seul, qui s'améliore dès qu'une file commence à se fermer sans être lue.

Comptez les décisions distinctes par semaine sur votre propre télémétrie, avant et après, et chronométrez un triage dans chacun des deux états.

Nous ne publions aucun chiffre de précision, aucun pourcentage de réduction des faux positifs, aucun multiplicateur de temps gagné qui nous soit propre. Il n'existe aucun benchmark inter-éditeurs crédible auquel les rattacher, et un chiffre invérifiable vaut moins que pas de chiffre du tout. Nous sommes en pré-GA, nous n'avons aucun client à ce jour, et nous préférons que vous fassiez le calcul sur une semaine de vos propres alertes plutôt que de croire le nôtre.

Le modèle commercial est fait exactement pour ce test : facturé par déploiement et par an, sans compteur ni sur le volume, ni sur les endpoints que vous supervisez, ni sur le nombre de clients que vous servez. Envoyer davantage de télémétrie pour en avoir le cœur net ne coûte jamais plus cher.

Faites les trois, dans cet ordre

1. Le tuning. Le moins cher, effet immédiat, mais borné et périssable : budgétez la maintenance et acceptez que ça ne passe pas à l'échelle.
2. Le rapprochement. Le seul terme qui divise. En amont de l'humain, pas après, sinon vous payez des heures analystes pour le faire à la main.
3. Le recrutement. En dernier, et d'ici là chaque heure gagnée atterrit sur une décision plutôt que sur la reconstitution de ce que quelqu'un a déjà démêlé au poste précédent.

La fatigue des alertes s'arrête quand la somme s'équilibre, et la somme s'équilibre quand le nombre de décisions baisse. Tout le reste traite le symptôme.

Apportez une semaine de votre volume d'alertes à une démonstration et nous ferons le calcul avec vous — y compris si les chiffres disent que vous n'avez pas encore besoin de nous.