Plan de maintenance WordPress mensuel : checklist complète

Pourquoi instaurer une maintenance mensuelle WordPress

Une maintenance mensuelle ne remplace ni la surveillance quotidienne d’un site critique, ni les sauvegardes automatisées, ni les contrôles effectués avant chaque mise en production. Elle joue un autre rôle : prendre du recul, vérifier que les mécanismes censés protéger le site fonctionnent réellement et supprimer les fragilités accumulées au fil des semaines. WordPress recommande d’inscrire l’entretien dans un calendrier régulier, avec notamment les mises à jour, les sauvegardes, l’examen des extensions et le contrôle des liens. ([wordpress.org](https://wordpress.org/documentation/article/wordpress-site-maintenance/?utm_source=openai))

Le bon rythme dépend de l’activité. Un site e-commerce, un média, une plateforme d’adhésion ou un site recevant de nombreux formulaires ne doit pas attendre un mois pour découvrir une panne de paiement, de connexion ou d’envoi d’e-mail. En revanche, une revue mensuelle reste utile à tous les sites : elle permet de confirmer l’état des sauvegardes, d’examiner les accès, de traiter les alertes techniques et de documenter les décisions prises.

La page Santé du site de WordPress présente les problèmes selon trois niveaux : problèmes critiques, améliorations recommandées et tests réussis. C’est une base pratique pour organiser la revue mensuelle. ([wordpress.org](https://wordpress.org/documentation/article/site-health-screen/?utm_source=openai))

Cette checklist est volontairement stratégique. Elle ne consiste pas à cliquer aveuglément sur « mettre à jour ». Chaque étape répond à une question opérationnelle : pourra-t-on revenir en arrière si nécessaire, les personnes qui ont accès au site en ont-elles toujours besoin, les fonctions importantes répondent-elles correctement, et les signaux de lenteur ou d’indisponibilité exigent-ils une investigation ?

Avant de commencer : préparer la routine et fixer les priorités

Planifiez ce rendez-vous à une date récurrente et choisissez un créneau où le trafic est habituellement plus faible si vous devez intervenir sur un site en production. Centralisez dans une note interne les accès nécessaires, la procédure de restauration, l’emplacement des sauvegardes, les URL de pages importantes, les adresses de réception des formulaires et les contacts de l’hébergeur. Une checklist qui dépend de la mémoire d’une seule personne finit souvent par être incomplète.

Utilisez trois niveaux simples. Priorité critique : tout ce qui compromet la disponibilité, la restauration, la confidentialité ou l’intégrité du site. Priorité haute : un défaut visible ou une dette technique susceptible d’affecter la sécurité, la conversion ou le référencement. Priorité normale : les améliorations, le rangement et les observations à suivre le mois suivant. Cette hiérarchie évite qu’un nettoyage cosmétique fasse perdre du temps alors qu’une sauvegarde est inutilisable.

À préparer une fois : une liste de pages et d’actions vitales, par exemple accueil, page de contact, tunnel de commande, connexion, recherche interne ou prise de rendez-vous.
À consigner chaque mois : la date, la personne responsable, les anomalies observées, les mises à jour appliquées, la preuve de sauvegarde et les actions reportées.
À ne pas confondre : une sauvegarde créée n’est pas une restauration vérifiée ; une alerte résolue n’est pas forcément une cause identifiée.

Étape 1 : contrôler et appliquer les mises à jour

Fréquence : mensuelle, avec suivi plus rapproché lorsque le site est sensible. Priorité : critique si une mise à jour de sécurité ou un correctif lié à une vulnérabilité concerne un composant installé.

Commencez par relever les mises à jour disponibles pour le cœur WordPress, les extensions, les thèmes et, selon votre environnement, la version de PHP. La documentation officielle indique qu’il faut sauvegarder le site avant une mise à jour afin de pouvoir le restaurer en cas de problème. Elle précise aussi que les mises à jour mineures et de sécurité du cœur peuvent être appliquées automatiquement en arrière-plan sur les installations compatibles. ([wordpress.org](https://wordpress.org/documentation/article/updating-wordpress/?utm_source=openai))

Ne réduisez pas cette étape à la mise à jour du cœur. Les extensions ont un accès profond aux fonctionnalités du site, ce qui explique que Santé du site considère les extensions en attente de mise à jour comme un point important. L’écran fournit aussi les versions installées, l’état des mises à jour automatiques et la liste des thèmes ou extensions actifs et inactifs. ([wordpress.org](https://wordpress.org/documentation/article/site-health-screen/?utm_source=openai))

Contrôler : les notes de version, les prérequis techniques et les éventuels changements fonctionnels annoncés par les éditeurs.
Sauvegarder : les fichiers et la base de données avant l’opération.
Mettre à jour : d’abord sur un environnement de préproduction lorsque le site dispose de personnalisations, de commerce en ligne ou de connexions à des services externes.
Tester après mise à jour : les pages essentielles, la connexion à l’administration, les formulaires, les paiements si concernés et les tâches automatisées.
Nettoyer : supprimer les extensions et thèmes inutilisés après validation. WordPress recommande de retirer les thèmes inactifs qui ne sont pas prévus pour être réutilisés. ([wordpress.org](https://wordpress.org/documentation/article/site-health-screen/?utm_source=openai))

Conservez au minimum un thème par défaut pertinent pour le diagnostic, sans multiplier les thèmes dormant inutilement. En revanche, ne supprimez pas un composant dont le rôle n’est pas identifié : notez-le, vérifiez ses dépendances et validez son retrait sur préproduction. La simplification est utile seulement lorsqu’elle est maîtrisée.

Étape 2 : vérifier la sauvegarde par un test de restauration

Fréquence : contrôle mensuel ; test de restauration selon le niveau de risque, au minimum de façon planifiée et documentée. Priorité : critique.

Une sauvegarde doit couvrir ce qui permet de reconstruire le site : les fichiers WordPress, les thèmes, les extensions, les médias et la base de données. La documentation WordPress recommande des sauvegardes régulières incluant les bases MySQL et souligne l’importance de l’intégrité des données de sauvegarde. Elle évoque aussi l’intérêt de conserver des instantanés à intervalles réguliers dans un emplacement de confiance. ([developer.wordpress.org](https://developer.wordpress.org/advanced-administration/security/hardening/?utm_source=openai))

Le contrôle mensuel commence par des questions simples : la dernière sauvegarde a-t-elle bien abouti, contient-elle les fichiers et la base attendus, est-elle stockée dans un emplacement distinct du serveur de production, et la personne responsable peut-elle y accéder ? Vérifiez également la durée de conservation réellement disponible. Une série de sauvegardes trop courte peut être insuffisante si une compromission ou une corruption n’est détectée que plusieurs jours plus tard.

Le test le plus utile consiste à restaurer une sauvegarde sur un environnement isolé, jamais par réflexe sur le site en ligne. Vérifiez que l’administration s’ouvre, que le thème et les médias sont présents, que les pages importantes répondent et que les fonctions indispensables marchent. Le cours Learn WordPress conseille de sauvegarder avant les mises à jour, l’installation d’extensions ou de thèmes, les migrations et après des changements importants de contenu. ([learn.wordpress.org](https://learn.wordpress.org/lesson/how-to-backup-your-site/?utm_source=openai))

À valider : date de la dernière sauvegarde réussie, emplacement, accès et périmètre fichiers plus base de données.
À tester : une restauration sur une copie isolée, puis la connexion et les parcours essentiels.
À documenter : le temps nécessaire, les prérequis, les erreurs rencontrées et la personne capable d’exécuter la procédure.

Étape 3 : revoir les comptes, les rôles et les accès

Fréquence : mensuelle. Priorité : critique pour les comptes administrateurs et les accès d’hébergement.

Dans Santé du site, la section d’informations affiche notamment le nombre d’utilisateurs et indique si l’inscription est ouverte. Profitez-en pour rapprocher ce constat de la liste des comptes dans l’administration. ([wordpress.org](https://wordpress.org/documentation/article/site-health-screen/?utm_source=openai)) Supprimez ou désactivez les accès des prestataires, salariés ou comptes de test qui n’ont plus de raison d’exister, après avoir réattribué les contenus si nécessaire. Réduisez aussi les privilèges : un compte qui publie des contenus n’a pas automatiquement besoin des droits d’administration.

La documentation de durcissement de WordPress rappelle qu’une personne qui obtient l’accès à un compte administrateur peut installer des scripts malveillants susceptibles de compromettre le serveur. Elle recommande également d’éviter les identifiants administrateur faciles à deviner, tels que « admin » ou « webmaster ». ([developer.wordpress.org](https://developer.wordpress.org/advanced-administration/security/hardening/?utm_source=openai))

Vérifier : la liste des administrateurs, les comptes inactifs, les comptes génériques et les accès au compte d’hébergement.
Corriger : les rôles trop larges, les accès devenus inutiles et les mots de passe ou méthodes d’authentification qui ne respectent pas votre politique interne.
Examiner : les adresses e-mail de récupération et les destinataires des alertes techniques.

Étape 4 : exécuter le contrôle de sécurité et examiner Santé du site

Fréquence : mensuelle, plus souvent si le site reçoit beaucoup de trafic ou traite des données sensibles. Priorité : critique lorsqu’un résultat signale un fichier inattendu, une vulnérabilité ou une modification non expliquée.

Lancez le scan de votre solution de sécurité si vous en utilisez une, puis traitez les résultats avec méthode. Un avertissement n’est pas nécessairement une infection ; il peut aussi provenir d’une personnalisation ou d’un fichier légitime. À l’inverse, ne classez pas automatiquement une alerte comme faux positif. Vérifiez l’origine, la date du changement, le composant concerné et la possibilité de restaurer une version saine avant toute suppression.

Pour les extensions provenant du répertoire WordPress.org, WP-CLI propose une commande qui vérifie les fichiers des extensions par rapport aux sommes de contrôle de WordPress.org. Cet outil ne remplace pas une analyse complète, mais il peut contribuer à repérer des écarts sur les extensions concernées. ([developer.wordpress.org](https://developer.wordpress.org/cli/commands/plugin/verify-checksums/?utm_source=openai))

Ouvrez ensuite Outils puis Santé du site. WordPress y rassemble les alertes de sécurité et de performance, ainsi que des informations sur la base de données, le serveur, les droits des fichiers, les extensions et les thèmes. Les problèmes critiques méritent une décision immédiate : correction, escalade vers l’hébergeur ou ajout dans un plan de remédiation avec responsable et échéance. ([wordpress.org](https://wordpress.org/documentation/article/site-health-screen/?utm_source=openai))

Étape 5 : contrôler la base de données sans optimisation aveugle

Fréquence : mensuelle pour l’observation ; intervention lorsque les données ou les symptômes le justifient. Priorité : haute.

La base de données contient une part essentielle du contenu et de la configuration du site. Santé du site expose des informations techniques sur la base et indique aussi la taille de la base, des répertoires, des extensions, des thèmes et des téléversements. Cette vue permet de détecter une croissance inhabituelle et d’orienter l’enquête. ([wordpress.org](https://wordpress.org/documentation/article/site-health-screen/?utm_source=openai))

Relevez les tendances plutôt que de chercher un chiffre universel de « bonne » taille. Une hausse peut être normale après l’ajout de médias, de commandes ou de contenu. Elle devient un signal à examiner si elle est inexpliquée, si les sauvegardes grossissent fortement, si l’espace disque approche de sa limite ou si l’administration devient lente. Vérifiez les éléments à supprimer avec prudence : commentaires indésirables, brouillons, révisions, données temporaires ou tables créées par d’anciennes extensions.

Ne lancez pas une opération d’optimisation de tables simplement parce qu’un outil la propose. Sauvegardez d’abord, identifiez le gain attendu et validez la compatibilité avec les extensions actives, particulièrement sur un site transactionnel. La maintenance vise la fiabilité, pas la réduction d’un indicateur sans contexte.

Étape 6 : contrôler uptime, formulaires et e-mails

Fréquence : mensuelle pour l’audit ; surveillance automatisée recommandée entre deux revues pour les sites importants. Priorité : critique pour les parcours qui génèrent des demandes, des ventes ou des inscriptions.

Consultez l’historique de votre outil de supervision si vous en avez un : incidents, durée, code de réponse, fréquence et cause connue. Un simple contrôle manuel de la page d’accueil ne suffit pas toujours, car le site peut afficher une page alors que l’administration, un paiement, une API ou l’envoi d’e-mail est défaillant. Si vous ne disposez pas de supervision, créez au moins une liste de pages à ouvrir chaque mois depuis une session non connectée.

Testez un formulaire réel avec une adresse de réception contrôlée. Vérifiez le message de confirmation côté visiteur, la réception du message, les champs transmis, les éventuelles automatisations et la présence dans le système tiers si le formulaire alimente un CRM ou une solution marketing. Pour un e-commerce, ajoutez un test de panier et du moyen de paiement prévu par votre procédure interne. Ne saisissez pas de données personnelles réelles dans un environnement de test.

Ajoutez à ce contrôle les tâches planifiées. WordPress indique que les requêtes de bouclage servent notamment à exécuter des événements programmés ; une erreur de bouclage peut donc affecter des fonctions planifiées. Santé du site signale ce type de problème lorsqu’il le détecte. ([wordpress.org](https://wordpress.org/documentation/article/site-health-screen/?utm_source=openai))

Étape 7 : mesurer la vitesse et vérifier les pages clés

Fréquence : mensuelle, et après une modification importante. Priorité : haute lorsque la régression est nette ou touche une page stratégique.

Mesurez toujours les mêmes pages représentatives : accueil, contenu éditorial, page de contact, page produit ou tunnel selon le site. Google recommande de mesurer avant d’améliorer : PageSpeed Insights s’appuie sur des métriques orientées utilisateur et aide à identifier des pistes d’amélioration. Les Core Web Vitals couvrent notamment le chargement perçu, la stabilité visuelle et la réactivité aux interactions. ([web.dev](https://web.dev/performance?hl=fr&utm_source=openai))

Comparez les résultats à vos mesures précédentes plutôt qu’à une quête abstraite du score parfait. Notez les changements de thème, d’extension, de scripts tiers, de médias ou de configuration de cache intervenus depuis le dernier relevé. Une baisse identifiée tôt est plus facile à rapprocher d’un changement technique. Vérifiez également en navigation réelle les pages lentes signalées par les données ou les retours utilisateurs.

Le modèle de routine mensuelle en 30 à 60 minutes

Sur un petit site vitrine dont les sauvegardes, la surveillance et les procédures sont déjà en place, prévoyez environ 30 minutes. Sur un site plus vaste, multi-utilisateur, avec commerce, formulaires connectés ou préproduction, prévoyez plutôt 60 minutes, sans compter une restauration de test complète ou une intervention technique qui doit être planifiée séparément.

Minutes 0 à 5 : ouvrir le journal du mois précédent, consulter l’uptime et relever les alertes nouvelles.
Minutes 5 à 15 : vérifier la sauvegarde, confirmer l’accès à son emplacement et programmer ou réaliser le test de restauration selon votre calendrier.
Minutes 15 à 25 : examiner les mises à jour, effectuer la sauvegarde préalable, appliquer les mises à jour validées puis tester les fonctions critiques.
Minutes 25 à 35 : revoir administrateurs, comptes inactifs et rôles ; lancer le scan de sécurité et consulter Santé du site.
Minutes 35 à 45 : contrôler la taille et les signaux de la base de données, tester un formulaire et vérifier la réception de l’e-mail.
Minutes 45 à 60 : mesurer les pages clés, consigner les résultats, attribuer les actions restantes et fixer leur échéance.

La valeur de cette routine ne vient pas d’une liste cochée à toute vitesse. Elle vient de la répétition, de preuves conservées et de décisions attribuées. Si une étape dépasse le temps prévu, ne la masquez pas : transformez-la en ticket, notez le risque, désignez un responsable et conservez une sauvegarde exploitable. C’est ainsi qu’une checklist mensuelle devient un véritable dispositif de maintenance WordPress.