Détection-Ingénierie sans verrouillage fournisseur : Wazuh-Stack 2026

8 min de lecture

Les contrats SIEM des grands fournisseurs seront renégociés au cours des deux prochaines années dans de nombreuses équipes de sécurité DACH. Ceux qui prennent la date de renouvellement comme une opportunité ne cherchent pas seulement un fournisseur moins cher, mais aussi une architecture qui ne dépend pas d’un fournisseur unique. Wazuh, Sigma et Shuffle ne sont pas un simple stack marketing, mais une option sérieuse, à condition que l’équipe mette honnêtement les compromis sur la table.

Les points clés en bref

L’ingénierie de détection n’est pas une question d’outil, mais une discipline. Wazuh + Sigma + Shuffle ne remplacent pas un SIEM, ils remplacent un certain modèle opérationnel. Ceux qui ne développent pas cette discipline auront les mêmes problèmes qu’avec un fournisseur plus cher.
NIS2 exige l’auditabilité, pas la conformité au fournisseur. Les stacks open-source répondent aux exigences si la traçabilité de l’audit est documentée. L’obstacle réside dans la contribution propre, pas dans le choix de l’outil.
Le calcul du TCO n’est pas trivial. Les coûts de licence diminuent, les efforts en FTE augmentent – souvent pas nettement mieux pour les petites équipes. À partir de trois ingénieurs de détection seniors, le stack devient économique.

RelatedNIS2-Audit : la liste des fournisseurs se brise en 2h / Adaptive MFA : la pression NIS2 comme levier

Pourquoi le Vendor-Lock dans le marché SIEM devient un risque opérationnel

Les renouvellements SIEM dans les PME et les grandes entreprises DACH ont montré un schéma au cours des 18 derniers mois. Les coûts de licence augmentent de deux chiffres, les limites EPS deviennent plus strictes, le volume de journalisation croît plus rapidement que le budget en raison des charges de travail cloud. Ceux qui ont signé un contrat en 2018 paient souvent le double en 2026 pour une architecture nominalement identique.

Le Vendor-Lock n’est pas seulement une question de coûts. Ceux qui ont maintenu 2.000 règles de détection dans un langage de requête propriétaire ne peuvent pas changer sans friction. C’est précisément ce qui fait de l’ingénierie de détection une discipline qui doit être ancrée dans le modèle opérationnel, et non dans un contrat de fournisseur. Ceux qui reportent cela paient le manquement de trois ans lors du renouvellement.

Le cloud hybride n’est pas un modèle architectural, mais la conséquence lorsque deux équipes n’ont pas communiqué à temps. Le Vendor-Lock dans le SIEM est la conséquence lorsque personne ne traite les règles de détection comme un actif indépendant.

La pile en un coup d’œil : Wazuh, Sigma, Shuffle, DFIR-IRIS

La pile open-source discutée ici se compose de quatre composants qui couvrent différentes fonctions. Ils sont ajustables les uns aux autres, mais ne constituent pas une plateforme intégrée au sens d’un SIEM commercial. C’est précisément cette caractéristique qui est à la fois sa force et son défi.

Wazuh constitue la plateforme de détection. Il combine les fonctionnalités HIDS, l’analyse des logs et les rapports de conformité basés sur Elasticsearch, et fournit une interface utilisateur web pour le triage des alertes. Sigma est le standard de règles de détection, formulé de manière indépendante de la plateforme, et peut être traduit en règles Wazuh, règles de détection Elastic ou requêtes Splunk. Shuffle est le composant SOAR qui orchestre les workflows entre la détection, l’enrichissement et la réponse. DFIR-IRIS est l’outil de gestion de cas pour les workflows de réponse aux incidents.

Celui qui entend le terme « agentic-AI-fähig » doit être prudent. Les composants ont des points d’intégration pour l’enrichissement basé sur LLM, mais cela ne fait pas de la pile une plateforme de sécurité autonome. Celui qui utilise des agents IA dans les workflows Shuffle assume également la responsabilité des hallucinations que chaque agent apporte. Celui qui traite les clés KMS comme un menu déroulant n’a soit jamais vécu d’audit, soit n’en a pas eu de bon. La même chose s’applique aux agents IA dans le pipeline de détection.

