Un journal d'activité WordPress : savoir qui a modifié votre site, et quand
Ce que WordPress enregistre de lui-même, ce qu'il laisse de côté, ce que doit conserver un bon journal d'activité et comment savoir si quelqu'un en a supprimé des entrées.
Un administrateur que personne ne se souvient d'avoir ajouté apparaît sur votre site, ou une extension a disparu sans que l'on sache qui l'a retirée. La question est de savoir qui l'a fait, et quand. WordPress peut répondre en partie. Il garde l'historique des modifications du contenu des articles, mais il n'enregistre ni les connexions, ni les installations d'extensions, ni les changements de réglages. Pour cela, il faut un journal d'activité, c'est-à-dire une extension qui note ces événements, et pour tout ce qui est sérieux, aussi les journaux du serveur de votre hébergeur.
Cet article présente ce que vous pouvez voir sans outil supplémentaire, ce qu'un bon journal doit enregistrer, pourquoi un journal ordinaire dans la base de données peut être effacé discrètement et comment le détecter.
Ce que WordPress enregistre de lui-même
- Les révisions des articles et des pages. À chaque enregistrement du contenu, WordPress conserve une révision avec son auteur et son heure, sauf si votre hébergeur ou votre développeur a désactivé les révisions. Vous pouvez comparer deux révisions et restaurer une version plus ancienne.
- La date de dernière modification d'un article ou d'une page.
- La date d'inscription de chaque compte dans la liste des utilisateurs.
Ce qu'il n'enregistre pas : qui s'est connecté et quand, qui a installé, mis à jour ou supprimé une extension ou un thème, qui a changé le rôle d'un compte et qui a modifié les réglages.
Journaux du serveur : où chercher quand il n'y a pas de journal d'activité
Votre hébergeur conserve ses propres journaux : chaque requête adressée au site, avec l'adresse IP, l'heure et la page demandée. Le guide de durcissement de WordPress publié par WordPress.org (dans sa mise à jour du 14 octobre 2026) note que ces journaux n'indiquent pas quel nom d'utilisateur s'est connecté, mais montrent bien l'adresse IP, l'heure et les actions effectuées.
En pratique, cela demande beaucoup de fouille : des milliers de lignes, et aucun nom de compte. Les hébergeurs les gardent aussi pendant une durée limitée, demandez donc au vôtre combien de temps avant d'en avoir besoin. Un journal d'activité à l'intérieur de WordPress raconte la même histoire en termes clairs : le compte, l'événement, l'heure, l'adresse.
Ce qu'un bon journal d'activité doit enregistrer
- les connexions réussies et échouées, et les blocages après trop de tentatives,
- les nouveaux comptes, les changements de rôle et les comptes supprimés,
- les extensions et thèmes installés, mis à jour, désactivés et supprimés,
- les changements de thème et les mises à jour de WordPress,
- les modifications de réglages, surtout ceux de sécurité,
- les résultats d'analyse, si le journal fait partie d'une extension de sécurité.
Chaque entrée doit dire ce qui s'est passé, quand, depuis quel compte et depuis quelle adresse.
Le point faible de tout journal : il vit dans la même base de données
La plupart des journaux d'activité conservent leurs entrées dans la base de données du site. Quelqu'un qui accède à la base, par exemple par une faille dans une extension obsolète ou avec le mot de passe trouvé dans un fichier de sauvegarde laissé sur le serveur, peut supprimer les entrées qui le concernent. Un journal ordinaire n'a aucun moyen de remarquer qu'il manque quelque chose. Il affiche simplement un historique plus court.
Il y a deux façons de contourner ce problème :
- Envoyer une copie hors du serveur. Les entrées partent vers un service extérieur ou un autre serveur au fur et à mesure. Cela demande une mise en place, et souvent un service payant.
- Rendre les modifications visibles. C'est ce que veut dire « inviolable avec détection » (tamper-evident). Chaque entrée reçoit une signature calculée à partir de son contenu et de la signature de l'entrée précédente, avec une clé secrète qui n'est pas stockée dans la base de données. Modifier une entrée, ou en supprimer une au milieu, casse toutes les signatures à partir de ce point, et une vérification désigne l'entrée qui ne correspond plus.
La seconde approche n'empêche personne de supprimer des entrées. Elle fournit la preuve que cela s'est produit. Elle a aussi une limite : quelqu'un qui possède à la fois la base de données et le fichier contenant la clé peut recalculer toutes les signatures. C'est pourquoi, pour un incident sérieux, les journaux de votre hébergeur restent importants.
Comment juger une extension de journal d'activité
- Où elle stocke les entrées. Une table dédiée gère de grands volumes d'entrées. Un journal conservé comme un seul réglage plafonné à quelques centaines d'éléments perd vite les événements anciens.
- Combien de temps elle les garde, et si vous pouvez le changer. La durée doit couvrir le délai réaliste dans lequel vous remarquez un problème. Au-delà, ce sont des données que vous gardez sans raison.
- Si vous pouvez l'exporter. Un fichier CSV s'ouvre dans un tableur et peut accompagner une demande à votre développeur ou à votre hébergeur.
- Si les blocages noient les autres événements. Les robots peuvent produire des milliers de connexions échouées par jour. Si chacune est une entrée distincte dans le même ensemble, les événements qui comptent sont repoussés.
- Ce qu'elle conserve des connexions échouées. Il arrive que l'on saisisse son mot de passe dans le champ du nom d'utilisateur, si bien qu'un journal qui stocke chaque nom saisi peut finir par contenir des morceaux de mots de passe. Les adresses IP et les noms de compte peuvent constituer des données personnelles : un journal ne doit donc garder que le nécessaire et le supprimer après une durée fixée. L'article sur le RGPD et la sécurité d'un site détaille cet aspect.
- Si elle détecte les modifications de ses propres entrées. La description de l'extension doit le dire clairement.
Quand ouvrir le journal
- un administrateur apparaît sans que personne se souvienne de l'avoir ajouté,
- la page d'accueil a changé d'aspect ou envoie les visiteurs ailleurs,
- un e-mail indique qu'un compte administrateur a été bloqué,
- vous avez cessé de travailler avec une agence, ou quelqu'un est parti, et vous voulez voir ce qu'il a fait en dernier.
Exportez le journal, trouvez le premier événement inhabituel et notez son heure. Avec cette heure, les journaux de votre hébergeur sont bien plus faciles à examiner. Changez les mots de passe de l'administrateur et de la base de données depuis un ordinateur de confiance. L'article Les signes d'un site piraté traite de la première heure après une intrusion.
Comment Ensomedia Security procède
Ensomedia Security est une extension gratuite du répertoire WordPress.org que j'ai conçue pour ShieldWave. Son journal s'appelle Historique et fonctionne sans compte. Les faits, d'après sa fiche et son code :
- il enregistre les analyses, les problèmes trouvés et corrigés, les nouveaux administrateurs, les mises à jour, les changements de réglages et les blocages,
- les entrées sont conservées dans une table de base de données dédiée,
- chaque entrée porte une signature HMAC-SHA256 calculée avec le sel d'authentification du site (auth salt) de wp-config.php, qui n'est pas dans la base de données, et la signature inclut celle de l'entrée précédente,
- Vérifier l'intégrité de l'historique indique si une entrée a été modifiée ou supprimée en dehors de ShieldWave, et la suppression des entrées les plus récentes est aussi détectée,
- quelqu'un qui peut écrire dans la base de données mais ne peut pas lire wp-config.php ne peut ni modifier ni supprimer une entrée sans que la vérification le montre,
- les entrées de blocage sont regroupées et tenues hors de la chaîne de signatures : leur modification est détectée, leur suppression ne l'est pas,
- si vous remplacez les clés de sécurité dans wp-config.php, la vérification indique que les entrées plus anciennes ne peuvent plus être vérifiées, ce qui est normal après un renouvellement des clés, par exemple après une intrusion,
- les entrées sont conservées de 7 à 730 jours (90 par défaut) et peuvent être exportées en CSV,
- pour une connexion échouée, le nom d'utilisateur saisi n'est stocké que si ce compte existe. Sinon, seule son empreinte avec clé est conservée.
Ce n'est pas un pare-feu applicatif complet, et il ne nettoie pas les fichiers infectés. C'est vous, votre développeur ou votre hébergeur qui effectuez la modification qu'il explique. La page de l'extension énumère ses autres fonctions, et le guide écran par écran montre comment lire l'Historique au quotidien.
Que faire aujourd'hui
- Vérifiez si votre site a un journal d'activité, et depuis quand.
- Demandez à votre hébergeur combien de temps il conserve les journaux du serveur.
- Décidez combien de temps vous voulez garder les entrées, et réglez-le dans le journal.
- Une fois par mois, parcourez la liste des administrateurs et comparez-la au journal.
Vérifiez votre site depuis l'extérieur. Saisissez votre adresse sur shieldwave.io. Cela prend environ 90 secondes, sans mot de passe et sans extension.