VPS hardening sécurité 2026 : guide complet (checklist Linux)

Un VPS public en 2026 (informations vérifiées en avril 2026, susceptibles d’évoluer) sera scanné en moins de 5 minutes après mise en ligne, et tenté pour brute-force SSH dans l’heure. Le hardening systématique est non négociable. Voici la checklist complète pour sécuriser un VPS Linux en production : SSH, firewall, mises à jour, audit logging, intrusion detection.

Ce guide général couvre tout. Les articles connexes détaillent : SSH hardening complet, fail2ban configuration, mises à jour sécurité auto, audit Lynis.

Checklist hardening initial

1. Mises à jour système avant tout
2. Désactiver login root par mot de passe
3. Authentication SSH par clef uniquement
4. Firewall (UFW + Hetzner Cloud Firewall)
5. fail2ban
6. Mises à jour sécurité automatiques
7. Disable services inutiles
8. Auditd pour logs sécurité
9. 2FA SSH (optionnel mais recommandé)
10. Audit régulier avec Lynis

Hardening kernel

Le fichier 99-hardening.conf est chargé par sysctl en dernier (ordre alphabétique des fichiers dans /etc/sysctl.d/) et surcharge donc tous les paramètres précédents. tcp_syncookies protège contre les SYN flood, rp_filter=1 bloque l’IP spoofing, accept_source_route=0 rejette les paquets avec routage source.

# /etc/sysctl.d/99-hardening.conf
# Network
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv6.conf.all.accept_redirects = 0

# Kernel
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.unprivileged_bpf_disabled = 1
fs.protected_hardlinks = 1
fs.protected_symlinks = 1

sysctl --system

Appliquer immédiatement avec sysctl -p /etc/sysctl.d/99-hardening.conf sans rebooter. Pour audit : sysctl -a | grep -E 'syncookies|rp_filter' doit retourner les valeurs attendues. CIS Benchmark Linux 3.0 (2023) cite ce socle comme prérequis pour le niveau Server-L1.

SSH

Voir notre tutoriel SSH hardening complet.

Firewall

Double couche : Hetzner Cloud Firewall (avant le VPS) + UFW (sur le VPS). Voir notre guide Hetzner Firewall.

Audit logs (auditd)

auditd journalise au kernel-level toute modification critique. Les règles -w /etc/passwd -p wa écoutent l’écriture et l’ajout d’attributs (chmod, chown) sur le fichier, et taggent les events avec un mot-clé pour faciliter la corrélation SIEM.

apt install auditd

# Règles de base : /etc/audit/rules.d/audit.rules
-w /etc/passwd -p wa -k passwd_changes
-w /etc/shadow -p wa -k shadow_changes
-w /etc/sudoers -p wa -k sudoers_changes
-w /var/log/auth.log -p wa -k auth_log

systemctl restart auditd

# Voir les events
ausearch -k passwd_changes

Les events sont écrits dans /var/log/audit/audit.log au format binaire — utiliser ausearch -k passwd_changes pour les requêter. Sur un VPS supervisé par Wazuh, l’agent lit automatiquement ces logs et alerte sur tout changement de /etc/passwd en quasi-temps réel.

Détection d’intrusion

• fail2ban : ban IP brute-force SSH/HTTP
• AIDE ou Tripwire : intégrité fichiers système
• Wazuh : SIEM open-source complet (voir notre guide Wazuh)
• Crowdsec : alternative moderne fail2ban avec blacklist communautaire

Mises à jour automatiques

Voir notre tutoriel unattended-upgrades.

Audit Lynis

Voir notre tutoriel Lynis. Audit complet en 5 minutes, score de sécurité.

Adaptation Afrique de l’Ouest

Pour les PME africaines, le hardening protège contre les bots automatisés (qui ne discriminent pas géographiquement) et limite l’impact d’un potentiel incident. Coût : 1-2 heures de setup initial pour réduire la surface d’attaque drastiquement.

Pour approfondir

• SSH hardening
• fail2ban
• Mises à jour auto
• Audit Lynis

