Monitoring uptime : superviser 50 sites clients sans se noyer

Monitoring uptime : superviser 50 sites clients sans se noyer

À 5 sites, un outil de monitoring gratuit suffit amplement. À 50, les quotas de moniteurs, les faux positifs à 3h du matin et l'absence de vue consolidée par client transforment la supervision en source de bruit plutôt qu'en aide à la décision. Ce guide détaille l'architecture à mettre en place, les paramètres à ajuster par type de CMS, et la façon d'intégrer les données de disponibilité dans vos rapports clients.

• De 5 à 50 sites : quand les outils gratuits atteignent leurs limites
• Architecture d'un monitoring uptime pour 50 sites
• Réduire le bruit : double confirmation et fenêtres de silence
• Intégrer l'uptime dans les rapports clients
• Configuration recommandée par CMS pour un parc de 50 sites

De 5 à 50 sites : quand les outils gratuits atteignent leurs limites

UptimeRobot propose 50 moniteurs gratuits avec une vérification toutes les 5 minutes. Pour une agence qui débute, ce quota suffit. Le problème se pose à mesure que le portefeuille client grossit :

• Quota de moniteurs : dépasser 50 sites implique de passer sur un plan payant. Sur le plan Team d'UptimeRobot, l'intervalle minimum descend à 60 secondes, ce qui est utile pour les boutiques — mais la facture évolue en proportion du parc, sans notion de regroupement client.
• Absence de vue par client : les outils généralistes n'ont pas de notion de portefeuille. Impossible de générer un rapport de disponibilité spécifique à chaque client sans export et retraitement manuels, ce qui représente plusieurs heures de travail par mois à partir d'une vingtaine de clients.
• Gestion des faux positifs : sans double confirmation, chaque micro-indisponibilité réseau déclenche une alerte, puis un retour-à-la-normale quelques secondes plus tard. Deux notifications pour un incident fictif. Sur 50 sites, cela peut représenter plusieurs dizaines d'alertes par semaine qui ne correspondent à aucune vraie panne.
• Surveillance SSL et domaine : la vérification des certificats TLS et des noms de domaine est absente des plans d'entrée de gamme ou facturée séparément. Or un certificat expiré ou un domaine non renouvelé produit exactement la même coupure qu'un serveur hors-ligne — sans aucun signal côté infrastructure.

Ces limites ne sont pas rédhibitoires sur un petit parc. Elles deviennent coûteuses en temps et en crédibilité quand chaque nuit peut apporter une dizaine d'alertes pour autant de faux positifs, et quand votre client découvre que son domaine a expiré avant que vous l'ayez remarqué.

Pour un tour d'horizon des indicateurs à mettre en place en priorité sur un parc d'agence, l'article supervision des sites web pour agences détaille les métriques et les outils adaptés à chaque taille de portefeuille.

Architecture d'un monitoring uptime pour 50 sites

Vérifications HTTP, SSL et domaine

Un monitoring uptime complet couvre quatre types de contrôles distincts :

1. Sonde HTTP/HTTPS : une requête GET sur l'URL de la page d'accueil et sur au moins une page critique (checkout, formulaire de contact, page produit principale). Les codes de statut HTTP 5xx indiquent une erreur côté serveur — un 503 signale que le serveur n'est pas disponible pour traiter la requête, souvent à cause d'une surcharge ou d'une maintenance. Un 4xx sur une URL censée exister signale une régression à investiguer sans délai.
2. Certificat SSL : vérification de la date d'expiration avec alerte à J-30 puis J-7. Un certificat expiré rend le site inaccessible pour tous les visiteurs — et votre client vous appellera avant que vous l'ayez détecté si vous ne surveillez que le HTTP.
3. Expiration du domaine : un domaine non renouvelé entraîne la même coupure qu'un serveur hors-ligne, mais ne se détecte pas par la sonde HTTP habituelle. Configurer une alerte à J-60 et J-30 laisse suffisamment de temps pour agir auprès du registrar avant que le service soit interrompu.
4. Temps de réponse : un site qui répond en 8 secondes est techniquement « en ligne » mais inutilisable. Un seuil de dégradation (par exemple, un temps de réponse supérieur à 3 secondes sur deux vérifications consécutives) complète utilement la sonde binaire disponible/indisponible.

Intervalles de check selon le type de site

La fréquence de vérification est un compromis entre réactivité et volume de requêtes générées. Un check à la minute sur 50 sites produit 72 000 requêtes par jour — certains hébergeurs mutualisés peuvent l'interpréter comme du trafic anormal. La règle pratique :

Type de site	Intervalle recommandé	Justification
Site vitrine	15 min	Tolérance à une panne courte, faible impact commercial immédiat.
Blog ou portail de contenu	15 min	Audience non transactionnelle, pas de panier en jeu.
Boutique WooCommerce ou PrestaShop	5 min	Chaque minute d'indisponibilité a un coût direct sur les conversions.
Application métier ou SaaS	1 min	SLA client à respecter, tolérance à la panne quasi nulle.

