Qu'est-ce que le Synthetic Monitoring ? Définition, Types, RUM
Le synthetic monitoring exécute des tests scriptés depuis des emplacements globaux 24/7 — détecte les problèmes avant les utilisateurs réels.
Qu'est-ce que le synthetic monitoring ?
Le synthetic monitoring est une technique proactive de testing de performance et availability où des scripts pré-définis simulent les interactions utilisateur avec un site web, une API ou une application depuis des emplacements cloud ou agents contrôlés. Contrairement au Real User Monitoring (RUM), qui mesure les vrais utilisateurs dans la nature, le synthetic monitoring tourne sur une cadence planifiée (chaque minute, heure ou jour) indépendamment du trafic réel touchant le système. L'objectif est de détecter les régressions d'availability et performance avant les utilisateurs.
Un synthetic monitor typique envoie une requête HTTP, navigue un navigateur à travers un flow multi-step (login, browse, checkout) ou valide une réponse API, puis enregistre timing, status code et résultats d'assertions. Quand quelque chose échoue — endpoint down, response trop lente, contenu manquant — le monitor déclenche une alerte via Slack, PagerDuty, email ou webhook.
Comment le synthetic monitoring fonctionne
- Définissez un check. Une URL à frapper, un endpoint API à valider, ou un browser flow à parcourir. Le check inclut généralement des assertions : status code 200, response body contient certain texte, response time sous N ms.
- Planifiez le check. Tournez chaque minute (high-criticality), toutes les 5 minutes (typique), ou chaque heure (priorité plus basse).
- Exécutez depuis plusieurs emplacements. Les synthetic monitors cloud-based exécutent les checks depuis des agents dans plusieurs régions géographiques — typiquement au moins un en Amérique du Nord, Europe et Asie.
- Enregistrez les résultats. Chaque run produit des métriques (latence, status, body size), screenshots (pour browser checks) et waterfall traces.
- Alertez sur les échecs. Des seuils configurables déclenchent des notifications.
Types de synthetic monitoring
- Uptime monitoring. Le plus simple — frapper répétitivement une URL, confirmer le status 200.
- API monitoring. Envoyez une requête à un endpoint HTTP/REST/GraphQL avec headers auth optionnels et request body, assertez sur status, contenu du body et timing.
- Browser-based monitoring. Exécutez un vrai navigateur Chromium pour charger une page, mesurez les Core Web Vitals (LCP, CLS, TBT) et capturez filmstrip + données waterfall.
- Transaction (multi-step) monitoring. Un browser flow scripté parcourt un user journey critique — login, search, add to cart, checkout.
- Monitoring de certificat SSL/TLS. Vérifiez expiration du certificat, validité de la chain et grade SSL Labs.
- DNS monitoring. Résolvez un hostname depuis plusieurs resolvers.
Synthetic monitoring vs Real User Monitoring (RUM)
Les deux approches mesurent des choses différentes et se complètent :
| Aspect | Synthetic Monitoring | Real User Monitoring (RUM) |
|---|---|---|
| Source de données | Tests scriptés depuis agents contrôlés | Vrais utilisateurs via beacon JavaScript |
| Couverture | Ce que vous scriptez — prévisible | Ce que les utilisateurs font réellement — variable |
| Quand ça tourne | Planifié (24/7) | Quand un vrai utilisateur visite |
| Détecte problèmes avant utilisateurs | Oui | Non (après coup) |
| Capture variance real-world | Non (environnement contrôlé) | Oui (devices, réseaux, géographies) |
| Fonctionne sans trafic | Oui | Non (nécessite utilisateurs) |
| Testing pre-launch | Oui | Non (pas encore d'utilisateurs) |
| Diagnostic per-user | Non | Oui |
La plupart des stratégies de monitoring matures combinent les deux : synthetic pour "le système fonctionne-t-il comme conçu ?", RUM pour "qu'est-ce que les utilisateurs vivent réellement ?".
Métriques courantes suivies
- Availability / Uptime %. Pourcentage de checks réussis. Les SLAs sont typiquement exprimés comme cibles d'availability (99,9 %, 99,95 %, 99,99 %).
- Response time. Latence end-to-end, souvent décomposée par phase.
- Core Web Vitals. Pour browser checks : LCP, CLS, TBT. Facteurs de ranking Google.
- Taux d'erreur. Pourcentage de checks retournant status codes inattendus.
- Time-to-first-byte (TTFB). Signal de responsiveness server-side.
- Apdex score. Métrique standard de l'industrie.
Quand utiliser le synthetic monitoring
- Vous avez besoin de visibilité 24/7.
- Vous testez pre-launch ou services low-traffic. RUM nécessite du trafic. Synthetic fonctionne dès le premier jour.
- Vous avez besoin de reporting SLA.
- Vous voulez détecter les régressions tôt. Exécutez des synthetic checks contre staging après chaque deploy.
- Vous avez besoin de visibilité géographique.
- Vous avez besoin de mesures cohérentes.
Limitations
- Ne capture pas la variance real-world. Les synthetic checks tournent depuis des data centers sur réseaux rapides ; les vrais utilisateurs frappent depuis WiFi de café, 4G congestionnée et anciens navigateurs.
- Limité à ce que vous scriptez.
- Le coût scale avec fréquence de check × emplacements.
- Peut être bruyant sans bons seuils.
- Les browser checks consomment plus de ressources.
Synthetic monitoring avec LoadFocus
LoadFocus offre du synthetic monitoring à travers les trois types principaux de check :
- Page speed monitoring. Checks vrai navigateur Chromium avec audits Lighthouse complets, tracking Core Web Vitals et alerts de régression budget-based. Tournez depuis 25+ régions cloud sur des schedules dès chaque minute.
- API monitoring. Checks endpoints HTTP/REST avec validation assertion-based. Multi-step request chaining via scripts k6.
- Load testing. Au-delà du synthetic monitoring des conditions normal-traffic, LoadFocus exécute du trafic simulé à concurrency choisie pour tester la capacité.
La plateforme s'intègre avec Slack, PagerDuty, email et webhooks, et fournit CLI + GitHub Action pour CI/CD. L'analyse waterfall générée par IA explique pourquoi un check est lent.
FAQ : Synthetic monitoring
Comment le synthetic monitoring diffère-t-il de l'APM ?
L'APM est typiquement agent-based et observe l'intérieur de votre application — exécution de code, requêtes de base de données, timing de fonctions. Le synthetic monitoring observe depuis l'extérieur — ce qu'un utilisateur voit. APM et synthetic se complètent.
À quelle fréquence les synthetic checks devraient-ils tourner ?
Services critiques user-facing : chaque 1 minute. APIs internes et paths de priorité plus basse : toutes les 5-15 minutes. Background jobs : toutes les 30 minutes à 1 heure.
Depuis combien d'emplacements devrais-je monitorer ?
Minimum 3 (un par région majeure — Amériques, EMEA, APAC). Pour services globaux, 5-10 emplacements couvrent la plupart des problèmes régionaux.
Le synthetic monitoring devrait-il remplacer RUM ?
Non — ils se complètent. Utilisez synthetic pour monitoring proactif 24/7 SLA ; utilisez RUM pour comprendre l'expérience utilisateur réelle.
Quelle est la différence entre synthetic monitoring et load testing ?
Le synthetic monitoring exécute des checks single-user à intervalles. Le load testing simule beaucoup d'utilisateurs concurrents.
Le synthetic monitoring peut-il détecter des problèmes de sécurité ?
Limité. Pour security monitoring, des outils dédiés (Sucuri, Cloudflare Security, SIEM focalisé sécurité) sont meilleur fit.
Essayez LoadFocus synthetic monitoring gratuitement
Si vous évaluez des outils de synthetic monitoring, LoadFocus offre page speed monitoring, API monitoring et load testing sur une plateforme avec un tier gratuit sans carte de crédit. Inscrivez-vous sur loadfocus.com/signup pour configurer votre premier synthetic check en moins de 5 minutes — multi-région, avec assertions, alerts et analyse générée par IA inclus dans tous les plans.
Outils LoadFocus connexes
Mettez ce concept en pratique avec LoadFocus — la plateforme même qui propulse tout ce que vous venez de lire.