Comment détecter les problèmes WordPress avant que vos clients ne les signalent ?

Beaucoup d’entreprises découvrent un problème sur leur site de la pire des façons : un client écrit pour dire que le checkout ne fonctionne pas, un formulaire de contact est resté muet pendant une semaine, ou le site affiche un avertissement de sécurité.

À ce moment-là, le problème existe parfois depuis des heures ou des jours. Des commandes ont été perdues, des demandes sont restées sans réponse et les clients se sont fait une opinion.

La plupart de ces problèmes peuvent être détectés plus tôt. La surveillance n’empêche pas tous les incidents, mais elle réduit le délai entre le moment où quelque chose casse et le moment où quelqu’un s’en aperçoit.

Ce guide présente les principaux types de surveillance d’un site WordPress, ce que chacun détecte, ce qu’il laisse passer, et comment décider qui reçoit les alertes et ce qu’il doit en faire.

Pourquoi les problèmes passent-ils inaperçus ?

Un site peut être en partie cassé tout en paraissant normal aux personnes qui le gèrent.

Par exemple :

• la page d’accueil se charge, mais le checkout échoue à l’étape du paiement
• le formulaire de contact semble s’envoyer, mais les e-mails ne sont jamais livrés
• le site est rapide depuis le bureau, mais lent pour les visiteurs ailleurs
• une mise à jour de plugin a provoqué des erreurs sur certaines pages seulement
• le certificat SSL expire un week-end
• une page piratée n’affiche du spam qu’aux visiteurs venant de Google

Les dirigeants et les équipes ne consultent généralement pas chaque page et ne passent pas de commandes de test tous les jours. Sans une forme de surveillance, la première personne à remarquer le problème est souvent un client.

Que faut-il surveiller ?

Chaque contrôle détecte des problèmes différents. Aucun outil ne couvre tout à lui seul.

Surveillance de la disponibilité

Un outil de surveillance de la disponibilité (uptime) visite votre site à intervalles réguliers et vous alerte s’il ne répond pas ou s’il renvoie une erreur.

C’est la forme de surveillance la plus élémentaire, et elle détecte :

• un site complètement hors ligne
• les erreurs serveur
• les pannes de l’hébergeur
• les problèmes de DNS

Ses limites : la plupart des outils ne vérifient qu’une seule page, en général la page d’accueil. Un site peut répondre normalement à cet endroit et être cassé ailleurs. Certains outils peuvent aussi vérifier qu’un mot précis apparaît sur la page, ce qui aide à repérer les pages blanches ou d’erreur qui renvoient pourtant une réponse normale.

Alertes d’expiration du certificat SSL et du domaine

Un certificat SSL expiré pousse les navigateurs à afficher un avertissement de sécurité à la place de votre site. Un domaine expiré peut mettre hors ligne tout le site et la messagerie.

Ces deux échéances sont parfaitement prévisibles. Des alertes quelques semaines avant l’expiration laissent largement le temps d’agir.

Beaucoup de certificats se renouvellent automatiquement, mais ce renouvellement peut échouer, par exemple après une modification DNS ou un changement d’hébergeur. Le renouvellement du domaine dépend souvent d’une carte de paiement qui a pu expirer. Il est utile de connaître les deux dates et de savoir qui reçoit les e-mails de renouvellement.

Surveillance des logs d’erreurs

WordPress et PHP peuvent écrire les erreurs dans des fichiers de log sur le serveur. Une hausse soudaine des erreurs apparaît souvent avant que les visiteurs ne remarquent quoi que ce soit.

Consulter régulièrement les logs, ou utiliser un outil qui alerte en cas de nouvelles erreurs graves, permet de repérer :

• les conflits de plugins après des mises à jour
• du code qui ne fonctionne plus après un changement de version PHP
• les erreurs de base de données
• les problèmes de mémoire

Les logs demandent quelqu’un qui sait les lire. Ils peuvent aussi contenir des informations sensibles, il faut donc en limiter l’accès.

Tests du checkout et des formulaires

Pour beaucoup d’entreprises, les fonctions les plus importantes ne sont pas sur la page d’accueil. Ce sont le checkout, le formulaire de réservation ou le formulaire de contact.

On peut les tester :

