Entretenir un site WordPress : sécurité, mises à jour, sauvegardes

D'où viennent les failles

Patchstack, une société qui vend de la protection pour les sites WordPress, a recensé 11 334 nouvelles failles dans l'écosystème WordPress en 2025, soit 42 % de plus qu'en 2024. Les extensions en concentraient 91 % et les thèmes 9 % ; le cœur de WordPress n'en a compté que 6, toutes de faible priorité¹.

Toutes ne menacent pas n'importe quel site. Wordfence, autre éditeur de sécurité, estime que plus de 68 % des failles publiées en 2024 présentaient un faible risque pour la plupart des sites, car elles demandent un compte sur le site ou une action de la victime². Patchstack classe 17 % des failles de 2025 comme graves, exploitables en masse¹.

Les failles graves sont exploitées vite : la moitié environ des failles à fort impact l'ont été dans les 24 heures qui ont suivi leur publication, et 46 % des failles n'avaient pas de correctif au moment d'être rendues publiques¹. Dans ce cas, on désactive ou on remplace l'extension en attendant.

Les failles anciennes restent visées : six des dix failles les plus attaquées en 2025 avaient été publiées les années précédentes, et les tentatives visaient des sites restés sur les versions vulnérables. Les extensions et thèmes payants, ou en partie payants, comptaient trois fois plus de failles réellement exploitées que les gratuits¹.

Ce que WordPress met à jour tout seul

Depuis la version 3.7, WordPress installe seul ses mises à jour mineures, celles de maintenance et de sécurité, par exemple de 3.8 à 3.8.1^3, 4. Depuis la version 5.6, les nouvelles installations reçoivent aussi automatiquement les versions majeures ; un site installé avant garde l'ancien réglage tant qu'un administrateur ne l'a pas changé⁵.

Les extensions et les thèmes ne se mettent à jour seuls que si l'administrateur l'active, extension par extension (ou par lot) et thème par thème, une possibilité apparue avec la version 5.5. WordPress lance alors ces mises à jour deux fois par jour et envoie un courriel après chaque tentative⁶.

La documentation conseille de pouvoir revenir à une version antérieure du site avant d'activer ces automatismes⁶, de sauvegarder avant toute mise à jour manuelle³ et, pour rattraper plus de deux versions majeures, de monter par étapes⁵. Les anciennes versions ne reçoivent plus de correctifs de sécurité, et une fois une faille corrigée, les informations pour l'exploiter sont presque toujours publiques⁴.

Les extensions abandonnées ou fermées

Wordfence considère comme abandonnée une extension sans mise à jour depuis deux ans, et conseille de remplacer ces extensions et de supprimer celles qui ne servent pas². Cybermalveillance.gouv.fr retient le même signe, une dernière mise à jour vieille de plusieurs années, et recommande de ne télécharger les extensions que sur le site officiel du CMS⁷.

Sur wordpress.org, la page d'une extension affiche une alerte si elle n'a pas été testée avec les trois dernières versions majeures de WordPress, qui en publie deux à trois par an. Une autre alerte signale une extension fermée, avec la date, puis, après 60 jours, le motif, par exemple une demande de l'auteur ou un problème de sécurité⁸. Une extension fermée ne se télécharge plus et ne s'installe plus depuis l'administration⁹ ; on en déduit qu'un site qui l'a déjà la garde, sans nouvelle version à attendre par ce canal.

La documentation demande de supprimer toute extension inutilisée⁴, et l'écran Santé du site, dans le menu Outils, liste les extensions et les thèmes inactifs¹⁰.

La version de PHP

WordPress est écrit en PHP¹⁰, dont la version dépend de l'hébergeur. Chaque version de PHP reçoit deux ans de corrections, puis deux ans de correctifs de sécurité seulement¹¹.

**Versions de PHP maintenues au 25 septembre 2026**Les versions antérieures à PHP 8.2 ne reçoivent plus aucun correctif
Version	Correctifs de sécurité jusqu'au
PHP 8.2	31 décembre 2026
PHP 8.3	31 décembre 2027
PHP 8.4	31 décembre 2028
PHP 8.5	31 décembre 2029

