Wazuh SIEM tutoriel : installation et configuration open

Lecture : 16 minutes · Niveau : sysadmin / sécurité · Mise à jour : avril 2026

Wazuh est en 2026 (informations vérifiées en avril 2026, susceptibles d’évoluer) le choix rationnel pour une PME qui veut un SIEM + XDR + HIDS sérieux à coût d’infra seul. Open-source, déployable en 10-20 minutes sur un seul VPS via script officiel, avec agents pour Windows, Linux, macOS, et intégrations natives cloud (AWS, Azure, GCP, Microsoft 365). Ce tutoriel pratique couvre l’installation single-node, le déploiement d’agents, la configuration de règles de détection, l’intégration avec d’autres outils (Suricata, VirusTotal, MISP, Slack), et les optimisations production. Toutes les commandes sont testées sur Ubuntu 22.04 / 24.04.

Pour le contexte stratégique global, voir le pillar Sécurité défensive SOC PME.

Sommaire

Architecture Wazuh
Prérequis et dimensionnement
Installation single-node Ubuntu
Première connexion dashboard
Déployer des agents (Linux, Windows, macOS)
Configuration et règles de détection
Intégrations utiles
Tuning et performance
Sauvegardes et maintenance
Pièges fréquents
FAQ

1. Architecture Wazuh

3 composants principaux.

Wazuh Server.
– Cerveau du système.
– Reçoit télémétrie agents.
– Analyse via decoders + rules.
– Génère alertes.

Wazuh Indexer (basé OpenSearch).
– Stocke événements et alertes.
– Permet recherche, queries, dashboards.
– Précédemment basé Elasticsearch.

Wazuh Dashboard (basé OpenSearch Dashboards).
– Interface web (login, dashboards, recherche, configuration).
– Précédemment Kibana.

Wazuh Agents.
– Installés sur chaque endpoint à surveiller.
– Collectent : logs, processes, file integrity, vulnerabilities, system inventory.
– Envoient au Server via TLS.

Modes de déploiement.
– Single-node (all-in-one) : tout sur un VPS. Démarrage PME, jusqu’à ~100 agents.
– Multi-node : Server + Indexer + Dashboard sur machines séparées. Pour scaling 100-1000 agents.
– Cluster : multiples Indexers et Servers pour haute disponibilité et très grands volumes.

2. Prérequis et dimensionnement

Single-node Ubuntu 22.04 / 24.04.
– 4 GB RAM minimum, 8 GB recommandé pour PME (50 agents).
– 2 vCPU minimum, 4 recommandé.
– 50 GB SSD minimum (logs accumulent).
– Connexion internet pour installation et updates.

Dimensionnement par taille PME.
| Agents | RAM | vCPU | Storage |
|——–|—–|——|———|
| 10 | 4 GB | 2 | 50 GB |
| 50 | 8 GB | 4 | 100 GB |
| 100 | 16 GB | 4 | 250 GB |
| 250 | 32 GB | 8 | 500 GB |
| 500 | 64 GB | 8 | 1 TB |

Hébergeur recommandé PME ouest-africaine.
– Hetzner CX33 (8 GB RAM, ~12 EUR/mois) : excellent pour 50 agents.
– OVH VPS Comfort (~10 EUR/mois).
– AWS Cape Town t3.large (~50-80 USD/mois) si présence Afrique souhaitée.

Réseau.
– Port 1514/UDP : agents → server (events).
– Port 1515/TCP : agents → server (registration).
– Port 55000/TCP : API Wazuh.
– Port 443/TCP : dashboard web.
– Bonnes pratiques : whitelist IPs agents, certificats TLS, pas d’exposition internet du dashboard sans VPN.

3. Installation single-node Ubuntu

Étape 1 : préparer le VPS.

Mise à niveau préalable du système Ubuntu/Debian. curl est l’unique dépendance manuelle — le script all-in-one Wazuh ajoute lui-même Java 17 et les autres prérequis à l’exécution.

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl

Sur Ubuntu 24.04 LTS, curl est déjà préinstallé via snap dans certaines images Hetzner — l’apt install retourne alors already the newest version. Aucun risque.

Étape 2 : installation via script officiel.

