Déployer un SIEM en production avec Wazuh : retour d'expérience et utilisation de l'IA comme assistant

Auteur : Ingénieur systèmes & sécurité

Contexte : Migration et maintien en condition opérationnelle d'un SIEM Wazuh en environnement industriel

Date : Février 2026

---

Sommaire

1. Le SIEM : pourquoi, pour qui, comment ?
2. Wazuh : le choix de l'open source assumé
3. Retour d'expérience : migrer et maintenir un SIEM en production
4. L'IA comme copilote : comment j'utilise Claude dans un projet SIEM
5. Ce que j'en retiens

---

1. Le SIEM : pourquoi, pour qui, comment ?

1.1 C'est quoi un SIEM ?

Un SIEM (Security Information and Event Management) est un système centralisé qui collecte, corrèle et analyse les journaux d'événements (logs) de l'ensemble de votre infrastructure informatique. En clair : c'est la tour de contrôle de votre sécurité.

Imaginez un aéroport. Chaque avion (serveur), chaque porte d'embarquement (poste de travail), chaque caméra (pare-feu) génère des données en permanence. Sans tour de contrôle, personne ne voit le tableau d'ensemble. Un SIEM, c'est cette tour de contrôle : il agrège tout, détecte les anomalies, et alerte quand quelque chose ne va pas.

Concrètement, un SIEM :

• Collecte les logs de vos serveurs, postes de travail, pare-feux, applications...
• Normalise ces données hétérogènes dans un format unifié
• Corrèle les événements pour détecter des patterns (un échec de connexion isolé n'est pas un incident — 50 échecs en 2 minutes, c'est une attaque par brute-force)
• Alerte en temps réel quand un comportement suspect est identifié
• Archive les logs pour la conformité réglementaire et l'investigation post-incident

1.2 Pourquoi c'est devenu indispensable ?

Il y a dix ans, un SIEM était un luxe réservé aux grandes entreprises et aux SOC (Security Operations Center). Aujourd'hui, c'est devenu une nécessité pour plusieurs raisons :

La pression réglementaire

• NIS2 (applicable depuis octobre 2024) impose aux entités essentielles et importantes une journalisation des incidents de sécurité avec une rétention minimale de 6 à 12 mois
• NIS2 exige la traçabilité des accès et la capacité de détecter les incidents de sécurité
• ISO 27001 (A.12.4) requiert une gestion formelle des journaux d'événements et leur protection
• Les recommandations ANSSI préconisent un minimum de 12 mois de rétention des logs de sécurité

Sans SIEM, répondre à un audit de conformité relève de l'exercice acrobatique.

Le paysage des menaces

Les attaques ne sont plus l'apanage de groupes étatiques. Les ransomwares-as-a-service (RaaS) ont démocratisé la cybercriminalité. Une PME industrielle est aujourd'hui une cible aussi probable qu'un grand groupe — parfois plus, car elle est perçue comme moins protégée.

Un SIEM ne remplace pas un antivirus ou un pare-feu. Il les complète en offrant une vision transversale : c'est la corrélation entre un accès VPN inhabituel à 3h du matin, une élévation de privilèges sur un serveur de fichiers, et un volume anormal de transfert de données qui permet de détecter une intrusion — pas chaque événement pris isolément.

La réponse à incident

Sans SIEM, une investigation post-incident consiste à se connecter manuellement sur chaque machine, fouiller des fichiers de logs au format différent, tenter de reconstituer une timeline. Avec un SIEM, vous avez l'historique centralisé, indexé et corrélé. La différence entre des jours de travail et quelques heures.

1.3 Qui doit le mettre en place ?

La réponse courte : Toute organisation qui gère des données sensibles, qui est soumise à des obligations réglementaires de journalisation, ou qui souhaite avoir une posture de sécurité proactive.

La réponse pragmatique :

Profil d'organisation	Besoin SIEM	Remarque
TPE (< 20 postes)	Optionnel	Un bon EDR peut suffire, sauf si données très sensibles
PME (50–500 postes)	Recommandé	NIS2 peut s'appliquer ; coût maîtrisable avec l'open source
ETI / Grande entreprise	Indispensable	Obligation réglementaire quasi-systématique
Secteur santé, finance, industrie	Critique	Données réglementées, risque élevé

