RUM ou monitoring synthétique : lequel vous faut-il ?

Publié le

14 juil. 2026

Temps de lecture

8 min de lecture

La réponse pratique n'est pas de choisir l'un ou l'autre. Utilisez le Real User Monitoring (RUM) pour comprendre l'expérience en production sur les appareils, réseaux, localisations et interactions réels. Utilisez le monitoring synthétique pour tester en continu des parcours connus dans des conditions contrôlées. Le RUM est la source de vérité pour la distribution de l'expérience utilisateur ; les tests synthétiques constituent la couche d'alerte précoce et de diagnostic.

Cette distinction est importante pour les Core Web Vitals. Google définit de bonnes performances à partir du 75e percentile des pages vues sur le terrain : un LCP inférieur ou égal à 2,5 secondes, un INP inférieur ou égal à 200 millisecondes et un CLS inférieur ou égal à 0,1. Une exécution synthétique peut reproduire un chargement contrôlé, mais elle ne peut pas représenter chaque appareil, réseau, état du cache, parcours de personnalisation ou interaction. Lighthouse ne peut pas mesurer l'INP sur une page sans véritable saisie utilisateur ; le Total Blocking Time est à la place un proxy de laboratoire utile pour diagnostiquer la réactivité.

Ce que chaque méthode permet de répondre

RUM : la distribution en production

Le RUM collecte des mesures côté navigateur lors de visites réelles. Il peut segmenter la performance par modèle de page, version, catégorie d'appareil, connexion, pays, langue, navigateur, état du cache et parcours utilisateur. Il peut également relier la performance aux événements métier lorsque les exigences de confidentialité et de consentement sont correctement prises en compte.

Le RUM est le plus pertinent lorsque la question est : Quels utilisateurs sont concernés, dans quelle mesure et après quel changement ? Il révèle un réseau mobile lent qu'un test sur ordinateur ne verra jamais, une interaction qui intervient après une tâche longue ou un décalage de mise en page causé par du contenu personnalisé. Il peut aussi montrer qu'une régression en laboratoire n'affecte pas la majorité des visites réelles.

Le RUM a ses limites. Il n'observe que les utilisateurs qui chargent suffisamment la page pour rapporter des données ; il peut donc sous-estimer les pannes complètes et les navigations échouées. Il s'agit d'une distribution, pas d'un score unique. Les moyennes masquent la forme de cette distribution : utilisez donc des percentiles et des segments pertinents. CrUX est utile pour une vue globale des données de terrain, mais un RUM propriétaire fournit un contexte plus détaillé par page vue et par version.

Monitoring synthétique : la sonde contrôlée

Les contrôles synthétiques exécutent des requêtes scriptées ou des parcours navigateur depuis des emplacements connus selon un calendrier défini. Ils peuvent tester la résolution DNS, TLS, la connexion TCP, le temps jusqu'au premier octet, les codes d'état, les redirections, l'état du cache, le chargement des ressources et les interactions clés. Comme l'appareil, le profil réseau, l'URL et les étapes sont contrôlés, une exécution en échec peut être comparée plus fiablement aux exécutions précédentes.

Le monitoring synthétique est le plus pertinent lorsque la question est : Ce point de terminaison ou ce parcours connu est-il disponible et dans sa plage attendue en ce moment ? Il peut détecter un problème de certificat, une panne régionale du CDN, une boucle de redirection, un délai d'attente de l'origine ou une étape de paiement défaillante avant que suffisamment d'utilisateurs ne génèrent un échantillon RUM statistiquement exploitable.

Le monitoring synthétique a aussi ses limites. Un emplacement de test ne représente pas le monde. Un navigateur scripté ne se comporte pas comme tous les utilisateurs, et un test réussi ne prouve pas que les appareils modestes ont un bon INP ni que chaque expérience personnalisée est stable. Considérez les résultats des tests comme des preuves relatives au scénario testé, et non comme un score utilisateur universel.

Une séquence qui fonctionne en pratique

1. Définissez le service et ses parcours

Listez les pages et les actions importantes : page d'entrée, recherche, fiche produit, connexion, panier, paiement, appels API et tout contenu critique pour les robots d'exploration. Attribuez à chacun un responsable métier et un responsable technique. Ne commencez pas par un tableau de bord avec toutes les métriques disponibles ; commencez par les décisions que l'équipe doit prendre lorsqu'un signal évolue.