Le script wazuh-install.sh branche tout en une commande : manager, indexer (fork OpenSearch), dashboard, certificats TLS générés localement, configuration cluster. Le flag -a sélectionne l’installation all-in-one sur un seul nœud — adapté jusqu’à environ 500 agents.

curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
sudo bash ./wazuh-install.sh -a

La durée d’exécution typique est de 5 à 8 minutes sur VPS 4 vCPU / 8 Go. À la fin, le script affiche les credentials administrateur dans wazuh-install-files.tar — fichier à protéger (chmod 600) et stocker dans un gestionnaire de secrets, jamais committed.

L’installation prend 10-20 minutes selon connexion. Le script déploie Server + Indexer + Dashboard + certificats TLS auto-signés.

Étape 3 : récupérer les credentials.
À la fin, le script affiche les mots de passe générés (ou les sauvegarde dans wazuh-install-files.tar).

Extraction et affichage en clair des mots de passe générés à l’installation. Le flag -O envoie la sortie sur stdout sans extraire le fichier sur disque — pratique pour copier-coller dans un coffre-fort sans laisser de trace temporaire.

sudo tar -axf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt -O

Sauvegarder immédiatement le mot de passe admin du dashboard et celui du compte kibanaserver pour l’API REST. Les autres comptes (anomalie_detection_user, kibanaro, etc.) ne sont utiles qu’en cluster multi-nœuds.

Notez le mot de passe admin (pour le dashboard).

Étape 4 : vérifier statut services.

Trois services systemd doivent être active (running) pour que Wazuh fonctionne : wazuh-manager (réception des logs agents), wazuh-indexer (stockage moteur OpenSearch), wazuh-dashboard (UI web). Si l’un échoue, les deux autres deviennent inutiles.

sudo systemctl status wazuh-manager
sudo systemctl status wazuh-indexer
sudo systemctl status wazuh-dashboard

L’indexer est le plus susceptible d’échouer sur un VPS sous-dimensionné : il alloue par défaut la moitié de la RAM disponible à la JVM (config /etc/wazuh-indexer/jvm.options). Sur moins de 4 Go RAM, ajuster -Xms1g -Xmx1g manuellement pour éviter le kill du kernel OOM.

Tous devraient être active (running).

Étape 5 : firewall.

Cinq ports à ouvrir sur UFW selon le rôle : 22 (SSH admin), 443 (dashboard HTTPS public), 1514/udp (réception logs des agents — flux principal), 1515/tcp (registration des agents), 55000/tcp (API REST manager).

sudo ufw allow 22
sudo ufw allow 443    # dashboard
sudo ufw allow 1514/udp  # agents
sudo ufw allow 1515   # registration
sudo ufw allow 55000  # API
sudo ufw enable

Limiter le port 22 et 55000 à l’IP de l’admin via ufw allow from X.X.X.X to any port 22 divise par 100 la pression brute-force visible dans les logs. Le port 1514 doit rester ouvert mais idéalement segmenté en VLAN si les agents sont sur un réseau interne.

Étape 6 : accéder au dashboard.
– Ouvrir https://VOTRE_VPS_IP dans un navigateur.
– Login : admin + mot de passe noté.
– Dashboard Wazuh apparaît.

4. Première connexion dashboard

Vue d’ensemble.
– Modules : Security Events, Integrity Monitoring, Vulnerabilities, MITRE ATT&CK, Compliance (PCI DSS, HIPAA, GDPR, NIST), etc.
– Agents : liste des endpoints surveillés.
– Discover : recherche libre dans logs.

Premier check : Security Events.
– Cliquer Security Events → Dashboard.
– Voir alertes générées par les règles default.
– Le manager génère des événements internes même sans agents.

Naviguer dans logs.
– Discover → choisir index wazuh-alerts-*.
– Filtrer par sévérité (rule.level), agent, MITRE technique.
– KQL ou Lucene queries.

Configuration utilisateurs.
– Stack Management → Security → Users.
– Créer comptes pour analystes (rôle wazuh-admin ou custom).
– Activer MFA si possible (depuis OpenSearch 2.x).

5. Déployer des agents (Linux, Windows, macOS)

Linux Ubuntu/Debian.