• en passant régulièrement une commande de test, avec un moyen de paiement de test lorsque c’est possible
• en envoyant le formulaire de contact et en vérifiant que l’e-mail arrive
• avec un outil de surveillance capable d’enchaîner plusieurs étapes, comme ajouter au panier puis atteindre le checkout
• en vérifiant que les e-mails de notification des commandes et des formulaires arrivent toujours

Même un simple test manuel planifié, noté à chaque fois, vaut bien mieux que rien.

Surveillance des performances

Un site passe rarement de rapide à cassé d’un seul coup. Il commence souvent par ralentir.

La surveillance des performances peut suivre :

• le temps de réponse des pages
• les changements après des mises à jour ou de nouveaux plugins
• les ralentissements à certaines heures de la journée

Les ralentissements progressifs passent facilement inaperçus au jour le jour, mais se voient bien sur plusieurs semaines.

Alertes de sécurité

La surveillance de sécurité peut inclure :

• des alertes lorsque des fichiers du cœur de WordPress changent de manière inattendue
• des notifications de création de nouveaux comptes administrateur
• des avertissements sur les plugins présentant des vulnérabilités connues
• des analyses antimalware
• des alertes provenant d’un pare-feu ou d’un service de sécurité

Ces alertes doivent parvenir à quelqu’un capable de juger si elles sont fondées et d’agir rapidement si c’est le cas.

E-mails de Google Search Console

Google Search Console envoie des e-mails sur les problèmes qu’il détecte, comme les problèmes de sécurité, les actions manuelles, les problèmes d’indexation et les pages qu’il ne parvient pas à explorer.

Ces e-mails sont faciles à ignorer parce qu’ils ont souvent l’air routiniers. Certains, comme les notifications de problèmes de sécurité, sont pourtant importants et urgents.

Vérifiez que Search Console est configuré pour votre site et que ses e-mails parviennent à quelqu’un qui les lit.

Qui doit recevoir les alertes et que doit-il faire ?

La surveillance n’est utile que si les alertes parviennent à la bonne personne et que cette personne sait quoi faire.

Les problèmes fréquents sont :

• des alertes envoyées à un ancien salarié ou à un ancien développeur
• toutes les alertes envoyées à une boîte partagée que personne ne consulte
• tellement d’alertes que plus personne ne les lit
• des alertes qui parviennent à quelqu’un qui ne peut rien faire

Une façon simple de s’organiser consiste à décider, pour chaque type d’alerte :

• qui la reçoit
• qui prend le relais si cette personne n’est pas disponible
• quelle est la première action à mener
• qui contacter si le problème ne peut pas être résolu

Par exemple, un dirigeant peut recevoir les alertes de disponibilité et de checkout pour savoir que quelque chose ne va pas, tandis qu’un partenaire technique reçoit les mêmes alertes ainsi que les logs d’erreurs et les avertissements de sécurité pour pouvoir enquêter.

Gardez un nombre d’alertes gérable. Mieux vaut bien surveiller quelques éléments importants que recevoir des dizaines de messages que personne ne lit.

Comment déterminer le niveau de surveillance nécessaire ?

Commencez par ce qui nuirait le plus à l’entreprise si cela cessait de fonctionner sans que personne ne s’en aperçoive.

Sites vitrines

La surveillance de la disponibilité, les alertes d’expiration du SSL et du domaine, Search Console et un test régulier du formulaire de contact constituent généralement une bonne base.

Sites avec réservations, espaces membres ou génération de leads

Ajoutez des tests réguliers des formulaires et des parcours de réservation, et vérifiez que les e-mails de notification arrivent. Ajoutez des alertes de sécurité si les utilisateurs ont des comptes.

Boutiques WooCommerce

Ajoutez des tests du checkout, des contrôles des notifications de paiement, une surveillance des performances et une revue des logs d’erreurs. Chaque heure pendant laquelle un problème de checkout passe inaperçu coûte de l’argent.

Quelles sont les erreurs les plus courantes ?

• Ne surveiller que la page d’accueil. Les pages les plus importantes se trouvent souvent ailleurs.
• Des alertes envoyées à la mauvaise personne. Vérifiez les destinataires des alertes à chaque changement de personne ou de prestataire.
• Trop d’alertes. Le bruit conduit à ignorer les vraies alertes.
• Aucun plan pour la suite. Une alerte sans responsable n’est qu’une notification.
• Penser que l’hébergeur surveille. La surveillance de l’hébergeur couvre généralement le serveur, pas votre checkout ni vos formulaires.
• Ne jamais tester les alertes. Un système d’alerte qui ne s’est jamais déclenché ne fonctionne peut-être pas.

