La question qui revient le plus souvent au comptoir, c’est celle-ci : « comment je saurais si mon site tombe en panne ? » La réponse honnête, la plupart du temps, c’est qu’on ne le sait pas, jusqu’à ce qu’un client mécontent appelle pour dire que le formulaire de contact ne répond plus depuis trois jours. Ça se corrige, et ça ne coûte ni beaucoup de temps ni beaucoup d’argent.
Trois choses à surveiller, pas trente
On peut vite se noyer sous les tableaux de bord et les alertes. En pratique, trois choses suffisent à couvrir l’essentiel : la disponibilité du site, les erreurs qui se produisent en coulisses, et l’état des sauvegardes. Le reste est du confort, pas de l’urgence.
La disponibilité, c’est la plus simple à surveiller : un service comme UptimeRobot interroge le site toutes les quelques minutes et prévient par e-mail ou par notification dès qu’il ne répond plus. C’est gratuit pour un usage basique, ça se configure en cinq minutes, et ça évite d’apprendre une panne par un client plutôt que par une alerte.
Les erreurs, elles, se cachent dans le journal d’erreurs PHP du serveur, un fichier texte que la plupart des propriétaires de site n’ouvrent jamais. C’est pourtant là que s’accumulent les avertissements d’une extension mal codée, les tentatives de connexion suspectes, les ratés qui, un jour, finissent par faire planter tout le site. Y jeter un œil une fois par mois permet souvent d’anticiper un problème plutôt que de le subir.
Les sauvegardes, enfin, ne servent à rien si on ne vérifie jamais qu’elles se produisent réellement. Une extension comme UpdraftPlus peut programmer des copies automatiques du site et de sa base de données, envoyées vers un espace de stockage distant. Mais une sauvegarde qu’on ne teste jamais est une fausse promesse : le seul moyen de savoir qu’elle fonctionne, c’est d’essayer de la restaurer, au moins une fois, sur un site de test.
Un tableau pour s’y retrouver
Voici comment je résume, pour mes clients, ce qu’il faut surveiller, à quelle fréquence, avec quel type d’outil, et ce qu’on fait quand l’alerte arrive.
| Ce qu’on surveille | À quelle fréquence | Avec quel type d’outil | Si ça alerte |
|---|---|---|---|
| Disponibilité du site | En continu, contrôle toutes les 5 minutes | Service de supervision externe (UptimeRobot ou équivalent) | Contacter l’hébergeur, vérifier si le domaine a expiré |
| Journal d’erreurs PHP | Une fois par mois, ou après chaque mise à jour | Journal d’erreurs accessible via le panneau d’hébergement | Identifier l’extension ou le thème en cause, la désactiver au besoin |
| Sauvegardes automatiques | Vérification hebdomadaire que la dernière copie existe | Extension de sauvegarde programmée (UpdraftPlus ou équivalent) | Relancer une sauvegarde manuelle, vérifier l’espace de stockage distant |
| Sécurité et tentatives d’intrusion | Alerte en temps réel | Pare-feu applicatif (Wordfence ou équivalent) | Bloquer l’adresse concernée, changer les mots de passe sensibles |
| Référencement et indexation | Contrôle mensuel | Google Search Console | Vérifier les pages retirées de l’index, corriger les erreurs signalées |
Ne pas confondre surveillance et paranoïa
Un site bien surveillé n’est pas un site sous cloche. Il s’agit de mettre en place quatre ou cinq automatismes qui préviennent quand quelque chose cloche, pas de vérifier soi-même chaque matin que tout fonctionne. C’est justement le rôle d’un pare-feu applicatif comme Wordfence : il tourne en tâche de fond, bloque les tentatives de connexion suspectes, et n’envoie une alerte que si quelque chose sort vraiment de l’ordinaire.
Le point que beaucoup négligent, c’est la Google Search Console, qui n’a l’air de rien mais prévient parfois avant tout le monde qu’un problème existe : une chute brutale des pages indexées peut signaler un piratage ou une erreur de configuration bien avant que le trafic ne s’effondre visiblement.
Qui reçoit l’alerte, et que fait-on avec
Un piège fréquent : configurer toutes ces alertes vers une adresse e-mail que plus personne ne consulte, celle d’un ancien salarié ou d’un prestataire qui n’intervient plus sur le site. Je recommande toujours de centraliser les notifications vers une adresse suivie activement, et d’écrire noir sur blanc, quelque part, qui est censé réagir en cas d’alerte. Un site associatif que j’ai repris avait ainsi accumulé six mois d’avertissements de sécurité, tous envoyés à une boîte mail fermée depuis le départ du bénévole qui l’avait créée. Personne n’en avait vu la couleur.
Il faut aussi accepter qu’une alerte ne demande pas toujours une intervention dans l’heure. Une notification de mise à jour disponible peut attendre le lendemain matin ; une alerte de site inaccessible, en revanche, mérite qu’on regarde tout de suite. Distinguer l’urgent de l’important évite de s’épuiser à réagir à chaque notification comme si le site était en flammes.
Mettre en place cette surveillance ne prend pas plus d’une heure, une fois. Après, c’est le silence qui devient rassurant : pas de notification, pas de problème. Et le jour où l’alerte arrive, mieux vaut avoir de quoi restaurer le site rapidement, ce qui suppose d’avoir déjà réglé la question des sauvegardes en amont, un sujet suffisamment important pour mériter son propre article. Pour la partie hébergement, notamment le choix d’une offre qui propose déjà certaines de ces protections en série, voir notre comparatif sur le choix d’un hébergement WordPress.
Sur le fonctionnement de la Search Console et son utilité pour repérer les problèmes d’indexation, la documentation officielle de Google Search Console reste la source la plus fiable.
