Alertes panne site client : détecter avant que le client appelle

Alertes panne site client : détecter avant que le client appelle

Une panne sur le site d'un client génère deux scénarios : soit votre supervision l'a détectée en premier et vous appelez proactivement, soit le client vous appelle parce que son site est inaccessible depuis plusieurs minutes. Le second cas n'est pas seulement une mauvaise expérience : c'est de la confiance perdue. Ce guide explique comment paramétrer des alertes fiables, quel canal utiliser selon l'urgence, et comment intervenir avec méthode grâce à un runbook d'incident copiable.

1. Pourquoi le client détecte avant vous
2. Paramétrer des alertes fiables
3. Runbook d'intervention : arbre de décision
4. Intégrer les alertes dans le rapport client

Pourquoi le client détecte avant vous

Trois causes expliquent ce décalage. La première est l'absence de surveillance : le site n'est pas monitoré, ou ne l'est que par une vérification manuelle lors des livraisons. La deuxième est une fréquence trop basse : une sonde toutes les 30 minutes laisse un site hors ligne pendant jusqu'à 30 minutes sans alerte. La troisième est la fatigue aux faux positifs : quand les notifications se déclenchent pour chaque micro-interruption réseau, l'équipe finit par les désactiver.

Il existe également des angles morts que les sondes HTTP standard ne couvrent pas : un certificat SSL expiré qui renvoie une erreur navigateur sans déclencher de panne 5xx, un domaine expiré qui interrompt la résolution DNS silencieusement, ou un site qui répond 200 mais affiche une page blanche à cause d'une erreur PHP non fatale. Ces situations passent souvent inaperçues jusqu'à ce qu'un utilisateur signale le problème directement.

Paramétrer des alertes fiables sur votre parc

Fréquence de vérification : l'arbitrage coût-bénéfice

La fréquence détermine votre délai de détection maximum. Une sonde toutes les 5 minutes garantit une détection en moins de 10 minutes dans le pire cas — c'est la fréquence par défaut adaptée à la majorité des sites d'agence. Pour une boutique en ligne à fort trafic ou un site de réservation, descendre à 1 minute est justifié : chaque minute de panne pendant une campagne publicitaire peut représenter des commandes perdues. Pour les sites vitrines peu actifs ou les préproductions, 15 à 30 minutes suffisent.

Une fréquence uniforme et prévisible vaut mieux qu'une configuration complexe qui varierait selon les horaires : les angles morts du week-end sont une source classique d'incidents non détectés.

Multi-canal : quel canal selon l'urgence

Tous les canaux ne se valent pas au moment d'une panne. L'e-mail est tracé et archivable, mais peut rester non lu pendant des heures. Slack ou Teams déclenche une alerte collective visible par toute l'équipe en quelques secondes. Le webhook autorise l'intégration dans vos outils internes : créer automatiquement un ticket, déclencher un pipeline CI, ou notifier une application mobile interne.

Configurez au minimum deux canaux : e-mail pour la trace écrite, Slack ou Teams pour la réaction immédiate. Réservez le webhook aux cas où vous disposez d'un système d'escalade automatique.

Éviter les faux positifs : la double confirmation

Un faux positif se produit quand une micro-interruption réseau entre la sonde et le serveur déclenche une alerte pour un site parfaitement opérationnel. La parade standard est la double confirmation : l'alerte n'est déclenchée qu'après deux sondes consécutives en échec. PagerDuty le souligne : une surveillance superficielle génère plus de bruit que de valeur. Deux échecs consécutifs à 5 minutes d'intervalle signifient une panne détectée en moins de 10 minutes — délai acceptable pour la grande majorité des sites.

La supervision Sentinelo applique ce mécanisme par défaut. La sonde est configurable à 1, 5, 15, 30 ou 60 minutes selon le site, avec un historique conservé sur 13 mois pour analyser les incidents récurrents et les tendances de disponibilité.

Runbook d'intervention : arbre de décision

Ce runbook est structuré par type d'erreur. Chaque entrée liste les commandes de diagnostic prioritaires et un temps d'intervention cible pour une agence de taille standard.