À quoi ressemble une bonne configuration ?

Une configuration de surveillance pragmatique comprend généralement :

• des contrôles de disponibilité sur la page d’accueil et sur une ou deux pages clés
• des rappels d’expiration du SSL et du domaine bien à l’avance
• des tests réguliers du checkout et des formulaires
• des logs d’erreurs examinés par quelqu’un qui les comprend
• des alertes de sécurité adressées à quelqu’un qui peut agir
• Search Console validé, avec des e-mails qui parviennent à une vraie personne
• une courte liste écrite indiquant qui reçoit quoi et ce que chacun doit faire

Comment D4Hub peut vous aider

D4Hub peut vous aider à mettre en place une surveillance adaptée à votre site, sans vous noyer sous les alertes.

Selon vos besoins, D4Hub peut vous aider à :

• choisir les pages et les fonctions à surveiller
• mettre en place les contrôles de disponibilité, d’expiration du SSL et du domaine
• examiner les logs d’erreurs et identifier les problèmes récurrents
• tester le checkout, les formulaires et les e-mails de notification
• examiner les alertes de sécurité et les notifications de Search Console
• décider qui reçoit chaque alerte et quelle doit être la réponse
• intégrer la surveillance et les contrôles réguliers dans les plans de support D4Hub

Vous pouvez demander de l’aide à tout moment, que vous ayez besoin de mettre en place la surveillance ou de réagir à une alerte que vous venez de recevoir.

curl -s -o /dev/null -w "%{http_code}" https://www.example.com/

#!/bin/sh
URL="https://www.example.com/"
CODE=$(curl -s -L -o /dev/null -w "%{http_code}" --max-time 30 "$URL")
if [ "$CODE" != "200" ]; then
  echo "$(date) $URL returned $CODE" >> "$HOME/site-check.log"
fi

*/15 * * * * /path/to/check-site.sh

echo | openssl s_client -servername www.example.com -connect www.example.com:443 2>/dev/null | openssl x509 -noout -enddate

echo | openssl s_client -servername www.example.com -connect www.example.com:443 2>/dev/null | openssl x509 -noout -checkend 2592000

wp core verify-checksums

Questions fréquentes

La surveillance de la disponibilité suffit-elle ?

C’est un bon début, mais elle indique seulement si une page répond. Elle ne vous dira pas que le checkout échoue, qu’un formulaire n’envoie plus d’e-mails ou qu’une page a été piratée. Combinez-la avec des tests de vos fonctions clés.

Mon hébergeur surveille-t-il mon site ?

La plupart des hébergeurs surveillent leurs serveurs et leur infrastructure. Ce n’est pas la même chose que surveiller le checkout, les formulaires ou le contenu de votre site. Demandez à votre hébergeur ce qu’il surveille et s’il vous alerte.

À quelle fréquence tester les formulaires et le checkout ?

Cela dépend de leur importance. Pour une boutique très active ou un site de génération de leads, des tests réguliers planifiés et un test après chaque mise à jour sont raisonnables. Pour un simple formulaire de contact, un contrôle périodique et un test après les mises à jour peuvent suffire.

La surveillance va-t-elle ralentir mon site ?

Les contrôles externes, comme les outils de surveillance de la disponibilité, envoient une petite requête à intervalles réguliers, comme le ferait un visiteur normal. Certains plugins de sécurité et de performance fonctionnent à l’intérieur de WordPress et peuvent ajouter de la charge : il vaut donc la peine de bien choisir ses outils.

Que faire lorsque je reçois une alerte ?

Vérifiez d’abord si le problème est réel en visitant vous-même le site, idéalement dans une fenêtre de navigation privée. S’il est réel, notez l’heure et ce que vous voyez, évitez de faire plusieurs modifications à la fois et contactez la personne responsable du site. Le guide sur que faire lorsqu’un site WordPress est hors ligne peut vous aider pour les premières étapes.

D4Hub peut-il recevoir les alertes de mon site ?

D4Hub peut vous aider à décider comment les alertes doivent être traitées, y compris si un partenaire technique doit les recevoir en parallèle de votre équipe. Ce point peut être abordé dans le cadre d’un support continu.