Étape 1 : auditer l’état initial du serveur

Avant de durcir un VPS, mesurez ce qu’il expose. Connectez-vous en SSH et lancez quatre commandes de reconnaissance :

Inventaire d’avant-hardening. ss -tlnp liste les ports TCP en écoute avec le processus associé, iptables -L montre les règles actives, systemctl list-units --running énumère les services tournants, last -n 20 affiche les 20 dernières connexions.

ss -tlnp
sudo iptables -L -n -v
sudo systemctl list-units --type=service --state=running
last -n 20

Cet état initial sert de base de comparaison post-hardening — toute écoute non identifiée à cette étape doit être investiguée avant le durcissement, sans quoi on peut accidentellement bloquer un service légitime (Postfix, monitoring agent) au moment d’activer UFW.

ss -tlnp liste les ports en écoute. Sur un VPS Contabo ou OVH fraîchement loué, vous trouverez typiquement SSH (22), parfois rpcbind (111), et postfix sur 25. Tout port supplémentaire non documenté est une anomalie. last affiche les 20 dernières connexions. Toute IP exotique signale un serveur déjà compromis : redéployez plutôt que de tenter de nettoyer.

Étape 2 : créer un utilisateur sudo non-root

Travailler en root est interdit. Créez un compte avec mot de passe robuste et ajoutez-le au groupe sudo :

Création d’un utilisateur de service nommé ops avec accès sudo. La copie de authorized_keys depuis root vers /home/ops/.ssh/ préserve la connexion SSH par clé sans repasser par le mot de passe. Les permissions 700 sur le dossier et chown ops:ops sont obligatoires : sshd refuse de lire les clés d’un dossier de permissions trop laxistes.

adduser ops
usermod -aG sudo ops
mkdir -p /home/ops/.ssh
chmod 700 /home/ops/.ssh
cp ~/.ssh/authorized_keys /home/ops/.ssh/
chown -R ops:ops /home/ops/.ssh
chmod 600 /home/ops/.ssh/authorized_keys

Vérifier la connexion avec ssh ops@vps depuis une AUTRE session avant de basculer en root et de désactiver le login root. Garder la session root active pendant le test évite un blocage total en cas de mauvaise configuration des permissions.

Testez la connexion depuis une autre fenêtre avant de désactiver root. Si vous ne pouvez plus vous connecter en ops, ne fermez surtout pas votre session root, vous seriez verrouillé hors du serveur. Cette règle simple évite des heures de support kvm chez l’hébergeur.

Étape 3 : durcir SSH

Éditez /etc/ssh/sshd_config avec les directives suivantes :

Configuration sshd durcie. PermitRootLogin no bloque le login root direct, PasswordAuthentication no impose les clés, MaxAuthTries 3 limite les tentatives par connexion, ClientAliveInterval 300 avec CountMax 2 coupe les sessions inactives après 10 minutes.

Port 22
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
AllowUsers ops
KbdInteractiveAuthentication no
X11Forwarding no

Tester la config avant restart : sudo sshd -t retourne silencieusement sur succès. Toujours sudo systemctl reload ssh (pas restart) sur la première itération — reload garde la session active, restart la coupe et peut bloquer si la nouvelle config est cassée.

Rechargez avec sudo systemctl reload ssh puis testez immédiatement une nouvelle connexion. PasswordAuthentication no bloque les attaques par dictionnaire, qui représentent 80 % des tentatives observées sur un VPS exposé. AllowUsers ops est une liste blanche stricte : même si un attaquant créait un compte, il ne pourrait pas se connecter.

Étape 4 : générer des clés SSH Ed25519 côté client

Ed25519 est plus rapide et plus sûr que RSA. Sur votre poste local :

Génération d’une clé Ed25519 — algorithme à courbe elliptique moderne, plus rapide et plus sûr que RSA-4096 à taille équivalente. Le flag -a 100 applique 100 rounds de KDF (key derivation function) qui ralentit le brute-force d’un mot de passe protégeant la clé privée.

