La checklist de maintenance WordPress : chaque semaine, chaque mois, chaque trimestre

par Francis Rozange | Oct 2, 2026 | WordPress

Four concentric glass rings turning at different speeds around a glowing core

Le 10 mars 2026, le propriétaire d’un site WordPress reçoit un message de son hébergeur : son site s’est mis à jour tout seul vers la version 6.9.2, une mise à jour de sécurité publiée environ une heure et demie plus tôt. Quelques minutes plus tard, il écrit sur le forum d’assistance de WordPress : toutes les pages publiques s’affichent blanches. L’administration fonctionne, le contenu est intact, mais les visiteurs ne voient plus rien.

La version corrective arrivera environ huit heures après la publication de la 6.9.2. Et quinze jours plus tard, l’équipe de sécurité de WordPress publiera un retour d’expérience dont une phrase résume tout : il manquait une ligne à sa propre liste de vérifications.

La maintenance d’un site WordPress demande bien plus qu’un clic sur « Mettre à jour » : un rythme, un responsable pour chaque tâche, un outil, et une vérification après chaque action. Ce guide propose cette liste, organisée par fréquence : ce qui s’automatise, ce qui se fait chaque semaine, chaque mois et chaque trimestre.

Pourquoi un calendrier plutôt qu’un réflexe

Le rythme des mises à jour

WordPress a publié deux versions majeures en 2025, puis vise trois versions majeures en 2026, environ une tous les quatre mois : la 7.0 en mai, la 7.1 en août, la 7.2 attendue en décembre. Entre les versions majeures, les versions mineures s’enchaînent : la branche en cours en a compté dix au cours des neuf premiers mois de 2026, dont sept versions de sécurité.

Ces versions mineures s’installent automatiquement par défaut. Les versions majeures aussi, mais seulement sur les installations créées depuis WordPress 5.6. Les mises à jour automatiques des plugins et des thèmes doivent en revanche être activées une à une.

Ce calendrier lui-même bouge. En avril 2025, le projet avait annoncé une seule version majeure par an, parce que des procédures judiciaires en cours mobilisaient une partie des ressources ; la 6.9 est pourtant sortie en décembre 2025, et le plan pour 2026 revient à trois versions. Votre liste de maintenance ne peut donc pas reposer sur un calendrier fixe : elle doit absorber une mise à jour à tout moment.

Le rythme des menaces

Selon le rapport de Patchstack publié en février 2026, 91 % des nouvelles vulnérabilités découvertes en 2025 dans l’univers WordPress touchaient des plugins. Près de la moitié n’avaient pas de correctif au moment de leur publication. Et environ la moitié des failles à fort impact étaient exploitées dans les vingt-quatre heures. Une tournée de mises à jour hebdomadaire est donc trop lente pour les failles critiques : elles relèvent des mises à jour automatiques ou d’un pare-feu applicatif.

Notre analyse des chiffres des vulnérabilités WordPress détaille ces données et leurs limites.

Un responsable par ligne

Chaque ligne de la liste qui suit indique un responsable. Le propriétaire du site, ou le responsable des contenus, valide ce qui touche à l’activité. Le technicien, interne ou prestataire, exécute. L’hébergeur prend en charge ce que son offre couvre, et chaque tâche reste attribuée à une personne nommée.

Le cas réel : WordPress 6.9.2, une mise à jour de sécurité et une page blanche

L’épisode de mars 2026 est documenté par les annonces officielles de WordPress, le forum d’assistance, le retour d’expérience de l’équipe de sécurité et Search Engine Journal. Il concerne WordPress lui-même, et il apprend plus sur la maintenance que n’importe quelle liste générique.

Une mise à jour de sécurité ordinaire

Le 10 mars 2026, WordPress publie la version 6.9.2, qui corrige dix failles de sécurité. L’annonce précise que les sites dotés des mises à jour automatiques la recevront sans rien faire, et que des correctifs seront reportés sur les anciennes branches jusqu’à la version 4.7.

