Comment fonctionne MousePlayer
Un guide simple de notre architecture de suivi, de la gestion des résolutions d’écran selon les appareils et des limites du système.
1. Pourquoi nous n’enregistrons pas de vidéo
On croit souvent que les outils d’analyse visuelle enregistrent des fichiers vidéo classiques (comme MP4 ou WebM) de l’écran du visiteur. Cela consommerait une bande passante énorme, ralentirait fortement votre site et produirait un texte flou et illisible.
MousePlayer utilise à la place une technologie légère appelée télémétrie par instantanés du DOM. Voici comment elle fonctionne concrètement :
L’instantané « plan »
Lorsqu’un visiteur ouvre votre page, notre script prend un « plan » textuel de votre structure HTML et de vos styles. Il enregistre l’emplacement des éléments sans copier les fichiers image ou vidéo de votre page ; pendant la relecture, le lecteur charge les images depuis leur adresse d’origine. Exception : les éléments canvas, dont le contenu est transmis sous forme d’image (voir plus bas).
Télémétrie des coordonnées
Au fil des interactions, nous enregistrons un flux d’événements : positions de la souris, profondeur de défilement, cibles des clics et redimensionnements du navigateur, ainsi que les modifications de la page elle-même et, selon les réglages, les messages de console, les requêtes en échec ou lentes et les mesures de temps de chargement (Web Vitals). Les mouvements et les clics sont légers ; les instantanés et modifications de page peuvent être nettement plus volumineux selon la page et sont transmis compressés.
La relecture en mode cinéma
Lorsque vous regardez une session dans votre tableau de bord, notre lecteur recrée la page à partir du plan enregistré et y déplace un curseur virtuel en temps réel, avec un texte parfaitement net.
Conçu pour rester léger : le script se charge de manière asynchrone et transmet de petites données numériques plutôt que de la vidéo, ce qui limite sa propre empreinte. Ce que cela signifie pour vos Core Web Vitals dépend de vos pages, de votre hébergement et du réseau de vos visiteurs : mesurez-le donc sur votre propre site plutôt que de vous fier à un chiffre de notre part. Aucune vitesse de chargement particulière n’est garantie – voir l’article 20 des Conditions d’utilisation.
2. Résolutions d’écran & appareils mobiles
Les utilisateurs d’aujourd’hui naviguent sur tout, des smartphones compacts aux moniteurs de bureau 4K ultra-larges. Les sites déplacent, replient et réorganisent automatiquement leur mise en page pour s’adapter aux différentes largeurs d’écran—un principe appelé responsive web design.
Comment nous reproduisons la zone d’affichage exacte du visiteur
Pour qu’une relecture ne paraisse pas déformée, MousePlayer enregistre les dimensions exactes de la zone d’affichage du visiteur (par ex. 390x844 pour un smartphone ou 1920x1080 pour un moniteur de bureau). Lorsque vous ouvrez le lecteur en mode cinéma, notre moteur crée un bac à sable mis à l’échelle qui reproduit parfaitement le rapport d’écran d’origine du visiteur.
Écrans d’ordinateur de bureau & portable
Sur les ordinateurs classiques, nous capturons le mouvement continu de la souris et la navigation entre plusieurs onglets au sein d’une même session de navigateur. Les menus qui s’ouvrent au survol apparaissent dans la relecture lorsque la page modifie son document pour cela ; un pur effet de survol CSS n’est pas visible dans le document et n’est pas reproduit dans la relecture.
Smartphones & tablettes
Les écrans tactiles n’ont pas de curseur de souris en survol. MousePlayer s’adapte automatiquement en enregistrant les appuis, le défilement par balayage et les changements d’orientation (portrait ou paysage).
Le défi du redimensionnement en cours de session
Si un visiteur fait pivoter sa tablette ou redimensionne la fenêtre de son navigateur en cours de session, la mise en page du site change dynamiquement. MousePlayer capture ces événements de redimensionnement et ajuste le canevas de lecture à la volée, sans interruption, afin que le contexte de l’interaction soit préservé.
3. Limites du système & contraintes techniques
Pour respecter la vie privée des utilisateurs, préserver la sécurité du navigateur et garder un traitement des données rapide, MousePlayer fonctionne dans des limites techniques définies :
| Limite du système | Comment MousePlayer la gère |
|---|---|
| iFrames | Les iframes de même origine que votre page sont enregistrées avec leur contenu et l’interaction qui s’y déroule. Le contenu intégré d’une autre origine (par ex. lecteurs YouTube, formulaires de paiement Stripe) ne peut pas être enregistré à l’intérieur en raison des règles de sécurité des navigateurs (Same-Origin Policy) ; il apparaît comme un espace réservé dans la relecture et n’y est pas chargé. |
| Champs de saisie sensibles (données personnelles) | Les champs de mot de passe et de paiement sont masqués sur l’appareil du visiteur à chaque niveau de masquage, et le masquage complet de toutes les saisies de formulaire est le réglage par défaut de chaque propriété. Vous voyez qu’une saisie a eu lieu, pas ce qui a été saisi. Deux limites s’appliquent : les deux niveaux de masquage plus faibles ne sont activés qu’avec notre approbation écrite, et le masquage ne s’étend jamais à ce que votre propre page affiche dans le document – une page de confirmation affichant une adresse fait partie de l’instantané. Ces deux points sont précisés dans l’accord de traitement des données (DPA). |
| Éléments canvas & WebGL | Le contenu d’un canvas est enregistré sous forme d’image : une fois avec l’instantané de la page, puis à chaque modification, au maximum environ une fois par seconde et avec une limite de taille. Les animations fluides apparaissent donc comme une suite d’images. Aucune image n’est transmise dans les zones masquées ni pour les éléments canvas contenant des images d’une autre origine ; le contenu WebGL peut rester vide. |
| Web Components (Shadow DOM) | Les shadow roots ouvertes sont enregistrées avec leur contenu. Les shadow roots fermées sont inaccessibles aux scripts ; leur contenu manque dans la relecture. |
| Transport & stockage du navigateur | Les données sont envoyées via une connexion WebSocket chiffrée (HTTPS/WSS). Si elle ne peut pas être établie, par exemple à cause d’un proxy, le script bascule vers une voie HTTP chiffrée ; les très gros instantanés de page sont envoyés séparément via HTTPS. MousePlayer ne dépose aucun cookie ; il utilise le stockage local et le stockage de session du navigateur sur votre site. |
| Périodes d’inactivité (AFK) | Si un visiteur laisse son onglet ouvert et s’absente 20 minutes, notre moteur détecte automatiquement l’inactivité et compresse ce temps mort pendant la relecture, pour que vous ne perdiez pas de temps à regarder des écrans figés. |