Qui opère le SIEM au quotidien ?

C'est la question qui fâche. Un SIEM n'est pas un produit "fire and forget". Il nécessite :

• Un administrateur systèmes pour l'installation, les mises à jour, la maintenance de l'infrastructure
• Un analyste sécurité (ou à minima une personne formée) pour interpréter les alertes, ajuster les règles de détection, investiguer les incidents
• Une gouvernance pour définir la politique de rétention, les périmètres surveillés, les seuils d'alerte

Dans une PME, ces trois rôles sont souvent portés par la même personne — l'admin sys/réseau qui porte aussi la casquette sécurité. C'est exactement le contexte de ce retour d'expérience.

---

2. Wazuh : le choix de l'open source assumé

2.1 Pourquoi Wazuh ?

Wazuh est une plateforme SIEM et XDR (Extended Detection and Response) open source, basée sur OSSEC, couplée à OpenSearch (fork d'Elasticsearch) pour l'indexation et la visualisation. Son architecture se compose de trois briques :

Les raisons du choix :

1. Coût de licence : zéro. Pour une PME qui n'a pas le budget d'un Splunk ou d'un QRadar, c'est un argument décisif. Le coût se déplace vers l'infrastructure (serveurs) et le temps humain d'exploitation
2. Capacité XDR native : Wazuh ne se contente pas de centraliser des logs — il embarque la détection d'intrusion (HIDS), le monitoring d'intégrité des fichiers (FIM), l'évaluation de conformité (SCA/CIS Benchmark), la détection de vulnérabilités, et la réponse active
3. Agent multi-plateforme : Windows, Linux, macOS — un seul agent couvre tout le parc
4. Communauté et documentation : La documentation officielle est dense, le GitHub actif, et la communauté Slack/forum réactive
5. Compatibilité réglementaire : Mappings natifs PCI-DSS, HIPAA, GDPR, NIST 800-53 dans le dashboard

2.2 Les points forts en production

Après plus d'un an d'exploitation (v4.8 → v4.12 → v4.14), voici ce qui fait la force de Wazuh au quotidien :

Déploiement massif d'agents simplifié

Le déploiement peut se faire via GPO Active Directory avec un script PowerShell. Sur un parc de ~500 postes Windows, le processus est industrialisable : détection de version, mise à jour automatique, vérification par hash SHA-256, rollback si échec. En quelques jours, l'ensemble du parc est sous surveillance.

Détection out-of-the-box pertinente

Wazuh arrive avec des milliers de règles de détection pré-configurées. Dès le premier jour, vous détectez :

• Les tentatives de brute-force (SSH, RDP, authentification Windows)
• Les modifications de fichiers critiques (hosts, registre, configurations système)
• Les installations de logiciels non autorisés
• Les élévations de privilèges suspectes
• Les événements de sécurité Windows (EventLog) corrélés

Personnalisation poussée

Le moteur de règles XML permet de créer des règles sur mesure pour votre contexte. Intégrer un pare-feu tiers (Stormshield, Fortinet, Palo Alto...) demande du travail de décodage, mais c'est faisable — et le résultat est une corrélation pare-feu + endpoints + serveurs dans une seule console.

Architecture évolutive

Un cluster mono-noeud suffit pour un parc de quelques centaines d'agents. Besoin de monter en charge ? Wazuh supporte le multi-noeud, le load balancing, les workers dédiés.

2.3 Les points faibles — soyons honnêtes

Aucune solution n'est parfaite. Voici les irritants réels rencontrés en production :

La courbe d'apprentissage

Wazuh est puissant, mais il n'est pas plug-and-play. Entre la configuration du Manager (ossec.conf), la syntaxe XML des règles/decoders, la gestion d'OpenSearch (ISM policies, shards, templates), et l'administration Linux sous-jacente — le spectre de compétences requis est large.

Il n'y a pas d'assistant graphique pour créer une règle de détection custom. Tout passe par l'édition de fichiers XML, le test en ligne de commande, et le redémarrage du service. C'est efficace mais exigeant.

La gestion des mises à jour

Les montées de version majeures (ex : 4.12 → 4.14) ne sont pas anodines. Il faut mettre à jour le Manager, l'Indexer, le Dashboard et le module Filebeat dans le bon ordre, avec des risques de régression (heap JVM réinitialisé, certificats cassés, configurations écrasées). La documentation officielle est bonne, mais chaque environnement a ses particularités.

Les agents déployés doivent aussi être mis à jour — et sur un parc hétérogène, c'est un projet en soi.

Le Dashboard (OpenSearch Dashboards)

Le Dashboard est fonctionnel mais perfectible :

• L'interface est parfois lente sur de gros volumes de données
• La création de visualisations personnalisées demande de maîtriser le langage de requête OpenSearch
• Certaines actions d'administration (gestion RBAC, rôles réservés) ne sont pas réalisables via l'interface et nécessitent des outils en ligne de commande

La gestion des agents à grande échelle

Au-delà de quelques centaines d'agents, des problèmes émergent :

• Les conflits d'enregistrement (même nom de machine, clés dupliquées) génèrent des warnings en continu
• Les agents déconnectés s'accumulent et polluent la vue opérationnelle
• Il n'existe pas de mécanisme natif robuste de ré-enregistrement automatique en cas de réinstallation d'un poste

Le stockage est vorace

Chaque agent génère des alertes quotidiennement. Sur ~500 agents, cela représente plusieurs Go par jour d'index. Sans politique de rétention (ISM), les shards s'accumulent et on atteint rapidement les limites du cluster. C'est gérable, mais il faut l'anticiper dès le jour 1.

2.4 Wazuh vs. les alternatives

Critère	Wazuh	Splunk	Elastic SIEM	Microsoft Sentinel
Coût licence	Gratuit	$$$$	Gratuit (basic) / $$$ (enterprise)	$$$ (au Go ingéré)
XDR intégré	Oui	Non (add-ons)	Partiel	Oui (via Defender)
On-premise	Oui	Oui	Oui	Cloud uniquement
Agents natifs	Oui	Universal Forwarder	Elastic Agent	Microsoft Defender
Communauté	Active	Large	Très large	Microsoft ecosystem
Courbe d'apprentissage	Moyenne-haute	Haute	Haute	Moyenne
Adapté PME	Excellent	Non (coût)	Possible	Si déjà Azure

Wazuh est le choix le plus pertinent pour une PME/ETI qui veut un SIEM complet, on-premise, sans coût de licence, et qui dispose d'au moins une personne compétente en administration Linux.

---

3. Retour d'expérience : migrer et maintenir un SIEM en production

3.1 Le contexte

L'infrastructure que je gère est celle d'une entreprise industrielle d'environ 500 collaborateurs. Le SIEM surveille un parc de ~500 agents (postes Windows, serveurs) via un cluster Wazuh dédié composé de trois serveurs :

Rôle	RAM	Stockage	Fonction
Indexer	128 Go	~40 To RAID5	Stockage et indexation OpenSearch
Manager	32 Go	~2 To	Réception des logs, corrélation, alertes
Dashboard	8 Go	250 Go NVMe	Interface web de visualisation

Le SIEM était initialement déployé en version 4.8 (mi-2024), migré en 4.12 (fin 2024), puis en 4.14 (janvier 2026). C'est cette dernière migration et les maintenances qui ont suivi qui font l'objet de ce retour d'expérience.

3.2 La migration majeure : de 4.12 à 4.14

Pourquoi migrer ?

• Correctifs de sécurité critiques
• Nouvelles fonctionnalités de détection
• Support étendu et compatibilité des agents récents
• Fin de support progressive des anciennes versions

Ce qui s'est bien passé :

• Migration composant par composant (Indexer → Manager → Dashboard → Filebeat) selon la procédure officielle
• Cluster resté GREEN tout au long du processus
• Aucune perte de données
• Récupération de ~600 Go d'espace disque grâce à la relocalisation des données sur le RAID

Ce qui a posé problème :

Problème	Cause	Résolution
Dépôt Wazuh inaccessible	Certificat du proxy manquant	Installation du CA sur les 3 serveurs
OutOfMemoryError sur l'Indexer	La mise à jour avait réinitialisé le heap JVM à 1 Go (au lieu de 64 Go)	Restauration manuelle de la configuration JVM
Doublons dans les fichiers de liste	Script de configuration qui concaténait au lieu d'écraser	Nettoyage et correction de la procédure

3.3 Les maintenances correctives — le vrai travail

La migration n'est que le début. En 6 semaines, j'ai enchaîné 7 maintenances correctives majeures. Voici les plus instructives.

Maintenance #1 : La sécurité OpenSearch cassée

Symptôme : Après la migration, impossible de modifier quoi que ce soit dans le Dashboard — erreur "Forbidden" partout.

Diagnostic : Un script d'initialisation de sécurité avait été exécuté sans les prérequis. Les mappings utilisateurs/rôles étaient corrompus, et Java n'était même pas installé sur l'Indexer — ce qui faisait échouer silencieusement l'outil securityadmin.sh.

Résolution :

1. Installation de Java (OpenJDK 17)
2. Reconfiguration complète de l'index de sécurité OpenSearch via securityadmin.sh
3. Réactivation de l'authentification Dashboard ↔ Indexer

Maintenance #2 : La bombe à retardement des shards

Symptôme : En surveillant le cluster, je constate ~900 shards actifs sur une limite de 1 000.

Diagnostic : Le template Wazuh par défaut crée 3 shards par index. Avec un index par jour, cela fait 3 x 365 = 1 095 shards par an — largement au-dessus de la limite. Le cluster allait être saturé en ~30 jours.

Résolution :

1. Augmentation temporaire de max_shards_per_node à 2 000 (le temps de la transition)
2. Création d'un template override (priorité supérieure) qui force 1 shard par index au lieu de 3
3. Nouvelle projection : 365 shards/an au lieu de 1 095

La transition est transparente : les anciens index gardent leurs 3 shards (ils seront supprimés par la politique de rétention), les nouveaux sont créés avec 1 shard. En ~9 mois, le parc de shards est entièrement optimisé.

Maintenance #3 : L'intégration d'un pare-feu tiers

Objectif : Intégrer les logs d'un pare-feu Stormshield SNS 4.x dans le SIEM.

C'est typiquement le genre de tâche qui illustre la puissance — et la complexité — de Wazuh. Il a fallu :

1. Construire l'infrastructure de transport : rsyslog avec TLS (certificats PKI dédiés), rate limiting (5 000 msg/sec), file d'attente (50 000 messages)
2. Écrire les decoders : 6 catégories de logs Stormshield (firewall, authentification, VPN, système, alarmes IPS, services) avec extraction de champs
3. Écrire les règles de détection : ~40 règles couvrant les événements critiques (blocage, brute-force, failover HA, attaques IPS soutenues...)
4. Gérer le volume : Un pare-feu peut générer 20 à 50 Go de logs par jour. Activation progressive par catégorie, avec les règles "pass" (trafic autorisé) désactivées dans un premier temps

Maintenance #4 : L'archivage chiffré conforme NIS2

Objectif : Mettre en place un archivage à froid chiffré avec une rétention de 3 ans.

Architecture déployée :

Détails techniques de l'archive froide :

• Volume chiffré de ~15 To (fichier sparse LUKS2, AES-256-XTS)
• Clé de chiffrement de 4 096 octets, stockée en permissions 400 (root uniquement)
• Montage automatique au démarrage via crypttab + fstab
• Snapshots hebdomadaires automatisés (cron, dimanche 2h)
• Nettoyage automatique des snapshots de plus de 3 ans
• Journalisation de chaque opération de snapshot

Conformité atteinte :

Réglementation	Exigence	Implémentation
NIS2	6–12 mois de rétention	365 jours live + snapshots
NIS2	Protection au repos	AES-256-XTS
ANSSI	12 mois minimum	365 jours indexés
NIS2	Minimisation des données	Suppression auto après 3 ans
ISO 27001	Sauvegardes automatisées	Snapshots hebdomadaires + ISM

3.4 Bilan des maintenances

En 6 semaines, 7 maintenances correctives totalisant ~30 heures de travail :

#	Sujet	Durée	Criticité
1	Remédiation RBAC OpenSearch	~4h	Critique
2	Synchronisation temporelle (NTP/Chrony)	~4h	Haute
3	Gestion des droits admin + santé cluster	~4h	Haute
4	Analyse des conflits d'agents	~4h	Moyenne
5	Intégration complète pare-feu	~6h	Haute
6	ISM lifecycle + optimisation shards	~4h	Critique
7	Archivage chiffré + snapshots automatisés	~2h	Haute

Chaque maintenance a fait l'objet d'un document de suivi structuré : contexte, diagnostic, actions, résultat, leçons apprises. C'est cette discipline documentaire qui permet de capitaliser — et c'est précisément là que Claude entre en jeu.

---

4. L'IA comme copilote : comment j'utilise Claude dans un projet SIEM

4.1 Pourquoi Claude, et pourquoi Opus 4.6

Soyons concrets : l'IA que j'utilise au quotidien sur ce projet, c'est Claude d'Anthropic, et plus précisément le modèle Opus 4.6 — le plus avancé de leur gamme à ce jour.

J'ai testé d'autres modèles au fil du projet (GPT-4, Gemini, des modèles open source locaux). Claude Opus 4.6 s'est imposé pour plusieurs raisons spécifiques au contexte de l'administration système et sécurité :

• La qualité du raisonnement technique : Sur des problématiques croisées Linux / OpenSearch / Wazuh / sécurité, Opus 4.6 produit des analyses structurées qui tiennent la route. Il ne se contente pas de proposer "la première réponse Stack Overflow" — il construit un diagnostic différentiel, pèse les hypothèses, et justifie ses recommandations.
• La rigueur sur les commandes système : Quand je demande une commande curl sur l'API OpenSearch ou un script bash, la syntaxe est correcte, les options sont les bonnes, et les cas d'erreur sont anticipés. Sur des sujets de niche comme les ISM policies OpenSearch ou les decoders XML Wazuh, le taux d'erreur est remarquablement bas.
• La mémoire projet (Claude Code) : J'utilise Claude via Claude Code (l'interface CLI d'Anthropic). Cet outil maintient une mémoire persistante entre les sessions : architecture du cluster, versions, historique des maintenances, pièges déjà rencontrés. Quand j'attaque une nouvelle maintenance, Claude a le contexte complet sans que j'aie besoin de tout ré-expliquer. C'est un avantage décisif par rapport à une utilisation "one-shot" dans un chat web.
• La capacité de rédaction structurée : Les 7 documents de maintenance, les guides d'installation, les politiques de backup — tout a été co-rédigé avec Claude. Le ton est professionnel, la structure est homogène, et surtout la documentation est réellement produite (combien d'entre nous documentent vraiment chaque intervention ?).

