Supervision d’un site autonome : seuils d’alerte pour la disponibilité, la performance, les erreurs et les certificats
1. Supervision de la disponibilité : une sonde toutes les 5 minutes, seuls les échecs consécutifs comptent
La supervision de la disponibilité est la couche la plus élémentaire : le site s’ouvre-t-il ou non. Beaucoup alertent dès une seule sonde en échec, et la moindre fluctuation réseau réveille tout le monde ; au bout d’une semaine, plus personne ne regarde les alertes. La bonne méthode : ne compter que les échecs consécutifs. 2 échecs consécutifs envoient un message jaune dans le groupe, 3 échecs consécutifs déclenchent SMS et appel. Intervalle de sonde de 5 minutes, au moins 3 points de sonde dans le monde (par exemple côte Est des États-Unis, Europe, Asie-Pacifique) pour éviter les fausses alertes d’un point unique.
Ne surveillez pas seulement la page d’accueil. Elle peut rester en vie grâce au cache alors qu’une page produit ou le formulaire de demande de devis est déjà hors service. Surveillez au moins trois URL : la page d’accueil, une page de détail produit et le point de soumission du formulaire de demande de devis. Si l’une tombe, c’est une panne de disponibilité. La version gratuite d’UptimeRobot suffit : 50 emplacements de surveillance, intervalle de 5 minutes, plusieurs points de sonde dans le monde.
| Élément surveillé | Intervalle de sondage | Seuil jaune | Seuil rouge | Mode de notification |
|---|---|---|---|---|
| Statut HTTP de la page d’accueil | 5 minutes | 2 réponses non-200 consécutives | 3 réponses non-200 consécutives | Message de groupe → SMS et appel |
| Page de détail produit | 5 minutes | 2 réponses non-200 consécutives | 3 réponses non-200 consécutives | Message de groupe → SMS et appel |
| Point de soumission du formulaire de demande de devis | 10 minutes | 2 erreurs 5xx consécutives | 3 erreurs 5xx consécutives | Message de groupe → SMS et appel |
| Port TCP 22/3306 | 5 minutes | Injoignable | — | Message de groupe (heures ouvrées uniquement) |
| Certificat SSL | 24 heures | 30 jours restants | 15 jours restants | E-mail → WeCom |
Exemple concret : un site d’export surveille sa page d’accueil avec UptimeRobot et n’alerte qu’après 3 échecs consécutifs. Une nuit, le point de sonde de Singapour échoue 3 fois de suite, mais ceux de la côte Est des États-Unis et d’Europe répondent normalement : c’est un problème de réseau local à Singapour, pas une panne du site. Avec une alerte dès la première sonde, la personne d’astreinte est réveillée à 2 heures du matin, constate que le site va bien, et ne fera plus confiance aux alertes. Multiplier les points de sonde et exiger des échecs consécutifs réduit le taux de fausses alertes au minimum.
Disponibilité et RTO/RPO de reprise après sinistre vont de pair : quand une alerte de disponibilité se déclenche, on suit la procédure de reprise. Pour savoir comment réagir en cas de panne d’un nœud CDN, voir Accélération mondiale par CDN.
2. Suivi des performances : surveillez le LCP, pas la note globale
L’erreur la plus fréquente en suivi de performances, c’est de regarder la note globale. Le score Google PageSpeed fluctue énormément : la même page peut afficher 85 le matin et 65 l’après-midi. Déclencher une alerte sur ces variations n’a aucun intérêt. Ce qu’il faut vraiment surveiller, ce sont les trois indicateurs clés de Core Web Vitals, en particulier le LCP (Largest Contentful Paint), car il influence directement la perception des utilisateurs et le classement SEO.
Pour les alertes de performance, n’utilisez pas un seuil unique mais une durée. Un LCP qui dépasse ponctuellement 2,5 secondes peut venir d’une mauvaise connexion chez un utilisateur ; c’est seulement s’il reste au-dessus pendant 10 minutes qu’il y a un vrai problème. Seuil jaune : LCP supérieur à 2,5 secondes pendant 10 minutes. Seuil rouge : LCP supérieur à 4 secondes pendant 15 minutes. Côté outils, utilisez BrowserStack SpeedCurve ou les données publiques du Chrome User Experience Report, et suivez la tendance mois par mois.
| Indicateur | Seuil de qualification | Seuil jaune | Seuil rouge | Explication |
|---|---|---|---|---|
| LCP Largest Contentful Paint | ≤ 2,5 s | >2,5 s pendant 10 minutes | >4 s pendant 15 minutes | Le plus critique, impacte directement le SEO et la conversion |
| INP Interaction to Next Paint | ≤ 200 ms | >200 ms pendant 10 minutes | >500 ms pendant 15 minutes | À surveiller en cas de blocage à l’envoi d’un formulaire |
| CLS Cumulative Layout Shift | ≤ 0,1 | >0,1 pendant 10 minutes | >0,25 pendant 15 minutes | Causé par les publicités ou les images en lazy loading |
| TTFB Time to First Byte | ≤600 ms | >600 ms pendant 10 minutes | >1,5 s pendant 15 minutes | Backend lent ou problème de base de données |
| Taux d’erreur du site | <1 % | >1 % pendant 5 minutes | >5 % pendant 10 minutes | Compter séparément les 5xx et les 4xx |
Exemple concret : un jour, en matinée, le LCP d’un site est passé de 1,8 à 3,5 secondes, puis est revenu à la normale tout seul après 20 minutes. En consultant les logs, on a découvert une requête lente en base de données : une tâche planifiée d’un plugin lançait un scan complet de table. Sans alerte, les utilisateurs qui envoyaient un formulaire pendant ces 20 minutes auraient subi un timeout, et la vente était perdue. Tout l’intérêt du suivi de performances, c’est de repérer ce genre de dégradation passagère. Pour savoir comment optimiser les Core Web Vitals, voir Seuils et priorités d’optimisation des Core Web Vitals.
3. Taux d’erreur et logs : distinguez les 5xx des 4xx
Le suivi du taux d’erreur se fait en deux catégories : les 5xx sont des erreurs serveur et exigent une alerte ; les 4xx sont des erreurs client et, dans la plupart des cas, il ne faut pas s’en occuper. Si vous mélangez les deux, soit vous recevez trop d’alertes, soit les vrais problèmes passent inaperçus. Un taux de 5xx supérieur à 1 % pendant 5 minutes déclenche une alerte jaune, supérieur à 5 % pendant 10 minutes une alerte rouge. Pour les 4xx, surveillez uniquement les pics de 404 : beaucoup de 404 signifient des liens externes cassés ou des redirections 301 oubliées lors d’une refonte.
Pour le suivi des erreurs, utilisez un outil comme Sentry, qui collecte automatiquement les erreurs JavaScript côté front et les exceptions côté back, et les regroupe par type. Un site e-commerce indépendant n’a pas besoin de traiter chaque erreur, mais doit surveiller la fréquence des 3 erreurs les plus courantes. Si une erreur passe soudainement d’une fois par semaine à dix fois par heure, c’est qu’un déploiement a introduit un bug. Pour savoir comment analyser les logs, voir Analyse des logs de crawlers IA.
| Type d’erreur | Baseline normale | Seuil jaune | Seuil rouge | Mesure à prendre |
|---|---|---|---|---|
| Erreurs serveur 5xx | <0,5 % | >1 % pendant 5 minutes | >5 % pendant 10 minutes | Consulter les logs backend, revenir en arrière ou augmenter les ressources |
| 404 page inexistante | <1 % | Pic ×3 pendant 1 heure | Pic ×10 | Vérifier les liens externes et le mapping des 301 |
| Erreurs JavaScript front | <10/jour | >50/jour | >200/jour | Analyser les groupes dans Sentry |
| Échec d’envoi du formulaire de contact | <1 % | >3 % pendant 10 minutes | >10 % | Vérifier SMTP et la synchro CRM |
| Échec de connexion à la base de données | 0 fois | 1 fois | 3 fois de suite | Vérifier l’état de MySQL maintenant |
Exemple concret : un site publie une nouvelle version, et une erreur JS dans Sentry passe de 3 à 200 par jour. En regardant le code, on découvre qu’un script d’un emplacement publicitaire lève une exception sur Safari et bloque l’envoi des formulaires. Sans alerte, les demandes des utilisateurs Safari sont perdues. La surveillance de la fréquence des erreurs Sentry permet de détecter ce type de régression dans les 24 heures suivant une mise en production.
4. Certificats et sauvegardes : les deux oublis les plus fréquents
L’expiration d’un certificat est l’incident le plus bête sur un site e-commerce. Dans 90 % des cas, ce n’est pas un problème technique : on a simplement oublié de renouveler. Prévoyez deux niveaux d’alerte : un e-mail à 30 jours restants, une alerte WeCom à 15 jours. N’attendez pas les 3 derniers jours : à ce moment-là, l’e-mail du registrar peut déjà être en spam, ou un problème DNS peut être trop long à corriger. Côté outils, utilisez la surveillance de certificat d’UptimeRobot ou un script personnalisé qui vérifie chaque jour.
La tâche de sauvegarde elle-même doit aussi être surveillée. Si le script de sauvegarde échoue sans que vous le sachiez, vous ne le découvrirez qu’au moment du sinistre, en réalisant que la dernière sauvegarde date de deux semaines. Trois règles d’alerte : alerter si le code de sortie de la tâche de sauvegarde est non nul ; alerter si la taille du fichier de sauvegarde chute de 30 % par rapport à la veille (base de données peut-être inaccessible) ; alerter si la sauvegarde la plus récente a plus de 24 heures. Pour la stratégie de sauvegarde, voir Sauvegarde et restauration : s’entraîner à réagir.
| Élément surveillé | Fréquence de contrôle | Seuil jaune | Seuil rouge | Mode de notification |
|---|---|---|---|---|
| Jours restants du certificat SSL | Chaque jour | 30 jours restants | 15 jours restants | E-mail → WeCom |
| Code de sortie de la sauvegarde | À chaque exécution | Non nul | — | WeCom immédiat |
| Taille du fichier de sauvegarde | Chaque jour | -30 % vs la veille | -70 % vs la veille | WeCom |
| Âge du fichier de sauvegarde | Chaque jour | >24 heures | >48 heures | WeCom |
| Utilisation du disque | Chaque heure | >80 % | >90 % | WeCom |
| CPU/mémoire | Toutes les 5 minutes | >80 % pendant 10 minutes | >95 % pendant 10 minutes | WeCom |
Rappel contre-intuitif : ne misez pas sur un seul canal d’alerte. L’e-mail finit en spam, WeCom peut passer inaperçu pendant les congés, le SMS et l’appel sont le dernier recours. Les alertes importantes (site down, certificat bientôt expiré) doivent passer par SMS ou appel, les alertes ordinaires par groupe WeCom. Prévoyez aussi une escalade : si une alerte rouge n’est pas traitée en 15 minutes, elle est transmise automatiquement au responsable technique. Pour la checklist d’inspection quotidienne, voir Les six tâches mensuelles de la maintenance d’un site.
Une fois le système de surveillance en place, faites un bilan mensuel des alertes : combien d’alertes jaunes, combien de rouges, combien de faux positifs sur le mois écoulé. Tout seuil dont le taux de faux positifs dépasse 30 % doit être resserré ou ajusté. L’objectif n’est pas de couvrir tous les cas possibles, mais de réveiller quelqu’un dès qu’un vrai incident survient : pour cela, supprimez activement les règles qui déclenchent des fausses alertes tous les jours.
FAQ — Questions fréquentes
Quels outils utiliser pour surveiller un site e-commerce, et les solutions gratuites suffisent-elles ?
Que faire quand l’équipe ne prend plus les alertes au sérieux ?
Quel intervalle choisir pour la surveillance de disponibilité ?
Comment définir les seuils de surveillance d’un certificat SSL ?
Quel indicateur suivre pour la performance, et faut-il surveiller le score PageSpeed ?
Comment surveiller l’échec d’une tâche de sauvegarde ?
Pour conclure
L’échec le plus fréquent d’un système de surveillance n’est pas l’absence de surveillance, mais trop de surveillance que personne ne regarde. Quand on vient de le mettre en place, on veut tout surveiller : CPU, mémoire, disque, réseau, chaque URL, chaque erreur. Une semaine plus tard, il y a tellement d’alertes que l’équipe devient insensible, et les alertes rouges qui signalent un vrai incident se noient dans le bruit des jaunes. La valeur de la surveillance, c’est de réveiller quelqu’un au moment critique, pas la couverture.
Trois étapes pour passer à l’action. Premièrement, définissez deux niveaux de seuils, jaune et rouge, pour chacune des quatre dimensions (disponibilité, performance, erreurs, certificats) : le jaune part seulement dans le groupe sans réveiller personne, le rouge déclenche SMS et appel. Deuxièmement, lancez-vous avec une combinaison d’outils gratuits : UptimeRobot, Sentry et un script de certificat, pour un coût mensuel de 0 euro. Troisièmement, faites un bilan mensuel des alertes et supprimez les règles dont le taux de faux positifs dépasse 30 %. La surveillance est un système vivant, pas un chantier qu’on termine une fois pour toutes : elle demande un entretien continu.
Une phrase à retenir : l’objectif de la surveillance n’est pas de couvrir toutes les possibilités, mais de réveiller quelqu’un dès qu’un vrai incident survient. Quand il y a tellement d’alertes que l’équipe les met en sourdine, c’est plus dangereux que pas de surveillance du tout.