Checklist de surveillance des sites clients pour agences web

Une agence qui maintient trente ou cent sites clients n'a pas le même problème qu'une équipe qui surveille son propre produit. Chaque site a ses particularités, son hébergeur, ses échéances, son interlocuteur, et la surveillance se met souvent en place au fil de l'eau : un contrôle ajouté après une panne, un autre oublié lors d'une migration. Résultat, le jour où un nom de domaine expire ou une sauvegarde cesse de tourner, c'est le client qui prévient.

Voici la checklist que nous recommandons, organisée par étape : l'arrivée d'un site client, le routage des alertes, la communication avec le client, l'organisation du compte, les déploiements et la revue trimestrielle. Elle s'applique quel que soit votre outil ; nous indiquons au passage comment la mettre en œuvre avec LucidStack.

À l'arrivée d'un site client

C'est le moment où tout se joue : une fois le site en production et le client satisfait, plus personne ne revient compléter la surveillance.

Le site et ses pages clés

• Page d'accueil : un contrôle HTTP qui vérifie le code de réponse et le délai, avec un seuil de lenteur adapté au site.
• Pages qui rapportent : panier, tunnel de commande, page de contact, espace client. Un contrôle par mot-clé vérifie qu'un texte attendu est bien affiché, par exemple le libellé du bouton de commande.
• Textes interdits : à l'inverse, vérifiez qu'aucune page ne contient « Fatal error », « Maintenance » ou « Database connection ». Une page d'erreur servie avec un code 200 passe inaperçue pour un simple contrôle HTTP.
• API : si le site dépend d'une API (application mobile, connecteur ERP, recherche), contrôlez-la avec des assertions sur la réponse JSON plutôt que sur le seul code HTTP.

Un contrôle par mot-clé confirme que le formulaire de contact s'affiche, pas que les messages partent. Pour cette seconde moitié, surveillez aussi le serveur mail, comme indiqué plus bas.

Certificat, domaine, DNS et e-mail

• Certificat SSL/TLS : vérifié à chaque contrôle HTTPS, avec des rappels avant expiration et une alerte immédiate en cas de chaîne incomplète ou de nom d'hôte incorrect.
• Nom de domaine : LucidStack détecte les domaines à partir des moniteurs et les vérifie chaque jour via RDAP, avec des rappels 60, 30, 7 et 1 jour avant l'expiration. Un changement de serveurs de noms est signalé immédiatement.
• DNS : surveillez les enregistrements importants (A, MX, TXT) pour repérer une modification faite par le client ou son hébergeur sans vous prévenir.
• Serveur mail : si vous gérez la messagerie du client, contrôlez SMTP, IMAP ou POP, en STARTTLS ou TLS.

Tâches planifiées et sauvegardes

• Sauvegardes : chaque sauvegarde nocturne envoie un heartbeat à la fin ; si le signal n'arrive pas dans le délai de grâce, vous êtes alerté.
• Imports, synchronisations, envois de newsletters : même principe, avec le code de sortie pour distinguer un échec d'une absence d'exécution.

Le fonctionnement détaillé est expliqué dans notre guide pour surveiller une tâche cron avec des heartbeats.

Le cas de wp-cron sur WordPress

WordPress n'a pas de vraie tâche planifiée : wp-cron se déclenche lors des visites. Sur un site peu fréquenté, les publications programmées et les sauvegardes d'extension partent en retard, voire pas du tout. Et vos contrôles de surveillance, en visitant le site toutes les minutes, peuvent eux-mêmes déclencher wp-cron et masquer le problème.

// wp-config.php
define( 'DISABLE_WP_CRON', true );

# crontab (avec WP-CLI) : exécuter les tâches WordPress dues toutes les 5 minutes, puis signaler le résultat
*/5 * * * * cd /var/www/client && wp cron event run --due-now --quiet; curl -fsS -m 10 "https://ping.lucidstack.dev/<token>?exit_code=$?" > /dev/null

Le routage des alertes

Une alerte envoyée à tout le monde n'est lue par personne. Décidez qui reçoit quoi, et par quel canal :

