Étude de cas : surveiller en continu les sites WordPress de ses clients

Un site en ligne n’est pas un site qui fonctionne. Il peut répondre en moins d’une seconde et ne plus envoyer aucune demande de devis. Il peut afficher le cadenas HTTPS avec un certificat qui ne se renouvellera jamais. Il peut avoir une sauvegarde planifiée chaque nuit qui n’a jamais réellement abouti.

J’ai rencontré chacun de ces cas sur les sites de mes clients. C’est pour ça que je ne vends pas un hébergement : je vends un site surveillé. Cette étude de cas décrit le dispositif que j’ai mis en place pour suivre en continu les sites WordPress que j’héberge, ce qu’il surveille, ce qu’il a déjà détecté, et comment le client en est informé. La migration elle-même est racontée dans mon étude de cas sur la migration multi-sites WordPress. Ici, on parle de ce qui se passe après : l’exploitation, au quotidien.

Ce que couvre le dispositif

• Disponibilité de chaque site, contrôlée depuis plusieurs régions, avec alerte à la panne et au rétablissement.
• Performance serveur et performance réelle mesurée par Google.
• Certificats SSL, noms de domaine et versions de PHP.
• Sauvegardes exportées hors du serveur, et vérifiées.
• Sécurité et tâches planifiées de WordPress.
• Circuit des demandes de contact, jusqu’à la boîte de réception du client.
• Un rapport mensuel compréhensible par le client, et une surveillance de la surveillance elle-même.

Pourquoi un simple contrôle de disponibilité ne suffit pas

La plupart des offres d’hébergement s’arrêtent à une promesse de disponibilité. Le site répond, donc tout va bien. C’est faux, et je peux le prouver avec des cas réels :

• un site de services dont le formulaire de devis n’envoyait plus rien depuis des semaines, alors que le site était parfaitement en ligne ;
• une boutique en ligne sans aucune sauvegarde de ses fichiers, alors que la sauvegarde était planifiée, parce que l’envoi vers le stockage externe échouait à chaque fois sans prévenir ;
• des sites dont les tâches planifiées de WordPress ne s’exécutaient presque jamais, parce que le cache servait toutes les pages sans réveiller le moteur du site ;
• un site vitrine dont la page d’accueil affichait une erreur critique après une mise à jour d’extension, pendant que le reste du site fonctionnait.

Aucun de ces problèmes n’aurait déclenché une alerte de disponibilité. Tous coûtaient de l’argent au client. Le dispositif a donc été construit autour d’une idée simple : surveiller ce qui compte pour l’activité, pas seulement ce qui est facile à mesurer.

L’architecture : plusieurs couches qui se contrôlent entre elles

Les sites sont regroupés sur une infrastructure cloud que je pilote directement, avec un serveur web LiteSpeed et un cache au niveau du serveur. Ça me donne accès à ce qu’un prestataire extérieur ne voit jamais : la console d’administration du serveur, les journaux d’accès, les tâches planifiées, les versions de PHP.

Par-dessus, la surveillance fonctionne en couches indépendantes. Si l’une tombe, une autre le voit.

Couche 1 : la disponibilité vue de l’extérieur

Chaque site est contrôlé en continu par deux services de surveillance distincts, depuis plusieurs régions du monde. Dès qu’un site ne répond plus, une alerte part. Dès qu’il revient, une seconde alerte confirme le rétablissement. Un rapport hebdomadaire et un rapport mensuel récapitulent la disponibilité site par site.

Un détail qui évite les fausses alertes : un site volontairement mis en maintenance est suivi avec une règle dédiée, qui attend le code de maintenance plutôt qu’une page normale. L’alerte ne se déclenche que si ce comportement change.

Couche 2 : le contrôle approfondi, trois fois par semaine

Une tâche automatisée passe sur chaque site le lundi, le mercredi et le vendredi matin, et alimente un tableau de supervision. Elle relève :

