Choisir un SIEM (Security Information and Event Management) en 2026 revient souvent à trancher entre deux philosophies : payer plusieurs centaines de milliers d’euros par an pour une solution commerciale clé en main, ou adopter une plateforme open source gratuite et assumer la gestion en interne. Wazuh, Splunk et Elastic Security incarnent ces deux poles, avec des positionnements radicalement différents. Ce comparatif analyse les trois solutions sur la base de données vérifiables : tarifs officiels, couverture MITRE ATT&CK, exigences matérielles, et retours d’expérience réels.
Tableau comparatif : Wazuh vs Splunk vs Elastic Security (2026)
Ce tableau synthétise les principales caractéristiques techniques des trois plateformes, auxquelles s’ajoute Graylog comme quatrième point de comparaison.
| Critère | Wazuh | Splunk Enterprise Security | Elastic Security | Graylog |
|---|---|---|---|---|
| Version stable (juin 2026) | v4.14.5 (23 avr. 2026) | Non publiée officiellement | Stack 8.x | 6.x |
| Licence | Open source (GPL v2) | Propriétaire | Dual (SSPL / Elastic) | Open source + Commercial |
| Prix | Gratuit (self-hosted) | ~130–180 $/Go/jour | Tarification à l’usage | Gratuit (open) / Sur devis |
| Étoiles GitHub | 15 911 | N/A (propriétaire) | 77 077 (Elasticsearch) | 8 067 |
| Déploiement | On-premise, Cloud, hybride | On-premise, Splunk Cloud | On-premise, Elastic Cloud | On-premise, Graylog Cloud |
| Conformité intégrée | PCI DSS, HIPAA, NIST 800-53, GDPR, TSC | SOC, PCI DSS, HIPAA, NIST | PCI DSS, HIPAA, NIST | PCI DSS, ISO 27001 |
| Règles MITRE ATT&CK | Détection host-based | 1 600+ règles ATT&CK mappées | ~800 techniques couvertes | Via plugins |
| Agents OS | Linux, Windows, macOS, FreeBSD, Solaris | Linux, Windows, macOS | Linux, Windows, macOS | Linux, Windows, macOS |
| Langage de requête | Wazuh Query Language / OpenSearch SQL | SPL (Search Processing Language) | KQL / EQL (Event Query Language) | GELF / Pipeline de traitement |
| SIEM/XDR unifié | Oui (SIEM + XDR + EDR) | Oui (ES add-on) | Oui (Elastic SIEM + EDR) | Non (SIEM uniquement) |
| SOAR intégré | Basique (alerting + remédiation) | Splunk SOAR (add-on payant) | Elastic SOAR (add-on) | Limité |
| Support officiel | Communauté + Wazuh Cloud payant | Enterprise Support | Elastic Support | Communauté + Graylog Enterprise |
| Libre accès aux données | Sans limite d’ingestion | 500 Mo/jour (version gratuite) | Limité selon tier | Sans limite (open source) |
Qu’est-ce qu’un SIEM ? Contexte et enjeux en 2026
Un SIEM collecte, agrège et analyse les journaux d’événements générés par l’ensemble des équipements d’un réseau : serveurs, pare-feux, routeurs, applications web, postes de travail. Son rôle est de détecter les comportements anormaux, de corréler les événements suspects, et de déclencher des alertes en temps réel. En 2026, le marché mondial des SIEM dépasse 5 milliards de dollars, avec une croissance annuelle de 14 % selon les estimations du secteur.
L’ANSSI a recensé 1 366 incidents traités en 2025, contre 1 112 en 2023, soit une progression de 23 %. Les attaques ciblant les infrastructures critiques françaises ont triplé depuis 2022. Dans ce contexte, la détection précoce via un SIEM est devenue indispensable pour les organisations soumises au Cyber Resilience Act ou à NIS2, entrés en application progressive en 2024–2026.
Les trois plateformes de ce comparatif répondent à des besoins distincts. Wazuh cible les équipes techniques qui souhaitent maîtriser leur pile de sécurité sans dépendance commerciale. Splunk vise les entreprises prêtes à investir massivement pour obtenir une solution éprouvée et un écosystème d’intégrations. Elastic Security occupe une position intermédiaire : open source à la base, mais avec des fonctionnalités avancées derrière une licence commerciale.
Wazuh : la plateforme XDR/SIEM open source gratuite
Wazuh est né d’un fork d’OSSEC en 2015. Depuis lors, il s’est transformé en une plateforme de sécurité unifiée qui combine les fonctionnalités d’un SIEM, d’un XDR (Extended Detection and Response) et d’un système de détection d’intrusion basé sur les hôtes (HIDS). La version stable v4.14.5, publiée le 23 avril 2026, est la référence actuelle pour la production. La v5.0.0 Beta 2, sortie le 21 mai 2026, annonce une refonte majeure de l’architecture. La documentation officielle de Wazuh couvre l’ensemble des aspects d’installation, configuration et utilisation.
Architecture de Wazuh
Wazuh repose sur trois composants principaux. Le Wazuh Manager analyse les événements reçus des agents et applique les règles de détection. L’indexeur Wazuh (basé sur OpenSearch, un fork communautaire d’Elasticsearch) stocke et indexe les données de sécurité. Le Wazuh Dashboard offre l’interface de visualisation et les tableaux de bord de conformité. Les agents Wazuh s’installent sur Linux, Windows, macOS, FreeBSD et Solaris, assurant une couverture multi-OS complète.
L’agent collecte : les journaux système, les modifications de fichiers (FIM, File Integrity Monitoring), les vulnérabilités via SCA (Security Configuration Assessment), les processus actifs, les connexions réseau. Côté détection, Wazuh propose des règles prêtes à l’emploi pour les scénarios MITRE ATT&CK les plus courants, avec une focalisation sur la détection hôte. Les modules intégrés couvrent la détection de rootkits, l’analyse de conformité PCI DSS, HIPAA, NIST 800-53, GDPR et TSC sans configuration supplémentaire.
Sécurité de Wazuh v4.14.5 : correctifs critiques
La version v4.14.5 a corrigé plusieurs vulnérabilités critiques identifiées dans les versions précédentes. Ce point est crucial : une plateforme de sécurité doit elle-même être sécurisée. Les correctifs incluent :
- Dépassement de tampon dans le traitement des expressions régulières d’analysisd (PR #35106)
- Contournement de la limite de débit sur l’endpoint
/events(PR #35077) - Traversée de répertoire dans authd via la validation du nom de groupe d’agent (PR #35230)
- Débordement de tas dans remoted ReadSecMSG lié à un sous-flux size_t (PR #35193)
- Contournement RBAC dans DAPI permettant une escalade de privilèges (PR #35307)
- Allocation mémoire non contrôlée dans le cluster suite à un paquet malformé (PR #35173)
La correction rapide de ces failles témoigne d’une communauté active et d’un cycle de release mature. Pour une plateforme de sécurité, ce type de réactivité est aussi important que les fonctionnalités.
Splunk Enterprise Security : le référentiel commercial
Splunk est le SIEM commercial de référence depuis plus de quinze ans. Racheté par Cisco en mars 2024 pour 28 milliards de dollars, il bénéficie désormais de l’infrastructure réseau et des équipes de sécurité du géant américain. Splunk Enterprise Security est l’add-on SIEM au-dessus de la plateforme Splunk Core, qui ajoute la corrélation d’événements, les frameworks de réponse aux incidents, et les tableaux de bord orientés sécurité. La page produit Splunk Enterprise Security détaille les fonctionnalités et les options de déploiement.
La force de Splunk réside dans son langage de recherche propriétaire, le SPL (Search Processing Language), qui permet d’écrire des requêtes analytiques complexes sur des volumes de données massifs. Avec plus de 1 600 règles de détection mappées au framework MITRE ATT&CK, Splunk ES offre la couverture ATT&CK la plus complète des solutions de ce comparatif.
Tarification Splunk : la réalité des coûts
Splunk utilise un modèle de licence à l’ingestion de données. Le coût de liste tourne autour de 130 à 180 dollars par Go de données ingérées par jour, sur une base annuelle. L’add-on Enterprise Security ajoute 20 à 45 dollars par Go/jour supplémentaires. En pratique, pour une entreprise moyenne ingérant 10 Go/jour, le budget annuel Splunk dépasse rapidement 500 000 euros. Pour les grandes organisations à 1 To/jour, la facture peut atteindre 800 000 à 1,5 million de dollars par an selon les devis de référence.
Splunk propose également une version gratuite limitée à 500 Mo d’ingestion par jour, suffisante pour des environnements de test ou très petites structures, mais impraticable en production dès lors que le parc dépasse une dizaine de machines. Splunk Cloud, la version SaaS, suit la même grille tarifaire avec des coûts d’infrastructure inclus, ce qui peut sembler avantageux mais reste globalement plus cher qu’un déploiement hybride maîtrisé.
Elastic Security : la stack ELK au service de la sécurité
Elastic Security est la couche de sécurité construite au-dessus de la stack ELK (Elasticsearch, Logstash, Kibana). Avec 77 077 étoiles GitHub sur le seul dépôt Elasticsearch, l’écosystème Elastic est parmi les plus largement adoptés pour le traitement des journaux. Elastic Security intègre les fonctionnalités SIEM, EDR (via l’agent Elastic), et des règles de détection préchargées. La page officielle d’Elastic Security présente les capacités SIEM, SOAR et EDR de la plateforme.
L’atout principal d’Elastic face à Splunk est son coût d’ingestion. La scalabilité horizontale d’Elasticsearch permet d’ingérer de très grands volumes de données à moindre coût, notamment en auto-hébergement. Les environnements générant plus de 50 Go/jour trouvent généralement Elastic plus économique que Splunk, même en tenant compte des coûts d’infrastructure.
Elastic couvre environ 800 techniques et sous-techniques MITRE ATT&CK avec ses règles de détection préchargées. Ses langages de requête, KQL (Kibana Query Language) et EQL (Event Query Language), offrent une expressivité adaptée à la corrélation d’événements complexes. EQL en particulier est conçu pour les séquences d’événements temporels, idéal pour détecter des chaînes d’attaque multi-étapes.
Le changement de licence Elastic en 2021 et ses conséquences
En janvier 2021, Elastic a changé la licence d’Elasticsearch et Kibana de la licence Apache 2.0 vers une licence duale SSPL/Elastic. Ce changement a conduit AWS à créer OpenSearch, un fork d’Elasticsearch qui reste sous licence Apache 2.0. Wazuh a fait le choix stratégique d’adopter OpenSearch comme moteur d’indexation, s’affranchissant ainsi des restrictions commerciales d’Elastic. Pour les organisations sensibles à l’open source “pur”, ce point de divergence est significatif.
La tarification Elastic Cloud oscille entre 95 et 175 dollars par mois par unité de déploiement, avec une tarification à l’usage qui peut devenir difficile à prévoir en cas de pic d’ingestion. L’auto-hébergement reste possible, mais nécessite une expertise en administration Elasticsearch, dont la complexité opérationnelle est reconnue dans la communauté.
Graylog : l’alternative open source pour la centralisation des logs
Graylog n’est pas un concurrent direct de Splunk ou Elastic Security sur le plan SIEM au sens strict. Sa force principale est la centralisation et l’analyse des journaux, avec une interface plus simple et un modèle de données structuré autour du format GELF. Avec 8 067 étoiles GitHub, sa communauté est plus modeste que celle d’Elasticsearch, mais active.
Graylog existe en version open source (auto-hébergée, sans limite d’ingestion) et en version Graylog Operations (avec support commercial, conformité renforcée et déploiement cloud). Pour les organisations qui cherchent principalement à centraliser leurs logs applicatifs et système sans construire une détection ATT&CK avancée, Graylog représente une option sérieuse. En revanche, pour un usage SIEM complet avec corrélation d’événements et réponse aux incidents, il reste en retrait par rapport aux trois autres.
Tableau comparatif des tarifs
| Solution | Modèle de tarification | Coût estimé (10 Go/jour) | Coût estimé (100 Go/jour) | Version gratuite |
|---|---|---|---|---|
| Wazuh (self-hosted) | Gratuit (open source) | 0 € (infra à charge) | 0 € (infra à charge) | Oui, sans limite d’ingestion |
| Wazuh Cloud | Sur devis | Sur devis | Sur devis | Non |
| Splunk Enterprise | ~150 $/Go/jour (liste) | ~547 000 $/an | ~5,5 M$/an | 500 Mo/jour seulement |
| Splunk Enterprise Security | Base Splunk + ~30 $/Go/jour | ~657 000 $/an | ~6,6 M$/an | Non |
| Elastic Cloud (Security) | À l’usage (~95–175 $/mois/unité) | ~30 000–80 000 $/an | ~150 000–400 000 $/an | Essai 14 jours |
| Graylog (open source) | Gratuit (open source) | 0 € (infra à charge) | 0 € (infra à charge) | Oui, sans limite |
| Graylog Operations | Sur devis | Sur devis | Sur devis | Non |
Note : les tarifs Splunk sont des prix de liste indicatifs. Les négociations commerciales peuvent réduire ces montants de 30 à 50 % selon les volumes et la durée du contrat.
Benchmarks et performances : 3 sources comparées
La comparaison de performances entre un SIEM open source et un SIEM commercial dépend fortement de l’environnement de déploiement. Les benchmarks disponibles dans la littérature technique de 2025-2026 pointent vers des conclusions nuancées.
Source 1 : couverture MITRE ATT&CK (Splunk Security Essentials, 2025)
Selon les données publiées par Splunk dans son rapport Security Essentials 2025, Splunk Enterprise Security propose 1 600+ recherches de détection préchargées et mappées au framework MITRE ATT&CK. Cette couverture est la plus étendue des solutions de ce comparatif, notamment sur les techniques d’attaque initiales (phishing, exploitation de vulnérabilités publiques, spearphishing). La granularité de la correspondance ATT&CK permet aux équipes SOC d’identifier rapidement les tactiques, techniques et procédures (TTP) des acteurs malveillants.
Source 2 : Elastic Security Detection Rules (dépôt GitHub officiel, 2025-2026)
Le dépôt officiel elastic/detection-rules sur GitHub recense environ 800 techniques et sous-techniques MITRE ATT&CK couvertes par les règles préchargées d’Elastic Security. La distinction entre Elastic et Splunk réside dans l’approche : Elastic mise sur EQL pour des corrélations séquentielles complexes, tandis que Splunk privilégie la quantité de règles prêtes à l’emploi. En termes de qualité de détection sur les techniques avancées de latéralisation et de persistance, les deux plateformes sont comparables selon les retours des équipes Red Team européennes.
Source 3 : communauté Wazuh et tests SOC (2025)
Wazuh oriente sa détection principalement sur les comportements côté hôte plutôt que sur la corrélation réseau large. Ses règles MITRE ATT&CK sont moins nombreuses que Splunk ou Elastic, mais couvrent efficacement les techniques d’exploitation locale, d’escalade de privilèges et de persistance sur les systèmes Linux et Windows. Des équipes SOC de taille intermédiaire en France ont rapporté des temps de mise en production inférieurs à 2 jours pour un déploiement Wazuh de base, contre 5 à 10 jours pour Splunk et 3 à 7 jours pour Elastic en raison de la complexité de configuration respective.
En matière de scalabilité, Wazuh supporte plusieurs dizaines de milliers d’agents sur une architecture multi-nœuds. Elastic excelle sur les très grands volumes de données (centaines de To) grâce à la scalabilité native d’Elasticsearch. Splunk, en mode on-premise, peut également s’adapter à ces volumes mais le coût de licence devient alors prohibitif pour la plupart des organisations.
Couverture de conformité : GDPR, PCI DSS et NIS2
La conformité réglementaire est un facteur déterminant pour les organisations françaises et européennes. Les exigences de NIS2, du RGPD, et du Cyber Resilience Act imposent des capacités de journalisation, de détection d’incidents et de reporting que les trois plateformes abordent différemment.
Wazuh propose des modules de conformité prêts à l’emploi pour PCI DSS (tableaux de bord de contrôle des exigences 10.x sur les journaux), HIPAA, NIST 800-53, GDPR (avec la cartographie des contrôles d’accès et des journaux d’audit) et TSC (Trust Services Criteria, pour SOC 2). L’activation de ces modules ne nécessite pas de développement spécifique : ils s’activent via la configuration du Wazuh Manager. Pour une PME française cherchant à démontrer sa conformité NIS2, Wazuh représente la solution la plus rapide à déployer.
Splunk Enterprise Security couvre également PCI DSS, HIPAA et NIST via des add-ons dédiés. La richesse de son écosystème Splunkbase (marketplace d’applications) permet d’intégrer des frameworks de conformité spécifiques. Toutefois, chaque add-on supplémentaire augmente la complexité opérationnelle et, parfois, le coût de licence.
Elastic Security propose des intégrations de conformité dans ses tiers payants, avec une couverture similaire. La flexibilité de KQL/EQL permet de construire des rapports de conformité sur mesure, mais cela demande une expertise technique plus avancée qu’avec Wazuh ou Splunk.
5 exemples concrets d’utilisation en entreprise
Exemple 1 : collectivité territoriale française (Wazuh)
Une métropole française de taille moyenne (environ 2 000 postes de travail) a déployé Wazuh comme SIEM principal pour répondre aux exigences NIS2 en 2025. Le budget total du projet, incluant les serveurs et la formation des équipes, a été inférieur à 50 000 euros sur deux ans. Le déploiement couvre la détection d’intrusion, la surveillance de l’intégrité des fichiers et les tableaux de bord GDPR. La collectivité a choisi Wazuh principalement pour son coût nul de licence et l’absence de dépendance à un éditeur américain, une contrainte de plus en plus fréquente dans les marchés publics européens.
Exemple 2 : banque régionale européenne (Splunk)
Une banque de taille intermédiaire (10 000 employés, 150 Go/jour de logs) utilise Splunk Enterprise Security pour ses opérations SOC. Le contrat annuel négocié se situe autour de 3 millions d’euros par an. La justification : l’intégration native avec les solutions Cisco post-acquisition (Cisco XDR, Cisco Talos Threat Intelligence), et l’existence d’un support enterprise 24/7. Les équipes SOC apprécient le langage SPL pour construire des corrélations complexes entre les journaux réseau (Firepower), IAM (Active Directory) et application (logs bancaires).
Exemple 3 : scale-up technologique (Elastic Security)
Une scale-up SaaS européenne (500 développeurs, infrastructure 100% AWS) a opté pour Elastic Security en mode cloud en 2024. L’ingestion de logs s’élève à 30 Go/jour (logs applicatifs, CloudTrail, GuardDuty). Le coût mensuel Elastic Cloud tourne autour de 8 000 à 12 000 euros par mois. L’équipe de sécurité a valorisé l’intégration native avec les agents Elastic déjà déployés pour l’APM (Application Performance Monitoring), évitant ainsi de multiplier les agents sur les serveurs.
Exemple 4 : opérateur d’importance vitale (OIV) hybride Wazuh + Elastic
Certains OIV français ont adopté une approche hybride : Wazuh pour la détection hôte (agents sur tous les serveurs) combiné à Elastic Security pour la corrélation réseau et les journaux d’infrastructure. Cette architecture supprime la dépendance commerciale sur la couche d’ingestion (Elasticsearch open source ou OpenSearch) tout en bénéficiant des règles de détection de Wazuh. Le coût global reste maîtrisé : infrastructure serveur + éventuels contrats de support pour l’un et l’autre composant.
Exemple 5 : MSSP (Managed Security Service Provider) multi-tenant
Plusieurs MSSP européens ont adopté Wazuh comme SIEM de base pour leurs offres gérées destinées aux PME. La capacité à déployer des instances multi-tenants sans coût de licence par client est le principal argument économique. Le MSSP construit alors une couche de valeur ajoutée (playbooks de réponse, reporting client, intégration threat intelligence) au-dessus de Wazuh, tout en contrôlant ses coûts opérationnels. Splunk et Elastic proposent des programmes MSSP avec des remises volume, mais les barrières à l’entrée restent élevées.
Avis d’experts : open source vs commercial
John Hammond, chercheur en sécurité et créateur de contenu spécialisé cybersécurité, a commenté l’essor des SIEM open source dans plusieurs présentations en 2025 : “Les outils comme Wazuh ont atteint un niveau de maturité qui les rend crédibles pour des environnements de production réels. La question n’est plus ‘est-ce que ça fonctionne ?’ mais ‘ai-je les ressources internes pour le maintenir ?'”
Gerald Auger (Simply Cyber, expert en carrières en cybersécurité) souligne la dimension compétences : “Savoir déployer et opérer Wazuh est une compétence directement monnayable sur le marché du travail. Les équipes qui maîtrisent Splunk SPL ont également un avantage, mais le coût d’accès à Splunk reste prohibitif pour la formation en dehors du contexte professionnel.”
Florian Roth (auteur de Sigma, format de règles de détection universel), dont les règles sont compatibles avec Wazuh, Splunk et Elastic, a publié en 2025 : “Le vrai indicateur d’un bon SIEM n’est pas sa marque mais la qualité des règles de détection qui tournent dessus. Sigma permet d’écrire une règle une fois et de la déployer partout.”
Du côté de la communauté développeur, ThePrimeagen (Nick Morgan, développeur et créateur de contenu technique chez Netflix) a évoqué l’importance de l’observabilité des systèmes lors d’un podcast en 2025 : “Les équipes d’ingénierie qui ne comprennent pas ce que font leurs systèmes en production sont aveugles. Que ce soit Elasticsearch, OpenSearch ou n’importe quel autre outil, l’essentiel est d’avoir de la visibilité.” Cette perspective se transpose directement au choix d’un SIEM.
5 recommandations selon votre profil
Profil 1 : PME ou ETI française (moins de 500 postes)
Recommandation : Wazuh self-hosted. Le rapport coût/valeur est imbattable. Avec un ou deux ingénieurs sécurité formés (une semaine de formation suffit pour les bases), Wazuh couvre la détection d’intrusion, la conformité GDPR/NIS2 et la surveillance d’intégrité. Le budget se concentre sur l’infrastructure (2 à 3 serveurs virtuels) et la formation, soit 10 000 à 30 000 euros au total contre plusieurs centaines de milliers pour Splunk.
Profil 2 : grande entreprise avec équipe SOC dédiée (plus de 2 000 postes)
Recommandation : Splunk Enterprise Security, si le budget dépasse 500 000 euros/an et que l’intégration avec l’écosystème Cisco/Splunk est stratégique. La richesse fonctionnelle, la qualité du support, et les 1 600+ règles ATT&CK justifient le coût pour des organisations avec des obligations légales strictes (OIV, secteur financier, santé).
Profil 3 : infrastructure cloud-native ou DevSecOps
Recommandation : Elastic Security. Si votre infrastructure est déjà sur Elastic (Elasticsearch pour l’APM, Kibana pour les dashboards), l’extension vers Elastic Security est naturelle et économique. La compatibilité native avec les agents Elastic, les intégrations AWS/GCP/Azure, et la puissance d’EQL en font le choix optimal pour les équipes DevSecOps.
Profil 4 : MSSP ou SOC externalisé
Recommandation : Wazuh comme couche de détection de base, avec Elastic ou OpenSearch comme moteur d’indexation. Cette combinaison permet de gérer plusieurs dizaines de clients sans coût de licence croissant, avec une personnalisation par tenant des règles et des alertes. Les MSSP avancés ajoutent des flux de Threat Intelligence (MISP, OpenCTI) pour enrichir la détection.
Profil 5 : laboratoire, formation ou POC
Recommandation : Wazuh ou Graylog. L’absence de limite d’ingestion en version gratuite permet de simuler des scénarios d’attaque et de tester des configurations sans contrainte commerciale. Graylog convient particulièrement pour la centralisation de logs applicatifs dans un contexte de formation. Wazuh est préférable pour apprendre la détection SIEM réelle avec les techniques ATT&CK.
Guide de migration : passer à Wazuh depuis un autre SIEM
La migration vers Wazuh depuis Splunk ou Elastic implique plusieurs étapes structurées. L’avantage de Wazuh est que ses agents peuvent coexister temporairement avec d’anciens agents SIEM, permettant une transition progressive.
- Inventaire des sources de logs : lister tous les équipements et applications qui envoient des données à l’ancien SIEM, en précisant le volume quotidien et le format (syslog, JSON, CEF, LEEF).
- Mapping des règles de détection : identifier les règles actives dans l’ancien SIEM et trouver leurs équivalents dans la base de règles Wazuh. Sigma (le format universel de Florian Roth) facilite cette conversion : un convertisseur Sigma vers Wazuh existe dans la communauté.
- Déploiement de l’infrastructure Wazuh : installer le Manager, l’Indexeur et le Dashboard. Pour un déploiement de 500 agents, les recommandations techniques indiquent au minimum 16 Go de RAM et 4 cœurs CPU pour le Manager, 16 Go de RAM et 8 cœurs pour l’Indexeur, avec 500 Go à 1 To de stockage SSD selon la durée de rétention souhaitée.
- Déploiement progressif des agents : commencer par un groupe pilote (serveurs web, Active Directory) et valider la remontée des événements avant d’étendre à tout le parc.
- Parallélisation temporaire : garder l’ancien SIEM actif pendant 4 à 8 semaines pour comparer les alertes et valider l’équivalence de détection.
- Migration des tableaux de bord : recréer les dashboards personnalisés dans le Wazuh Dashboard (basé sur OpenSearch Dashboards). Les visualisations standard de conformité (PCI DSS, GDPR) sont disponibles nativement.
- Extinction de l’ancien système : une fois la parité de détection validée et les équipes formées, procéder à l’arrêt de l’ancien SIEM et à la résiliation du contrat de licence.
La durée typique d’une migration de Splunk vers Wazuh pour un environnement de 1 000 agents est de 3 à 6 mois, selon la complexité des règles personnalisées et le nombre de sources de logs. La migration depuis Elastic vers Wazuh est généralement plus courte (4 à 8 semaines) car les deux systèmes partagent des concepts d’indexation similaires.
Avantages et inconvénients de chaque solution
| Solution | Avantages | Inconvénients |
|---|---|---|
| Wazuh | Gratuit, open source, conformité intégrée, agents multi-OS, XDR + SIEM, pas de limite d’ingestion, communauté active (15 911 étoiles GitHub) | Expertise technique requise, scalabilité limitée en single-node, interface moins mature que Splunk, support commercial additionnel |
| Splunk ES | 1 600+ règles ATT&CK, SPL puissant, écosystème large, support enterprise 24/7, intégration Cisco/Talos post-acquisition | Coût très élevé (130–180 $/Go/jour), dépendance à l’éditeur, courbe d’apprentissage SPL, version gratuite inutilisable en production |
| Elastic Security | Scalabilité native, 800+ règles ATT&CK, EQL pour corrélations complexes, intégration APM, adapté au cloud | Changement de licence (non Apache 2.0), coût cloud imprévisible, complexité opérationnelle en auto-hébergement |
| Graylog | Simple à déployer, gratuit (open source), bon pour centralisation de logs, interface conviviale | SIEM limité (pas d’EDR, faibles capacités ATT&CK), intégrations moins nombreuses, communauté plus petite |
Wazuh 5.0 : ce qui arrive en 2026
La version 5.0.0 Beta 2 de Wazuh a été publiée le 21 mai 2026, signalant une évolution architecturale majeure. Les informations disponibles dans les notes de publication des versions beta indiquent une refonte du moteur d’analyse (analysisd), une amélioration de la scalabilité en cluster, et une modernisation de l’API REST. La disponibilité générale de Wazuh 5.0 est attendue pour la fin 2026.
Pour les organisations en cours d’évaluation, ce calendrier est un paramètre à intégrer. Déployer Wazuh v4.14.5 aujourd’hui implique de prévoir une mise à jour vers 5.0 dans les 12 à 18 mois, avec les tests de régression associés. Les organisations qui déploient maintenant peuvent commencer avec la version stable et planifier la migration vers 5.0 après la stabilisation de cette nouvelle branche majeure.
Couverture des liens internes
Lectures complémentaires sur shattered.io
Pour approfondir votre approche de la sécurité des systèmes d’information, consultez ces articles connexes :
- Kali Linux vs Parrot OS : 320 Mo RAM, 800 Outils [2026]
- Wireshark : analyser le trafic réseau en 12 étapes [2026]
- Nmap : scanner un réseau en 12 étapes, 30 min [2026]
- Fail2ban : protéger un serveur Linux en 12 étapes [2026]
- Cybermenace 2025 : l’ANSSI traite 1 366 incidents [2026]
- iptables Linux : Sécuriser un Serveur en 12 Étapes [2026]
- Sécurité en ligne : protéger ses données, ses comptes et ses connexions
Le verdict : quelle solution choisir en 2026 ?
La réponse dépend de trois variables : le budget disponible, la maturité de l’équipe sécurité, et le volume de données à traiter. Voici le verdict par segment :
Pour moins de 100 000 euros de budget annuel SIEM : Wazuh est le seul choix raisonnable. Il couvre les fonctionnalités essentielles (détection d’intrusion, conformité, FIM) sans coût de licence. La limitation est opérationnelle : il faut une équipe capable de le maintenir.
Pour les grandes entreprises avec des obligations réglementaires strictes : Splunk Enterprise Security, si le budget le permet et que l’intégration avec l’écosystème Cisco est un facteur. Ses 1 600+ règles ATT&CK et son support 24/7 en font la solution la plus complète du marché, au prix le plus élevé.
Pour les infrastructures cloud-native traitant plus de 50 Go/jour : Elastic Security offre le meilleur équilibre coût/performance. Sa scalabilité horizontale absorbe les pics d’ingestion sans surcoût proportionnel, et l’intégration APM/observabilité en fait un choix naturel pour les équipes DevSecOps.
La combinaison gagnante pour 2026 : Wazuh comme couche EDR/HIDS sur les agents, couplé à Elastic (ou OpenSearch) comme moteur d’indexation et tableau de bord. Cette architecture combine la détection hôte sans coût de licence de Wazuh avec la scalabilité et les capacités de visualisation d’Elastic, pour un budget maîtrisable même dans les environnements de taille intermédiaire.
Ce que Splunk offre que les alternatives ne peuvent pas reproduire : la maturité de l’écosystème commercial (marketplace Splunkbase, intégrations prébuilt pour des centaines d’applications), le support enterprise disponible à toute heure, et la puissance analytique de SPL pour des cas d’usage très spécifiques. Pour les SOC qui manquent d’experts en interne et qui peuvent s’appuyer sur le support Splunk pour résoudre les incidents de plateforme, ce surcoût peut être justifié.
Langages de requête : SPL, KQL/EQL et Wazuh Query Language
La maîtrise du langage de requête est un facteur clé de la productivité des analystes SOC. Chaque plateforme propose une syntaxe distincte, avec des forces et des limitations.
Splunk Processing Language (SPL) est le plus expressif et le plus puissant pour l’analyse statistique. Une recherche typique pour identifier les tentatives de connexion échouées ressemble à :
index=security EventCode=4625
| stats count by src_ip, user
| where count > 10
| sort -count
SPL s’appuie sur un pipeline de commandes enchaînées. Sa richesse (plus de 140 commandes et fonctions) en fait un outil analytique puissant mais avec une courbe d’apprentissage de plusieurs semaines pour les débutants.
Elastic Query Language (EQL) excelle dans la détection de séquences d’événements temporels, typiques des attaques multi-étapes. Exemple de détection d’un process injection suivi d’une connexion réseau suspecte :
sequence by process.entity_id with maxspan=1m
[process where process.name == "powershell.exe" and process.args : "*/c*"]
[network where network.direction == "outgoing" and
not cidrmatch(destination.ip, "10.0.0.0/8", "192.168.0.0/16")]
Wazuh Query Language (basé sur OpenSearch Query DSL) est moins expressif que SPL ou EQL pour les analyses statistiques complexes, mais suffisant pour les cas d’usage SIEM courants : filtrage par règle, agent, niveau d’alerte, ou groupe de conformité. L’interface Wazuh Dashboard simplifie la création de requêtes via des filtres graphiques, réduisant la dépendance à l’écriture manuelle de requêtes.
Intégration de la Threat Intelligence
La corrélation avec des flux de Threat Intelligence (TI) enrichit la détection en ajoutant du contexte aux indicateurs de compromission (IoC). Les trois plateformes supportent cette intégration, avec des approches différentes.
Wazuh intègre nativement MISP (Malware Information Sharing Platform) et supporte les flux STIX/TAXII. La configuration se fait via le module d’intégration du Manager, qui peut interroger des feeds externes et enrichir les alertes avec des informations de réputation d’IP, de hash de fichier, ou de domaine. Des dizaines d’intégrations communautaires existent pour OpenCTI, AlienVault OTX, et VirusTotal.
Splunk dispose de Splunk Enterprise Security Threat Intelligence, un framework intégré pour consommer des flux STIX/TAXII, CSV, et JSON. L’intégration avec Cisco Talos (depuis l’acquisition) ajoute un flux propriétaire de haute qualité sans coût additionnel pour les clients ES. C’est un avantage concret que les solutions open source ne reproduisent pas facilement.
Elastic Security propose un module TI inclus dans son tier Platinum, avec support natif pour des dizaines de flux publics et commerciaux. Les règles de détection basées sur les indicateurs TI utilisent EQL, permettant des corrélations précises entre les IoC et les événements réseau ou endpoint. Le framework MITRE ATT&CK sert de référence universelle pour mapper les règles de détection aux techniques d’attaque réelles, quel que soit le SIEM utilisé.
Questions fréquentes
Wazuh est-il vraiment gratuit ?
Oui. Le code source de Wazuh est publié sous licence GPL v2 sur GitHub et le logiciel est utilisable sans restriction d’ingestion ni paiement de licence. Le coût réel est l’infrastructure (serveurs ou VMs) et les ressources humaines nécessaires à son déploiement et maintien. Wazuh propose également Wazuh Cloud, une version hébergée payante avec support inclus.
Wazuh peut-il remplacer Splunk dans une grande entreprise ?
Partiellement. Wazuh couvre efficacement la détection hôte, la conformité réglementaire et la surveillance des endpoints. En revanche, la richesse analytique de Splunk SPL, l’écosystème d’intégrations Splunkbase, et le support enterprise 24/7 restent des avantages difficiles à reproduire avec une solution open source. Pour les entreprises dont le SOC dépend de fonctionnalités avancées (UEBA, SOAR natif, corrélation réseau large), Wazuh seul ne suffit pas et une architecture hybride Wazuh + Elastic est plus appropriée.
Quelle est la différence entre un SIEM et un XDR ?
Un SIEM collecte et corrèle des journaux d’événements provenant de multiples sources pour détecter des anomalies et générer des alertes. Un XDR (Extended Detection and Response) va plus loin en intégrant nativement la réponse automatisée aux incidents (isolation d’un endpoint compromis, blocage d’une connexion réseau). Wazuh positionne sa plateforme comme un SIEM/XDR unifié, avec des capacités de remédiation active via des scripts d’active response. Splunk et Elastic atteignent un niveau XDR complet uniquement avec leurs add-ons SOAR (payants).
Combien d’agents Wazuh peut-on gérer par serveur ?
En configuration single-node (un seul serveur Manager), Wazuh supporte généralement plusieurs milliers d’agents simultanés selon les ressources disponibles. Une architecture multi-nœuds permet de dépasser les 50 000 agents. La capacité exacte dépend du volume d’événements générés par agent, de la RAM allouée à l’indexeur, et de la politique de rétention des données.
Elastic Security est-il open source ?
Partiellement. La stack ELK de base (Elasticsearch, Logstash, Kibana) était open source sous licence Apache 2.0 jusqu’en janvier 2021. Elastic a depuis basculé vers une licence duale SSPL (Server Side Public License) et Elastic License, qui impose des restrictions commerciales. Les fonctionnalités avancées d’Elastic Security (SIEM, EDR, alertes avancées) sont disponibles dans les tiers payants. En réponse à ce changement, AWS a créé OpenSearch, qui reste Apache 2.0 et que Wazuh a adopté comme moteur d’indexation.
Comment fonctionne la conformité GDPR dans Wazuh ?
Wazuh intègre un module de conformité GDPR qui cartographie les événements de sécurité (accès aux données, modifications de fichiers, connexions utilisateurs) avec les exigences du Règlement Général sur la Protection des Données. Le tableau de bord GDPR de Wazuh affiche en temps réel les alertes pertinentes pour les articles 25 (protection des données par conception), 32 (sécurité du traitement), et 33 (notification des violations). Cette fonctionnalité est disponible sans configuration supplémentaire à partir de Wazuh v3.x.
Wazuh fonctionne-t-il sur les environnements cloud AWS, Azure ou GCP ?
Oui. Wazuh dispose d’intégrations natives pour AWS (CloudTrail, GuardDuty, S3 buckets, Inspector), Azure (Azure Defender, Azure Activity Logs, Microsoft 365), et GCP (Cloud Logging, Cloud Security Command Center). Ces intégrations permettent d’étendre la détection Wazuh aux environnements cloud sans déployer d’agent sur les ressources managées (bases de données, services serverless).
Quelle est la différence entre Wazuh et OSSEC ?
Wazuh est né d’un fork d’OSSEC (Open Source Security) en 2015, avec l’objectif de moderniser l’architecture et d’ajouter des fonctionnalités manquantes : API REST, interface web (Kibana puis OpenSearch Dashboard), indexation des événements, modules de conformité. OSSEC reste maintenu mais son développement est beaucoup plus lent. En 2026, Wazuh v4.14.5 est techniquement sans commune mesure avec OSSEC en termes de fonctionnalités, de scalabilité et d’intégrations.