4.2 Le postulat de départ

Je vais être direct : Claude ne remplace pas l'ingénieur. Il ne se connecte pas à vos serveurs, il ne diagnostique pas un problème réseau, il ne sent pas qu'un service "ne tourne pas rond" en regardant un htop.

Mon approche repose sur une répartition claire des rôles :

4.3 En pratique : le workflow

Voici comment se déroule concrètement une session de travail sur le SIEM avec Claude :

Étape 1 — Je constate un problème

Je me connecte au Dashboard, je vérifie l'état du cluster, je regarde les métriques. Quelque chose ne va pas : une erreur "Forbidden", un nombre de shards qui grimpe, un agent en conflit.

Étape 2 — Je collecte le contexte

Je copie les messages d'erreur, je lance les commandes de diagnostic (curl sur l'API OpenSearch, systemctl status, lecture des logs, etc.), je note l'état actuel.

Étape 3 — Je présente la situation à Claude

Je décris le problème, je colle les logs, je donne le contexte de l'infrastructure. Grâce à la mémoire persistante de Claude Code, Claude connaît déjà l'historique du projet : architecture, versions, décisions antérieures, pièges déjà rencontrés. Pas besoin de ré-expliquer que le cluster est mono-noeud ou que le heap est à 64 Go — il le sait.