Avantages et inconvénients dans le tableau honnête

La comparaison honnête entre un SIEM commercial et une pile open-source centrée sur Wazuh présente des compromis clairs, souvent absents des présentations marketing. Celui qui met la table avant la date de renouvellement gagne au moins une base de discussion.

Dimension	Pro Pile Open-Source	Pro SIEM commercial
Coûts de licence	Aucun par EPS, aucun plafond sur le volume de données. Souvent 70 pour cent moins cher en termes de licence pour les configurations cloud-heavy.	Prévisible, avec support de secours. Le rapport trimestriel du fournisseur inclut automatiquement la plupart des exigences d’audit.
Effort FTE	Plus élevé. 2–3 ingénieurs de détection en ligne, un senior pour le rôle de propriétaire de l’architecture.	Plus faible dans les opérations quotidiennes, plus élevé en cas d’escalades avec le fournisseur. La compétence de l’utilisateur avancé est spécifique au fournisseur.
Portabilité de la logique de détection	Les règles Sigma sont agnostiques de la plateforme. Passage à Elastic, Splunk ou Sentinel possible sans perte totale.	Langages de requête propriétaires. La migration coûte typiquement 6–12 mois par portefeuille de détection.
Audit / Conformité NIS2	Réalisable si le audit trail est documenté. Plus d’efforts personnels pour la preuve.	Le fournisseur livre des modules d’audit par défaut. Statut de conformité sur un tableau de bord.
Escalade du support Sev-1	Communauté + abonnement Wazuh payant. Efforts personnels pour les questions d’architecture profondes.	Support fournisseur 24/7, accord de niveau de service contractuel. Le chemin d’escalade est en place.

Le tableau a une conséquence importante. Les piles open-source ne valent pas principalement financièrement, mais stratégiquement. Celui qui considère le Vendor-Lock comme un risque plus grand que la liaison FTE a une réponse. Celui qui pondère le support fournisseur plus haut que la portabilité a une autre réponse. Les deux sont légitimes, les deux ont leurs conséquences.

Trois chiffres que le CISO doit présenter au comité de pilotage

Au sein du comité de pilotage, la discussion sur l’open-source échoue souvent à cause d’un seul chiffre que personne n’a correctement calculé. Trois valeurs sobres aident à mieux définir la réalité.

Réalité opérationnelle

3 FTE

Seuil d’ingénierie de détection. En dessous de trois ingénieurs seniors en détection, la pile open-source devient économiquement risquée. Au-dessus, elle devient productive.

~ 70 %

Économie moyenne sur les licences. Pour les profils de journalisation intensifs en cloud. La moitié de cette économie est réinvestie dans les coûts FTE, le reste est une économie nette.

12 M

Fenêtre de migration. Durée réaliste entre la décision architecturale et la production avec une couverture complète des règles. Ceux qui planifient moins sont malhonnêtes.

Ces chiffres ne sont pas issus d’une étude, ce sont des valeurs d’expérience provenant de migrations productives. Ceux qui ne peuvent pas les mesurer dans leur propre configuration n’ont pas de proposition fiable pour le comité de pilotage. C’est la vérité désagréable. La différence entre « security by design » et « security by incident » est environ une semaine de sommeil. La différence entre « nous réfléchissons à l’open-source » et « nous migrons en 12 mois » repose sur trois chiffres fiables.

Ce que Sigma change en tant que standard de règles

Le changement conceptuel le plus important n’est pas Wazuh, mais Sigma. Les règles de détection deviennent un actif portable, et non un artefact de fournisseur. Une équipe qui travaille en priorité avec Sigma peut exécuter sa logique de détection dans Wazuh, Elastic, Splunk ou Sentinel sans avoir à répéter 80 % du travail.