Moins de deux heures plus tard, un signalement arrive sur le forum : un site hébergé chez DreamHost, avec le thème Crio, affiche des pages blanches, même le code source est vide. D’autres utilisateurs signalent le même symptôme. Un bénévole conseille de consulter le journal d’erreurs et de tester un thème par défaut.

La cause et le correctif

Un peu plus tard, John Blackbourn, qui dirigeait la publication, intervient dans la discussion : il semble s’agir d’une incompatibilité avec des thèmes qui utilisent un certain cadre de développement. Ces thèmes chargeaient leurs modèles d’une façon que WordPress ne prend pas officiellement en charge, et une vérification ajoutée par la 6.9.2 les bloquait. Un membre de la communauté propose de restaurer un seul fichier de la version précédente.

Environ huit heures après la 6.9.2, la version 6.9.3 corrige le problème. Le lendemain, un nouveau signalement révèle que trois des dix correctifs de sécurité n’avaient pas été intégrés à la branche 6.9 : la version 6.9.4 les livre dans la journée. Les trois versions sont sorties en moins de vingt-quatre heures, et les sites en mise à jour automatique ont suivi sans intervention.

La ligne qui manquait

Le 25 mars, l’équipe de sécurité publie son retour d’expérience. Les intégrations oubliées relèvent d’une erreur humaine, mais rien dans le processus de publication ne vérifiait indépendamment que tous les correctifs avaient bien été intégrés. Le texte le reconnaît : un oubli dans la liste de vérifications, qu’on n’avait jamais repéré. L’équipe annonce la mise à jour de cette liste, avec une double vérification des intégrations et une règle claire : aucune étape ne se saute sans raison écrite.

Ce qu’il faut en retenir

Les versions mineures arrivent à l’heure de WordPress, pas à la vôtre : une préproduction ne peut pas s’interposer, c’est la vérification après mise à jour qui protège.
L’administration fonctionnait, le site public était vide : seul un contrôle du contenu des pages publiques, ou un humain qui regarde le site, détecte ce genre de panne.
Le propriétaire a appris la mise à jour par l’hébergeur : les notifications de mise à jour doivent être lues.
Couper les mises à jour automatiques aurait été la mauvaise réponse : la 6.9.4 apportait des correctifs de sécurité le lendemain.
Une liste de vérifications vit : chaque « faire » doit être suivi d’un « vérifier ».

Chaque jour, sans vous : ce qu’il faut automatiser

Les sauvegardes

Une sauvegarde automatique quotidienne de la base et des fichiers, stockée hors du serveur, est le socle de tout le reste. Elle relève de l’hébergeur ou d’un plugin, choisie parmi les plugins de sauvegarde WordPress que nous avons comparés. Responsable : l’hébergeur ou le technicien.

Les mises à jour automatiques

Gardez les mises à jour mineures de WordPress automatiques. Activez-les aussi pour les plugins à faible risque, bien maintenus, et réservez les plugins critiques, comme WooCommerce ou un constructeur de pages, à une mise à jour manuelle après test. Depuis WordPress 6.6, une mise à jour automatique de plugin qui provoque une erreur fatale de PHP est annulée et l’ancienne version restaurée. Mais ce filet ne détecte que les erreurs fatales : une mise en page cassée ou un tunnel de commande défaillant passent au travers.

La surveillance de disponibilité, des certificats et du domaine

Un service de surveillance vérifie que le site répond. Mais l’épisode de mars 2026 montre qu’un serveur qui répond ne suffit pas : préférez une surveillance par mot-clé, qui vérifie qu’un texte précis figure bien dans le code des pages publiques. Le moniteur gratuit de Jetpack interroge la page d’accueil toutes les cinq minutes, mais ne regarde que le code de réponse, pas le contenu ; UptimeRobot propose cinquante moniteurs gratuits, surveillance par mot-clé comprise, mais réserve la surveillance des certificats et des domaines à ses offres payantes.

