SIEM open source : ce qu'il règle, et ce qui reste à votre charge
Un SIEM open source règle la collecte, le stockage et l'exécution des règles. L'ingénierie de détection, la corrélation entre sources, le cycle de vie des dossiers et le reporting, c'est vous qui les construisez.
Si vous partez sur un SIEM open source, ou si vous en exploitez déjà un, voici le résumé honnête : la collecte et le stockage sont réglés, la décision ne l'est pas. OpenSearch, Elastic, ClickHouse et Wazuh ingèrent vos logs, les gardent sur du matériel que vous contrôlez et font tourner des règles dessus, sans vous facturer au gigaoctet la lecture de vos propres données. Ce qu'aucun ne livre, c'est la couche qui transforme ces déclenchements de règles en une courte liste de dossiers : chacun avec un verdict, un responsable et une échéance. Cette couche-là reste à votre charge, et c'est elle qui prend un an de travail.
Ce n'est pas un plaidoyer pour remplacer votre stack. Gardez-la. C'est un plaidoyer pour être lucide sur la frontière : ce que l'open source fait vraiment très bien, et ce qui se trouve juste au-dessus — que vous finirez sinon par bricoler avec une file de tickets, un tableur et ce que quelqu'un se rappelle avoir décidé jeudi dernier.
Ce qu'un SIEM open source règle déjà
Trois choses, et ce sont les trois qu'il coûte le plus cher de rater.
La collecte. Agents, parseurs, collecteurs, un schéma qui résiste au contact d'un parc réel. Faire arriver au même endroit, de façon fiable, les Windows Event Logs, les logs auditd, le syslog des firewalls et les logs d'audit du cloud, c'est un travail d'ingénierie réellement difficile, et l'open source l'a fait.
Le stockage. Vos index sont sur vos disques. La rétention redevient une décision de capacité au lieu d'une négociation de licence, et c'est toute la raison pour laquelle les équipes prennent cette voie. Gartner le dit sans détour : les acheteurs de SIEM n'en peuvent plus de l'inflation des coûts — le « SIEM cost bloat » — et le stockage ouvert en est la réponse la plus directe. Un compteur fait rentrer votre durée de rétention dans la négociation de licence, et c'est de l'enfermement fournisseur, quoi qu'en dise la clause de sortie.
L'exécution des règles. Un langage de règles de détection, un ordonnanceur, un moyen de dire « préviens-moi quand ceci arrive », et une interface de recherche pour la chasse aux menaces que vous finissez par mener à la main.
Chaque stack excelle sur une partie différente de l'ensemble :
| Stack | Ce qu'elle fait vraiment bien | Ce que vous constatez au bout de trois mois |
|---|---|---|
| Wazuh | Des agents sur les hôtes, le FIM, un jeu de règles opérationnel dès le premier jour, des alertes honnêtes, aucune facture d'ingestion | Une alerte produit une ligne ; rien ne regroupe ces lignes en un dossier |
| OpenSearch | Gouvernance ouverte, un moteur de recherche mature, un plugin d'alerting, la scalabilité horizontale sur du matériel standard | Le contenu de détection, c'est vous qui l'écrivez et vous qui le maintenez en état de marche |
| Elastic / ELK | L'expérience de requête et de visualisation la plus riche, une large communauté publique de règles de détection | Les fonctions de sécurité dont vous disposez vraiment dépendent du niveau de licence |
| ClickHouse | Une compression et une vitesse de requête imbattables sur de très gros volumes d'événements, à un coût au téraoctet sans équivalent | C'est une base de données, pas un SIEM : tout ce qui se situe au-dessus de la requête est à votre charge |
Ce n'est pas de la politesse. La collecte et le stockage sont les couches que les éditeurs commerciaux facturent le plus cher, et vous les avez déjà.
Ce qu'il vous reste à construire
Voici la liste, dans l'ordre où les équipes la découvrent :
- L'ingénierie de détection : du contenu aligné sur un référentiel, et une couverture qui continue de fonctionner à mesure que le parc évolue.
- La corrélation entre sources, pour qu'une alerte d'identité et une alerte endpoint sur le même poste ne fassent plus qu'une.
- Le cycle de vie des dossiers : premier tri, escalade en N2, désignation d'un responsable, statut, historique de qui a décidé quoi.
- Les échéances SLA, et un backlog classé par impact métier plutôt que par ordre d'arrivée.
- Le reporting et les preuves qu'un auditeur, un comité des risques ou un régulateur accepteront.
- La gouvernance : les rôles, un audit log dont toute altération se voit, et une trace des décisions qui survit à l'analyste qui les a prises.
Tout cela se construit. La vraie question est de savoir si c'est là-dessus que vous voulez occuper vos ingénieurs sécurité pendant les quatre prochains trimestres.
Le contenu de détection est la première chose qui vous appartient, et la première qui se dégrade
Pour son State of SIEM Detection Risk 2025, CardinalOps a lu les métadonnées de configuration de SIEM réellement en production : les SIEM d'entreprise couvraient 21 % des techniques MITRE ATT&CK alors que les données déjà ingérées permettaient d'en couvrir 90 %, et 13 % des règles en place étaient cassées sans que personne le sache. Sans que personne le sache : c'est là tout le problème. Une règle qui ne se déclenche plus ressemble exactement à une technique que personne n'utilise.
Cet écart ne tient pas au fait que l'outillage soit ouvert. Il tient au fait que l'ingénierie de détection est un poste à temps plein dont personne n'a le temps, et qu'une stack open source vous confie ce poste dès le premier jour. Si vous partez là-dessus, budgétez-le explicitement : quelqu'un est responsable de la couverture de détection, quelqu'un vérifie que chaque règle se déclenche toujours, et ces deux tâches sont récurrentes.
Seculogik livre 72 packs de détection alignés sur MITRE, importables depuis un écran. C'est un plancher, pas un substitut à ce travail — mais un parc neuf démarre avec une couverture réelle plutôt qu'avec un jeu de règles vide.
La corrélation entre sources est le travail qui dévore la semaine
Une règle se déclenche sur un événement. Une campagne, c'est beaucoup d'événements, répartis entre un outil endpoint, un fournisseur d'identité et un firewall, sur plusieurs jours. Les relier, c'est la semaine du N1, et ça se fait à la main : trois onglets ouverts, un hostname recopié de l'un à l'autre, un modèle mental qui ne survit pas à la relève.
Le State of the SOC 2026 de Microsoft et Omdia — étude commanditée par un éditeur, à lire comme un ordre de grandeur et non comme une loi — indique que deux tiers des équipes SOC consacrent environ un cinquième de leur capacité hebdomadaire à la corrélation manuelle. Un cinquième de la semaine, sur un travail mécanique.
C'est la couche qu'un SIEM open source n'occupe volontairement pas, et c'est celle que nous avons construite. Le moteur de corrélation de Seculogik passe chaque alerte au crible de neuf contrôles indépendants — les entités concernées, la progression dans la kill chain, la convergence ou non de plusieurs sources, la correspondance avec un scénario d'attaque connu, comme un phishing suivi d'une compromission de compte, ou une exécution suivie d'un ransomware — et ces neuf contrôles doivent s'accorder sur un verdict unique.
La déduplication relève de la même passe : des centaines d'alertes de faible gravité qui se répètent deviennent un seul dossier, correctement scoré, au lieu de centaines de lignes. Nous détaillons son fonctionnement, et ce qu'un moteur de corrélation vous doit, dans cet article.
Le cycle de vie des dossiers, c'est là que le projet devient discrètement un produit
C'est la partie que la plupart des équipes sous-estiment, parce qu'une file de tickets donne l'impression de la couvrir.
Elle ne la couvre pas. Un dossier a besoin d'une qualification — pas simplement de quelqu'un qui ouvre l'onglet —, d'un responsable qui a de la marge et pas seulement de celui qui est d'astreinte, d'une échéance qui démarre au bon moment, et d'une trace de décision capable de répondre à « pourquoi l'avons-nous classé en faux positif ? » six mois plus tard, quand l'analyste qui a clos le dossier a changé de boîte. Greffer tout ça sur un outil de ticketing, c'est construire un moteur de workflow, une politique d'attribution, un calculateur de SLA et un audit log — puis les maintenir.
The Verdict Layer, c'est exactement cette couche : une file de décision qui dit quoi ouvrir ensuite, calculée de façon déterministe à partir des faits de chaque dossier, avec des échéances SLA, une attribution qui tient compte de la charge de chacun, et une trace lisible de ce qui a pesé et de ce qui aurait changé le verdict.
Le reporting est l'échéance que vous ne pouvez pas décaler
Une stack open source vous donne des dashboards. Un dashboard n'est pas un document que lit un comité des risques, ce n'est pas un constat de posture défendable en réunion, et ce n'est pas une preuve pour un régulateur.
NIS2 vous impose une alerte précoce sous 24 heures et une notification sous 72 ; pour DORA, l'échéance des entités financières démarre à la classification et court sur quatre heures. Dans les deux cas, il faut pouvoir dire par écrit ce que vous saviez et à quel moment vous l'avez décidé. Le scoring NIST CSF, ISO 27001, RGPD, DORA et NIS2, et les dossiers de preuves qui exposent leur propre méthodologie et leur propre couverture, c'est le module SOC Reporting de Seculogik. Refaire tout ça au-dessus d'une stack open source, c'est un projet à part entière.
Gardez votre stack, ajoutez la couche qui décide
La conclusion n'est pas « remplacez tout ». Votre stockage de logs reste le vôtre, vos capteurs aussi, et il n'y a pas de deuxième facture d'ingestion : le modèle tarifaire est par déploiement et par an, sans compteur sur le volume, les endpoints ou les utilisateurs.
Seculogik se place au-dessus de ce que vous exploitez déjà : les stacks open source comme OpenSearch, Elastic, ClickHouse et Wazuh, les plateformes du marché comme Splunk, Microsoft Sentinel, CrowdStrike, Microsoft Defender, SentinelOne, Cortex XDR, Fortinet, Okta et Entra ID — 23 connecteurs de plateformes du marché au total — plus les webhooks en push, et un connecteur que nous développons si le vôtre manque.
Deux choses que nous ne vous dirons pas. Nous ne vendons pas un SOC autonome : la position formelle de Gartner est qu'il n'y en aura jamais, et nous la partageons. Et nous sommes en pré-GA : aucun client à citer à ce jour, aucune qualification ANSSI ou CSPN, aucun rapport de pentest tiers, aucun SLA. Si l'un de ces points est une exigence chez vous, dites-le tôt et nous vous dirons franchement où nous en sommes.
Si votre stack, c'est Wazuh, l'édition Free tourne dessus sans frais, avec de vrais dossiers et une vraie file : on le raconte ici. Sinon, le plus rapide pour savoir si la couche de décision vaut le coup est de la brancher sur une semaine de vos propres alertes. Demandez une démonstration, c'est exactement ce que nous ferons.