2. Instrumentez le RUM sans devenir le problème

Mesurez le LCP, l'INP et le CLS avec une bibliothèque navigateur prête pour la production ou des API standard équivalentes. Chargez le code de mesure de façon asynchrone et différez les rapports non critiques. Utilisez un mécanisme de balise à faible surcharge, échantillonnez de manière responsable et évitez de collecter des données dont personne ne se servira. Ajoutez une version de déploiement, un type de page, une catégorie d'appareil, une région et un état de consentement afin de comparer les régressions équitablement.

Rapportez les distributions sur mobile et ordinateur, ainsi que sur les segments importants pour l'activité. Incluez le pourcentage de visites dans les catégories bon, à améliorer et mauvais, et pas uniquement une moyenne globale. Marquez les visites qui échouent avant que la page puisse rapporter des données afin que le monitoring de disponibilité couvre cet angle mort.

3. Créez une petite matrice synthétique

Choisissez quelques régions représentatives et un ou deux profils d'appareils réalistes. Exécutez fréquemment un contrôle de disponibilité léger et moins fréquemment un parcours navigateur. Testez les états de cache froid et chaud lorsque la distinction est importante. Vérifiez le statut, l'URL finale, un texte ou des données importantes, le temps de réponse et les échecs de ressources clés. Pour un site international, incluez chaque langue principale et vérifiez que le corps, la canonique et les en-têtes de cache correspondent à l'URL demandée.

4. Croisez les signaux pendant un incident

Lorsqu'un contrôle synthétique échoue, inspectez les journaux de périphérie et d'origine, le DNS, TLS, le code d'état, l'état du cache et les déploiements récents. Lorsque le RUM se dégrade, segmentez par région, appareil, version, route et chemin CDN avant de modifier la configuration. Une régression RUM régionale accompagnée de contrôles synthétiques sains ailleurs indique souvent le routage, le peering ou la localité du cache plutôt qu'un défaut généralisé de l'application.

Pour la diffusion CDN, comparez le temps de périphérie avec le temps navigateur. Pour le Multi CDN, conservez les dimensions de fournisseur, route et basculement dans la télémétrie. Le SEO/GEO technique est pertinent lorsque des réponses lentes ou des erreurs affectent l'accès des robots d'exploration comme celui des utilisateurs.

5. Définissez des alertes avec une action et un retour arrière

Une alerte doit indiquer ce qui a changé et ce que l'intervenant peut faire. Par exemple : une erreur synthétique 5xx dans une région, une hausse durable des LCP médiocres pour une version ou un échec d'interaction au paiement. Définissez la sévérité, le responsable, les éléments de preuve à collecter et l'action réversible : désactiver une version, restaurer une règle de cache, basculer le trafic vers un CDN sain ou annuler une politique de routage.

Versionnez chaque déploiement et chaque modification de configuration. Google note que la mise en cache à la couche HTTP, service worker ou CDN peut rendre les comparaisons par date trompeuses. Une dimension de version permet de comparer la population réellement exposée à chaque changement et de décider s'il faut poursuivre, interrompre ou annuler.

Erreurs courantes

• Considérer un score Lighthouse unique comme un verdict sur la performance de terrain.
• Moyenner les valeurs RUM jusqu'à faire disparaître les utilisateurs lents dans la moyenne.
• Exécuter des contrôles synthétiques depuis une seule ville et qualifier le site de mondial.
• Mesurer uniquement la page d'accueil alors que le modèle le plus lent est le paiement ou la recherche.
• Charger le RUM de manière synchrone et dégrader le LCP qu'il doit mesurer.
• Alerter sur chaque fluctuation sans taille d'échantillon, percentiles ni plan de réponse.
• Ignorer les chargements de page échoués parce qu'aucune balise navigateur n'a été envoyée.
• Modifier le routage CDN avant de séparer les temps applicatifs, d'origine, de périphérie et client.

Utilisez le guide des budgets de performance web pour transformer les signaux récurrents en limites de version, et le guide de migration CDN lorsqu'un changement de fournisseur exige une comparaison contrôlée. Si les signaux divergent, contactez Optimi en indiquant l'URL, la période, les régions, la version et les données de réponse brutes.

There are only two hard things in Computer Science: cache invalidation and naming things.