Les alertes d’expiration de certificat et de nom de domaine deviennent indispensables. Let’s Encrypt a cessé d’envoyer ses courriels d’expiration le 4 juin 2025, et recommande lui-même une surveillance pour détecter un renouvellement qui n’a pas eu lieu.

Ce que WordPress fait déjà seul

WordPress vérifie les mises à jour deux fois par jour, lance une analyse de la Santé du site chaque semaine, supprime chaque jour les données temporaires expirées et vide la corbeille au bout de trente jours. Ces tâches dépendent toutefois de WP-Cron, qui ne se déclenche qu’avec les visites : sur un site peu fréquenté, mieux vaut le remplacer par une vraie tâche planifiée du serveur.

Déclarez aussi le type d’environnement de chaque copie avec la constante WP_ENVIRONMENT_TYPE : production pour le site en ligne, staging pour la préproduction. Certains plugins s’en servent, comme WooPayments, qui n’accepte que des comptes de test quand la constante vaut staging ou development, et certains tests de la Santé du site, comme ceux du cache de pages, ne s’exécutent qu’en production.

Chaque semaine : quinze à trente minutes

Les mises à jour, avec un passage en préproduction

Une fois par semaine, le technicien passe en revue les mises à jour en attente et les courriels de mises à jour automatiques. Ce qui est mineur et à faible risque part en production.

Ce qui est majeur, pour WordPress, WooCommerce ou un constructeur de pages, passe d’abord par une copie du site ; sur une installation qui reçoit aussi les versions majeures automatiquement, limitez d’abord les mises à jour automatiques de WordPress aux versions mineures. En ligne de commande, un essai à blanc montre ce qui serait mis à jour, comme l’explique notre sélection de commandes WP-CLI essentielles :

wp core check-update
wp plugin update --all --dry-run

Le jour d’une version de sécurité, on n’attend pas le créneau hebdomadaire : on applique dans la journée.

Les filets de sécurité de WordPress ont leurs limites. Une mise à jour de WordPress qui échoue est annulée depuis la version 3.7, une mise à jour manuelle de plugin depuis la 6.3, une mise à jour automatique de plugin depuis la 6.6. Mais aucun ne vérifie que la page d’accueil affiche le bon contenu ou que le paiement fonctionne : ce contrôle reste humain.

Après chaque mise à jour : vérifier le site public

Après chaque mise à jour, ouvrez le site comme un visiteur : la page d’accueil, une page de contenu, un formulaire, et pour une boutique, le panier et la commande jusqu’au paiement en mode test. C’est la vérification qui aurait détecté en quelques minutes les pages blanches de mars 2026. Vérifiez aussi l’intégrité des fichiers de WordPress :

wp core verify-checksums

Un coup d’œil aux alertes

Parcourez le widget Santé du site du tableau de bord et les alertes de surveillance de la semaine. Une alerte ignorée trois semaines de suite cesse d’être lue : traitez sa cause ou réglez son seuil.

Une colonne de tuiles de verre lumineuses dont une seule reste vide et sombre

Chaque mois : une à deux heures

La revue de la Santé du site

L’écran Santé du site, dans le menu Outils, classe ses tests en problèmes critiques, améliorations recommandées et tests réussis. Lisez-le en entier une fois par mois. Il signale notamment une tâche planifiée en retard ou en échec, des mises à jour en arrière-plan qui ne fonctionnent pas, un site qui décourage les moteurs de recherche, ou des options chargées automatiquement trop volumineuses, au-delà de 800 Ko.

Mais la Santé du site ne vérifie ni les sauvegardes, ni l’expiration du certificat, ni celle du domaine, ni les plugins retirés du répertoire, ni les comptes administrateurs : c’est pour cela que le reste de cette liste existe. Notre article sur les erreurs WordPress à éviter détaille ses signaux les plus utiles.

Les journaux d’erreurs