• SMS réservés au critique : ils coûtent des crédits et réveillent. Gardez-les pour les sites où une panne coûte de l'argent au client.
• Heures calmes : dans LucidStack, les avertissements (rappels de certificat, état dégradé) attendent la fin des heures calmes ; les pannes et les rétablissements passent toujours.
• Escalade : à partir de l'offre Agency, une politique d'escalade prévient la personne suivante si personne n'accuse réception de l'incident dans le délai prévu.
• Test de chaque canal : envoyez un message de test à la création de chaque canal, pas le jour de la panne.

La communication avec le client

• Page de statut sur le domaine du client : par exemple statut.client-exemple.fr, avec un enregistrement CNAME vers status.lucidstack.dev. Le certificat HTTPS est émis automatiquement à la première visite. En marque blanche à partir de l'offre Agency : logo, couleurs, sans mention de LucidStack.
• Abonnés : proposez au client et à ses équipes de s'abonner aux annonces par e-mail.
• Rapport mensuel : un PDF envoyé le 1er de chaque mois avec la disponibilité, les incidents, les temps de réponse et un résumé rédigé. C'est la preuve concrète du travail inclus dans votre contrat de maintenance. Voir les rapports clients.
• Accès en lecture seule : le client consulte ses propres projets, sans voir ceux des autres clients.

Une page de statut bien tenue réduit aussi les appels du type « le site est en panne ? » quand le problème vient du réseau du client.

L'organisation du compte

• Un projet par client, qui regroupe ses moniteurs, ses pages de statut, son rapport et ses destinataires.
• Une convention de nommage lisible dans une alerte reçue sur un téléphone à 3 heures du matin.
• Des étiquettes cohérentes : technologie, hébergeur, type de contrat. Elles servent quand un hébergeur tombe et qu'il faut savoir quels clients prévenir.
• Un inventaire des échéances : LucidStack regroupe dans un tableau toutes les échéances de certificats et de domaines, triées par urgence. Notez à côté qui paie le renouvellement, l'agence ou le client.
• Des rôles par membre : l'offre Agency compte 5 membres, avec des rôles et un journal d'audit.

Client · Site · Contrôle
Boulangerie Martin · boutique · Commande (mot-clé)
Boulangerie Martin · boutique · Sauvegarde nocturne (heartbeat)

Les fenêtres de maintenance pendant les déploiements

• Planifiez une fenêtre de maintenance avant chaque mise en production ou migration : les contrôles pendant la fenêtre ne déclenchent pas d'alerte et la période est exclue du calcul de disponibilité.
• Annoncez-la sur la page de statut, pour que les abonnés soient prévenus.
• Gardez-la courte : une fenêtre de quatre heures pour un déploiement de dix minutes masque les vraies pannes qui surviendraient entre-temps.
• Vérifiez après coup que tous les contrôles du client sont revenus au vert.

La revue trimestrielle

Une fois par trimestre, prenez une heure pour faire le ménage :

• supprimer les moniteurs des sites arrêtés et des clients partis ;
• vérifier les destinataires des alertes et des rapports, et les accès clients ;
• envoyer un message de test sur chaque canal d'alerte ;
• relire les incidents du trimestre et les actions encore ouvertes ;
• repérer les faux positifs et ajuster délais d'expiration et seuils ;
• regarder l'évolution des temps de réponse sur 30 jours ;
• passer en revue les échéances des 90 prochains jours ;
• comparer votre consommation aux limites de votre offre.

Récapitulatif

Ce que prévoit l'offre Agency

L'offre Agency de LucidStack, à 24 € HT par mois, est pensée pour ce mode de travail : 200 moniteurs contrôlés jusqu'à toutes les 30 secondes, 100 heartbeats, 50 pages de statut, la marque blanche sur les pages et les rapports, l'accès client en lecture seule, 5 membres et les politiques d'escalade. Des moniteurs supplémentaires sont disponibles en option. Tous les détails sont sur la page dédiée aux agences web.

Avec ou sans LucidStack, l'essentiel reste de dérouler la même checklist pour chaque nouveau client. C'est ce qui fait la différence entre une maintenance que l'on facture et une maintenance que l'on peut prouver.