La maintenance WordPress qu'on vend trop souvent, c'est « on met à jour les plugins ». La maintenance qui évite les crises, c'est d'abord le monitoring d'un site WordPress. Savoir que la home répond, que le HTTPS n'expire pas dimanche, que le disque n'est pas plein, que le cron tourne, que le tunnel Woo n'est pas en 500 depuis 40 minutes. Cet article détaille quoi mesurer, à quelle fréquence, quels seuils, comment alerter sans noyer, et comment ça s'articule avec la TMA et les sauvegardes.
🔎 Pourquoi le monitoring fait partie de la TMA WordPress
Mettre à jour sans surveiller, c'est conduire sans tableau de bord. Le site peut être lent trois semaines, le certificat peut expirer, le paiement peut renvoyer une erreur 500 en silence. Le client l'apprend par un prospect. À ce moment, la TMA a déjà échoué, même si les plugins sont à jour.
Le monitoring WordPress n'est pas « un outil de plus ». C'est la condition pour que les sauvegardes, les mises à jour et les demandes aient un sens. On restaure parce qu'on a vu. On revient en arrière sur une mise à jour parce qu'une sonde a bougé. Sans ça, on réagit au mail paniqué.
🛠️ Uptime : plus qu'un ping sur la home
Une sonde HTTP sur la page d'accueil depuis deux régions, chaque minute ou toutes les cinq minutes, c'est le minimum. Elle doit vérifier un code 200 et un morceau de contenu (le titre, un identifiant), pas seulement le TCP. Un WAF qui sert une page d'erreur « 200 » ment à un ping naïf.
Sur une boutique, on ajoute une sonde sur une page produit, sur /panier/, parfois sur une URL de santé du paiement. Un WordPress dont la home est up et le tunnel de vente down n'est pas up. C'est une caisse fermée avec la vitrine allumée.
- Home + une page intérieure + tunnel de vente si WooCommerce
- Vérifier le corps de la réponse, pas seulement le code HTTP
- Deux localisations pour éviter les faux positifs réseau
- Alerte SMS ou appel si le chiffre d'affaires dépend du site, pas seulement un e-mail noyé
✅ Certificats, DNS, noms qui expirent
Un certificat Let's Encrypt qui n'a pas renouvelé, c'est un site « hacké » aux yeux des visiteurs. On surveille la date d'expiration, on alerte à J-15. On surveille aussi le domaine et le DNS si vous en êtes responsable. Plus d'incidents « le site a disparu » viennent d'un domaine oublié que d'un zero-day WordPress.
Après une migration ou un changement d'hébergeur, les sondes DNS et SSL sont les premières à poser. Avant les plugins de « sécurité » qui envoient 40 e-mails par jour.
⚠️ Ressources serveur : disque, inode, RAM, cron
Les sauvegardes qui remplissent le disque, les logs qui grossissent, les miniatures WordPress qui s'accumulent : le site tombe en erreur 500 faute d'espace. Une sonde disque et inode à 80 % évite ça. La RAM et la charge se regardent après un pic, pas seulement en moyenne mensuelle.
Le cron WordPress (wp-cron) qui ne tourne pas, ce sont des mails en retard, des publications planifiées bloquées, des files d'action mortes. En TMA je préfère un vrai cron système qui appelle wp-cron, et une alerte si la dernière exécution est trop vieille.
📌 Erreurs applicatives : logs PHP, 500, debug
On ne laisse pas WP_DEBUG allumé en production. On journalise vers un fichier ou un agrégateur, on alerte sur les fatals, on ignore le bruit des notices d'un plugin bavard. Après chaque mise à jour, on regarde le log. C'est plus utile qu'un plugin de sécurité qui scanne les mots de passe.
Les 404 en masse (bot ou mauvaise redirection) se voient dans les logs web. Un pic après une refonte, on le traite. Un fond permanent de scan wp-login, on le contient (limiter, 2FA, URL d'admin) sans s'alarmer toutes les minutes.
🧭 Performance : Core Web Vitals et lenteur utile
Une mesure synthétique mensuelle de la home et d'une page clé (LCP et INP : vitesse d'affichage et de réaction) suffit pour une vitrine. Pour une page produit, c'est plus fréquent en campagne. On ne « monitore » pas 50 URLs toutes les heures : on se noie. On choisit les pages qui font le métier.
La lenteur soudaine (LCP qui double) est une alerte TMA : cache mort, image énorme, plugin de stats. La lenteur chronique est un chantier d'allègement, pas une notification toutes les heures.
💡 Sécurité : ce qu'on surveille vraiment
Nouveaux comptes admin, changements de fichiers core, pics de 401 sur wp-login, plugins inconnus apparus. Un bon monitoring sécu est petit et actionnable. Un plugin qui envoie chaque nuit un mail « 6 000 tentatives bloquées » n'est pas lu. Donc inutile.
Couplé à la désactivation de XML-RPC, à la double authentification et à une URL d'admin moins évidente, le monitoring sécu devient calme. C'est le but. Un tableau rouge en permanence, plus personne n'intervient.
🧪 Alertes : qui, quand, quoi faire
On définit une astreinte ou au moins un canal (e-mail plus SMS). On définit ce qui réveille (down tunnel de vente, down home > 5 min, SSL < 7 jours, disque 90 %) et ce qui attend le matin (CWV, 404). Sans cette liste, le monitoring fatigue tout le monde.
Chaque alerte a un runbook d'une page : regarder X, restaurer si Y, appeler Z. Le monitoring sans procédure, c'est une sirène. La TMA WordPress que je propose inclut les sondes et les procédures d'une page. Pas un accès à un dashboard que vous n'ouvrirez pas.
🔎 Mettre en place sans surcharger
Pour une vitrine : uptime home + page, SSL, disque, log fatal, sauvegarde vérifiée. Pour WooCommerce : plus sondes panier / tunnel de vente, file mail. Les outils existent chez l'hébergeur, chez des SaaS d'uptime, en Prometheus si on a déjà l'infra. L'outil est secondaire. La liste l'est moins.
Si votre prestataire de maintenance WordPress ne peut pas dire ce qu'il surveille, vous n'avez pas de monitoring. Vous avez un forfait de mises à jour. Les deux se vendent sous le même nom. Ce n'est pas le même métier.
🛠️ Outils : assez, pas une surcharge
Un SaaS d'uptime (deux sondes, deux régions), les mails de l'hébergeur pour le disque, un canal Slack ou e-mail unique, éventuellement un agent pour les fatals. Ça tient une vitrine. Une boutique ajoute une sonde métier et un regard sur la file de mails. On n'installe pas Grafana, Loki et une équipe SRE pour un site de trente pages.
Les plugins WordPress « status » qui tournent dans le site qu'ils surveillent ont une limite : si PHP est mort, ils sont morts. Une sonde externe voit le down. Un plugin interne voit le reste, quand le reste répond. Les deux se complètent. L'externe est non négociable.
✅ Faux positifs et fatigue d'alerte
Une sonde trop sensible (un timeout de 3 s sur un TTFB de 2,8 s) réveille pour rien. Au troisième réveil, plus personne ne se lève. On règle les seuils après une semaine de bruit. On garde une fenêtre de maintenance pour les déploiements. Le monitoring d'un site WordPress utile est calme 95 % du temps.
Si votre prestataire vous transfère 400 mails de « login bloqué » par mois, ce n'est pas du monitoring. C'est du spam interne. On le coupe, on garde les vrais down. Voir aussi XML-RPC et URL d'admin : moins de bruit à la source.
Pinger la home ne surveille pas une boutique. Ça surveille une vitrine.