Étape 4 — Claude analyse et propose

Claude identifie la cause probable, propose un plan d'action étape par étape, et rédige les commandes exactes à exécuter. Chaque commande est accompagnée d'une explication du pourquoi. Ce n'est pas un bête copier-coller de documentation — c'est un raisonnement adapté à mon infrastructure spécifique.

Étape 5 — J'exécute, je valide, je corrige

J'exécute chaque commande, je vérifie le résultat, je renvoie les sorties à Claude si nécessaire. On itère jusqu'à résolution. C'est un vrai dialogue technique, pas un monologue.

Étape 6 — Claude rédige la documentation

Une fois le problème résolu, Claude produit le document de suivi de maintenance : contexte, diagnostic, actions réalisées, résultat, leçons apprises, recommandations. Format homogène sur les 7 maintenances.

4.4 Exemples concrets

Le plus parlant, c'est de montrer des échanges réels. Voici 4 situations rencontrées sur le projet.

Moi : "Après la migration en 4.14, l'Indexer plante avec des OutOfMemoryError."

Claude : identifie que la mise à jour a écrasé la config JVM (heap passé de 64 Go à 1 Go par défaut), propose la commande exacte, et avertit de vérifier ce point après chaque montée de version.

Résultat : 2 minutes au lieu de 30 minutes de recherche dans la doc. Classique, efficace.

