Surveillance des Utilisateurs Réels (RUM)

La surveillance des utilisateurs réels (RUM, pour Real User Monitoring) est une manière de mesurer le comportement d'un site web ou d'une application pour les personnes qui les utilisent vraiment. Un petit fragment de code dans la page, ou un SDK dans l'application mobile, enregistre les temps et les erreurs de chaque visite réelle et les envoie à un service de collecte pour analyse.

Le mot « réels » est essentiel. Un test en laboratoire montre comment une page se charge sur une machine rapide, dans un seul centre de données. Le RUM montre comment elle se charge sur un téléphone de trois ans, dans un train, avec un réseau faible et une extension de navigateur qui injecte ses propres scripts. Ces conditions sont trop variées pour être reproduites : la seule façon de les connaître est de les mesurer là où elles se produisent.

Le RUM est passif : il ne génère aucun trafic de test, il observe. C'est l'une des deux moitiés de la mesure de l'expérience numérique, l'autre étant la surveillance synthétique, et l'une des lectures du terme plus large de surveillance des utilisateurs finaux, qui couvre aussi le suivi d'activité. Il relève de la pratique générale de la surveillance. Malgré le nom, l'« utilisateur » est ici une session de visiteur, pas un salarié évalué.

Quel que soit l'éditeur, un dispositif RUM suit le même chemin, de l'appareil du visiteur jusqu'au tableau de bord.

1. 1

   Instrumenter

   Ajoutez un script à la page ou un SDK à l'application. Il enregistre des observateurs sur les données de performance que le navigateur expose déjà.

2. 2

   Collecter

   Au fil de la visite, le script lit les temps de navigation, de ressources, d'affichage et d'interactions, et note les erreurs JavaScript et les requêtes échouées.

3. 3

   Enrichir

   Chaque enregistrement reçoit un contexte : la page ou l'écran, le navigateur, la catégorie d'appareil, le type de connexion, la localisation approximative et un identifiant de session.

4. 4

   Envoyer

   Le script envoie les données par petits lots sous forme de beacon, de préférence quand la page est masquée ou fermée, pour ne pas ralentir la visite elle-même.

5. 5

   Agréger

   Le serveur regroupe les enregistrements par page, version, pays ou appareil et affiche des distributions, des tendances et des alertes.

Le RUM enregistre de nombreux signaux, mais trois sont devenus la norme dans le travail web. Ce sont les Core Web Vitals, et Google publie des valeurs cibles considérées comme bonnes lorsqu'elles sont atteintes pour au moins 75 % des visites. En plus, le RUM suit généralement le temps de réponse du serveur (TTFB), les erreurs JavaScript, la durée des appels d'API effectués par la page et, dans les applications mobiles, les plantages et le temps de démarrage.

Les données RUM forment une distribution, pas un chiffre unique. Une moyenne cache les visiteurs qui souffrent le plus, c'est pourquoi les équipes lisent des percentiles : la médiane montre la visite typique, tandis que le 75e ou le 95e percentile montre la longue traîne lente. Comparez le même percentile d'une version à l'autre, sinon un changement dans la composition des visiteurs ressemblera à un changement du site.

La vraie valeur vient du découpage. Segmentez les données par catégorie d'appareil, navigateur, type de connexion, modèle de page et géolocalisation, et le problème se nomme souvent de lui-même : un script lourd qui ne pénalise que les téléphones d'entrée de gamme, une région éloignée du serveur le plus proche, une version qui a fait grimper le taux d'erreurs sur une seule version de navigateur. La méthode a aussi des angles morts. Elle ne voit que les visites où le script s'est chargé, et les bloqueurs et les choix de consentement en retirent une partie.

Le RUM est rarement utilisé seul. La surveillance synthétique exécute des vérifications scriptées depuis des lieux fixes selon un calendrier, et la surveillance des performances applicatives (APM) retrace ce qui se passe à l'intérieur des serveurs. Chacune répond à une question différente :

La plupart des projets RUM décevants échouent de façons bien connues :

• Lire des moyennes au lieu de percentiles, ce qui rend invisibles les visiteurs les plus lents
• Comparer des périodes dont la composition en appareils, pays ou sources de trafic diffère, puis attribuer le résultat à la dernière version
• Collecter des URL complètes avec paramètres, valeurs de formulaires ou identifiants d'utilisateurs dont la question n'avait jamais besoin, un problème que l'anonymisation à la source supprimerait
• Échantillonner si fortement que les pages rares et les erreurs rares disparaissent
• Ne regarder que la vitesse sans jamais la relier à des résultats comme le taux de rebond, la conversion ou les demandes au support

Les données RUM servent plusieurs équipes, et chacune veut une coupe différente. Il faut aussi dire à quoi le RUM ne sert pas : ce n'est pas un outil pour observer des salariés à titre individuel, ce rôle revient à la surveillance de l'activité des utilisateurs.

Le RUM porte sur des données de performance, mais elles peuvent tout de même être des données personnelles. Les adresses IP, les caractéristiques de l'appareil, les identifiants de session et les URL peuvent désigner une personne, si bien que le droit de la protection des données (le RGPD dans l'UE) peut s'appliquer, et que les règles ePrivacy sur le stockage ou la lecture d'informations sur l'appareil peuvent exiger un consentement. Une configuration respectueuse de la vie privée évite les identifiants persistants, raccourcit les adresses IP, supprime les paramètres des URL et respecte le choix fait dans le bandeau de consentement. Validez les détails pour vos marchés avec un conseil juridique.

Un bon départ reste modeste. Choisissez les trois ou quatre pages qui rapportent le plus, mesurez-y les Core Web Vitals, réglez une alerte sur le 75e percentile et revoyez-la après chaque version. Si votre question porte sur ce que font les salariés plutôt que sur la performance d'un site, la bonne catégorie est la surveillance de l'activité des employés, qui s'appuie sur d'autres données et d'autres garde-fous.