Une fois par mois, parcourez le journal d’erreurs de PHP de l’hébergement, ou celui de WordPress si la constante WP_DEBUG_LOG est activée sur la copie de test. Les avertissements répétés annoncent souvent la panne de la prochaine mise à jour. Depuis WordPress 5.2, une erreur fatale déclenche aussi l’envoi d’un courriel à l’adresse d’administration, avec un lien vers un mode de récupération : encore une raison de vérifier que cette adresse est lue.

Les liens cassés et les erreurs 404

Dans la Search Console, le rapport d’indexation des pages liste les adresses en erreur 404. Google prévient qu’une page vide peut aussi y apparaître comme une « soft 404 ». Côté site, le plugin Broken Link Checker, plus de 500 000 installations, analyse les liens en ligne ou sur votre serveur, et le plugin Redirection, plus de deux millions d’installations, permet de rediriger les adresses perdues.

La performance mesurée sur le terrain

Le rapport Core Web Vitals de la Search Console s’appuie sur les données réelles de Chrome, sur une fenêtre de vingt-huit jours. Une revue mensuelle colle donc à son rythme. Après une modification importante, testez avec PageSpeed Insights, puis attendez quatre semaines pour confirmer sur le terrain, comme le détaille notre guide des correctifs Core Web Vitals.

La base de données

Surveillez la taille de la base dans l’onglet Informations de la Santé du site, et celle des options chargées automatiquement dans le test qui leur est consacré, onglet État. Par défaut, WordPress conserve un nombre illimité de révisions ; une ligne dans wp-config.php les limite :

define( 'WP_POST_REVISIONS', 3 );

Les données temporaires expirées se suppriment avec wp transient delete --expired, après une sauvegarde. Notre guide de l’optimisation de la base de données WordPress va plus loin.

Les sauvegardes, vérifiées

Une fois par mois, vérifiez que la dernière copie hors serveur existe, qu’elle est récente et qu’elle a une taille plausible. Une sauvegarde qui échoue en silence depuis trois mois est un classique.

Chaque trimestre : une demi-journée

Le test de restauration

L’agence américaine de cybersécurité CISA recommande de tester la procédure de sauvegarde pour s’assurer de pouvoir restaurer rapidement les données, en totalité ou en partie. Une fois par trimestre, restaurez la dernière sauvegarde sur une copie du site, chronométrez l’opération, connectez-vous et parcourez les pages clés. Plusieurs hébergeurs proposent la restauration directe vers un site de préproduction, ce qui rend l’exercice simple.

Refaites ce test après tout changement d’hébergeur ou d’outil de sauvegarde : tant qu’une sauvegarde n’a pas été restaurée, rien ne prouve qu’elle fonctionne.

L’audit des utilisateurs

Commencez par la liste des administrateurs :

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Le propriétaire valide la liste, le technicien retire les comptes inutiles, en réattribuant leurs contenus. Le départ d’un salarié ou d’un prestataire déclenche cet audit immédiatement, sans attendre le trimestre. Vérifiez aussi les sessions ouvertes et les mots de passe d’application, qui donnent accès à l’API REST et à XML-RPC sans le mot de passe principal :

wp user session list admin
wp user application-password list admin

WordPress demande d’ailleurs à l’administrateur de confirmer l’adresse de contact du site tous les six mois : ne cliquez pas sans lire, c’est cette adresse qui reçoit les alertes. WordPress ne garde aucun historique des connexions : un plugin de journal d’activité comble ce manque. Notre guide des rôles utilisateurs WordPress détaille le principe du moindre privilège.

L’exemple de la commission électorale britannique, réprimandée par l’autorité de protection des données, montre que ces lignes ennuyeuses comptent. Des attaquants sont entrés par un serveur de messagerie dont les correctifs, publiés des mois plus tôt, n’avaient pas été appliqués. Et un audit a ensuite cassé 178 comptes actifs dont les mots de passe ressemblaient à ceux attribués par défaut.

L’audit des plugins et des thèmes

WordPress n’affiche rien quand un plugin est retiré du répertoire officiel : il apparaît comme à jour. En 2024, selon Patchstack, 1 614 plugins et thèmes ont été retirés du répertoire pour des failles non corrigées. La commande suivante signale les plugins fermés :