Moi : "Je constate ~900 shards actifs. C'est normal ?"

Claude : calcule 3 shards x 365 jours = 1 095, identifie que la limite est à 1 000, évalue qu'il reste ~30 jours avant la casse, et propose une stratégie complète : augmentation temporaire + template override + politique ISM.

Là, c'est plus que du dépannage. Claude voit le problème dans sa globalité et propose une architecture, pas un pansement.

Moi : "Je veux intégrer les logs de notre pare-feu Stormshield. Voici le format brut : id=firewall time=... fw=..."

Claude : propose l'architecture rsyslog + TLS, rédige les 6 decoders, génère ~40 règles de détection, et anticipe le problème de volume avec une activation progressive.

40 règles XML sans erreur de syntaxe (ou presque), c'est des heures de gagnées. Manuellement, j'y aurais passé la journée.

Moi : "J'ai ajouté la directive <force> pour gérer les ré-enregistrements d'agents. Le Manager ne redémarre plus."

Claude : identifie immédiatement l'incompatibilité avec la version 4.14, propose le rollback.

Sauf que... c'est Claude qui m'avait suggéré cette directive. Elle marchait sur des versions antérieures, plus sur la 4.14. Claude peut se tromper. C'est pour ça qu'on teste toujours avant de redémarrer (wazuh-analysisd -t). La confiance n'exclut pas le contrôle.