ssh-keygen -t ed25519 -a 100 -f ~/.ssh/vps_ops -C "ops@dakar-vps"
ssh-copy-id -i ~/.ssh/vps_ops.pub ops@vps.example.sn

La clé privée doit rester sur le poste de l’admin (chiffrée par passphrase) — jamais sur le serveur. ssh-copy-id ajoute automatiquement la clé publique au bon endroit avec les bonnes permissions. Sur macOS, ajouter UseKeychain yes à ~/.ssh/config pour stocker la passphrase dans le trousseau.

Le flag -a 100 applique 100 itérations KDF, ce qui ralentit considérablement une attaque par force brute en cas de fuite du fichier. Configurez ~/.ssh/config avec un alias pour ne pas retaper la commande complète à chaque connexion.

Étape 5 : installer et configurer ufw

UFW (Uncomplicated Firewall) est une surcouche conviviale d’iptables :

Pare-feu en mode default-deny : tout trafic entrant est bloqué sauf ce qui est explicitement autorisé. Les règles 22/80/443 ouvrent SSH et le web. L’ordre des commandes importe — toujours autoriser SSH AVANT d’activer le pare-feu, sinon la session courante est tuée.

sudo apt update && sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Pour les opérateurs basés au Sénégal, en Côte d’Ivoire ou au Mali, restreindre SSH à votre plage IP via ufw allow from 41.214.0.0/16 to any port 22 (exemple Orange Sénégal) réduit massivement le bruit fail2ban — sans bloquer un voyage où l’IP change.

La politique deny incoming bloque tout par défaut, ne s’ouvre que sur les ports autorisés. Si vous changez le port SSH (recommandé : 2222 ou 22000), n’oubliez pas ufw allow 22000/tcp avant enable sinon vous vous verrouillez. Lisez deux fois la commande avant Enter.

Étape 6 : fail2ban contre les brute-force

Fail2ban analyse les logs et bannit automatiquement les IP qui multiplient les tentatives échouées :

fail2ban scanne les logs d’authentification et bannit les IPs qui échouent N fois en T secondes. La copie jail.conf → jail.local est obligatoire : les mises à jour APT écrasent jail.conf mais respectent jail.local.

sudo apt install fail2ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Vérifier que la jail SSH est active après modif avec sudo fail2ban-client status sshd — montre le compteur des IPs actuellement bannies et la liste. Pour Wazuh ou CrowdSec, fail2ban devient redondant : ces deux outils gèrent le bannissement en multi-serveur et avec corrélation, ce que fail2ban ne fait pas.

Éditez /etc/fail2ban/jail.local et adaptez la section [sshd] :

Configuration de la jail SSH dans jail.local. maxretry=3 + findtime=600 = 3 échecs en 10 minutes déclenchent un ban. bantime=86400 bannit pour 24 heures. ignoreip exclut localhost et un préfixe d’IP réseau (ici exemple Orange Sénégal) pour ne pas se bannir soi-même.

[sshd]
enabled = true
port = ssh
maxretry = 3
findtime = 600
bantime = 86400
ignoreip = 127.0.0.1/8 ::1 41.214.0.0/16

Pour les IPs récidivistes, configurer un recidive jail qui bannit définitivement après plusieurs cycles courts — pattern recommandé pour les VPS exposés à Internet public. Recharger la config avec sudo fail2ban-client reload sans interrompre les bans en cours.

Le paramètre ignoreip protège contre l’auto-bannissement depuis votre IP de bureau. Adaptez avec votre plage Sonatel ou Orange Sénégal. Redémarrez : sudo systemctl restart fail2ban. Vérifiez l’état avec sudo fail2ban-client status sshd. Au bout de 24 heures, vous verrez typiquement 50 à 200 IP bannies, principalement des bots chinois et russes.

Étape 7 : désactiver les services inutiles

Sur Debian 12 / Ubuntu 24.04, plusieurs services tournent par défaut sans utilité pour un VPS web :

Désactivation des services réseau hérités, souvent activés par défaut dans les images cloud : rpcbind (port mapper RPC, vecteur DDoS amplification), nfs-common (client NFS), avahi-daemon (mDNS, fuite info LAN), cups (impression, inutile sur serveur). Les paquets telnet et rsh-* exposent des protocoles non chiffrés à proscrire.