Installation d’un agent Linux Debian/Ubuntu. La variable d’environnement WAZUH_MANAGER est lue par le post-install script du paquet et pré-remplit /var/ossec/etc/ossec.conf avec l’IP du manager — évite l’édition manuelle après chaque installation.

# Sur l'endpoint à surveiller
curl -sO https://packages.wazuh.com/4.14/wazuh-agent_4.14.5-1_amd64.deb
sudo WAZUH_MANAGER='IP_DU_SERVER' dpkg -i ./wazuh-agent_4.14.5-1_amd64.deb
sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

L’agent doit ensuite être démarré (sudo systemctl enable --now wazuh-agent) puis enregistré côté manager. La méthode automatique passe par le port 1515 avec un mot de passe partagé (configuré dans /var/ossec/etc/authd.pass), simple mais à révoquer dès qu’une migration est terminée.

Linux RHEL/CentOS.

Variante RHEL/CentOS/Rocky Linux. Le repo Wazuh signé GPG s’enregistre dans /etc/yum.repos.d/wazuh.repo ; la signature garantit l’authenticité des paquets téléchargés et bloque les mises à jour man-in-the-middle.

sudo rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH
sudo cat > /etc/yum.repos.d/wazuh.repo <<EOF
[wazuh]
gpgcheck=1
gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH
enabled=1
name=Wazuh
baseurl=https://packages.wazuh.com/4.x/yum/
protect=1
EOF
sudo WAZUH_MANAGER='IP_DU_SERVER' yum install wazuh-agent
sudo systemctl daemon-reload && sudo systemctl enable --now wazuh-agent

Sur AlmaLinux 9 / Rocky 9 le repo fonctionne sans modification. Sur RHEL 8 et descendants, ajouter --enablerepo=wazuh à chaque commande dnf install si le repo est désactivé par défaut.

Windows.
– Télécharger MSI depuis wazuh.com/install.
– Installation interactive : renseigner IP du Manager.
– Ou via PowerShell automation :

Installation Windows pas-à-pas via PowerShell. Invoke-WebRequest télécharge le MSI, msiexec /i l’installe en mode silencieux — déployable via GPO Active Directory ou Intune sur un parc.

Invoke-WebRequest -Uri "https://packages.wazuh.com/4.x/windows/wazuh-agent-4.14.5-1.msi" -OutFile "C:\wazuh-agent.msi"
msiexec.exe /i "C:\wazuh-agent.msi" /q WAZUH_MANAGER="IP_SERVER"
NET START WazuhSvc

Pour pré-configurer l’IP du manager en mode silencieux, ajouter WAZUH_MANAGER="x.x.x.x" /qn à la ligne msiexec. Le service WazuhSvc démarre automatiquement : vérifier avec Get-Service WazuhSvc.

macOS.
– Télécharger pkg depuis wazuh.com.
– Configuration manuelle ou script.

Vérifier registration.
– Dashboard → Agents.
– Le nouvel agent doit apparaître Active après quelques minutes.

Mass deployment.
– Ansible playbook (officiel sur GitHub Wazuh).
– Group Policy (Windows AD).
– Image base VM (cloud).

6. Configuration et règles de détection

Architecture rules Wazuh.
– Règles définies en XML.
– Rules built-in : /var/ossec/ruleset/rules/.
– Custom rules : /var/ossec/etc/rules/local_rules.xml.
– Decoders parsing logs : /var/ossec/ruleset/decoders/.
– Custom decoders : /var/ossec/etc/decoders/local_decoder.xml.

Règles built-in importantes.
– Authentication : SSH brute-force, sudo failures, Windows logon failures.
– File Integrity Monitoring (FIM) : modifications fichiers critiques.
– Rootkits / Trojans : détection signatures connues.
– Vulnerability detection : CVEs sur applications.
– MITRE ATT&CK mapping : techniques tagged.

Exemple custom rule (alerter login admin).

/var/ossec/etc/rules/local_rules.xml :

Création d’une règle locale custom dans /var/ossec/etc/rules/local_rules.xml. La syntaxe if_sid 5715 rattache cette nouvelle règle à la règle Wazuh native 5715 (login SSH réussi), puis filtre sur les utilisateurs privilégiés.

