Monitoring de l'expérience réelle, OpenTelemetry-natif et souverain UE. Découvrez l'outil, puis connectez-vous pour accéder à votre console.
Le Real User Monitoring mesure la performance et les erreurs réellement vécues par vos utilisateurs en production — pas une sonde de laboratoire. On capte ce que vivent les vrais visiteurs (vitesse d'affichage, réactivité, bugs JavaScript, parcours), parce que c'est cette expérience-là qui pèse sur la conversion et la satisfaction. Un site rapide convertit mieux : le RUM le prouve avec des chiffres terrain.
Tout repose sur des standards ouverts (OpenTelemetry) : pas de format propriétaire, pas d'enfermement fournisseur, et une compatibilité immédiate avec l'écosystème observabilité existant.
Un SDK léger (~5 ko) lit les Core Web Vitals, les erreurs JS et les interactions chez le vrai visiteur, via les API standard du navigateur (PerformanceObserver).
Les mesures partent en OpenTelemetry (OTLP/HTTP JSON) — un standard ouvert, pas un format maison : aucun enfermement fournisseur.
Une fonction serverless (Deno) ou un service Node aplatit le flux OTLP et l'écrit en base, avec garde-fous de charge et idempotence.
PostgreSQL pour le POC ; chemin ClickHouse prouvé pour le grand compte (mêmes p75, ×15 plus compact). Rétention RGPD (TTL 30 j).
Cette interface Next.js 15 / React 19 calcule les agrégats (p75, score de santé, anomalies) et les rend lisibles — du commercial à l'ingénieur.
De la création de l'app au premier graphe : ce qu'il faut faire, concrètement, pour brancher un nouveau site et le rendre monitorable.
Administration → Clients → « Ajouter un client ». On renseigne le nom, un identifiant (app_id : minuscules, chiffres et tirets — ex. plateforme-client) et les domaines du site (les origines autorisées pour le CORS).
À la validation, l'outil génère la clé d'API (affichée une seule fois !) et autorise le domaine — pris en compte en ≤ 60 s, sans redéploiement.
Une note unique (vitals, erreurs, stabilité, anomalies) pour piloter en un coup d'œil.
Ouvrir →LCP, INP, CLS, FCP, TTFB au 75ᵉ percentile — la qualité vécue par 3 visiteurs sur 4.
Ouvrir →Détection automatique des dérapages vs comportement habituel, sans seuil à régler.
Ouvrir →La tenue jour par jour, heure par heure — pour lire la performance dans la durée.
Ouvrir →Les erreurs JS dédupliquées par cause (fingerprint), triées par impact réel.
Ouvrir →Le parcours réel d'un visiteur (pages, vitals, erreurs), sans donnée identifiante. Rejeu visuel (rrweb) à venir, activé derrière consentement.
Ouvrir →Chaque appel API relié à son exécution serveur (W3C traceparent) : réseau, serveur ou code ?
Ouvrir →L'écart entre le monitoring synthétique et les vrais utilisateurs — le terrain prime sur le labo.
Ouvrir →Appels LLM (tokens, coût, latence, erreurs) + gouvernance des données : ce qui expose de la PII, pseudonymisé ou non.
Ouvrir →Le ressenti (feedbacks + CSAT) marié à la perf mesurée : un score d'expérience, le pont chiffres ↔ satisfaction.
Ouvrir →Le graphe pages → API → backend, coloré par santé et pondéré par le volume : cartographie, flux et anticipation.
Ouvrir →Projette la dérive des indicateurs sur 14 j et l'ETA au franchissement de seuil : du réactif au prédictif.
Ouvrir →