sudo systemctl disable --now rpcbind nfs-common avahi-daemon cups
sudo apt purge telnet rsh-client rsh-redone-client

Vérification post-disable : ss -tlnp | grep -E '111|2049|5353|631' doit retourner vide. Sur Ubuntu 24.04, certains de ces services ne sont plus installés par défaut — la commande peut afficher des warnings not loaded, ce qui est normal.

Chaque service supprimé réduit la surface d’attaque et libère de la RAM. Après cleanup, un VPS Debian utilise typiquement 110 Mo de RAM au repos, contre 220 Mo en config par défaut. Sur un VPS 2 Go, c’est 5 % de RAM en plus pour vos applications.

Étape 8 : mises à jour automatiques

Activation des mises à jour de sécurité automatiques. dpkg-reconfigure -plow bascule la config en mode interactif minimal : répondre Yes à la question installe le cron /etc/apt/apt.conf.d/20auto-upgrades qui exécute le check quotidiennement.

sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades

Pour les serveurs de production critiques, configurer Unattended-Upgrade::Automatic-Reboot "true" avec Automatic-Reboot-Time "04:00" dans /etc/apt/apt.conf.d/50unattended-upgrades — applique les patches kernel sans intervention humaine. Vérifier le log dans /var/log/unattended-upgrades/ chaque semaine.

Activez les mises à jour de sécurité automatiques. Vérifiez /etc/apt/apt.conf.d/50unattended-upgrades : la ligne "${distro_id}:${distro_codename}-security"; doit être active et non commentée. Configurez l’envoi d’un email en cas d’erreur via Unattended-Upgrade::Mail "ops@example.sn";. Cette discipline ferme automatiquement les CVE OpenSSL ou systemd dans les 24 heures suivant la publication du patch.

Étape 9 : audit de configuration avec Lynis

Lynis génère un score de hardening de 0 à 100 :

Lynis (Michael Boelen, CISOfy) audite le système et produit un score de hardening sur 100 ainsi qu’une liste de recommandations classées par sévérité. C’est l’outil de référence pour les audits CIS-aligned côté Linux.

sudo apt install lynis
sudo lynis audit system

Premier passage typique sur Ubuntu 24.04 fresh : 55-65/100. Après application du présent guide, viser 75-85/100. Au-delà de 90 nécessite des durcissements avancés (SELinux/AppArmor enforcing, sandboxing systemd unit-by-unit) qui peuvent casser des applications mal écrites.

Sur un VPS fraîchement déployé, le score est typiquement 55. Après application des étapes 1 à 8, vous montez à 75-80. Visez 85+. Le rapport liste les recommandations triées par priorité : sysctl, kernel modules, banners de connexion, permissions de fichiers. Implémentez les 10 premières chaque trimestre.

Dans la continuité

Combinez ce hardening avec notre guide Docker multi-stage pour des conteneurs eux aussi durcis, et notre tutoriel PostgreSQL extensions pour sécuriser la couche données.

Étape 10 : durcir le noyau via sysctl

Le noyau Linux expose des paramètres réseau critiques. Créez /etc/sysctl.d/99-hardening.conf :

net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.log_martians = 1
net.ipv6.conf.all.accept_redirects = 0
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
fs.suid_dumpable = 0

Appliquez avec sudo sysctl --system. Ces directives bloquent SYN flood, IP spoofing, redirections ICMP malveillantes, et limitent l’accès aux pointeurs noyau qui aident à exploiter une élévation de privilèges. Vérifiez avec sudo sysctl net.ipv4.tcp_syncookies.

Étape 11 : 2FA SSH avec Google Authenticator

Pour les VPS critiques (production, données clients), ajoutez un second facteur :

Activation de la 2FA TOTP sur SSH via PAM. google-authenticator génère un secret par utilisateur stocké dans ~/.google_authenticator. Les flags -t -d -f -r 3 -R 30 -W activent les options recommandées (time-based, no reuse, 3 tries per 30s, rate limiting).