En pratique, cela signifie une discipline de maintenance. Les règles de détection sont versionnées en Sigma-YAML, gérées dans Git, validées avec des pipelines CI contre des journaux de test, et ensuite seulement traduites dans le langage de la plateforme respective. Cette pipeline est rarement présente dans les piles SIEM classiques, car elle ne semble pas nécessaire. Elle devient nécessaire dès que le fournisseur change.

« Nous avons réécrit le playbook deux fois parce que la première version à 03:40 semble être quelque chose inventé par un département marketing. Nous n’essayons d’écrire les règles Sigma qu’une seule fois. »

Ingénieur senior en détection, groupe industriel DACH, 2026

Quand la pile est rentable, et quand elle ne l’est pas

En pratique, la pile est rentable dans trois configurations. Premièrement : pour les équipes de sécurité composées d’au moins trois ingénieurs seniors qui veulent pratiquer la détection comme une discipline et non seulement comme une question d’outillage. Deuxièmement : pour les PME qui ont une journalisation intensive en cloud et qui suffoquent sous les plafonds SIEM-EPS. Troisièmement : pour les grandes entreprises qui ont fixé la diversification des fournisseurs comme objectif stratégique et qui ne veulent pas dépendre d’un seul fournisseur pour chaque catégorie d’outils.

Elle n’est pas rentable si l’équipe compte moins de deux ingénieurs seniors, si les exigences d’audit nécessitent un rapport de conformité clé en main générable en quatre clics, ou si le modèle opérationnel considère la détection comme une simple livraison de fournisseur. Ceux qui l’oublient se créent une deuxième tâche à temps plein qui n’était pas prévue par le comité de pilotage.

Foire aux questions

Wazuh suffit-il comme unique SIEM pour les entités soumises à NIS2 ?

Techniquement oui, avec les efforts nécessaires. Wazuh répond à la plupart des exigences de détection, de journalisation et de conformité. La conformité NIS2 ne découle pas de l’outil, mais du processus documenté : audit-trail, cadence de reporting, escalade des incidents. Ceux qui ont déjà cela économisent de l’argent. Ceux qui ne l’ont pas encore ne devraient pas combiner le changement de fournisseur avec la mise en place du processus.

Quelle est la complexité de la maintenance des règles Sigma par rapport à un SIEM commercial ?

Initialement beaucoup plus complexe, car la pipeline CI et le test-logging doivent être mis en place. Après 6 à 9 mois, l’effort de maintenance en cours est comparable, car la couverture de test détecte les régressions plus tôt que le cycle de mise à jour du fournisseur.

Combien coûte un stack Wazuh réaliste en exploitation ?

Pour des configurations moyennes (5.000 EPS, 50 capteurs), les coûts d’infrastructure se situent entre 30.000 et 60.000 euros par an, plus 3 ETP pour l’ingénierie de détection. Un SIEM commercial comparable se situe souvent dans le bas de la gamme des six chiffres en termes de licences, plus 1 à 2 ETP. L’équation penche en faveur du stack open-source dès que le volume EPS ou la profondeur de l’audit augmente.

Quel rôle joue DFIR-IRIS par rapport aux outils de gestion de cas commerciaux ?

DFIR-IRIS couvre 80 pour cent de ce qu’un outil de gestion de cas pour le marché intermédiaire peut faire. Les 20 pour cent restants sont souvent des modèles de reporting et une logique SLA préconfigurée. Pour les configurations d’entreprise avec des exigences d’audit strictes, les outils commerciaux restent avantageux, mais pour les PME, DFIR-IRIS est très productif.

Les workflows Shuffle peuvent-ils être combinés avec des outils SOAR commerciaux ?

Oui, via des API REST des deux côtés. En pratique, cela a rarement du sens – l’architecture hybride crée plus de chemins d’escalade qu’elle n’en économise. Soit l’équipe choisit Shuffle comme SOAR principal, soit elle reste avec l’outil commercial. L’hybride est une phase de transition, pas une architecture cible.