# Premiers réflexes face à une alerte de sécurité nocturne : ce qu’un développeur doit vérifier > Une alerte tombe à trois heures du matin. Que vérifier avant de décider d'escalader ou de refermer le dossier sans plus attendre le matin ? - Auteur : WordPress Développement - Publié le : 2024-07-26 - Mis à jour le : 2024-07-26 - Catégorie : Sécurité - URL : https://www.wpmoderne.fr/securite/premiers-reflexes-alerte-securite-nocturne/ ## L’essentiel - Distinguer un faux positif d'un signal réel avant toute action - Vérifier trois sources avant de conclure quoi que ce soit - Documenter chaque étape, même en pleine nuit Que vérifier en premier quand une alerte de sécurité tombe en pleine nuit, avant de décider si elle mérite de réveiller quelqu'un d'autre ou peut attendre le matin ? Cette question, banale en apparence, concentre l'essentiel de la difficulté d'une astreinte sécurité : le jugement doit s'exercer vite, avec une attention réduite par l'heure, sur une information souvent incomplète. La checklist qui suit ne remplace pas une procédure d'astreinte formalisée propre à chaque équipe, mais couvre les vérifications de base qui permettent, en quelques minutes, de distinguer un faux positif d'un signal qui mérite une escalade immédiate. ## Étape 1 : identifier précisément la source de l'alerte Avant toute autre action, il faut établir d'où vient exactement l'alerte : un outil de supervision applicatif, un scanner de vulnérabilités programmé, une alerte de l'hébergeur sur une charge anormale, ou un signalement humain. Chaque source a un taux de fiabilité différent, et une alerte de scanner automatisé mérite un niveau de vérification différent d'un signalement d'hébergeur sur un pic de trafic sortant inhabituel. ## Étape 2 : croiser au moins deux sources avant de conclure Une seule alerte, même issue d'un outil réputé fiable, reste sujette au faux positif. Le réflexe à adopter consiste à croiser systématiquement l'alerte initiale avec au moins une seconde source : les journaux d'accès du serveur pour l'heure concernée, l'historique des connexions administrateur récentes, ou l'état du système de fichiers si l'alerte porte sur une modification de fichier suspecte. > L'essentiel à retenir : Distinguer un faux positif d'un signal réel avant toute action ; Vérifier trois sources avant de conclure quoi que ce soit ; Documenter chaque étape, même en pleine nuit Ce croisement rapide, souvent réalisable en moins de cinq minutes avec un accès SSH et quelques commandes de base, suffit dans la majorité des cas à écarter un faux positif sans avoir besoin d'escalader davantage. ## Étape 3 : vérifier l'intégrité des fichiers cœur si l'alerte le suggère Si l'alerte concerne une modification de fichier suspecte, la commande WP-CLI suivante permet une vérification rapide de l'intégrité du cœur WordPress par rapport à la version officielle publiée : ``` wp core verify-checksums ``` Un résultat positif (fichiers modifiés détectés) constitue un signal fort qui justifie une escalade immédiate, sans attendre le matin. Un résultat négatif ne suffit pas à écarter totalement une compromission — cette commande ne vérifie que les fichiers du cœur, pas les extensions ni les thèmes — mais réduit significativement l'incertitude en quelques secondes. ## Étape 4 : évaluer l'impact avant de décider d'escalader Toutes les alertes ne justifient pas un réveil d'astreinte à trois heures du matin. La décision d'escalader doit s'appuyer sur une évaluation rapide de l'impact potentiel : - Le site reste-t-il accessible et fonctionnel pour les visiteurs ? - Des données sensibles (paiement, informations personnelles) sont-elles potentiellement concernées ? - L'alerte indique-t-elle une action en cours, ou un événement déjà terminé ? Une alerte sur un événement déjà terminé, sans impact visible sur la disponibilité ou les données, peut généralement attendre une analyse plus approfondie au matin, avec une équipe reposée et davantage de contexte disponible. ## Étape 5 : documenter chaque étape, même en pleine nuit La tentation, à trois heures du matin, consiste à traiter l'alerte rapidement puis à se rendormir sans rien noter. Cette habitude coûte cher le lendemain : sans trace écrite de ce qui a été vérifié, l'équipe qui reprend le dossier au matin doit reproduire les mêmes vérifications depuis le début. Une note courte, même informelle — l'heure, la source de l'alerte, les vérifications effectuées, la conclusion — suffit à éviter cette perte de temps. ### Un modèle minimal de note d'astreinte ``` 03h12 - Alerte scanner : modification détectée sur wp-content/mu-plugins/ 03h14 - wp core verify-checksums : aucune modification du cœur 03h16 - Vérification journal FTP/SFTP : aucune connexion hors horaires habituels 03h18 - Fichier mu-plugin identifié : mise à jour légitime déployée à 02h58 par la CI 03h19 - Conclusion : faux positif lié au déploiement programmé. Pas d'escalade. ``` ## En résumé Face à une alerte de sécurité nocturne, le tri initial repose sur trois réflexes simples : identifier précisément la source, croiser au moins deux signaux avant de conclure, et documenter la démarche même sommairement. Cette discipline, appliquée systématiquement, évite à la fois les escalades inutiles qui épuisent une équipe d'astreinte et les incidents réels laissés sans suite faute de vérification suffisante.