Le SIEM est le système nerveux central de la détection : il rassemble les logs de tout votre SI, les corrèle et lève des alertes. C'est aussi l'outil le plus survendu et le plus sous-exploité du marché. Ce guide se lit à deux niveaux : l'essentiel pour décider, puis un volet technique poussé — architecture moderne, ingénierie de détection, économie réelle et comparatif à critères durs — pour celles et ceux qui doivent le concevoir et l'exploiter.
Le SIEM moderne n'est plus un bloc monolithique. Un pipeline d'observabilité route, réduit et normalise (vers OCSF) avant ingestion ; un tier analytics chaud porte la détection temps réel ; un data lake froid encaisse la rétention longue à coût maîtrisé.
The modern SIEM is no longer a monolith. An observability pipeline routes, reduces and normalizes (to OCSF) before ingestion; a hot analytics tier carries real-time detection; a cold data lake absorbs long retention at controlled cost.
Le SIEM des années 2010 — un moteur monolithique qui ingère, indexe et corrèle tout au même endroit — a cédé sous le poids du volume et de la facture. L'architecture actuelle se découpe en quatre plans. Collecte : agents, syslog, OpenTelemetry et API pull. Pipeline d'observabilité (Cribl, Vector, Logstash) : on route, on réduit et on enrichit les événements avant ingestion — c'est là que se gagne le contrôle des coûts. Normalisation : chaque événement est réécrit dans un schéma commun. C'est le nerf de la guerre — un log Windows et un log de pare-feu ne se corrèlent que s'ils parlent la même langue. Trois écoles : schéma propriétaire (Splunk CIM, Sentinel ASIM), ECS (Elastic) et surtout OCSF (Open Cybersecurity Schema Framework), le standard ouvert qui monte et rend vos détections portables d'un outil à l'autre.
Enfin, le stockage se dédouble (voir le schéma ci-dessus) : un tier analytics chaud, petit et coûteux, pour la détection temps réel ; un security data lake froid pour la rétention longue, la chasse et le forensic, à coût bas. Sentinel a son data lake (rétention longue durée), Splunk découple via SmartStore et la federated search, Google SecOps facture au volume forfaitisé avec une rétention d'un an par défaut. Découpler le calcul du stockage, c'est casser l'équation « volume = facture » qui ruine les SIEM mal conçus.
Une détection moderne n'est pas une règle écrite à la main dans une console : c'est un artefact de code. Le standard de fait est Sigma — une règle YAML portable qui se compile vers le backend cible (SPL, KQL, EQL, YARA-L…). On la versionne dans Git, on la teste, on la déploie en CI/CD. C'est la discipline du detection-as-code.
Une détection n'est pas une case cochée : c'est un artefact versionné, testé (émulation d'adversaire) et mesuré contre ATT&CK. Sans cette boucle, on accumule des règles bruyantes que personne n'ose désactiver.
A detection isn't a checkbox: it's a versioned, tested (adversary emulation) and measured artifact against ATT&CK. Without this loop you pile up noisy rules nobody dares disable.
Le cycle compte plus que la règle isolée. On part d'une menace (threat intel, technique ATT&CK), on formule une hypothèse de comportement, on écrit la détection, on la teste par émulation d'adversaire (Atomic Red Team, Caldera), on la déploie, puis on tune et on mesure la couverture. Deux pièges d'expert : le coverage theater (afficher 90 % de couverture ATT&CK avec des règles jamais validées) et l'oubli de la Pyramid of Pain — détecter des hashes ou des IP coûte peu à l'attaquant à contourner ; détecter des TTP (comportements) fait mal. La détection statique (corrélation) se complète d'UEBA (analyse comportementale, détection d'anomalies sur des lignes de base).
Déroulons une intrusion type, du phishing à l'exfiltration, pour voir ce que le SIEM attrape — et où il devient aveugle si la source manque.
| Étape (ATT&CK) | Source de log | Signal de détection | Si la source manque |
|---|---|---|---|
| Accès initial / exécution | Passerelle e-mail + EDR | Pièce jointe ouverte, processus enfant suspect d'Office | Aveugle sans EDR |
| Persistance | EDR + journaux Windows | Tâche planifiée, clé Run, service créé | Détection partielle |
| Élévation de privilèges | Windows Security (4672 / 4688) | Création de token privilégié, outil connu | Aveugle sans journaux hôte |
| Mouvement latéral | AD / Kerberos (4768 / 4769), NDR | TGT anormal, SMB inhabituel | Aveugle sans logs AD |
| Exfiltration | Proxy / firewall, DLP, logs cloud | Volume sortant anormal, upload SaaS massif | Aveugle sans logs réseau / cloud |
Deux leçons d'expert : la détection est une chaîne — rater une étape n'est pas rater l'attaque si une autre la rattrape ; et chaque détection dépend d'une source précise. D'où l'exercice clé : cartographier vos sources × techniques ATT&CK pour repérer vos angles morts avant l'attaquant.
Le même SIEM peut vivre au niveau 1 (alertes par défaut, bruit) ou au niveau 4 (détection testée, mesurée, chassée). La marche qui compte, c'est le passage à la détection custom mesurée — pas le choix du produit.
The same SIEM can live at level 1 (default alerts, noise) or level 4 (tested, measured, hunted detection). The step that matters is reaching custom, measured detection — not the product choice.
Un programme de détection se pilote au chiffre. Les indicateurs qui comptent — ordres de grandeur à caler sur votre criticité :
| Indicateur | Cible | Ce qu'il révèle |
|---|---|---|
| MTTD (détection) | < 1 h pour un P0, < 24 h sinon | Vitesse de détection |
| MTTR (réponse) | Heures, pas jours | Vitesse de remédiation |
| Couverture ATT&CK testée | Techniques pertinentes validées (pas seulement écrites) | Anti coverage-theater |
| Taux de faux positifs | < 5-10 %, en baisse | Santé du tuning |
| Ratio alerte → incident | En hausse | Qualité du signal |
| Coût / Go (tendance) | Maîtrisé / baissier | Discipline d'ingestion |
Le TCO d'un SIEM se joue sur le modèle de tarif, pas sur le prix unitaire. Au Go ingéré (Splunk, Sentinel historiquement), le volume pilote la facture et punit la curiosité. Au compute / asset, on découple stockage et calcul (logique data-lake). En forfaitaire (Google SecOps), le prix est prévisible et rentable à très gros volume. Quel que soit le modèle, le seul levier universel est la data reduction au pipeline.
Le TCO d'un SIEM se joue moins sur le prix unitaire que sur le modèle et sur ce que vous ingérez. Filtrer et router en amont (drop, sample, agrégation, bascule vers le data lake) est le seul levier qui marche sur tous les modèles.
A SIEM's TCO is driven less by unit price than by the model and by what you ingest. Filtering and routing upstream (drop, sample, aggregate, tier to the data lake) is the only lever that works across all models.
Les critères qui décident vraiment : le modèle de déploiement, le modèle de tarif (pilote du TCO), le schéma de données (propriétaire vs ECS vs OCSF — votre portabilité), le support detection-as-code (Sigma), le langage de requête (compétence de l'équipe) et la souveraineté (résidence UE). Le marché a bougé : Splunk est chez Cisco, le QRadar SaaS d'IBM est passé chez Palo Alto (migration vers Cortex XSIAM), et Sentinel converge dans le portail Defender.
| Solution | Déploiement | Tarif | Schéma / OCSF | Detection-as-code | Requête | UE |
|---|---|---|---|---|---|---|
| Splunk (Cisco) | On-prem / cloud | Go ingéré ou workload | CIM propriétaire | Sigma via conversion | SPL | Régions cloud |
| Microsoft Sentinel | Cloud (Defender) | Go + paliers + data lake | ASIM (OCSF émerge) | Règles Git, Sigma convertible | KQL | EU Data Boundary |
| Elastic Security | Cloud / self-hosted | Ressources / licence | ECS (socle d'OCSF) | Détections Git, Sigma | EQL / ES|QL / KQL | Self-host / cloud UE |
| Wazuh | Open source self-hosted | Gratuit (infra + temps) | Décodeurs propres | Règles XML, Sigma via conversion | OpenSearch DSL | Souveraineté totale |
| Cortex XSIAM (Palo Alto) | Cloud SaaS | Plateforme (data / assets) | Modèle XSIAM | Corrélation / BIOC, Sigma importable | XQL | Régions UE |
| Google SecOps (Chronicle) | Cloud SaaS | Forfait au volume | UDM | YARA-L (versionnable) | YARA-L / UDM | Régions UE |
| Graylog | Open source + commercial | Licence / volume | Schéma propre (GIM) | Pipelines, Sigma via conversion | Lucene / DSL | Self-host |
Lecture rapide : parc Microsoft 365 → Sentinel dans Defender est le chemin le plus court. Compétence interne + budget serré → Wazuh (gratuit, souverain) ou Elastic. Très gros volumes prévisibles → Google SecOps. Modernisation agressive du SOC avec convergence SIEM+SOAR+XDR → Cortex XSIAM. Et si vous n'avez personne pour l'exploiter, la vraie question n'est pas « quel SIEM » mais « dois-je acheter de la détection managée » → voir le guide EDR / XDR / MDR.
En 2026, l'IA aide réellement l'analyste sur quatre fronts : le triage assisté (résumer et enrichir une alerte, proposer une qualification), la requête en langage naturel (génération de KQL / SPL), l'investigation automatisée (reconstituer une chaîne d'événements) et l'aide à l'écriture de détections. On voit émerger un SOC agentique : des agents qui trient et pré-investiguent en autonomie (Security Copilot et équivalents).
La règle qui sauve : un SIEM est un produit interne et un modèle opératoire (rôle d'ingénieur détection, cycle de contenu, gouvernance des coûts), pas un achat de licence. Cadrer l'architecture, le tiering et le programme de détection avant de signer, c'est exactement le genre de mission que j'accompagne.
The SIEM is the central nervous system of detection: it gathers logs from across your IT, correlates them and raises alerts. It's also the most over-sold and under-used tool on the market. This guide reads on two levels: the essentials to decide, then a deep technical part — modern architecture, detection engineering, real economics and a criteria-based comparison — for those who have to design and operate it.
Le SIEM moderne n'est plus un bloc monolithique. Un pipeline d'observabilité route, réduit et normalise (vers OCSF) avant ingestion ; un tier analytics chaud porte la détection temps réel ; un data lake froid encaisse la rétention longue à coût maîtrisé.
The modern SIEM is no longer a monolith. An observability pipeline routes, reduces and normalizes (to OCSF) before ingestion; a hot analytics tier carries real-time detection; a cold data lake absorbs long retention at controlled cost.
The 2010s SIEM — a monolith that ingests, indexes and correlates everything in one place — buckled under volume and cost. Today's architecture splits into four planes. Collection: agents, syslog, OpenTelemetry and pull APIs. Observability pipeline (Cribl, Vector, Logstash): you route, reduce and enrich events before ingestion — that's where cost control is won. Normalization: each event is rewritten into a common schema. This is the crux — a Windows log and a firewall log only correlate if they speak the same language. Three schools: proprietary (Splunk CIM, Sentinel ASIM), ECS (Elastic) and above all OCSF (Open Cybersecurity Schema Framework), the rising open standard that makes your detections portable across tools.
Finally, storage splits in two (see the diagram above): a hot, small, expensive analytics tier for real-time detection; a cold security data lake for long retention, hunting and forensics at low cost. Sentinel has its data lake (long retention), Splunk decouples via SmartStore and federated search, Google SecOps uses flat volume pricing with one-year default retention. Decoupling compute from storage breaks the "volume = bill" equation that ruins badly designed SIEMs.
A modern detection isn't a rule hand-written in a console: it's a code artifact. The de facto standard is Sigma — a portable YAML rule that compiles to the target backend (SPL, KQL, EQL, YARA-L…). You version it in Git, test it, deploy it via CI/CD. That's the detection-as-code discipline.
Une détection n'est pas une case cochée : c'est un artefact versionné, testé (émulation d'adversaire) et mesuré contre ATT&CK. Sans cette boucle, on accumule des règles bruyantes que personne n'ose désactiver.
A detection isn't a checkbox: it's a versioned, tested (adversary emulation) and measured artifact against ATT&CK. Without this loop you pile up noisy rules nobody dares disable.
The loop matters more than the lone rule. You start from a threat (threat intel, an ATT&CK technique), form a behavioral hypothesis, write the detection, test it via adversary emulation (Atomic Red Team, Caldera), deploy, then tune and measure coverage. Two expert traps: coverage theater (claiming 90% ATT&CK coverage with rules never validated) and forgetting the Pyramid of Pain — detecting hashes or IPs is cheap for the attacker to bypass; detecting TTPs (behaviors) hurts. Static detection (correlation) is complemented by UEBA (behavioral analytics, anomaly detection against baselines).
Let's walk a typical intrusion, from phishing to exfiltration, to see what the SIEM catches — and where it goes blind if a source is missing.
| Stage (ATT&CK) | Log source | Detection signal | If the source is missing |
|---|---|---|---|
| Initial access / execution | Email gateway + EDR | Attachment opened, suspicious Office child process | Blind without EDR |
| Persistence | EDR + Windows logs | Scheduled task, Run key, new service | Partial detection |
| Privilege escalation | Windows Security (4672 / 4688) | Privileged token creation, known tool | Blind without host logs |
| Lateral movement | AD / Kerberos (4768 / 4769), NDR | Anomalous TGT, unusual SMB | Blind without AD logs |
| Exfiltration | Proxy / firewall, DLP, cloud logs | Abnormal outbound volume, large SaaS upload | Blind without network / cloud logs |
Two expert lessons: detection is a chain — missing one stage isn't missing the attack if another catches it; and every detection depends on a specific source. Hence the key exercise: map your sources × ATT&CK techniques to spot your blind spots before the attacker.
Le même SIEM peut vivre au niveau 1 (alertes par défaut, bruit) ou au niveau 4 (détection testée, mesurée, chassée). La marche qui compte, c'est le passage à la détection custom mesurée — pas le choix du produit.
The same SIEM can live at level 1 (default alerts, noise) or level 4 (tested, measured, hunted detection). The step that matters is reaching custom, measured detection — not the product choice.
A detection program is steered by numbers. The metrics that matter — orders of magnitude to tune to your criticality:
| Metric | Target | What it reveals |
|---|---|---|
| MTTD (detect) | < 1 h for a P0, < 24 h otherwise | Detection speed |
| MTTR (respond) | Hours, not days | Remediation speed |
| Tested ATT&CK coverage | Relevant techniques validated (not just written) | Anti coverage-theater |
| False-positive rate | < 5-10%, trending down | Tuning health |
| Alert → incident ratio | Trending up | Signal quality |
| Cost / GB (trend) | Controlled / declining | Ingestion discipline |
A SIEM's TCO hinges on the pricing model, not the unit price. Per ingested GB (Splunk, Sentinel historically), volume drives the bill and punishes curiosity. Per compute / asset decouples storage and compute (data-lake logic). Flat (Google SecOps) is predictable and cost-effective at very large volume. Whatever the model, the only universal lever is data reduction at the pipeline.
Le TCO d'un SIEM se joue moins sur le prix unitaire que sur le modèle et sur ce que vous ingérez. Filtrer et router en amont (drop, sample, agrégation, bascule vers le data lake) est le seul levier qui marche sur tous les modèles.
A SIEM's TCO is driven less by unit price than by the model and by what you ingest. Filtering and routing upstream (drop, sample, aggregate, tier to the data lake) is the only lever that works across all models.
The criteria that actually decide: deployment model, pricing model (TCO driver), data schema (proprietary vs ECS vs OCSF — your portability), detection-as-code support (Sigma), query language (team skill) and sovereignty (EU residency). The market shifted: Splunk is at Cisco, IBM's QRadar SaaS moved to Palo Alto (migration to Cortex XSIAM), and Sentinel is converging into the Defender portal.
| Solution | Deployment | Pricing | Schema / OCSF | Detection-as-code | Query | EU |
|---|---|---|---|---|---|---|
| Splunk (Cisco) | On-prem / cloud | Ingested GB or workload | Proprietary CIM | Sigma via conversion | SPL | Cloud regions |
| Microsoft Sentinel | Cloud (Defender) | GB + tiers + data lake | ASIM (OCSF emerging) | Git rules, Sigma convertible | KQL | EU Data Boundary |
| Elastic Security | Cloud / self-hosted | Resources / license | ECS (basis of OCSF) | Git detections, Sigma | EQL / ES|QL / KQL | Self-host / EU cloud |
| Wazuh | Open source self-hosted | Free (infra + time) | Own decoders | XML rules, Sigma via conversion | OpenSearch DSL | Full sovereignty |
| Cortex XSIAM (Palo Alto) | Cloud SaaS | Platform (data / assets) | XSIAM model | Correlation / BIOC, Sigma import | XQL | EU regions |
| Google SecOps (Chronicle) | Cloud SaaS | Flat volume | UDM | YARA-L (versioned) | YARA-L / UDM | EU regions |
| Graylog | Open source + commercial | License / volume | Own schema (GIM) | Pipelines, Sigma via conversion | Lucene / DSL | Self-host |
Quick read: Microsoft 365 estate → Sentinel in Defender is the shortest path. In-house skills + tight budget → Wazuh (free, sovereign) or Elastic. Very large, predictable volumes → Google SecOps. Aggressive SOC modernization with SIEM+SOAR+XDR convergence → Cortex XSIAM. And if you have no one to operate it, the real question isn't "which SIEM" but "should I buy managed detection" → see the EDR / XDR / MDR guide.
In 2026, AI genuinely helps the analyst on four fronts: assisted triage (summarize and enrich an alert, suggest a verdict), natural-language query (KQL / SPL generation), automated investigation (reconstructing an event chain) and detection authoring assistance. An agentic SOC is emerging: agents that triage and pre-investigate autonomously (Security Copilot and equivalents).
The rule that saves you: a SIEM is an internal product and an operating model (detection-engineer role, content lifecycle, cost governance), not a license purchase. Framing the architecture, tiering and detection program before signing is exactly the kind of engagement I help with.
La donnée est gratuite. Pour un avis sur l'impact réel sur votre parc et un plan de remédiation, on en parle.
Nous contacter →