• le code HTTP renvoyé et l’historique de disponibilité ;
• le temps de réponse, le premier octet et le temps de chargement complet ;
• le score PageSpeed mobile et ordinateur, avec les indicateurs d’affichage et de stabilité ;
• le nombre de jours avant l’expiration du certificat SSL et le renouvellement du nom de domaine ;
• la version de PHP.

Le tableau peut être consulté à tout moment. La question « dans quel état est le site de tel client ? » a une réponse immédiate, sans aller se connecter à cinq outils.

Couche 3 : la surveillance de la surveillance

Un système de surveillance qui s’arrête en silence est pire que pas de système du tout : il donne une fausse impression de sécurité. Les automatisations qui tournent sur ma machine de pilotage envoient donc un signal régulier à un service externe. Si ce signal ne vient plus, c’est moi qui reçois une alerte. Même logique pour le contrôle quotidien des certificats, des domaines et des DNS : s’il ne rend pas compte, je le sais.

Couche 4 : la sécurité applicative

Sur les sites qui en sont équipés, une extension de sécurité signale les fichiers modifiés, les extensions vulnérables et les connexions administrateur. Ces alertes arrivent dans ma boîte, pas dans celle du client, et sont traitées lors des passages de maintenance.

Les sauvegardes : planifiées, exportées, puis vérifiées

Une sauvegarde n’existe que si elle est complète, stockée ailleurs que sur le serveur, et restaurable. Les trois conditions comptent.

• Exportées hors du serveur. Les bases de données partent chaque nuit vers un stockage externe. Les fichiers suivent selon un rythme adapté au site. Plusieurs versions sont conservées.
• Contrôlées. Sur la boutique en ligne citée plus haut, aucun fichier n’était sauvegardé : les archives étaient trop volumineuses et l’envoi échouait au découpage. La cause a été trouvée, corrigée, et chaque archive a été contrôlée une à une après correction.
• Toujours avant d’intervenir. Aucune mise à jour, aucun nettoyage, aucun changement de version de PHP sans sauvegarde complète confirmée juste avant.
• Restaurées à blanc. Une sauvegarde qui n’a jamais été restaurée n’est pas vérifiée. La restauration d’essai se fait sur une copie, sans toucher au site en production.

Les tâches planifiées : la panne que personne ne voit

WordPress déclenche ses tâches planifiées à l’occasion des visites. Sur un site bien mis en cache, les pages sont servies directement par le serveur, sans réveiller WordPress. Résultat : les tâches ne tournent presque jamais. Sauvegardes fragiles, optimisation des images à l’arrêt, préchauffage du cache jamais lancé.

La correction consiste à confier ces tâches au serveur lui-même, à intervalle fixe, et à désactiver le mécanisme par défaut. Sur la boutique concernée, l’effet a été visible le jour même : l’optimisation des images, à l’arrêt depuis des semaines, a repris toute seule.

C’est typiquement le genre de problème qui n’apparaît dans aucun tableau de disponibilité, et qui dégrade lentement un site pendant des mois.

La performance : mesurer avant, mesurer après

La performance se suit à deux niveaux : le serveur, que je pilote, et les mesures réelles que Google collecte chez les visiteurs.

Côté serveur, les interventions types sont la mise en place d’un cache natif LiteSpeed, la montée de version de PHP quand l’ancienne n’est plus corrigée côté sécurité, et le nettoyage des bases de données. Sur un site, ce nettoyage a retiré 2 452 révisions d’articles et des dizaines de données temporaires orphelines, avant optimisation des 78 tables. Sur un autre, l’activation du cache serveur et le regroupement des fichiers ont ramené le poids de la page d’accueil de 231 Ko à 58 Ko, et le nombre de fichiers CSS de 53 à 2.

La règle qui ne bouge pas : trois mesures de départ, jamais une seule, parce que les outils de mesure varient d’un passage à l’autre. Puis des réglages appliqués par groupe, avec vérification visuelle du site entre chaque groupe. Puis trois mesures finales. Les réglages qui cassent souvent les sites construits avec un constructeur de pages ne sont activés qu’un par un, avec retour arrière immédiat au moindre défaut.

