Une page d’accueil qui répond ne garantit pas qu’un site fonctionne : un formulaire peut cesser d’envoyer ses messages, un paiement peut échouer ou une tâche planifiée rester bloquée. Ce tutoriel montre comment mettre en place une surveillance WordPress utile, proportionnée et vérifiable, sans installer une accumulation d’extensions.
1. Définir ce qui doit réellement fonctionner
Avant de choisir un outil, recensez les parcours essentiels : ouverture de la page d’accueil, demande de devis, connexion, recherche, commande et confirmation de paiement. Classez chaque parcours selon son impact métier. Une boutique a besoin d’un contrôle du checkout ; un site vitrine doit surtout protéger ses formulaires et sa disponibilité.
Disponibilité, performance et fonctionnement métier
Un contrôle HTTP détecte une panne visible, mais pas une erreur métier. Distinguez trois couches : disponibilité (réponse du serveur), performance (temps de réponse et expérience réelle) et fonctionnel (actions importantes). Pour mesurer LCP, INP et CLS, consultez notre guide Core Web Vitals.
2. Configurer un contrôle externe de disponibilité
Créez une sonde HTTPS depuis un service de monitoring externe. Vérifiez le code HTTP attendu, le certificat TLS et le délai de réponse. Sur un site public, une page qui retourne 200 avec un message « maintenance » peut masquer une panne : configurez si possible un contrôle de contenu stable, sans données privées.
Éviter les fausses alertes
Choisissez une fréquence adaptée au risque et demandez une confirmation par une seconde vérification avant l’alerte critique. Testez les redirections et les protections anti-bot : elles peuvent faire échouer la sonde sans panne réelle. N’exposez jamais une URL d’administration ou un jeton secret dans un outil public.
3. Surveiller les erreurs PHP et WordPress
Activez une journalisation serveur maîtrisée, avec rotation et durée de conservation définie. En production, n’affichez pas les erreurs PHP aux visiteurs : elles peuvent révéler des chemins internes. Recherchez les erreurs fatales, les réponses 500 et les échecs récurrents après déploiement. Sur WordPress, WP_DEBUG_LOG peut aider au diagnostic ponctuel, mais un journal accessible publiquement ou conservé sans limite constitue un risque.
Observer les tâches planifiées
Vérifiez l’exécution des sauvegardes, synchronisations, notifications et tâches WooCommerce. WP-Cron dépend souvent des visites pour être déclenché ; sur des sites peu fréquentés ou à fortes exigences, un déclenchement par ordonnanceur serveur peut être plus prévisible, après validation de la configuration. Consultez la documentation WordPress sur WP-Cron.
4. Tester les formulaires sans générer de faux prospects
Préparez un formulaire de test distinct, identifié comme tel, et vérifiez la réception du message dans une boîte contrôlée. Un simple statut « envoyé » côté navigateur ne prouve pas la livraison. Contrôlez les journaux SMTP, les éventuels rejets et l’intégration CRM. N’injectez pas automatiquement des demandes fictives dans le pipeline commercial réel.
5. Contrôler un parcours d’achat en toute sécurité
Sur une boutique, préférez un environnement de préproduction avec passerelle de paiement en mode test. Contrôlez panier, taxes, livraison, commande et notifications. Si une sonde doit s’exécuter en production, évitez toute opération financière réelle et tout changement de stock ; documentez précisément les comptes et produits de test. Pour les mises à jour, suivez notre méthode de préproduction et retour arrière.
6. Construire des alertes exploitables
Une alerte doit répondre à quatre questions : quel service est touché, depuis quand, quel impact probable et qui intervient ? Définissez une personne responsable, un canal de secours et une procédure d’escalade. Séparez les avertissements (hausse de latence) des incidents critiques (site indisponible, paiement bloqué). Regroupez les alertes répétées pour éviter la fatigue de notification.
Exemple de matrice simple
| Signal | Priorité | Réponse |
|---|---|---|
| Page publique inaccessible, confirmé | Critique | Vérifier hébergement, DNS et déploiements |
| Formulaire test non reçu | Élevée | Contrôler SMTP, logs et CRM |
| Temps de réponse dégradé | À analyser | Comparer trafic, cache et serveur |
| Sauvegarde échouée | Élevée | Relancer puis tester la restauration |
7. Tester la procédure de restauration
Une sauvegarde non restaurée n’est pas une garantie de reprise. Organisez régulièrement un essai dans un environnement isolé : fichiers, base de données, médias, accès, liens et fonctionnalités essentielles. Définissez un RPO (perte de données acceptable) et un RTO (délai de reprise visé), puis vérifiez si votre dispositif les respecte. Ne restaurez jamais une copie de test par-dessus la production.
8. Checklist mensuelle de supervision
- Vérifier les sondes et leur couverture réelle.
- Tester au moins un formulaire et son acheminement.
- Consulter les erreurs serveur et les tâches échouées.
- Contrôler la dernière sauvegarde et planifier une restauration test.
- Vérifier les contacts et canaux d’alerte.
- Revoir les incidents, leur cause et les corrections durables.
Confier la surveillance et la maintenance à 3Vision Group
3Vision Group propose des prestations de maintenance, de sécurité et de surveillance adaptées aux sites existants. Découvrez 3Vision Care ou les services de l’agence pour demander un diagnostic et un périmètre de suivi adapté à votre activité.
Photographie : Daniil Komov / Pexels. Licence Pexels : usage commercial gratuit, attribution facultative ; ne pas suggérer l’approbation de personnes ou marques représentées.