La page de supervision Sentinelo applique 5 minutes par défaut, avec les options 1, 15, 30 et 60 minutes configurables site par site depuis le tableau de bord.

Réduire le bruit : double confirmation et fenêtres de silence

Le double-check comme premier filtre

Un nœud réseau intermédiaire — CDN, opérateur, point de sortie du service de monitoring — peut connaître une latence ponctuelle sans que le site soit réellement en panne. Sans double confirmation, cette latence génère une alerte, puis quelques secondes plus tard un retour à la normale : deux notifications pour un incident fictif. Sur 50 sites dont plusieurs en hébergement mutualisé, ce scénario se produit plusieurs fois par semaine.

Le double-check retarde le déclenchement d'une alerte jusqu'au deuxième échec consécutif. Sur un intervalle de 5 minutes, une vraie panne est détectée en 10 minutes au plus — un délai acceptable pour la grande majorité des clients. En contrepartie, les micro-indisponibilités d'une poignée de secondes ne génèrent plus aucune notification.

L'article détecter une panne avant votre client détaille comment configurer les canaux d'alerte et les niveaux d'escalade selon la disponibilité de votre équipe.

Fenêtres de maintenance et niveaux de criticité

Un déploiement planifié la nuit génère quelques secondes d'indisponibilité. Sans fenêtre de maintenance programmée, l'outil déclenche une alerte puis un retour-à-la-normale : deux notifications inutiles. La bonne pratique consiste à ouvrir la fenêtre avant chaque déploiement. Pendant cette période, les mesures continuent mais les alertes sont suspendues ; si le site ne revient pas dans le délai prévu, l'alerte part quand même.

Pour les agences gérant des clients de criticités différentes, une hiérarchisation des niveaux de service évite de traiter une vitrine informationnelle comme une boutique en ligne :

• Niveau critique (e-commerce, SaaS, application métier) : alerte immédiate par e-mail, Slack ou Teams, avec webhook vers l'outil de ticketing de l'agence.
• Niveau standard (vitrine, blog) : alerte e-mail seule, délai de confirmation porté à 15 minutes pour absorber les faux positifs résiduels.
• Niveau silencieux (site en refonte, migration en cours) : notifications désactivées, mesures conservées pour le rapport mensuel.

Intégrer l'uptime dans les rapports clients

Les données de disponibilité prennent tout leur sens dans un rapport mensuel remis au client. Le calcul du taux de disponibilité est direct :

Taux de disponibilité = (minutes du mois − minutes d'indisponibilité cumulées) ÷ minutes du mois × 100

Un mois de 30 jours représente 43 200 minutes. Présenter ce calcul dans le rapport, avec la liste des incidents datés et leur durée, donne au client une lecture concrète de la qualité de service et justifie l'investissement dans la maintenance.

Trois éléments suffisent pour structurer la section disponibilité d'un rapport mensuel :

1. Le taux de disponibilité du mois, exprimé en pourcentage.
2. La liste des incidents : date, heure de début, durée, cause identifiée ou en cours d'analyse.
3. L'état du certificat SSL et la prochaine échéance du domaine.

La page rapports de Sentinelo génère automatiquement ce PDF mensuel par client, avec le logo et les couleurs de votre agence. Il peut être envoyé automatiquement ou retenu pour relecture avant envoi — utile quand un incident du mois mérite une explication personnalisée.

Configuration recommandée pour un parc de 50 sites

Voici les paramètres qui offrent un bon équilibre entre réactivité et volume d'alertes maîtrisé pour un portefeuille de cette taille :

Paramètre	Valeur	Remarque
Fréquence par défaut	5 min	Configurable à 1 min pour les boutiques, 15 min pour les vitrines.
Double confirmation	Activée	Réduit les faux positifs sans allonger la détection de plus d'un intervalle.
Pages surveillées par site	2 à 3	Accueil + page critique métier (checkout, formulaire de contact).
Alerte SSL	J-30 et J-7	Deux points de contrôle pour anticiper le renouvellement.
Alerte domaine	J-60 et J-30	Délai plus long, l'action est à engager auprès du registrar.
Historique conservé	13 mois	Permet de présenter la disponibilité sur 12 mois glissants.
Canaux d'alerte	E-mail + Slack ou Teams	Webhook disponible pour intégration dans un outil de ticketing.

Sur le plan SCALE de Sentinelo, prévu pour 31 à 60 sites, le coût de supervision est de 39 € HT par site et par mois. La surveillance HTTP, SSL, domaine et performance Lighthouse est incluse dans ce tarif, sans supplément par canal d'alerte configuré ni par page surveillée.

Pour appliquer cette configuration à votre parc et tester les paramètres pendant 14 jours sans carte bancaire, la page supervision détaille les contrôles disponibles et les options par site.