<group name="custom,authentication,">
  <rule id="100100" level="10">
    <if_sid>5715</if_sid>
    <user>admin|root</user>
    <description>Critical: privileged user login from untrusted source</description>
    <mitre>
      <id>T1078</id>
    </mitre>
  </rule>
</group>

Le niveau 10 déclenche les alertes prioritaires dans le dashboard et active une notification email/Slack si l’integration est configurée. La plage 100000–119999 est réservée aux règles utilisateur — éviter de réutiliser les SID natifs Wazuh sous peine de comportement incohérent au prochain upgrade.

Redémarrer manager :

Le manager Wazuh ne recharge pas les règles à chaud : tout ajout dans local_rules.xml exige un redémarrage du service pour être pris en compte.

sudo systemctl restart wazuh-manager

Avant le restart, valider la syntaxe XML avec /var/ossec/bin/wazuh-logtest -t qui charge les règles sans démarrer le service — utile pour détecter une balise mal fermée avant qu’elle ne tue le manager en production.

File Integrity Monitoring (FIM).

Configurer dans /var/ossec/etc/ossec.conf :

<syscheck>
  <directories check_all="yes" realtime="yes">/etc,/usr/bin,/usr/sbin</directories>
  <directories check_all="yes" report_changes="yes">/var/www/html</directories>
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/hostname</ignore>
</syscheck>

Vulnerability detection.
Activer dans ossec.conf :

Activation du moteur de détection de vulnérabilités. Wazuh interroge les bases CVE des distributions (Canonical pour Ubuntu, Red Hat pour RHEL, Debian Security Tracker) toutes les 5 minutes et cross-référence avec l’inventaire logiciel collecté chez chaque agent (Syscollector).

<vulnerability-detector>
  <enabled>yes</enabled>
  <interval>5m</interval>
  <run_on_start>yes</run_on_start>
  <provider name="canonical">
    <enabled>yes</enabled>
    <os>focal</os>
    <os>jammy</os>
    <os>noble</os>
    <update_interval>1h</update_interval>
  </provider>
</vulnerability-detector>

Les CVE détectées apparaissent dans le module Vulnerabilities du dashboard, classées par sévérité CVSS et par agent. Pour rester rapide sur 100+ agents, l’intervalle 5m est un bon compromis ; descendre à 1m sur des serveurs critiques mais limiter à provider ciblé pour ne pas saturer l’API Nvd.

Active response (réponse automatique).

Exemple : bloquer IP après brute-force SSH.

Active Response : Wazuh exécute une commande automatiquement quand une règle déclenche. Ici, firewall-drop ajoute l’IP source à iptables/firewall-cmd pour 600 secondes, sur la base de la règle 5712 (échecs d’authentification multiples).

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5712</rules_id>
  <timeout>600</timeout>
</active-response>

Toujours tester en mode simulate avant production (flag disabled=yes temporaire) pour éviter de se bloquer soi-même via SSH. Ajouter sa propre IP de management à la whitelist /var/ossec/etc/lists/known-ips.txt est la sécurité de base.

MITRE ATT&CK dashboard.
– Modules → MITRE ATT&CK.
– Visualisation tactiques détectées sur votre environnement.
– Identifier gaps de couverture.

7. Intégrations utiles

VirusTotal.
– Hash files vérifiés contre VirusTotal pour identifier malware.
– Configuration dans ossec.conf avec API key.

Suricata (NIDS).
– Suricata = network IDS, complémentaire HIDS Wazuh.
– Wazuh peut ingérer alertes Suricata pour vue holistique.

MISP (threat intelligence).
– Plateforme partage IOCs.
– Wazuh enrichit alertes avec contextes IOC.

Slack / Discord / Email notifications.
– Webhook Slack pour alertes critiques.
– Configuration via <integration> block dans ossec.conf.

Intégration Slack via webhook entrant. Niveau 10 = uniquement les alertes critiques (privesc, malware détecté, brute-force confirmé). Le format json envoie un payload riche directement consommable par Slack pour rendu coloré.

<integration>
  <name>slack</name>
  <hook_url>https://hooks.slack.com/services/XXX/YYY/ZZZ</hook_url>
  <level>10</level>
  <alert_format>json</alert_format>