sudo apt install libpam-google-authenticator
google-authenticator -t -d -f -r 3 -R 30 -W

Scanner le QR code avec Aegis (Android) ou Raivo (iOS) — applications open source recommandées sur Google Authenticator/Authy qui ont des historiques de fuites. Sauvegarder les 5 codes de récupération générés dans un coffre-fort hors-ligne. Ensuite, modifier /etc/pam.d/sshd pour ajouter la ligne auth required pam_google_authenticator.so.

Scannez le QR code avec une app comme Aegis Authenticator ou Authy. Éditez /etc/pam.d/sshd et ajoutez en haut auth required pam_google_authenticator.so. Dans /etc/ssh/sshd_config : ChallengeResponseAuthentication yes et AuthenticationMethods publickey,keyboard-interactive. Rechargez SSH. La connexion exige désormais clé Ed25519 + code 6 chiffres. Cette double barrière neutralise quasi totalement le vol de clé privée seule.

Étape 12 : journaux centralisés et alerting

Un VPS sans monitoring est un VPS aveugle. Installez Promtail + Loki sur un serveur dédié, ou utilisez le service géré Grafana Cloud (gratuit jusqu’à 50 Go logs/mois) :

Promtail (agent Grafana Loki) collecte les logs locaux et les pousse vers un Loki distant pour centralisation. Configuration dans /etc/promtail/config.yml : pointer vers le manager Loki, déclarer les fichiers de logs à suivre (/var/log/auth.log, /var/log/syslog, /var/log/nginx/*.log).

sudo apt install promtail
sudo systemctl enable --now promtail

Pour les opérateurs ouest-africains qui n’ont pas de SIEM cluster, un Loki hébergé chez Grafana Cloud (free tier 50 Go/mois) suffit largement pour 3-5 VPS de PME. Au-delà, basculer sur un Loki self-hosted devient économiquement justifié vers 15-20 VPS supervisés.

Configurez /etc/promtail/config.yml pour pousser les logs /var/log/auth.log, /var/log/nginx/access.log, et /var/log/fail2ban.log. Créez une alerte Grafana sur le pattern Failed password for invalid user dépassant 50 hits par minute : signal d’attaque distribuée. Une alerte SMS via Free Mobile API ou un webhook WhatsApp Business avertit l’équipe ops dans les 60 secondes.

Étape 13 : sauvegardes chiffrées hors-site

Une attaque ransomware sur le VPS doit être survivable. Mettez en place restic avec un backend S3-compatible (Wasabi, Backblaze B2, Scaleway Glacier) :

restic est l’outil de backup chiffré côté client le plus mature en 2026 (déduplication, snapshots, vérification d’intégrité). Le repo est protégé par un mot de passe — perdre ce mot de passe rend les backups définitivement inutilisables. Stocker le password dans un gestionnaire externe (1Password, Bitwarden), pas sur le serveur sauvegardé.

sudo apt install restic
export RESTIC_REPOSITORY=s3:s3.fr-par.scw.cloud/backups-vps
export RESTIC_PASSWORD=$(openssl rand -base64 32)
restic init
restic backup /etc /home /var/www
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Scaleway Object Storage (fr-par) coûte 0,01 €/Go/mois et accepte les paiements en EUR via cartes Mastercard prépayées (Wave, Orange Money) — accessible aux freelances ouest-africains. Tester la restauration trimestrielle via restic restore latest --target /tmp/restore-test est non-négociable : une sauvegarde non vérifiée n’existe pas.

Ajoutez la commande backup dans une cron quotidienne et stockez la clé restic dans un coffre-fort (1Password, Bitwarden Premium). Coût Scaleway Glacier : 0,002 EUR/Go/mois soit environ 1,3 FCFA/Go. Pour 50 Go de sauvegardes 12 mois, le budget annuel reste sous 800 FCFA. Testez la restauration une fois par trimestre.

Étape 14 : segmentation réseau pour multi-services

Si votre VPS héberge plusieurs services (Nginx, PostgreSQL, app Node), exécutez chacun dans son propre conteneur avec un réseau Docker dédié. Postgres ne doit jamais écouter sur 0.0.0.0 mais uniquement sur le réseau interne backend-net. Nginx-proxy reste seul exposé à internet.

Isolement réseau Docker. Le flag --internal crée un réseau sans accès Internet — PostgreSQL et l’API ne peuvent ni initier ni recevoir de connexion externe. Seul le reverse proxy en frontal (placé sur un second réseau) expose l’application.

docker network create --internal backend-net
docker run -d --name pg --network backend-net postgres:17-alpine
docker run -d --name api --network backend-net api:1.0
docker run -d --name proxy --network backend-net -p 443:443 nginx:1.27-alpine

Cette segmentation limite drastiquement le rayon de souffle d’une vulnérabilité dans l’API : même avec un RCE, l’attaquant ne peut pas pivoter vers Internet pour exfiltrer ou télécharger un payload. Combiné avec un user non-root dans le Dockerfile (USER 1000), c’est la base d’un containment correct.

Le flag --internal empêche le réseau d’accéder à internet, ce qui contient une compromission applicative : un attaquant qui prend le contrôle de l’API ne peut pas exfiltrer vers un serveur externe sans franchir une seconde barrière.

Étape 15 : revue trimestrielle et discipline

Le hardening n’est pas un projet à boucler, c’est une routine. Tous les trois mois, lancez Lynis, comparez le score à la mesure précédente, et traitez les nouveaux écarts. Mettez à jour les paquets manuellement sudo apt update && sudo apt full-upgrade en complément des unattended-upgrades. Vérifiez /var/log/auth.log et fail2ban.log pour repérer les nouvelles tendances d’attaque. Renouvelez les clés SSH chaque année et révoquez immédiatement celles d’un membre qui quitte l’équipe via ~/.ssh/authorized_keys. Cette discipline simple, appliquée par toutes les équipes ops sérieuses d’Afrique de l’Ouest, fait la différence entre un VPS qui sert vos clients pendant 5 ans et un VPS compromis dans le mois.

Étape 16 : checklist finale en 12 points

Avant de considérer un VPS comme prêt pour la production, validez chaque ligne. Utilisateur sudo non-root créé et testé. Connexion SSH par clé Ed25519 uniquement, mot de passe désactivé. Port SSH éventuellement déplacé. Fail2ban actif avec bantime 24h. UFW configuré en deny par défaut. Services inutiles désinstallés (rpcbind, avahi, cups). Unattended-upgrades activé pour les patches de sécurité. Sysctl durci (syncookies, rp_filter, kptr_restrict). 2FA SSH activé sur les VPS critiques. Logs centralisés vers Loki ou équivalent. Sauvegardes restic chiffrées hors-site testées. Lynis score supérieur à 80. Cette discipline transforme un VPS standard à 6 EUR/mois en serveur de production fiable, capable de servir des milliers d’utilisateurs en Afrique de l’Ouest francophone sans craindre la prochaine vague de bots ou de ransomware.

Étape 17 : runbook d’incident et rotation des secrets

Préparez un runbook écrit qui couvre les trois incidents les plus probables. Premier scénario : tentative de brute-force massive observée dans fail2ban — vérifier que la jail est active, augmenter bantime à 7 jours, prévenir l’hébergeur si l’attaque sature la bande passante. Deuxième scénario : clé SSH compromise — révoquer immédiatement la clé dans ~/.ssh/authorized_keys, générer une nouvelle paire Ed25519, auditer last pour identifier les connexions illégitimes, lancer chkrootkit et rkhunter. Troisième scénario : exploit applicatif et escalade — couper Nginx, geler le VPS, snapshot disque côté hébergeur, restaurer depuis restic une sauvegarde antérieure à l’incident, refaire le hardening complet sur la nouvelle instance. Documentez les coordonnées du support OVH ou Contabo et les délais d’intervention contractuels. Faire un exercice à blanc une fois par an, idéalement après une mise à jour majeure du noyau.