wp plugin list --fields=name,status,version,update,wporg_status

Supprimez les plugins inactifs, comme le recommande la Santé du site, et remplacez ceux qui n’ont pas été mis à jour depuis deux ans, la définition de l’abandon retenue par Wordfence. Notre guide pour sécuriser WordPress complète cet audit.

Le thème

L’épisode de la 6.9.2 l’a montré : les thèmes qui s’appuient sur des comportements non officiels cassent les premiers. Chaque trimestre, vérifiez que votre thème reçoit encore des mises à jour, qu’il est testé avec la dernière version de WordPress, et que vos personnalisations vivent dans un thème enfant ou dans l’éditeur de site, pas dans les fichiers du thème parent, écrasés à chaque mise à jour.

La version de PHP

WordPress recommande PHP 8.3 ou plus. PHP 8.2 perd son support de sécurité le 31 décembre 2026 : si votre site l’utilise encore, planifiez la migration ce trimestre, après un test sur une copie. Notre guide sur la version de PHP pour WordPress détaille la méthode.

Les certificats et les domaines

Depuis le 15 mars 2026, un certificat public ne peut plus dépasser 200 jours de validité ; cette durée passera à 100 jours en mars 2027, puis à 47 jours en mars 2029. Let’s Encrypt réduira ses certificats à 45 jours d’ici 2028. Un certificat renouvelé à la main une fois par an n’existe donc plus : automatisez le renouvellement et surveillez-le.

Pour le domaine, vérifiez chaque trimestre que le renouvellement automatique est actif chez le bureau d’enregistrement, que la carte bancaire est valide et que les contacts sont toujours des personnes présentes dans l’entreprise. Pour les plugins génériques comme le .com, les rappels d’expiration sont encadrés par l’ICANN.

La règle de l’ICANN prévoit un rappel environ un mois avant, un autre environ une semaine avant, puis un dernier dans les cinq jours qui suivent l’expiration ; une fois le domaine supprimé, la plupart des domaines génériques bénéficient d’une période de rachat de trente jours. Ces règles ne s’appliquent pas automatiquement aux extensions nationales comme le .fr : vérifiez celles de votre registre.

Côté certificats, Let’s Encrypt prévient qu’un renouvellement à intervalle fixe de soixante jours ne suffira plus avec des durées plus courtes. Les clients de renouvellement compatibles ARI interrogent l’autorité pour savoir quand renouveler : assurez-vous que celui de votre hébergeur le fait.

À chaque changement : tenir un journal de maintenance

Chaque intervention s’écrit : la date, l’auteur, ce qui a changé avec les versions avant et après, la raison, la vérification faite et le chemin de retour arrière. Des plugins comme Simple History ou WP Activity Log, plus de 300 000 installations chacune, enregistrent automatiquement les actions dans l’administration.

C’est exactement la leçon de l’équipe de sécurité de WordPress : une liste de vérifications documentée, où chaque étape sautée doit être justifiée par écrit. Joignez chaque trimestre l’export de l’onglet Informations de la Santé du site : il photographie l’état technique du site à date.

Les outils qui tiennent la liste pour plusieurs sites

ManageWP, MainWP et WP Umbrella

Au moment où nous écrivons, en octobre 2026, ManageWP, dont le connecteur dépasse le million d’installations, propose un tableau de bord gratuit pour un nombre illimité de sites, avec des modules payants par site et par mois : sauvegardes, surveillance de disponibilité, rapports. MainWP, auto-hébergé, a une version gratuite et une version Pro à 199 dollars par an pour un nombre illimité de sites. WP Umbrella facture environ 2 euros par site et par mois, surveillance et mises à jour comprises.

Garder un responsable derrière l’outil

Ces tableaux de bord centralisent les mises à jour, les sauvegardes et la surveillance. Mais leurs connecteurs sont eux-mêmes des plugins dotés de pouvoirs d’administration sur chaque site : ils font partie de l’audit des plugins. Et aucun outil ne remplace la personne qui ouvre le site après une mise à jour.