</integration>

Pour les équipes basées au Sénégal, en Côte d’Ivoire ou au Mali avec décalage horaire, créer 2 channels distincts : #wazuh-critical qui ping @here à toute heure (level >= 12), #wazuh-info silencieux pour les events 7-9.

Microsoft 365 / Azure AD.
– Module dédié logs M365 et Azure AD via Graph API.
– Détection compromission comptes, exfiltration, partages anormaux.

AWS CloudTrail / GuardDuty.
– Module ingestion logs AWS pour visibilité cloud.

Cloud Native Application Protection.
– Wazuh + Falco pour containers Kubernetes.
– Détection runtime anomalies pods.

SIEM federation.
– Wazuh peut forward vers SIEM externe (Splunk, Sentinel) pour stratégies hybrides.

8. Tuning et performance

Réduire false positives.
– Premier mois : bcp de faux positifs sur certaines règles.
– Identifier dans dashboard : top rules triggered.
– Whitelist patterns connus inoffensifs (<if_matched_sid> avec ignore).
– Ajuster level rules trop bruyantes.

Performance manager.
– analysisd.queue_size à augmenter si forte volumétrie.
– logcollector.queue_size similaire.
– Monitoring via /var/ossec/var/state/manager_state.

Performance indexer.
– Vérifier RAM utilisée par OpenSearch (heap typiquement 50 % RAM).
– ILM (Index Lifecycle Management) pour rotation et purge anciens logs.
– Suppression manuelle si stockage saturé : curl -X DELETE "https://localhost:9200/wazuh-alerts-4.x-2025.01.*".

Rétention.
– Default 90 jours typique.
– Adapter selon storage et compliance (RGPD : 1-3 ans logs sécurité parfois requis).

Backup configuration.
– /var/ossec/etc/ossec.conf : config manager.
– /var/ossec/etc/rules/local_rules.xml : custom rules.
– /var/ossec/etc/decoders/local_decoder.xml : custom decoders.
– Versionner dans Git (privé).

Monitoring Wazuh.
– Module Cluster pour status interne.
– Métriques : agents actifs, events processed/sec, alertes/min.
– Alerts si manager down (Prometheus + node_exporter sur VPS Wazuh).

9. Sauvegardes et maintenance

Sauvegarde quotidienne.
– Snapshot OpenSearch indices (sauvegarde alertes) :

Snapshot OpenSearch des indices Wazuh. Le repository wazuh_backup doit être pré-configuré dans opensearch.yml avec un chemin disque local ou un bucket S3-compatible (MinIO, Backblaze B2, Wasabi). wait_for_completion=true bloque tant que le snapshot n’est pas écrit.

# Snapshot vers S3 ou disque local
curl -X PUT "https://localhost:9200/_snapshot/wazuh_backup/snapshot_1?wait_for_completion=true"

Pour les petites infrastructures, un cron quotidien à 03h locale qui snapshot puis envoie sur Backblaze B2 (0,005 USD/Go/mois) reste l’option la plus économique. Vérifier la restauration une fois par trimestre : une sauvegarde non testée n’existe pas.

Backup /var/ossec/etc/ (configurations).
Backup chiffré, rotation 30 jours minimum.

Mises à jour Wazuh.
– Wazuh sort 1-2 versions majeures/an + patches.
– Lire changelog avant chaque update (parfois breaking changes config).
– Test sur staging si critique.

Mise à jour Wazuh dans l’ordre prescrit : indexer d’abord (la couche stockage), puis manager, puis dashboard. L’inverse peut casser la compatibilité API entre les composants — l’indexer rejette alors les requêtes du manager avec une erreur version mismatch.

sudo apt update && sudo apt upgrade wazuh-manager wazuh-indexer wazuh-dashboard

Toujours snapshot d’abord, lire les release notes Wazuh (changements de schéma d’index entre versions majeures), puis upgrade hors heures de pointe. Les agents peuvent rester 1 à 2 versions mineures derrière le manager sans casse, ce qui permet un upgrade progressif sur un parc.

Mises à jour agents.
– Auto-upgrade depuis manager possible.
– Sinon redéploiement script ou Group Policy.