4.5 Les vrais gains — et les vraies limites

Plutôt qu'un long discours, voici le bilan après plusieurs semaines de ce workflow :

Là où Claude change la donne :

Domaine	Pourquoi ça marche	Exemple concret
Configurations complexes	XML/JSON verbeux, sensibles à la syntaxe — Claude produit vite et juste	~40 règles pare-feu : seulement 3 erreurs liées à des changements de version
Diagnostic	Il raisonne sur des problèmes croisés, pas juste un copier-coller de doc	Un "Forbidden" Dashboard causé par un Java manquant sur l'Indexer — il reconstitue la chaîne
Documentation	Soyons honnêtes : sans Claude, la moitié des maintenances n'auraient eu droit qu'à un post-it mental	7 documents de suivi homogènes, rédigés au fil des échanges
Mémoire projet	Via Claude Code et son MEMORY.md, il retient l'architecture, les pièges, les décisions	Pas besoin de ré-expliquer que le cluster est mono-noeud ou que -cd est destructif
Bonnes pratiques	Il intègre spontanément des aspects qu'on pourrait oublier	Swappiness, force merge, conformité NIS2 sur le chiffrement au repos...

Là où il faut rester lucide :

Limite	En pratique
Il ne teste pas	Il propose des commandes, c'est vous qui les exécutez. Un securityadmin.sh -cd syntaxiquement parfait peut écraser tout votre index de sécurité
Il peut être en retard	La directive <force> incompatible avec 4.14 : aucun modèle ne suit les changelogs en temps réel. Toujours tester avant la prod
Il ne "sent" pas l'infra	C'est moi qui ai remarqué les ~900 shards en surveillant le cluster. Claude a fait le calcul après. La surveillance proactive reste humaine
Il faut le comprendre	Claude est un accélérateur, pas un substitut. Si vous ne comprenez pas ce qu'il propose, vous ne pouvez pas le valider

4.6 Objectivement : quel gain de temps ?

Sur l'ensemble du projet (migration + 7 maintenances + documentation), voici mon estimation :

