On parle beaucoup de la création d'un site WordPress, rarement de ce qui vient après. Pourtant, c'est la maintenance qui décide si un site est encore sûr, rapide et en ligne deux ans plus tard. Ce guide décrit la routine que nous appliquons à nos sites et à ceux que nous maintenons en sous-traitance, et surtout les raisons de chaque étape — la plupart viennent d'un incident.
1. Les sauvegardes : vérifier, puis éloigner
Une sauvegarde doit prouver qu'elle est complète
Un dump de base de données peut échouer à mi-parcours — disque plein, connexion coupée, table verrouillée — et laisser un fichier tronqué qui a toutes les apparences d'une sauvegarde. Le jour où l'on en a besoin, il ne se restaure pas.
La parade est simple : un dump complet produit par mysqldump se termine par une ligne de commentaire -- Dump completed. Notre script de sauvegarde contrôle sa présence avant de conserver le fichier, et considère la sauvegarde comme échouée sinon. Le fichier compressé est également testé (gzip -t). Ce sont deux lignes de script qui transforment « un fichier existe » en « une sauvegarde exploitable existe ».
Une copie sur le même serveur ne protège pas du serveur
Nos sauvegardes quotidiennes sont conservées sept jours sur le serveur de production. Elles protègent contre une erreur de manipulation ou une corruption de données, pas contre la perte du serveur lui-même. Pour cela, il faut une copie ailleurs.
Le modèle que nous avons retenu est une copie tirée plutôt que poussée : c'est la machine de stockage distante qui vient chercher les sauvegardes, avec une clé SSH dédiée limitée côté serveur à la lecture seule d'un unique répertoire. Un attaquant qui prendrait le contrôle du serveur de production n'aurait ainsi aucun accès en écriture aux copies distantes et ne pourrait pas les effacer. La copie distante est organisée en rotations quotidienne, hebdomadaire et mensuelle, ce qui permet de remonter plusieurs mois en arrière sans multiplier l'espace occupé.
Répéter la restauration
Une procédure de restauration jamais exécutée est une hypothèse. Au moins une fois, restaurez une sauvegarde sur un environnement de test et vérifiez que le site fonctionne. Sur un multisite, vérifiez aussi que vous savez restaurer un seul site sans ramener les autres en arrière — ce point est détaillé dans notre guide sur le multisite à domaines distincts.
2. Les mises à jour : un seul chemin
La règle qui évite le plus de problèmes : une mise à jour suit le même chemin que le code. Elle est faite en local ou en test, enregistrée dans le dépôt, puis déployée. Jamais cliquée directement dans l'administration de production.
Nous avons constaté ce qui arrive quand la règle n'est pas tenue : une mise à jour du cœur de WordPress appliquée hors du flux laisse le dépôt désynchronisé : des fichiers du cœur modifiés dans wp-admin et wp-includes qu'aucun commit ne décrit. Le prochain déploiement risque alors d'écraser la mise à jour, ou d'embarquer par accident des changements que personne n'a relus. Le rattrapage est possible, mais demande un tri soigneux plutôt qu'un git add général.
Tester ce qui est livré, pas ce qui est développé
Un autre incident nous a appris à tester l'artefact final. Une de nos extensions a nécessité trois versions correctives successives, parce que le fichier principal avait été reconstruit sans une partie de ses inclusions : l'extension fonctionnait dans l'environnement de développement, où un chargeur automatique masquait le problème, et échouait une fois installée ailleurs. Depuis, l'archive livrée est installée dans un WordPress vierge avant publication. Le guide publier une extension sur WordPress.org reprend ces vérifications.
L'ordre des opérations
- Sauvegarde vérifiée juste avant.
- Mise à jour en test : cœur, puis extensions une par une, en lisant les notes de version des versions majeures.
- Parcours des pages critiques : accueil, un article, un formulaire, la connexion, et les fonctions métier du site.
- Enregistrement dans le dépôt et déploiement.
- Vérification en production, avec et sans contournement du cache.
3. La surveillance : les pannes silencieuses d'abord
Surveiller que la page d'accueil répond 200 est nécessaire, mais c'est la panne la moins probable à passer inaperçue : vous la verrez vous-même. Les pannes coûteuses sont celles qui ne se voient pas.
- Le cache objet. Nous surveillons le Redis de WordPress par une sonde dédiée, qui interroge le service et pousse le résultat vers notre outil de surveillance (Uptime Kuma, auto-hébergé). Côté API, un Redis sous-dimensionné redémarrait en boucle sans que le site public ne tombe : seules certaines pages d'administration échouaient. Le récit complet est dans notre guide sur la panne de Redis par manque de mémoire.
- Les tâches planifiées. Une tâche qui ne s'exécute plus ne produit aucune erreur visible. Vérifiez régulièrement qu'aucune échéance n'est largement dépassée (voir remplacer WP-Cron).
- Les certificats TLS. Le renouvellement automatique échoue parfois sans bruit. Une alerte quelques semaines avant l'expiration laisse le temps d'agir.
- Une page profonde, pas seulement l'accueil : une page qui interroge la base et les fonctions métier du site révèle des pannes que l'accueil, souvent en cache, masque.
Enfin, surveillez depuis l'extérieur ce que voit Google : les erreurs serveur et les 404 dans Search Console sont souvent les premiers signes d'un problème que la surveillance technique ne voit pas. Notre guide sur le rapport d'indexation explique comment les lire.
4. Les journaux : lisibles et bornés
Des journaux utiles doivent répondre à deux exigences contradictoires : être assez complets pour diagnostiquer un incident, et ne jamais remplir le disque. Sous Docker, le pilote de journalisation par défaut n'a pas de limite de taille. Nous plafonnons chaque conteneur :
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"Trente mégaoctets au plus par conteneur : assez pour remonter les dernières heures d'activité, jamais assez pour saturer le disque. À l'inverse, veillez à ce qu'aucune erreur ne soit envoyée vers /dev/null par commodité : un journal vide est pire qu'un journal bavard, car il donne une fausse assurance.
Côté WordPress, WP_DEBUG_DISPLAY doit rester à false en production — un message d'erreur affiché aux visiteurs révèle des chemins de fichiers et parfois des requêtes — mais les erreurs doivent être journalisées quelque part où quelqu'un les lira.
5. Le ménage régulier
- Extensions et thèmes inutilisés : à supprimer, pas seulement à désactiver. Leurs fichiers restent accessibles sur le serveur.
- Comptes : un ancien prestataire, un stagiaire parti, un compte de test créé « pour voir » sont autant d'accès à révoquer.
- Espace disque : sauvegardes locales, images Docker obsolètes et fichiers de cache s'accumulent. Un nettoyage planifié évite l'incident du disque plein, qui fait tomber la base de données en premier.
- Redirections et 404 : un site qui vit accumule des URL mortes. Traitez-les par lots à partir de Search Console plutôt qu'au fil de l'eau.
La routine, en résumé
| Fréquence | Tâche |
|---|---|
| Automatique, quotidienne | Sauvegarde vérifiée, copie distante tirée, sondes de surveillance |
| Dès publication | Correctifs de sécurité du cœur et des extensions exposées |
| Mensuelle | Mises à jour en test puis déploiement, revue des alertes, Search Console |
| Trimestrielle | Revue des comptes et des extensions, ménage disque, test de restauration |
Aucune de ces tâches n'est difficile. Ce qui est difficile, c'est de les tenir dans la durée ; d'où l'intérêt de les automatiser partout où c'est possible et de les écrire là où ça ne l'est pas.