Health checks réguliers.
– Statut services manager / indexer / dashboard hebdomadaire.
– Volume disk < 80 % usage.
– Latence requêtes dashboard correcte.
– Agents actifs vs déployés (différence = problèmes connectivité).

Documentation interne.
– Runbook : que faire si Wazuh down, agents disconnectés, alertes critiques.
– Playbook par type d’incident.
– Onboarding nouveaux analystes.

10. Pièges fréquents

Dashboard exposé internet sans VPN. Risque d’exposition. Toujours derrière VPN ou Cloudflare Access.

Pas de tuning des règles. Premier mois noyé sous false positives → désactivation Wazuh par fatigue. Tuner activement.

Pas d’agents déployés. Manager seul génère événements internes mais pas vue endpoints. Déployer agents partout.

FIM sur tout. Surveiller / cause performance désastreuse. Cibler /etc, /usr/bin, dossiers critiques applicatifs.

Pas de backup configuration. Hardware crash = recommencer from scratch. Backup /var/ossec/etc/ essentiel.

Pas de rotation logs. Storage saturé en 6 mois. ILM obligatoire.

Custom rules sans tests. Règle qui crash analysisd → pas d’alertes. Tester avec wazuh-logtest.

Pas de monitoring Wazuh lui-même. Manager down silencieusement. Heartbeat externe (UptimeRobot ping API Wazuh).

Mots de passe non changés. admin avec mot de passe initial = breach garanti. Rotation immédiate post-install.

Updates ignorées. CVEs Wazuh non patchées = vulnérabilités. Patches mensuels.

Pas de plan IR pour utiliser alertes. Wazuh détecte mais pas de processus pour traiter = sécurité théorique.

Trop d’agents pour single-node. > 200 agents sur all-in-one = saturation. Migrer multi-node.

FAQ

Wazuh est-il vraiment gratuit ?

Oui, 100 % open-source (licence GPLv2). Coût uniquement infra (VPS) et temps humain. Wazuh Cloud (managed) existe en option payante (~$571/mois pour 100 agents) mais non obligatoire. La majorité des PME en 2026 self-hostent.

Combien d’agents max pour single-node ?

Jusqu’à environ 100-200 agents avec 8-16 GB RAM. Au-delà : migrer multi-node ou cluster. Performance variable selon volume logs par endpoint.

Wazuh fonctionne-t-il sur Windows Server ?

Le manager : non, uniquement Linux (Ubuntu, RHEL, Debian). Les agents : oui, Windows Server 2012+ supportés. Architecture typique : manager sur VPS Linux, agents sur serveurs Windows et stations.

Quelle différence Wazuh vs ELK Stack ?

ELK (Elasticsearch + Logstash + Kibana) est un stack généraliste de logging. Wazuh est un SIEM complet construit sur OpenSearch (fork Elasticsearch) avec règles, agents, MITRE mapping intégrés. Pour cybersécurité PME : Wazuh prêt à l’emploi vs ELK où il faut tout construire.

Wazuh remplace-t-il un EDR commercial ?

Wazuh agents font de l’EDR (file integrity, log monitoring, vulnerability detection, behavioral analysis). Performance moindre que CrowdStrike ou SentinelOne sur détection comportementale avancée. Pour PME standard : suffit largement. Pour environnements high-risk : compléter avec EDR commercial.

Comment intégrer Wazuh à mon ticketing system ?

Via webhooks ou API custom. Exemples : intégration Jira, ServiceNow, Zendesk. Wazuh API REST permet trigger automatique sur alertes.

Wazuh respecte-t-il RGPD/CDP ?

Wazuh peut être configuré pour respecter ces normes (logs pseudonymisés si nécessaire, accès strictement contrôlé, rétention selon politique). À documenter dans DPIA. Modules compliance built-in (PCI DSS, HIPAA, GDPR, NIST 800-53) facilitent l’audit.

Combien de temps pour qu’une équipe maîtrise Wazuh ?

1 sysadmin Linux fluent : 1-2 semaines pour install et fonctionnel. 1 mois pour tuning sérieux. 3 mois pour autonomie complète (custom rules, intégrations avancées). Formation officielle Wazuh ou hands-on TryHackMe accélère.

Wazuh SIEM tutoriel : installation et configuration open source 2026