Tâche	Sans IA (estimation)	Avec IA (réel)	Gain
Migration 4.12 → 4.14	~8h	~4h	~50%
Remédiation RBAC	~6h	~4h	~33%
Intégration pare-feu (decoders + rules)	~12h	~6h	~50%
Politique ISM + archivage chiffré	~8h	~6h	~25%
Documentation (7 maintenances)	~10h	~3h	~70%
Total	~44h	~23h	~48%

Le gain le plus spectaculaire est sur la documentation (70%). Le gain le plus utile est sur les configurations complexes (decoders, règles, ISM policies) où le risque d'erreur de syntaxe est élevé.

---

5. Ce que j'en retiens

Sur le SIEM en général

1. Un SIEM n'est pas un projet, c'est un process. L'installation n'est que le début. La vraie valeur vient de l'exploitation quotidienne, de l'affinage des règles, de la réponse aux alertes.

2. La conformité est un moteur, pas un objectif. NIS2, ISO 27001 vous poussent à mettre en place un SIEM — mais le vrai bénéfice est la visibilité opérationnelle. Pouvoir répondre à la question "que s'est-il passé sur cette machine le 15 janvier à 14h32 ?" n'a pas de prix lors d'un incident.

3. Dimensionnez pour le long terme. Le stockage, les shards, la rétention — tout doit être pensé dès le départ. Un SIEM qui tombe parce que le disque est plein ou que la limite de shards est atteinte, c'est un SIEM qui vous laisse aveugle au pire moment.

Sur Wazuh

4. Wazuh est une solution mature et crédible pour les PME/ETI. Le coût de licence zéro compense largement la courbe d'apprentissage si vous avez la compétence interne.

5. Investissez dans la documentation. Chaque intervention, chaque piège, chaque décision d'architecture doit être documentée. Vous-même dans 6 mois serez votre premier lecteur.

6. Testez avant de redémarrer. wazuh-analysisd -t pour valider la configuration du Manager avant un systemctl restart. Cela m'a évité au moins deux crashs supplémentaires.

Sur l'utilisation de Claude

7. Claude est un copilote, pas un pilote automatique. La répartition "l'humain trouve le problème, Claude aide à l'analyser et le résoudre" fonctionne remarquablement bien dans un contexte d'administration système et sécurité.

8. Le gain de temps est réel mais conditionnel. Il faut savoir poser les bonnes questions, fournir le bon contexte, et surtout valider les réponses. Le gain est de l'ordre de 30 à 50% sur les tâches techniques, et jusqu'à 70% sur la documentation.

9. La mémoire persistante de Claude Code change la donne. Pouvoir reprendre une session de travail avec le contexte complet du projet (architecture, historique des interventions, pièges connus) est un avantage considérable par rapport à une utilisation ponctuelle dans un chat web. C'est la différence entre un consultant qui découvre votre infra à chaque visite et un collègue qui connaît le projet par coeur.

10. La transparence est essentielle. Claude peut se tromper, et c'est normal. Le workflow doit intégrer systématiquement une étape de validation humaine. C'est en étant lucide sur les limites de l'IA qu'on en tire le meilleur parti. L'incident de la directive <force> m'a coûté 5 minutes de downtime — parce que je n'avais pas testé avant de redémarrer. La leçon vaut pour l'IA comme pour n'importe quelle source de conseil technique.

---

En résumé

Déployer et maintenir un SIEM Wazuh en production, c'est un travail exigeant qui demande des compétences Linux, réseau, sécurité et une bonne dose de persévérance. Claude Opus 4.6 ne supprime pas cette exigence — il la rend plus tenable pour un administrateur qui porte plusieurs casquettes.

Si vous envisagez de déployer un SIEM et que vous hésitez : lancez-vous. Wazuh est une base solide, la communauté est là, et avec un copilote comme Claude bien utilisé, le projet est à la portée d'une équipe IT motivée — même réduite.

La sécurité de votre SI ne peut plus être un sujet remis à demain. NIS2 est là, les menaces aussi. Autant s'outiller correctement.

---

Retour d'expérience réel sur une infrastructure de production. Les volumes, identifiants et détails techniques ont été adaptés pour préserver l'anonymat. Cet article a lui-même été co-rédigé avec Claude Opus 4.6 — logique, non ?

---

Tags : #SIEM #Wazuh #OpenSource #Cybersécurité #NIS2 #IA #RetourDExpérience #OpenSearch #DevSecOps