Qu'est-ce que le Synthetic Monitoring (supervision synthétique) ? Définition, types, RUM

Qu'est-ce que le synthetic monitoring ?

Le synthetic monitoring (supervision synthétique) exécute des contrôles scriptés sur un site web, une API ou une application selon un calendrier, depuis les lieux que vous choisissez, et vous alerte quand un contrôle échoue ou ralentit. Le trafic est artificiel : cela fonctionne à 3 h du matin et avant le lancement, sans aucun visiteur. Il répond en continu à une question : cela marche-t-il toujours comme prévu ?

Cette page explique le concept. Pour configurer des contrôles, voir le synthetic monitoring de LoadFocus, qui couvre les contrôles d'API et les contrôles navigateur Playwright.

Comment fonctionne le synthetic monitoring

1. Définir un contrôle. Une URL, une requête d'API ou un parcours de navigateur scripté, avec des assertions : code de statut, texte dans le corps, temps de réponse sous une limite.
2. Le planifier. Chaque minute pour les services critiques, toutes les quelques minutes pour la plupart, toutes les heures ou chaque jour pour les pages secondaires.
3. L'exécuter depuis plusieurs lieux. Un échec vu depuis une région et pas depuis une autre pointe un problème de routage, de CDN ou de DNS. Exiger l'accord de deux lieux réduit aussi les fausses alertes.
4. Enregistrer le résultat. Temps, statut et, pour les contrôles navigateur, captures d'écran et cascades réseau.
5. Alerter. Par e-mail, Slack, webhook ou bipeur, éventuellement seulement après plusieurs échecs consécutifs.

Types de contrôles synthétiques

• Contrôles de disponibilité. Demandent une URL et vérifient qu'elle répond avec le statut attendu.
• Contrôles d'API. Appellent un endpoint avec des en-têtes et un corps, puis vérifient statut, en-têtes, contenu et durée. Les contrôles en plusieurs étapes enchaînent les appels, par exemple connexion, récupération du jeton, appel d'un endpoint protégé. Voir supervision d'API.
• Contrôles navigateur. Pilotent un vrai navigateur sur une page ou un parcours comme connexion, recherche et paiement, et indiquent l'étape qui a échoué ou ralenti.
• Contrôles de vitesse de page. Chargent une page en conditions de laboratoire à intervalles réguliers et suivent des métriques comme le Largest Contentful Paint et le Total Blocking Time. Voir Core Web Vitals.
• Contrôles SSL et DNS. Surveillent l'expiration des certificats et vérifient qu'un nom d'hôte pointe vers la bonne adresse.

Synthetic monitoring et supervision des utilisateurs réels

Ils mesurent des choses différentes et les équipes mûres utilisent les deux.

La comparaison détaillée se trouve dans synthetic monitoring ou supervision des utilisateurs réels.

Métriques à suivre

• Disponibilité. Part des contrôles réussis sur une période. Les objectifs comme 99,9 % se rapportent en général à partir de ce chiffre.
• Temps de réponse. De bout en bout, idéalement ventilé en DNS, connexion, TLS, attente et téléchargement.
• Taux d'erreurs. Assertions échouées et codes de statut inattendus.
• Time to First Byte. Un signal rapide de la santé du serveur.
• Métriques navigateur. LCP, CLS et TBT dans les contrôles navigateur ou de vitesse de page. L'Interaction to Next Paint exige de vrais utilisateurs, donc en laboratoire le TBT sert d'indicateur de réactivité.

Un exemple simple

Une boutique en ligne ajoute un contrôle d'API sur GET /products?limit=1 qui doit renvoyer 200 avec un corps JSON contenant items en moins de 500 ms, et un contrôle navigateur qui parcourt connexion, recherche et ajout au panier. Les deux s'exécutent toutes les quelques minutes depuis deux régions. Quand l'étape du panier se met à échouer après un déploiement, l'alerte nomme l'étape et joint la capture, avant que la plupart des clients ne soient touchés.

Erreurs courantes

• Ne contrôler que la page d'accueil. L'accueil peut fonctionner alors que la connexion ou le paiement sont cassés.
• Ne vérifier que le statut. Un 200 avec un message d'erreur ou une liste vide passe quand même. Vérifiez aussi le corps.
• Un seul lieu. Une coupure réseau locale vous réveille la nuit.
• Alerter à chaque échec. Exigez deux échecs consécutifs ou l'accord de deux lieux.
• Comptes de test partagés qui expirent. Le contrôle échoue pour des raisons étrangères au produit.
• La croire exhaustive. Elle ne remplace ni l'observabilité ni la supervision des performances applicatives, qui expliquent pourquoi quelque chose a cassé.

Synthetic monitoring et tests de charge

Les contrôles synthétiques envoient un mince filet de trafic pour confirmer qu'un utilisateur peut accomplir sa tâche. Un test de charge envoie beaucoup d'utilisateurs à la fois pour trouver le point de rupture. Ils se complètent : le test de charge trouve la limite avant le lancement, le synthetic monitoring signale quand la production s'en approche. Les contrôles d'API gratuits de LoadFocus s'exécutent toutes les 5 minutes ; les intervalles payants sont détaillés sur supervision d'API, et les audits Lighthouse planifiés sur surveillance de la vitesse des pages. Commencez avec les contrôles d'API gratuits. Pour des conseils pratiques, lisez comment améliorer l'expérience utilisateur grâce au synthetic monitoring.

Questions fréquentes : synthetic monitoring

Quelle différence entre synthetic monitoring et supervision de disponibilité ?

La supervision de disponibilité est le contrôle synthétique le plus simple : elle demande si une URL répond. Le synthetic monitoring couvre aussi les assertions d'API, les parcours en plusieurs étapes, les contrôles navigateur et les mesures de performance.

À quelle fréquence exécuter les contrôles synthétiques ?

Toutes les minutes ou deux pour les endpoints critiques pour le chiffre d'affaires, toutes les cinq minutes pour la plupart des services, toutes les heures ou chaque jour pour les pages qui changent peu. Des intervalles courts détectent plus vite mais consomment plus d'exécutions.

Le synthetic monitoring remplace-t-il la supervision des utilisateurs réels ?

Non. Le synthetic monitoring vous dit que quelque chose est cassé, même sans visiteurs. Le RUM vous dit comment de vraies personnes vivent le site sur de vrais appareils. Utilisez les deux.

Puis-je utiliser le synthetic monitoring avant le lancement ?

Oui. Comme il n'a pas besoin de visiteurs, vous pouvez viser un environnement de préproduction et l'exécuter après chaque déploiement.

Pourquoi exécuter les contrôles depuis plusieurs lieux ?

Pour distinguer une vraie panne d'un problème de réseau local et repérer les incidents régionaux de DNS, de CDN ou de routage qu'un seul lieu manquerait.