Tableau récapitulatif

Tâche	Fréquence	Responsable	Vérification
Sauvegarde hors serveur	Quotidienne, automatique	Hébergeur ou technicien	Copie récente chaque mois
Surveillance par mot-clé, certificat, domaine	Continue	Technicien	Destinataires valides chaque trimestre
Mises à jour	Hebdomadaire, le jour même si sécurité	Technicien	Site public ouvert après chaque mise à jour
Santé du site	Coup d’œil hebdomadaire, lecture mensuelle	Technicien	Export trimestriel
Liens cassés et 404	Mensuelle	Responsable des contenus	Rapport d’indexation
Performance terrain	Mensuelle	Technicien	Rapport Core Web Vitals
Base de données	Revue et nettoyage mensuels	Technicien	Taille et options chargées
Test de restauration	Trimestrielle	Technicien, validé par le propriétaire	Durée chronométrée
Audit des utilisateurs	Trimestrielle et à chaque départ	Propriétaire et technicien	Liste des administrateurs
Audit des plugins	Trimestrielle	Technicien	Plugins fermés et inactifs
PHP, certificats, domaine	Trimestrielle	Technicien et propriétaire	Versions et dates d’expiration

Questions fréquentes

Faut-il activer les mises à jour automatiques pour tous les plugins ?

Pour les plugins simples et bien maintenus, oui. Pour celles qui touchent au cœur de l’activité, comme WooCommerce ou un constructeur de pages, préférez une mise à jour manuelle après test sur une copie. Dans tous les cas, gardez les versions mineures de WordPress automatiques.

La Santé du site suffit-elle à surveiller un site ?

Non. Elle vérifie la configuration technique, mais ni les sauvegardes, ni l’expiration du certificat ou du domaine, ni les plugins retirés du répertoire, ni la disponibilité vue de l’extérieur.

À quelle fréquence tester une restauration ?

Une fois par trimestre est un bon rythme, et après chaque changement d’hébergeur ou d’outil de sauvegarde. Aucune norme ne fixe de fréquence : l’important est de l’avoir fait au moins une fois avant d’en avoir besoin.

Qu’est-ce que les certificats à 47 jours changent ?

Ils rendent le renouvellement manuel impossible à tenir. Dès aujourd’hui, avec 200 jours au plus, un renouvellement automatique et une alerte en cas d’échec sont indispensables.

Faut-il une préproduction pour les mises à jour mineures ?

Non : elles arrivent automatiquement et souvent dans l’urgence. La protection, c’est la vérification du site public juste après, et une sauvegarde récente pour revenir en arrière.

Que faire quand une mise à jour casse le site public ?

Consultez le journal d’erreurs, testez avec un thème par défaut sur une copie, et cherchez sur le forum d’assistance : d’autres ont souvent le même problème. Restaurez la sauvegarde si nécessaire, mais ne désactivez pas les mises à jour de sécurité.

Conclusion

Une maintenance WordPress solide tient en quatre rythmes : ce qui s’automatise chaque jour, la revue des mises à jour chaque semaine, la santé, les liens, la performance et la base chaque mois, la restauration, les utilisateurs, les plugins, PHP et les certificats chaque trimestre. Avec, à chaque ligne, un responsable et une vérification.

L’épisode de la 6.9.2 en est la meilleure démonstration : même l’équipe de sécurité de WordPress a découvert qu’il manquait une ligne à sa liste. La vôtre aussi évoluera. Commencez par celle-ci, tenez un journal, et ajoutez une ligne chaque fois qu’un incident vous apprend quelque chose.

Sources

LaFactory conçoit, développe et maintient des sites WordPress et WooCommerce, et développe ses propres plugins. Parlons de votre projet WordPress.

Francis Rozange

Ancien chef de rubrique à Libération, il dirige LaFactory, agence web internationale depuis 1996.