Comment nous détectons les pannes
Trois sources complémentaires, un algorithme robuste, zéro fausse alerte volontaire.
1. Signalements communautaires
Chaque visiteur peut signaler un problème via le bouton « J'ai un problème » présent sur chaque page service. Le signalement est immédiatement :
- •Horodaté à la seconde près
- •Géolocalisé par ville et département (via les headers IP Vercel, sans stockage de l'adresse IP)
- •Catégorisé par type de symptôme : connexion, paiement, vidéo, authentification, synchronisation, crash d'application, notifications
- •Pour les FAI, distingué par produit (BOX ou MOBILE)
Ces données constituent la base principale de notre analyse. Elles sont agrégées par tranches horaires et conservées pour constituer une baseline historique sur 7 jours.
2. Pings automatiques (monitoring technique)
En complément des signalements, des sondes techniques vérifient régulièrement la disponibilité des services via des requêtes HTTP. Pour chaque service surveillé, nous collectons :
- •Le code HTTP retourné (200, 503, timeout…)
- •La latence de réponse en millisecondes
- •Le message d'erreur éventuel
Un service qui ne répond pas, retourne une erreur 5xx ou dépasse le délai d'attente est signalé comme potentiellement indisponible. Les pings seuls ne déclenchent pas une alerte publique — ils viennent renforcer ou confirmer ce que les signalements communautaires indiquent déjà.
3. Pages de statut officielles
Pour les services qui publient une page de statut officielle (format Atlassian Statuspage, AWS Health, ou équivalent), nous interrogeons leur API toutes les 3 minutes. Les services couverts incluent Meta (Facebook, Instagram, WhatsApp), Discord, Cloudflare, GitHub, Epic Games (Fortnite) et Spotify.
Règle absolue : un indicateur JSON inattendu ou une erreur HTTP de l'API officielle ne déclenche aucune alerte. Seule une réponse JSON valide avec un indicateur explicitement différent de « none » (= tout va bien) déclenche une notification Telegram à l'équipe, avec un cooldown de 24 heures entre deux alertes pour le même service.
Cette approche garantit zéro faux positif lié à des endpoints cassés ou des APIs temporairement indisponibles.
4. Algorithme de détection — Indice de Disruption Nationale (IDN)
Pour éviter qu'un signalement isolé déclenche une fausse alerte, nous comparons le volume de signalements reçus sur les 2 dernières heures à une baseline historique calculée sur les 7 derniers jours.
La formule IDN 2.0 combine trois composantes :
avg7j2h = totalSignalements7j / (7 × 12)
baseline = MAX(avg7j2h × 1.5, 20)
ratio = signalements2h / baseline
scoreVolume = MAX(0, MIN(7.0, (ratio - 1) × 2.0))
scoreImpact = DEGRADED × 1.0 + MAJOR × 2.5
IDN = MIN(10.0, scoreVolume + scoreImpact)
Le plancher de bruit à 20 signalements évite qu'un service peu fréquenté atteigne un IDN élevé avec seulement 2 ou 3 signalements. Le score d'impactintègre les statuts officiels confirmés (DEGRADED, MAJOR_OUTAGE) lorsqu'ils sont disponibles.
L'IDN se traduit en 5 niveaux de statut : Opérationnel (0), Légère perturbation (1–2), Perturbation modérée (3–5), Panne significative (6–7), Panne majeure (8–10).
5. Résolution et retour à la normale
Un service revient au statut « Opérationnel » lorsque le volume de signalements retombe sous le seuil de la baseline pendant une période consécutive suffisante. Les abonnés aux alertes email reçoivent une notification automatique de « retour à la normale ».
Un mode Surveillance renforcée est activé dans les 6 heures suivant une perturbation significative : même si l'IDN est repassé sous le seuil d'alerte, le service est maintenu sous observation et le badge correspondant est affiché sur la page.
6. Alertes et notifications
Plusieurs couches d'alertes coexistent :
- •Alertes email abonnés : les utilisateurs inscrits reçoivent un email dès qu'un service qu'ils suivent passe en statut dégradé, puis un email de résolution.
- •Spike de signalements : un pic soudain (exactement 5 signalements en 15 minutes) déclenche une notification interne pour vérification manuelle.
- •Status pages officielles : tout incident confirmé par un éditeur est relayé immédiatement via alerte interne.
7. Limites et transparence
Statut Services ne peut pas détecter toutes les pannes. Certaines perturbations restent invisibles pour nous :
- •Pannes très locales (ville, opérateur spécifique, problème réseau personnel) si peu d'utilisateurs les signalent
- •Bugs fonctionnels discrets qui n'affectent qu'une minorité d'utilisateurs
- •Services peu fréquentés sur notre plateforme, pour lesquels la baseline est insuffisante
Nos données reflètent l'activité observée sur notre plateforme et ne constituent pas un audit exhaustif des infrastructures techniques des services. En cas de doute, consultez toujours la communication officielle du service concerné.
8. Protection anti-spam et RGPD
Pour garantir la fiabilité des données, plusieurs protections sont en place :
- •Un signalement par service par heure : l'empreinte IP + User-Agent est hachée de façon anonyme (SHA-256) — aucune IP brute n'est stockée
- •Aucun Cookie de tracking sur les signalements
- •Géolocalisation uniquement par IP (ville/département approximatif) — jamais de géolocalisation GPS
- •Commentaires modérés avant publication
- •Alertes email avec expiration automatique : les abonnements inactifs expirent après 24 heures sans confirmation