Le circuit des contacts : la surveillance qui compte pour le chiffre d’affaires

Pour un artisan, une agence ou une entreprise de services, le site n’a qu’une fonction : faire arriver des demandes. Surveiller l’hébergement sans surveiller ce circuit, c’est surveiller la vitrine sans vérifier que la porte s’ouvre.

Des e-mails qui arrivent vraiment

Les formulaires des sites que j’héberge envoient leurs messages par un service d’envoi transactionnel authentifié, et non par la fonction d’envoi par défaut du serveur, qui finit trop souvent en courrier indésirable. Après chaque intervention sensible, le circuit est testé de bout en bout, jusqu’à la boîte de réception du client, avec une demande de test clairement identifiée.

L’origine de chaque demande, dans l’e-mail

Sur les sites où le dispositif est en place, chaque demande se termine par un bloc qui indique d’où vient le prospect. Voici un bloc réel, issu d’un test de contrôle sur le site d’une entreprise de dératisation :

Le canal distingue le référencement naturel, la publicité, les assistants IA, les réseaux sociaux, les autres sites et les accès directs. La ligne « Fiabilité » dit honnêtement ce que le système sait et ce qu’il ne sait pas. Un visiteur qui refuse les cookies apparaît en origine inconnue : c’est la règle, et c’est mieux qu’une origine devinée.

Le fonctionnement complet, avec l’analyse croisée de la publicité et du référencement, est détaillé dans mon étude de cas 3D Résultats. Le circuit d’estimation d’une agence immobilière est décrit dans mon étude de cas Globe Immobilier.

Les incidents traités, et ce qu’ils enseignent

Une page d’accueil en erreur critique après une mise à jour

Sur un site vitrine, la page d’accueil affichait une erreur critique alors que le reste du site fonctionnait. Le diagnostic par élimination a montré une incompatibilité entre deux versions d’un constructeur de pages. Correction immédiate pour remettre le site en ligne, sauvegarde prise avant, puis remplacement définitif de la fonction concernée par un petit composant maison, sans dépendre d’une extension payante. La leçon : une mise à jour se teste sur les pages qui comptent, pas seulement sur le tableau de bord.

Un certificat qui ne se serait jamais renouvelé

Un site affichait un certificat auto-signé qui ne se serait jamais renouvelé automatiquement. La génération d’un vrai certificat échouait parce qu’un sous-domaine de messagerie sans enregistrement DNS était inclus par défaut dans la demande. Une fois ce sous-domaine retiré, le certificat a été généré, puis contrôlé en ligne. Le suivi des échéances SSL existe pour que ce genre de bombe à retardement soit vu avant d’exploser.

Une licence restée attachée à l’ancien domaine

Après un changement de serveur, la licence d’une extension payante restait occupée par l’ancien domaine de préproduction. Le site fonctionnait, mais sans mises à jour de sécurité de cette extension. Le créneau de licence a été libéré, puis réattribué au bon domaine, avec la connexion réalisée par le titulaire du compte. Je ne saisis jamais les identifiants d’un client.

Des mentions légales incomplètes

Sur une boutique en ligne, les mentions légales et les factures ne contenaient ni raison sociale, ni identifiant d’entreprise. Ce n’est pas un problème d’hébergement au sens strict. Mais c’est un risque réel pour le client, et c’est en surveillant le site dans son ensemble qu’on le voit. Le sujet a été remonté avec la liste des informations à fournir.

Le rapport client : rassurer avec des faits

Un client qui paie un hébergement géré ne voit rien quand tout va bien. C’est le paradoxe du métier. Le rapport mensuel sert à rendre ce travail visible, sans jargon :

