Un contrôle automatisé annonce que le site est disponible. Pourtant, les clients n’arrivent plus à envoyer un formulaire et le panier tourne dans le vide. Ce paradoxe est fréquent : une réponse HTTP 200 n’est pas la preuve que le service fonctionne.
La surveillance utile distingue plusieurs étages : accessibilité du domaine, temps de réponse, fonctionnement des parcours et expérience réelle des visiteurs. Ce sont quatre signaux différents, qui peuvent se contredire.
En bref : les sondes de disponibilité doivent être complétées par des contrôles de parcours, de latence et d’erreurs.
La disponibilité brute masque les pannes partielles
Un ping ou une requête sur la page d’accueil ne dit rien d’une API de paiement, d’un moteur de recherche interne ou d’un espace membre. Multipliez les points de contrôle selon la criticité : DNS, TLS, page publique, endpoint applicatif et parcours authentifié de test. Chaque sonde doit vérifier non seulement le code de retour mais aussi un élément attendu dans la réponse.
Un site peut répondre en 1,5 seconde alors que son formulaire met dix secondes à enregistrer une demande. Il faut donc séparer les métriques serveur des mesures de parcours. Les tests synthétiques reproduisent une action définie ; les données de terrain permettent de voir l’impact réel sur les utilisateurs.
Définir une alerte exploitable évite les nuits inutiles
Une alerte toutes les minutes pour une fluctuation momentanée de latence ne donne aucune priorité. Définissez des seuils, une durée minimale et une sévérité : indisponibilité du paiement, échec d’authentification ou hausse persistante des erreurs 5xx n’exigent pas la même escalade.
Calculez aussi un taux d’erreurs par service plutôt qu’un total brut. Cent erreurs sur un million de requêtes n’ont pas la même signification que cent erreurs sur deux cents. Les journaux doivent conserver l’horodatage, le service, la corrélation de requête et les informations nécessaires au diagnostic, sans exposer de données personnelles dans les alertes.
Pour distinguer mesure de performance et surveillance métier, le guide sur les tests de vitesse web aide à interpréter plusieurs métriques côté chargement, sans remplacer les contrôles de transactions.
Tester le parcours client, pas seulement la page d’accueil
Un contrôle HTTP qui renvoie 200 OK ne garantit pas qu’un visiteur puisse se connecter, rechercher un produit ou terminer une commande. Une erreur JavaScript peut empêcher le bouton d’achat de fonctionner alors que le serveur et le CDN restent disponibles. Pour les services critiques, créez un scénario de surveillance synthétique qui effectue les étapes clés dans un navigateur : ouvrir une fiche, ajouter au panier de test, puis atteindre l’écran de confirmation sans transaction réelle.
Séparez les alertes de disponibilité des alertes de performance. Un délai de réponse de 800 ms n’a pas le même impact qu’un formulaire qui renvoie une erreur. Définissez vos indicateurs de service : proportion de transactions abouties, délai au 95e percentile, erreurs de connexion et taux d’échec des ressources. Une alerte n’est utile que si quelqu’un sait quoi faire en la recevant.
Un exemple de règle exploitable
Exemple fictif : un formulaire d’inscription doit fonctionner dans 99,9 % des essais synthétiques sur une période de 30 jours. Sur 10 000 essais, 10 échecs correspondent à 0,1 % ; mais un incident de paiement peut justifier une alerte dès le premier échec répété depuis deux points de contrôle. Il faut adapter la sensibilité au coût de l’indisponibilité et limiter les faux positifs, notamment lors des déploiements.
Préparer la réparation fait partie du dispositif
Chaque signal critique devrait pointer vers une procédure : qui intervient, quel tableau ouvrir, quelle modification récente vérifier, et comment désactiver une fonction défaillante. Une surveillance sophistiquée sans personne responsable produit surtout des notifications.
Effectuez un exercice de panne contrôlée sur un environnement de test. Mesurez le temps entre l’incident et sa détection, puis entre la détection et le retour au service. Ces deux délais disent bien davantage que le nombre de sondes achetées.
Comment lire un taux de disponibilité
Une disponibilité annoncée de 99,9 % sur trente jours correspond mathématiquement à un maximum d’environ 43,2 minutes d’indisponibilité sur cette période, si la définition du fournisseur compte chaque minute de la même façon. Ce chiffre ne renseigne ni sur les pannes partielles ni sur la qualité des sessions. Définissez votre propre périmètre avant de comparer les engagements.
Les métriques qui orientent réellement une intervention
Une latence en hausse peut provenir du DNS, de la négociation TLS, du serveur d’application, d’une base de données ou d’un service tiers. Mesurez ces étapes séparément. Un tableau qui ne donne qu’un temps total oblige l’équipe à chercher à l’aveugle. Des traces corrélées et des identifiants de requête permettent au contraire de retrouver la cause d’un délai.
Évitez les moyennes pour surveiller des expériences dégradées. Si quatre-vingt-dix requêtes sont traitées en 100 ms mais dix prennent quatre secondes, la moyenne masque le ressenti des visiteurs affectés. Les percentiles élevés et les taux d’erreurs segmentés par parcours rendent le diagnostic plus proche de la réalité.
La surveillance doit également éviter les données sensibles dans les URL de test, les captures et les alertes envoyées par messagerie. Un système conçu pour observer le site ne doit pas devenir une source de fuite d’informations clients.
Je suis Marie Prigent, passionnée du monde numérique, des gadgets high-tech et des dernières tendances en matière de son et de télévision. J’explore les domaines du streaming, de la réalité augmentée, du home-cinéma et des appareils intelligents. En outre, je suis une adepte des podcasts et des médias sociaux, où je partage mes découvertes et conseils.