WordPress recommande PHP 8.3 ou plus récent, et MariaDB 10.11 ou MySQL 8.0 pour la base de données. Il fonctionne encore avec PHP 7.4 et MySQL 5.5.5, mais ces versions ont atteint leur fin de vie et peuvent exposer le site à des failles ; WordPress.org fournit un modèle de message à envoyer à son hébergeur¹². L'écran Santé du site signale une version de PHP dépassée comme un problème critique¹⁰.

Des sauvegardes qui se restaurent

Une sauvegarde WordPress a deux parties : la base de données, qui contient les articles, les commentaires et une grande partie des données du site, et les fichiers (cœur, thèmes, extensions, médias, configuration). Copier les fichiers ne copie pas la base, et il faut les deux pour restaurer¹³.

La documentation conseille une sauvegarde par semaine pour un petit site, une par jour pour un site très actif et une avant chaque mise à jour, et d'en garder trois à cinq récentes dans des endroits différents : serveur, stockage en ligne, ordinateur. Obtenir une copie des sauvegardes de l'hébergeur prend du temps¹³.

Plusieurs copies servent aussi après un piratage. Dans l'exemple de la documentation, un site compromis le 1er mai s'en aperçoit le 12 : avec une sauvegarde par semaine, il dispose encore d'une version antérieure à l'attaque⁴.

Cybermalveillance.gouv.fr recommande de tester la restauration et de déconnecter le support de sauvegarde après usage⁷. Le test consiste à restaurer la dernière sauvegarde sur une copie du site, les fichiers d'abord puis la base de données¹³, et à vérifier les pages, les images et les formulaires.

Les comptes et la double authentification

Hors réseau multisite, WordPress a cinq rôles : administrateur (accès à tout), éditeur (publie et gère tous les articles), auteur (publie les siens), contributeur (écrit sans publier) et abonné (gère son profil)¹⁴. Cybermalveillance.gouv.fr recommande peu d'administrateurs, des droits limités au nécessaire et des comptes nominatifs plutôt que partagés⁷ : pour publier les actualités, le rôle d'éditeur suffit.

D'après Wordfence, 34 % des failles publiées en 2024 demandaient au moins un compte de contributeur² : les comptes des personnes parties se suppriment. Un compte administrateur volé permet d'installer du code malveillant⁴. La documentation déconseille l'identifiant admin et recommande la double authentification pour tous les administrateurs ; le cœur de WordPress ne l'intègre pas, elle s'ajoute par une extension ou un fournisseur d'identité¹⁵.

La liste d'entretien

Chaque semaine

Ouvrir Tableau de bord, puis Mises à jour, et appliquer ce qui attend, après une sauvegarde.
Lire les courriels des mises à jour automatiques et reprendre celles qui ont échoué.
Vérifier que la sauvegarde de la semaine existe ailleurs que sur le serveur.
Ouvrir les pages principales et envoyer un message de test par le formulaire de contact.

Chaque mois

Restaurer la dernière sauvegarde sur une copie du site et la vérifier.
Ouvrir Outils, puis Santé du site, et traiter les problèmes critiques.
Consulter la page de chaque extension sur wordpress.org (fermeture, version non testée, dernière mise à jour) et supprimer les extensions et thèmes inactifs.
Passer les comptes en revue : départs, rôles, double authentification.

Chaque année

Vérifier la version de PHP et sa fin de maintenance, et prévoir le changement avec l'hébergeur.
Retirer les extensions dont le site peut se passer.
Vérifier les échéances de l'hébergement et du nom de domaine : un nom non renouvelé peut être repris par un tiers⁷.
Renouveler les mots de passe des administrateurs et de l'hébergement⁷.

Le temps que cela représente

Aucune des sources citées ne chiffre ce temps ; ce qui suit est une estimation. Pour un site vitrine d'une dizaine d'extensions, chez un hébergeur qui permet une copie de test, la liste demande environ un quart d'heure par semaine, une heure par mois et deux à trois heures par an, soit 25 à 30 heures par an, hors incidents : mise à jour qui casse une page, extension à remplacer, piratage.

Quand WordPress est le bon choix

Entretenu, WordPress a des atouts : un cœur qui n'a compté que six failles en 2025¹, plus de 73 000 extensions gratuites dans le répertoire officiel¹⁶, des conditions techniques remplies par la plupart des hébergeurs¹⁷ et un export XML des articles, des pages et des commentaires¹⁸. Il convient à une structure qui publie souvent ou qui a besoin d'extensions, et qui a quelqu'un, en interne ou chez un prestataire, pour tenir cette liste.