• l’état de la configuration et ce qui a été mis à jour ;
• la disponibilité constatée et les alertes éventuelles ;
• les sauvegardes réalisées et vérifiées ;
• les interventions du mois, avec leur cause et leur effet ;
• les décisions qui reviennent au client, clairement séparées du reste.

Pour les clients qui ne prennent que l’hébergement, le rapport se limite à cette partie. Pour ceux qui ont aussi un accompagnement SEO, l’hébergement devient une section du rapport mensuel complet. Et pour moi, un récapitulatif hebdomadaire de tous les sites est préparé chaque lundi matin.

Une règle de fond : rien n’est envoyé automatiquement au client. Chaque message est préparé, relu, puis envoyé. Un rapport qui part seul avec une erreur détruit la confiance qu’il était censé construire.

Ce que ce dispositif t’apprend si tu gères ton propre site

Envoie-toi une demande de devis. Depuis ton propre site, aujourd’hui. Si elle n’arrive pas, rien d’autre ne compte.

Vérifie que tes sauvegardes contiennent tes fichiers, pas seulement ta base de données, et qu’elles sont stockées ailleurs que sur ton serveur.

Regarde la date d’expiration de ton certificat. Si elle est proche et que rien ne bouge, le renouvellement automatique ne fonctionne peut-être pas.

Méfie-toi du « tout est vert ». Un tableau de disponibilité au vert ne dit rien de ton formulaire, de tes tâches planifiées ni de tes sauvegardes.

Surveille ta surveillance. Un outil qui s’arrête sans prévenir est le pire des outils.

Tu veux un site surveillé plutôt qu’un simple hébergement ?

Je prends en charge l’hébergement, la maintenance et la surveillance de sites WordPress, avec sauvegardes vérifiées, mises à jour sécurisées, suivi des performances et contrôle du circuit des contacts. Tout est détaillé sur mon offre d’hébergement professionnel.

Si ton site doit aussi être repris, c’est le rôle de la refonte accompagnée en SEO. Pour savoir où en est ton site, commence par le pré-audit SEO ou demande un audit SEO approfondi. Les automatisations qui font tourner ce dispositif relèvent de mon offre d’automatisation des process. Et pour en parler, écris-moi ou découvre mon parcours.

Questions fréquentes

Quelle différence entre un hébergement classique et un hébergement géré ?

Un hébergement classique fournit un serveur. Un hébergement géré ajoute la surveillance, les sauvegardes vérifiées, les mises à jour, le suivi des certificats et l’intervention en cas d’incident. La différence se voit le jour où quelque chose casse.

Un contrôle de disponibilité suffit-il à surveiller un site WordPress ?

Non. Un site peut répondre normalement avec un formulaire cassé, des sauvegardes qui échouent ou des tâches planifiées qui ne s’exécutent plus. Il faut surveiller aussi le circuit des contacts, les sauvegardes, les certificats et la performance réelle.

À quelle fréquence faut-il sauvegarder un site WordPress ?

La base de données change souvent et mérite une sauvegarde quotidienne. Les fichiers peuvent suivre un rythme adapté au site. Dans tous les cas, les sauvegardes doivent être stockées hors du serveur et testées par une restauration d’essai.

Pourquoi les tâches planifiées de WordPress ne s’exécutent-elles pas toujours ?

Parce que WordPress les déclenche lors des visites, et qu’un cache serveur sert les pages sans réveiller le site. La solution est de confier ces tâches au serveur, à intervalle fixe.

Comment savoir si mon certificat SSL va se renouveler ?

Vérifie sa date d’expiration et l’émetteur. Un certificat auto-signé ou une date d’expiration qui approche sans renouvellement sont des signaux d’alerte. Un suivi des échéances permet de le voir à l’avance.

Le client reçoit-il des alertes ?

Les alertes techniques arrivent chez le prestataire, qui les traite. Le client reçoit un rapport mensuel clair et, quand une intervention importante a eu lieu, un message qui explique ce qui s’est passé et ce qui a été fait.