Le monitoring synthétique teste votre site ou votre API avec des requêtes scriptées à intervalles réguliers, qu’il y ait des visiteurs ou non. Le Real User Monitoring (RUM) mesure ce que vivent les vrais visiteurs, grâce à un script dans leur navigateur, mais uniquement quand ils visitent le site. Les contrôles synthétiques vous disent que quelque chose est cassé, souvent avant que les clients ne s’en aperçoivent. Le RUM vous dit à quel point le site est rapide et fluide pour ceux qui l’utilisent, sur leurs appareils et leurs réseaux. Commencez par des contrôles synthétiques pour la disponibilité, et ajoutez le RUM quand la performance pour les vrais visiteurs devient une question à laquelle vous devez répondre.
Comment fonctionne le monitoring synthétique
Un service de monitoring joue le rôle du visiteur. Depuis un emplacement connu, selon un planning fixe, il envoie une requête ou exécute un script et évalue le résultat. Comme il fait toujours la même chose, les résultats sont comparables d’un contrôle à l’autre, et une panne à 03:00 est détectée à 03:00, sans qu’il faille du trafic. Le monitoring synthétique se décline sous plusieurs formes :
Contrôles de disponibilité : une requête vers une URL, un hôte ou un port, qui vérifie le code de statut, le temps de réponse et souvent le contenu. C’est la forme la plus simple ; voir ce qu’est la surveillance de disponibilité.
Contrôles d’API : une requête avec une méthode, des en-têtes et un corps, et des vérifications sur le JSON renvoyé.
Parcours en plusieurs étapes : un parcours comme la connexion ou le paiement, exécuté étape par étape, en simples requêtes HTTP ou dans un vrai navigateur qui exécute le JavaScript.
Tests de performance en laboratoire : un outil comme Lighthouse charge une page sur un appareil et un réseau simulés et lui attribue un score.
Comment fonctionne le Real User Monitoring
Le Real User Monitoring ajoute un script à vos pages. Dans le navigateur de chaque visiteur, il lit les mesures de temps que les navigateurs exposent via des API standard, comme Navigation Timing, et les envoie à un collecteur. En agrégeant les visites, vous obtenez des distributions : le temps de chargement des pages, leur réactivité aux clics, les pages qui génèrent des erreurs JavaScript, ventilés par pays, appareil et navigateur.
Comme les résultats sont des distributions, le RUM fournit des percentiles plutôt que des valeurs uniques. Les Core Web Vitals de Google sont mesurés au 75e percentile des chargements de page, avec ces seuils pour une bonne expérience :
Largest Contentful Paint (chargement) : 2,5 secondes ou moins.
Interaction to Next Paint (réactivité) : 200 millisecondes ou moins.
Cumulative Layout Shift (stabilité visuelle) : 0,1 ou moins.
Il existe aussi des données RUM que vous ne collectez pas vous-même. Le Chrome UX Report (CrUX) de Google publie des données terrain issues des utilisateurs de Chrome qui l’acceptent, par page et par site, dès que le trafic est suffisant. Ce sont les données que Google utilise pour les Core Web Vitals dans la recherche.
Côte à côte
Monitoring synthétiqueReal User MonitoringQui génère les donnéesUn service de monitoring, selon un planningVos visiteurs, quand ils visitent le siteNécessite du traficNonOuiNécessite un script dans vos pagesNonOuiDétecte une panneOui, au contrôle suivantIndirectement, quand les données s’arrêtentCouvreLes pages et parcours que vous scriptezChaque page visitéeAppareils et réseauxQuelques-uns, connusCeux de tous vos visiteursRésultatsRéussite ou échec, une mesure de temps par contrôleDistributions et percentilesIdéal pourDisponibilité, alertes, détection des régressions après un déploiementPerformance réelle, Core Web Vitals, erreurs dans le navigateur
Ce que chacun rate
Les angles morts du synthétique
Les parcours que vous n’avez pas scriptés. Si le parcours de paiement teste un seul produit, une page cassée dans une autre catégorie passe inaperçue.
L’endroit où se trouvent vos visiteurs. Un contrôle depuis une ville voit la route de cette ville vers votre serveur, pas celle d’un visiteur sur un réseau mobile à l’autre bout du monde.
Les vrais appareils. Un téléphone lent, une extension de navigateur ou une ancienne version de navigateur peut casser ou ralentir une page qui réussit tous les contrôles.
Les angles morts du RUM
Pas de visiteurs, pas de données. La nuit, sur une nouvelle page ou sur un site à faible trafic, le RUM n’a pas grand-chose à dire, voire rien.
Les pannes. Quand le site est hors ligne, le script ne se charge jamais : rien n’est remonté. Un trou dans un graphique passe facilement inaperçu et ne réveille personne.
Les visiteurs impossibles à mesurer. Les bloqueurs de publicité et les choix de consentement peuvent bloquer le script : les données ne décrivent que les visiteurs qui l’acceptent.
Le poids. Le script lui-même ajoute du travail à la page. Chargez-le de façon asynchrone et vérifiez sa taille.
Données de laboratoire et données terrain
La même distinction se retrouve dans les outils de performance, sous le nom de données de laboratoire et données terrain. Un score Lighthouse est une donnée de laboratoire : un chargement de page synthétique sur un téléphone et un réseau de milieu de gamme simulés. CrUX et votre propre RUM sont des données terrain : ce qu’ont mesuré de vraies visites. Les deux divergent souvent. Une page peut obtenir un mauvais score en laboratoire et réussir quand même les Core Web Vitals sur le terrain parce que la plupart des visiteurs ont des appareils rapides, ou l’inverse. Utilisez les données de laboratoire pour trouver et corriger les problèmes et pour comparer une version à la suivante, et les données terrain pour juger de ce que les visiteurs obtiennent réellement. Nos conseils pour un site plus rapide aident sur les deux plans, et l’article sur ce qu’est un bon temps de réponse couvre le côté serveur.
Par lequel commencer
Tous les sites : des contrôles de disponibilité synthétiques sur la page d’accueil et sur les pages qui rapportent de l’argent. Une panne coûte plus cher qu’une page lente, et seuls les contrôles synthétiques vous en alertent de façon fiable. La checklist de ce qu’il faut surveiller liste les URL qui méritent d’être couvertes.
Boutiques et produits SaaS : ajoutez des parcours en plusieurs étapes pour le paiement ou la connexion, afin de détecter un parcours cassé même quand chaque page répond 200.
Sites où le trafic de recherche compte : suivez les Core Web Vitals via CrUX et un test de laboratoire quotidien, pour repérer une version lente avant qu’elle ne se ressente dans le classement.
Audiences larges ou internationales, front-ends complexes : ajoutez le RUM pour voir la performance et les erreurs JavaScript par pays, appareil et page.
Comment ils se complètent
Imaginez une boutique qui déploie un nouveau tunnel de paiement le mardi après-midi. Le mercredi à 03:12, l’étape de paiement commence à dépasser le délai d’attente. Personne ne fait d’achats, donc le RUM ne montre rien d’inhabituel, mais le parcours de paiement synthétique échoue, un second contrôle le confirme et le développeur d’astreinte reçoit une alerte. Corrigé à 03:30. Le jeudi, le RUM montre que l’Interaction to Next Paint du nouveau tunnel a doublé pour les visiteurs sur Android, ce qu’aucun contrôle synthétique depuis un serveur rapide n’aurait remarqué. Un outil a détecté la panne, l’autre l’expérience lente. C’est la répartition habituelle des rôles.
Ce qu’Uptimecheck couvre, et ce qu’il ne couvre pas
Uptimecheck est un service de monitoring synthétique. Il n’ajoute pas de script RUM à vos pages : pour les mesures de temps et les erreurs JavaScript de vos propres visiteurs, utilisez un outil RUM dédié en complément. Ce qu’il fait :
Surveillance de disponibilité : des contrôles HTTP(S), ping et port jusqu’à chaque minute depuis Stockholm, Londres et New York, avec vérification de mots-clés, de JSON et d’en-têtes, et chaque échec confirmé depuis un second emplacement avant toute alerte. Les temps de réponse sont détaillés en DNS, connexion, TLS, serveur et téléchargement.
Surveillance de parcours : jusqu’à 10 étapes, comme ouvrir une page, se connecter, envoyer un formulaire ou appeler une API, avec des valeurs transmises d’une étape à l’autre. Les parcours en simples requêtes peuvent tourner chaque minute ; les parcours dans un vrai navigateur exécutent le JavaScript et les clics au plus toutes les 15 minutes, avec une capture d’écran de l’étape qui a échoué.
Surveillance de la vitesse des pages : un test Lighthouse quotidien sur mobile et sur ordinateur pour la page d’accueil et jusqu’à 4 autres pages, et, pour les pages et sites suffisamment visités, ce qu’ont vécu les vrais utilisateurs de Chrome sur 28 jours d’après le Chrome UX Report. Vous recevez une alerte quand le score d’une page passe sous votre seuil.
Pour configurer un parcours, consultez comment surveiller une connexion ou un paiement avec un parcours et comment vérifier la vitesse des pages. Les formules démarrent à 9 € par mois en facturation annuelle ou 12 € en facturation mensuelle, HT ; voir la page des tarifs.
Sachez que quelque chose est cassé avant que vos visiteurs ne vous le disent. Essayez Uptimecheck gratuitement pendant 14 jours, sans carte bancaire.