Erreur HTTP 503 (service indisponible)

Le serveur répond mais le service applicatif est en erreur. Vérifiez dans cet ordre :

1. L'état du service web : sudo systemctl status nginx (ou apache2). S'il est arrêté, relancez-le et consultez immédiatement les logs : sudo tail -50 /var/log/nginx/error.log
2. L'espace disque : df -h. Un disque plein est l'une des causes les plus fréquentes de 503 sur les serveurs mutualisés ou mal dimensionnés.
3. PHP-FPM si le site tourne en PHP : sudo systemctl status php8.2-fpm, puis sudo journalctl -u php8.2-fpm -n 100 pour les 100 dernières lignes de log.

Temps d'intervention cible : 15 minutes pour identifier la cause, 30 minutes pour résoudre les cas courants (espace disque, service arrêté).

Timeout (pas de réponse du serveur)

Le serveur ne répond pas du tout. Distinguez deux cas avant d'agir :

1. Serveur injoignable par ping : escaladez immédiatement vers l'hébergeur. Le problème est infrastructure, hors de votre périmètre direct.
2. Ping OK mais HTTP timeout : le serveur est surchargé. Connectez-vous en SSH et lancez top pour identifier le processus qui monopolise le CPU ou la mémoire. Sur WordPress, un plugin en boucle ou une migration de base de données non terminée sont des coupables fréquents.

Temps d'intervention cible : 10 minutes pour escalader vers l'hébergeur ou identifier le processus responsable.

Certificat SSL expiré

Le navigateur affiche une erreur de sécurité, ce qui bloque l'accès pour la quasi-totalité des visiteurs. Vérifiez la date d'expiration avec la commande : openssl s_client -connect exemple.com:443 </dev/null 2>/dev/null | openssl x509 -noout -dates. Si le certificat est Let's Encrypt et que le renouvellement automatique a échoué, vérifiez la crontab : crontab -l | grep certbot, puis forcez le renouvellement avec certbot renew --force-renewal.

Pour éviter ce type de panne, configurez une alerte à 30 jours et à 7 jours avant expiration. La plateforme de supervision inclut ce contrôle dans le même tableau de bord que la disponibilité HTTP, sans configuration supplémentaire.

Temps d'intervention cible : 30 minutes pour renouveler et vérifier la propagation HTTPS.

Contenu injecté ou hack

Le site répond 200 mais affiche du contenu suspect : publicités, redirections vers des pages étrangères, texte en langue inconnue. Ne tentez pas de nettoyer manuellement en production.

1. Mettez le site en maintenance immédiatement pour limiter l'exposition des visiteurs.
2. Prenez un instantané de l'état compromis à des fins d'analyse post-incident.
3. Restaurez depuis la dernière sauvegarde saine connue. Sur l'offre client final, l'équipe Sentinelo lance la restauration après votre demande ; sur l'offre agence, c'est votre équipe qui intervient avec ses propres outils.
4. Lancez un scan complet avant de remettre le site en ligne.

Temps d'intervention cible : variable selon l'ancienneté de la dernière sauvegarde saine disponible.

Intégrer les alertes dans le rapport client mensuel

Un incident bien géré, documenté et communiqué renforce la confiance davantage qu'une absence totale de panne apparente. Chaque incident mérite une entrée dans le rapport mensuel : heure de détection, heure de premier contact client, heure de résolution, cause identifiée. Ce niveau de transparence distingue une agence professionnelle d'un prestataire qui gère les urgences en silence.

Le rapport PDF mensuel peut agréger disponibilité, sauvegardes exécutées et temps d'intervention sur l'ensemble de votre parc. Pour structurer ce suivi de bout en bout, consultez notre guide sur la supervision de sites web pour agences.

Paramétrez vos alertes, documentez chaque intervention, et votre client apprendra toujours les pannes de votre bouche — jamais de la sienne. La plateforme de supervision Sentinelo centralise sondes HTTP, contrôles SSL, expiration de domaine et historique d'alertes dans un seul tableau de bord pour votre parc de sites clients.