Surveillance WordPress : protocole de suivi post-intervention

Un site réparé n’est pas un site stabilisé. Les semaines qui suivent une intervention sont celles où la panne revient, souvent par le même chemin, et cette fois sans prévenir.

La rechute se joue dans le mois qui suit un dépannage. Trois gestes la préviennent : garder un état de référence du site réparé, surveiller les parcours qui font votre chiffre plutôt que le site entier, et n’activer que les alertes sur lesquelles vous agirez vraiment.

Si votre site est encore en panne, commencez par le protocole de dépannage WordPress. Cette page prend le relais une fois qu’il est remis en ligne.

Avant de brancher la moindre alerte, il vous faut deux choses : une sauvegarde déjà restaurée une fois, et un état de référence du site réparé. Faute de quoi, la surveillance produira du bruit plutôt que des réponses.

• Une sauvegarde disponible et déjà restaurée une fois, pas seulement présente.
• Les journaux d’erreurs accessibles, avant d’en avoir besoin.
• Les accès centralisés : hébergeur, administration, DNS, messagerie.
• L’état de référence noté : versions de WordPress, du thème, des extensions et de PHP.
• Le périmètre écrit : ce qui est surveillé, et ce qui ne l’est pas.

L’outil Santé du site de WordPress donne un premier état des lieux en une page, versions et configuration serveur comprises.

Surveillez les parcours qui font votre chiffre, pas le site entier. Accueil, formulaire de contact, tunnel de commande, envoi des emails : si l’un casse, vous perdez de l’argent. Le reste peut attendre le rapport mensuel.

• Les pages qui convertissent, testées sur un mot attendu dans la réponse et pas seulement sur un code 200 : une page peut répondre correctement en affichant une erreur.
• Les formulaires. Un envoi qui part et un email qui arrive sont deux choses différentes.
• Le tunnel de commande de bout en bout, si vous vendez.
• Les enregistrements DNS de messagerie, SPF, DKIM et DMARC, dont la modification passe inaperçue jusqu’au jour où plus rien ne part.

Pour cadrer les seuils et l’hygiène des journaux, les recommandations du NIST (SP 800-92) font référence.

Cinq symptômes reviennent après un dépannage mal refermé. Les reconnaître tôt évite la seconde panne, qui coûte plus cher que la première parce qu’elle arrive sans prévenir.

• Le site ralentit par vagues : cache instable, requêtes lourdes, extension trop bavarde. Voyez nos techniques de dépannage d’un site lent.
• Un formulaire part mais l’email n’arrive pas : délivrabilité, DNS de messagerie, conflit d’extension.
• Des erreurs 500 apparaissent sur les pages clés : mise à jour cassée, limite mémoire, conflit thème et extension. Voyez notre guide de l’erreur 500.
• Des connexions administrateur inhabituelles : force brute, identifiants fuités, comptes oubliés. Voyez notre guide de la sécurité WordPress.
• Des paiements échouent au hasard : webhooks non reçus, cache posé sur les points d’entrée. Voyez notre dépannage WooCommerce.

Un symptôme qui revient deux fois n’est pas une coïncidence : la cause n’a pas été traitée, seulement contournée.

Une alerte sans action associée finit ignorée, et emporte les autres avec elle. Six alertes suffisent après un dépannage : disponibilité, encaissement, formulaire, connexions, intégrité des fichiers, messagerie.

Site injoignable, ou erreur 5xx persistante sur une page qui convertit
Paiement en échec, si vous vendez
Formulaire clé : envoi parti, email non reçu
Pic d’échecs de connexion administrateur, avec adresses IP répétées
Modification de fichiers dans wp-admin, wp-includes ou le thème actif
Création d’un administrateur, changement de rôle, ou DNS de messagerie modifié

Ces six couvrent la disponibilité, la conversion et la compromission. Tout le reste peut attendre le rapport mensuel.

Le piège est de vouloir tout surveiller. Réglez des seuils plutôt que des interrupteurs : un nombre d’échecs sur une durée, une priorité critique distincte de l’information, une plage horaire, et une règle d’escalade. Vous serez alerté juste plutôt que souvent.

Côté durcissement, les principes officiels du guide de sécurisation WordPress et la logique de filtrage d’un pare-feu applicatif couvrent l’essentiel de la surface d’attaque.

Ce qu’une sonde bien posée change, sur un cas réel

Pendant une migration DNS chez un organisateur d’événements, un sous-domaine critique, la billetterie, a été oublié dans le transfert. La plateforme est restée injoignable et personne ne l’a su avant le signalement du prestataire, le lendemain. Une fois le service rétabli, nous avons ajouté deux sondes : un contrôle HTTP avec mot-clé attendu, et une sonde DNS qui vérifie que le sous-domaine résout vers la bonne adresse. La seconde aurait détecté l’oubli en quelques minutes.

Une alerte qui n’a jamais sonné ne prouve rien. Provoquez la panne en heures creuses, puis regardez ce qui remonte, à qui, et en combien de temps. Une sonde muette se découvre pendant un test, pas pendant un incident.

• Coupez un service non critique et vérifiez le délai réel avant l’alerte.
• Envoyez un formulaire et confirmez la réception, pas seulement l’envoi.
• Passez une commande test de bout en bout si vous vendez.
• Vérifiez qui a reçu l’alerte, et si cette personne savait quoi en faire.

Ensuite, un point mensuel suffit : incidents survenus, temps de rétablissement, correctifs appliqués, et ce qui reste à traiter. C’est ce document qui montre si la surveillance sert à quelque chose.

Quand la même panne revient une deuxième fois, ou quand votre site porte du chiffre d’affaires. À ce stade, payer une intervention après coup revient plus cher que de prévenir, et l’arrêt se compte en ventes perdues.

Confier la maintenance d’un site WordPress à une agence coûte 50 € HT par mois pour un site vitrine, et 90 € HT par mois pour un catalogue ou un petit site de vente. À comparer au coût d’une intervention d’urgence, facturée à l’heure, plus le temps où le site ne produit rien.

Le contrat fixe ce qui n’est jamais écrit après une panne : fréquence des mises à jour, fréquence des sauvegardes, délai d’intervention, et ce qui déclenche une escalade. Voyez le détail de nos formules de maintenance WordPress.