Votre moniteur de disponibilité affiche 100%. Vos serveurs répondent en 180 ms. Et les commandes ont diminué de 30 % depuis mardi matin.
La surveillance de l’expérience numérique (DEM) existe pour cette situation. Les métriques côté serveur confirment que votre infrastructure a répondu. Elles ne disent rien sur le fait qu’un acheteur à Francfort puisse réellement finaliser son paiement sur un Android milieu de gamme avec un script de paiement lent devant le bouton de paiement.
La plupart des guides sur ce sujet définissent la DEM pour les équipes informatiques surveillant les ordinateurs portables des employés et les tunnels VPN. Celui-ci couvre l’autre version : surveiller les parcours côté client qui génèrent des revenus. Ce que la DEM mesure, les zones aveugles de chaque source de données, comment la configurer sur une vraie boutique, et quelle vérification Dotcom-Monitor détecte chaque erreur.
Ce que contient ce guide
- Qu’est-ce que la surveillance de l’expérience numérique ?
- Pourquoi vos tableaux de bord deviennent verts alors que la caisse est en panne
- Surveillance synthétique vs. RUM vs. analyse du chemin réseau
- Ce qu’il faut mesurer sur un parcours générant des revenus
- Quatre échecs que votre contrôle de disponibilité manquera
- Comment configurer la surveillance de l’expérience numérique
- Comment choisir un outil de surveillance de l’expérience numérique
- Comment Dotcom-Monitor gère la surveillance de l’expérience numérique
- FAQ sur la surveillance de l’expérience numérique
- En résumé
Qu’est-ce que la surveillance de l’expérience numérique ?
La surveillance de l’expérience numérique est la pratique de mesurer comment les utilisateurs vivent votre site ou application de bout en bout, à travers le réseau, le navigateur et l’appareil qu’ils utilisent pour vous atteindre. Au lieu de demander « le serveur a-t-il répondu », elle s’interroge « quelqu’un a-t-il pu accomplir ce pour quoi il est venu, et combien de temps cela a-t-il pris ». Cette mesure peut provenir de sessions réelles, de parcours scriptés lancés selon un calendrier, ou des deux.
La portée est plus large que la disponibilité. Une configuration DEM surveille le rendu des pages, les transactions en plusieurs étapes comme la recherche et le paiement, les API derrière ces étapes, les scripts tiers, et comment tout cela change selon la région, le navigateur et la vitesse de connexion. Vous verrez la même pratique vendue sous les noms de surveillance de l’expérience utilisateur finale, surveillance de l’expérience applicative ou gestion de l’expérience numérique. Les étiquettes diffèrent ; ce qui est mesuré en général, pas.
Les deux types de DEM (et pourquoi ils se confondent)
En recherchant ce terme, la première page penche fortement vers les fournisseurs réseau et sécurité : Palo Alto Networks, Fortinet, Cloudflare, ThousandEyes, Tanium. La plupart de ces pages décrivent un DEM côté employé, surveillant la santé des terminaux, les tunnels SASE et le chemin entre le portable d’un télétravailleur et Microsoft 365. Certains couvrent aussi le trafic client, mais les définitions en haut des résultats penchent vers la main-d’œuvre.
C’est une vraie catégorie répondant à un vrai problème. Ce n’est simplement pas celui d’une équipe e-commerce ou des opérations numériques.
La version côté client regarde vers l’extérieur. Vos utilisateurs sont des inconnus sur des réseaux que vous ne contrôlez pas, utilisant des appareils que vous n’avez pas fournis, et partent sans déposer de ticket. Personne ne signale un champ de code promo cassé. Ils vont chez un concurrent.
Le DEM employé répond à « pourquoi l’appel Zoom de Sarah est-il haché ». Le DEM client répond à « pourquoi les validations de panier ont chuté de 18 % au Brésil la nuit dernière ». Même acronyme, outils différents, propriétaires différents.
Le reste de ce guide concerne le deuxième.
Pourquoi vos tableaux de bord deviennent verts alors que la caisse est en panne
Trois configurations courantes échouent toutes dans la même direction, et échouent silencieusement.
Un ping de disponibilité vérifie la mauvaise chose. Une vérification HTTP sur votre page d’accueil confirme qu’une URL a renvoyé un 200. Le paiement peut renvoyer un 200 avec un message « Nous n’avons pas pu traiter votre paiement » affiché dans la page. Le code d’état ne dit rien sur le contenu.
Les métriques côté serveur s’arrêtent à votre périphérie. Le temps de réponse de l’application, le CPU, et les taux d’erreur décrivent votre infrastructure. Ils n’incluent pas la résolution DNS, les négociations TLS, le comportement du CDN, l’exécution des balises tierces, ni les 2,8 secondes où un widget de chat bloque le thread principal sur mobile.
La surveillance des vrais utilisateurs a un problème de survivance. La surveillance des vrais utilisateurs collecte des données d’un beacon JavaScript dans la page. Ce qui signifie qu’elle ne rapporte que les sessions où la page s’est chargée et le beacon a été déclenché. Les utilisateurs rencontrant un échec DNS, un 403 CDN, ou une erreur TLS ne chargent jamais le beacon, donc ne rapportent rien. Les plus grosses pannes produisent le moins de données RUM, et le trafic qui disparaît silencieusement ressemble à une journée de vente calme.
La vitesse de détection aggrave ces trois cas. Beaucoup de pannes réelles sont courtes, et les pannes courtes sont celles que personne ne remarque à force de regarder un tableau de bord. Si vos contrôles s’exécutent toutes les cinq minutes, une panne de quatre minutes peut commencer et se terminer entre deux contrôles et ne laisser aucune trace sauf les commandes que vous n’avez pas eues.
Combler ces trois lacunes demande trois éléments : contrôler depuis l’extérieur de votre propre infrastructure, rendre dans un vrai navigateur, et juger le résultat sur le contenu de la page plutôt que sur les codes d’état. C’est ce que fait la surveillance synthétique, et c’est ce que configure le reste de ce guide.
Surveillance Synthétique vs. RUM vs. Analyse du Chemin Réseau
Les analystes divisent généralement la DEM en trois entrées. Elles se chevauchent, et chacune a des angles morts où les autres voient.
| Source | Ce qu’elle mesure | Ce qu’elle détecte en premier | Angle mort |
|---|---|---|---|
| Surveillance synthétique | Parcours scriptés exécutés selon un calendrier depuis des emplacements fixes, dans un vrai navigateur | Étapes cassées, pannes régionales, ralentissements tiers, certificats expirés, pannes hors pointe | Test uniquement des chemins scriptés, avec les appareils et emplacements choisis |
| Surveillance des vrais utilisateurs | Données de terrain de sessions réelles : Core Web Vitals, composition des appareils, composition des navigateurs | Problèmes appareils et navigateurs rares, distribution réelle du trafic | Biais de survivance : nécessite du trafic et une page chargée. Silence pendant les grosses pannes et sur les pages à faible volume |
| Analyse du chemin réseau | Routage d’étape en étape, latence et perte de paquets entre points d’observation et service | Changements de routage ISP, problèmes de peering, problèmes BGP, latence régionale | Ne dit rien sur le fonctionnement de la logique applicative |
La surveillance synthétique et la RUM sont la paire que la plupart des équipes utilisent réellement. La synthétique fournit un signal constant qui ne dépend pas qu’une personne soit réveillée et en train d’acheter. La RUM vous décrit l’audience réelle. Utilisez la synthétique pour détecter et alerter, la RUM pour prioriser ce qu’il faut réparer.
Dotcom-Monitor couvre la première et la troisième ligne. La surveillance des applications web exécute les parcours scriptés dans un navigateur, tandis que les contrôles Infrastructure Internet gèrent DNS, TLS et les couches réseau sous-jacentes. Il ne collecte pas de données RUM, donc si vous voulez de l’analyse session par session, utilisez un outil RUM en parallèle.
La synthétique a une limite importante : elle ne connaît que les parcours que vous avez scriptés. Si personne n’a jamais scripté le paiement invité, ce dernier peut rester cassé pendant une semaine.
Ce qu’il faut mesurer sur un parcours générant des revenus
Commencez par le parcours, pas par la liste des métriques. Pour la plupart des sites e-commerce et SaaS, quatre parcours portent presque tout le risque : recherche, ajout au panier, paiement, et connexion.
Pour chacun, suivez :
- Succès à chaque étape. Chaque étape s’est-elle terminée et la page contenait-elle le texte attendu ? Un numéro de confirmation est un meilleur signal qu’un code d’état. Dans EveryStep, c’est une assertion de contenu attachée à chaque étape, qui peut vérifier du texte, des éléments, le statut HTTP, les en-têtes de réponse ou une charge JSON.
- Durée par étape. Le temps total masque le problème. Vous voulez voir « appliquer code promo » passer de 400 ms à 9 secondes pendant que tout le reste reste stable. Les Script Time Watchers d’EveryStep définissent un seuil par étape, pour qu’une étape échoue seule au lieu de disparaître dans un parcours qui passe encore.
- Core Web Vitals. Largest Contentful Paint, Interaction to Next Paint et Cumulative Layout Shift sur les pages qui convertissent, pas seulement la page d’accueil. La surveillance des pages web rapporte ces métriques par page avec la chronologie des éléments.
- Temps jusqu’au premier octet. Sépare le délai de première réponse, qui inclut DNS, TLS, redirections, comportement CDN et latence d’origine, du travail de rendu qui suit. Une page lente avec un TTFB rapide est un problème front-end.
- Timing des éléments tiers. Fournisseurs de paiement, gestionnaires de balises, widgets de chat, plateformes d’avis, pixels publicitaires. La surveillance du contenu tiers importe car ce sont des actifs impossibles à patcher, seulement à contourner. Le graphique en cascade liste chaque requête tierce comme une ligne distincte pour voir quel fournisseur a ajouté 900 ms ce mois. Surveillez aussi les domaines tiers eux-mêmes : une passerelle de paiement avec certificat expiré bloque le paiement autant que votre propre panne.
- Temps de réponse et exactitude de l’API. Inventaire, tarification, taxes, expédition et paiement se trouvent derrière chaque étape de l’entonnoir. Les contrôles Web Services interrogent directement ces points et valident la charge, pour détecter un mauvais payload avant que la page ne rende incorrectement.
- État des certificats et DNS. Un certificat expiré sur un sous-domaine de paiement bloque complètement la caisse, et c’est entièrement évitable avec la surveillance SSL et la surveillance DNS dans les contrôles navigateur.
- Variation géographique. La même page depuis Chicago, Londres et Singapour. Une divergence entre emplacements indique généralement un problème CDN ou DNS plutôt que l’application, c’est pourquoi Dotcom-Monitor exécute le même script depuis 30+ points mondiaux au lieu d’un seul.
Quatre échecs que votre contrôle de disponibilité manquera
Chacun laisse un tableau de bord de disponibilité vert derrière lui.
1. La page erreur 200 OK
Un processeur de carte change un contrat API. Votre paiement intercepte l’exception, affiche un message convivial « Quelque chose s’est mal passé, veuillez réessayer » et renvoie HTTP 200. Tous les contrôles de disponibilité sur Internet disent que le site va bien. Les commandes s’arrêtent.
La solution est une assertion de contenu : le parcours scripté doit trouver le numéro de confirmation, sinon l’étape échoue.
Ce qui le détecte : un contrôle Web Applications (UserView) avec une assertion sur l’étape de confirmation. EveryStep valide le texte rendu, donc « Quelque chose s’est mal passé » fait échouer même si le serveur a renvoyé 200.
2. Un script tiers qui ne pénalise que le mobile
Une équipe marketing ajoute une balise de personnalisation. Le desktop à peine impacté. Sur une connexion mobile limitée, cela ajoute trois secondes avant que le bouton de paiement ne soit interactif, donc la conversion mobile chute pendant que le desktop semble normal. Personne ne fait le lien pendant une semaine, car le déploiement vient d’un gestionnaire de balises et non d’une release.
Exécuter le paiement sur desktop et profil mobile limité montre la différence le jour même. C’est pourquoi la surveillance navigateur pour l’optimisation de conversion revient souvent dans les analyses post-mortem des tunnels.
Ce qui le détecte : le même script EveryStep rejoué sur plus de 40 navigateurs mobiles et appareils ainsi que le desktop. Comparez les chronos par étape entre eux pour voir la balise comme une étape lente unique, pas comme un vague « le site est lent sur mobile ».
3. Une panne régionale CDN ou DNS
Une modification de configuration CDN brise un point de présence. Les clients à São Paulo reçoivent un 403 du bord et ne chargent jamais votre JavaScript. Vos données RUM ne baissent pas, elles cessent juste de recevoir des sessions brésiliennes, ce qui ressemble à un jour de trafic faible.
Un point de contrôle à São Paulo échoue dès le premier test. C’est l’argument en faveur d’un réseau de surveillance mondial plutôt que des contrôles depuis une seule région cloud.
Ce qui le détecte : exécution du parcours depuis 30+ emplacements, avec enregistrement vidéo synchronisé au graphique en cascade en cas d’échec. Vous obtenez la page 403 vue par le client brésilien et la requête qui la produit, au lieu d’un ticket support trois jours plus tard.
4. Une API qui se dégrade au lieu d’échouer
Votre service de tarif d’expédition commence à répondre en 11 secondes au lieu de 300 ms. Il ne renvoie jamais d’erreur, donc les alertes de taux d’erreur restent silencieuses. Les clients atteignent l’étape d’expédition, regardent un spinner et abandonnent.
Ce qui le détecte : un contrôle Web Services (WebView) sur le point final de tarif d’expédition avec seuil de temps de réponse et assertion sur le JSON retourné. Il se déclenche sur l’API elle-même plutôt que d’attendre un timeout en aval dans le parcours navigateur.
Comment configurer la surveillance de l’expérience numérique
Cet ordre fonctionne que vous partiez de rien ou que vous approfondissiez des contrôles de disponibilité existants.
Étape 1 : Cartographiez les parcours qui génèrent de l’argent. Sortez votre rapport entonnoir et listez les trois à cinq parcours que les clients empruntent réellement : recherche, ajout au panier, paiement invité, paiement compte, connexion. Notez la condition exacte de succès pour chacun.
Étape 2 : Enregistrez chaque parcours comme une transaction scriptée. Parcourez le chemin une fois dans EveryStep Web Recorder qui capture les clics, remplissages, navigation et attentes, y compris menus déroulants, modales, contenus AJAX et iframes. Pas besoin d’écrire des sélecteurs. Gérez les parties délicates délibérément : bannières de cookies, IDs dynamiques, mots de passe à usage unique, et méthode de paiement test qui ne facturera personne. Donnez au script son propre compte test et un SKU compatible inventaire pour que la surveillance ne crée jamais de vraies commandes. C’est à cela que sert la surveillance des transactions web.
Étape 3 : Ajoutez une assertion à chaque étape. Chaque étape vérifie un texte ou un élément visible uniquement en cas de succès : « Commande confirmée », un numéro de confirmation, un sous-total panier correspondant au prix article. EveryStep vérifie aussi le statut HTTP, les en-têtes et la charge JSON, donc une étape peut échouer sur une mauvaise réponse API avant même que la page ne rende mal. Sans assertions, vous êtes de retour à la vérification des codes d’état.
Étape 4 : Choisissez emplacements et appareils correspondant à votre trafic. Prenez vos top régions dans les analytics et surveillez depuis celles-ci, pas depuis l’endroit où vivent vos serveurs. Dotcom-Monitor vous propose 30+ emplacements et 40+ navigateurs et appareils mobiles : choisissez trois ou quatre qui correspondent à votre audience réelle et ajoutez au moins un profil mobile limité. La fréquence et lieux de contrôle doivent refléter vos clients réels.
Étape 5 : Définissez la fréquence par impact sur le revenu. Le paiement mérite un intervalle plus serré qu’une page carrières. Les scripts complets coûtent plus cher que les contrôles pages simples, donc investissez où sont les commandes.
Étape 6 : Surveillez les services sous-jacents. Ajoutez des contrôles pour les API dont dépend votre tunnel, plus DNS, certificats TLS et toute API partenaire dans le parcours paiement. La surveillance API avec assertions détecte la dégradation avant que le navigateur la montre en aval.
Étape 7 : Orientez les alertes pour qu’une personne agisse. Confirmez une panne depuis un second emplacement avant d’alerter, pour éliminer les fausses alertes liées à du bruit réseau local. Utilisez un second site dans la même région. Tester depuis un nœud sur un autre continent supprime les pannes régionales que vous voulez capturer. Les règles d’alerte de Dotcom-Monitor gèrent seuils et confirmation, et poussent naturellement vers PagerDuty, Slack et Teams pour que les pannes paiement atteignent ceux qui peuvent rollback un déploiement.
Étape 8 : Examinez régulièrement les cascades. Chaque semaine, ouvrez le graphique en cascade de votre parcours le plus lent et regardez les changements. Les ressources tierces s’infiltrent graduellement sans prévenir. Lors d’un échec, la cascade est accompagnée d’une vidéo de la session, qui répond souvent en dix secondes à « que voyait réellement le client ». Lire les graphiques en cascade transforme un chiffre lent en une requête précise de correction, et les tableaux de bord publics et rapports par email mettent ces chiffres devant ceux qui demandent des explications sur la conversion.
Comment choisir un outil de surveillance de l’expérience numérique
La plupart des fournisseurs montrent un tableau de bord. Moins posent ces questions :
- Est-ce qu’il utilise un vrai navigateur ? Les contrôles HTTP ne peuvent exécuter JavaScript, donc passent à côté de tout ce qu’un front moderne fait après la réponse initiale.
- Est-il facile de script un parcours multi-étapes ? Si un script de paiement prend deux jours à un dev, personne ne le maintient quand la page panier change.
- De quels emplacements peut-il tester ? Comptez les lieux qui correspondent à vos clients, pas le total. Vingt nœuds en Amérique du Nord n’aident pas un lancement européen.
- Peut-il faire des assertions sur le contenu, pas seulement sur le statut ? Cela sépare la surveillance des transactions d’un simple ping sophistiqué.
- Le résultat d’échec donne-t-il des données racine ? Une cascade, une capture d’écran à la panne, l’élément en erreur. Une alerte « paiement échoué » démarre l’enquête à zéro.
- Est-il compatible avec votre workflow d’incidents ? Les alertes qui arrivent dans PagerDuty, Slack, Teams, SMS ou un webhook sont traitées. Celles qui restent dans un tableau de bord jamais ouvert ne le sont pas.
- Peut-il toucher des environnements internes ou en préproduction ? Les apps en pre-prod ou sous firewall ont besoin d’un agent privé dans le réseau.
- Comment évoluent les prix en ajoutant des parcours ? La facturation à la passe ou à l’étape pénalise la surveillance profonde de parcours que vous achetez.
Comment Dotcom-Monitor gère la surveillance de l’expérience numérique
Dotcom-Monitor couvre la partie synthétique de la DEM, qui est la couche de détection pour tout ce qui précède. Quatre types d’appareils correspondent aux couches d’un parcours client, et la plupart des boutiques utilisent les quatre.
| Type d’appareil | Ce qu’il surveille | Ce qu’il fournit en cas d’échec |
|---|---|---|
| Applications Web (UserView) | Parcours multi-étapes scriptés dans un vrai navigateur : recherche, panier, paiement, connexion | Enregistrement vidéo de la session synchronisée avec le graphique en cascade, plus chronométrage par étape |
| Pages Web (BrowserView) | Rendu de page unique, Core Web Vitals, timing des éléments et actifs tiers | Cascade détaillée par élément montrant quelle requête a ralenti la page |
| Services Web (WebView) | Appels API REST, SOAP, GraphQL et importés Postman derrière le tunnel | Temps de réponse, statut, en-têtes et résultats d’assertions sur la charge |
| Infrastructure Internet (ServerView) | Contrôles DNS, certificats TLS, mail, FTP, TCP, ping | Couche qui a échoué, pour arrêter le débogage côté appli quand c’est un problème DNS |
Les parcours sont enregistrés dans EveryStep Web Recorder par capture point-and-click et non par sélecteurs écrits à la main, puis rejoués sur 40+ navigateurs mobiles et 30+ emplacements du réseau mondial. Les seuils par étape captent l’étape ralentie. Les assertions captent l’étape qui semble bonne mais ne l’est pas. Les agents privés exécutent les mêmes contrôles dans les environnements staging ou derrière votre firewall, ce qui compte si vous voulez détecter un mauvais déploiement paiement avant production.
Deux caveats honnêtes. Dotcom-Monitor est une plateforme synthétique, ne collecte pas de données RUM, donc associez-le avec un outil RUM si vous voulez de l’analyse session. Et ce n’est pas un APM : il vous dit qu’une étape a cassé et où, pas quelle ligne de code a jeté l’exception. Les équipes qui veulent les deux utilisent généralement monitoring retail et e-commerce avec un APM interne et traitent la couche synthétique comme un signal d’alerte précoce extérieur.
En résumé
La surveillance de l’expérience numérique comble le fossé entre « nos serveurs tournent » et « nos clients peuvent acheter ». La plupart des revenus que vous perdez à cause des problèmes de performance disparaissent dans ce fossé : pages d’erreur 200 OK, scripts tiers ralentissant que sur mobile, pannes régionales CDN invisibles dans vos données RUM, et APIs qui se dégradent sans jamais afficher d’erreur.
Pas besoin d’un gros programme pour commencer. Choisissez votre parcours le plus rentable, enregistrez-le dans EveryStep avec une assertion à chaque étape, lancez-le depuis les trois régions où vos clients sont, et routez les alertes vers quelqu’un qui peut agir. Ce contrôle seul détectera les pannes que votre tableau actuel cache.
Une fois stable une semaine, scriptz le parcours suivant et répétez. La plupart des équipes couvrent tout leur tunnel en trois ou quatre passes.
Surveillez les parcours qui comptent
Enregistrez votre parcours de paiement dans EveryStep, ajoutez une assertion à l’étape de confirmation, et exécutez-le depuis 30+ emplacements dans de vrais navigateurs. Lancez un essai gratuit Dotcom-Monitor et découvrez ce que votre tableau de bord de disponibilité ne vous montre pas.
