Rejeu de session : usages, méthode et conformité RGPD

Un outil de rejeu de session a sa place dans le CRO avancé et l’analyse comportementale lorsqu’il répond à une question précise. Les outils déployés sans finalité produisent surtout des heures de visionnage, une collecte excessive et des conclusions fragiles.

Ce qu’apporte un outil de rejeu de session

Une carte de chaleur agrège les interactions. Elle localise une concentration de clics ou un niveau de défilement, mais efface l’ordre des événements. L’enregistrement conserve cet ordre. Vous pouvez voir qu’un visiteur ouvre une aide, revient au formulaire, corrige deux champs, clique sur le bouton puis quitte après l’apparition d’une erreur.

Cette séquence apporte du contexte. Elle ne permet pas d’affirmer que la personne a « hésité », qu’elle « ne faisait pas confiance » ou que le message d’erreur a causé l’abandon. Un mouvement de souris ne représente pas l’attention ; une pause peut venir d’une interruption hors écran ; un retour en arrière peut être volontaire. Le comportement enregistré ne résume pas toute l’expérience. L’observation soutient une hypothèse, jamais un diagnostic psychologique.

La force du dispositif est donc qualitative : il aide à choisir quoi examiner ensuite. Sa faiblesse est tout aussi nette : quelques enregistrements ne donnent ni la prévalence d’un problème, ni son impact sur le taux de conversion, ni l’effet futur d’une correction.

Comment analyser sans perdre son temps ?

La méthode commence dans les données quantitatives. Une rupture mesurée dans l’entonnoir d’un formulaire, une hausse des erreurs JavaScript sur mobile ou un taux anormal de retours vers l’étape précédente fournit le symptôme. Les outils de rejeu de session servent ensuite à examiner des cas qui partagent ce symptôme.

1. Écrire la question avant d’ouvrir la solution. Par exemple : « Que se passe-t-il juste avant l’abandon du champ adresse sur Safari mobile ? » Une question observable vaut mieux que « Pourquoi les internautes ne convertissent-ils pas ? »
2. Construire un filtre reproductible. Événement, appareil, navigateur, source de trafic, version de l’application web, erreur, étape atteinte et période doivent pouvoir être rejoués par un autre analyste.
3. Examiner un petit lot homogène. Quelques sessions peuvent suffire à formuler une piste. Elles ne suffisent pas à mesurer sa fréquence dans l’ensemble des utilisateurs, qu’ils soient équipés d’un ordinateur ou d’un mobile.
4. Décrire avant d’interpréter. Notez « deux clics, message d’erreur, correction, sortie » plutôt que « la personne s’énerve ». Ce vocabulaire sépare le comportement observable de l’hypothèse.
5. Coder les observations. Utilisez les mêmes catégories pour chaque relecture : blocage technique, contenu ambigu, retour de validation absent, cible tactile, latence, chemin inattendu ou aucune anomalie visible.
6. Chercher les contre-exemples. Si cinq personnes abandonnent après le même message, comparez aussi des sessions d’internautes qui l’ont vu puis ont terminé. Vous évitez de confondre coïncidence et mécanisme.
7. Choisir la validation adaptée. Reproduction et journaux pour un bug, test d’utilisabilité pour une incompréhension, audit d’accessibilité pour un blocage d’usage, expérimentation contrôlée pour un effet causal sur la conversion.

Le bon livrable de ces analyses n’est pas une collection de vidéos commentées. C’est une liste courte d’hypothèses, chacune reliée à un symptôme mesuré, à des observations codées, à des contre-exemples et à une prochaine preuve. Ces analyses séparent aussi les problèmes techniques des problèmes de compréhension et des incidents sans anomalie observable.

Le rejeu de session est-il conforme au RGPD ?

Avant toute capture, cadrez la finalité, le consentement, le masquage, la conservation, les droits et les accès. Les outils de rejeu de session ne sont pas conformes par nature ou par marque. La conformité dépend de la finalité, des opérations de lecture ou d’écriture dans le terminal, des données traitées, des intervenants, des destinataires, des transferts, de la durée et des réglages réels. Un produit équipé de fonctionnalités de confidentialité peut rester mal configuré.

Le projet de la CNIL considère que les opérations de traçage nécessaires à la fonction de rejeu de session relèvent de l’article 82 de la loi Informatique et Libertés. Pour les finalités examinées, la CNIL estime qu’elles ne sont pas strictement nécessaires au service demandé et requièrent donc un consentement préalable. Ce point concerne l’accès ou l’inscription d’informations dans le terminal.

Il faut le distinguer de la base juridique du traitement ultérieur de données personnelles au titre de l’article 6 du RGPD. Dans son projet, la CNIL indique que le consentement lui paraît généralement le plus approprié pour ce traitement aussi, tout en rappelant que l’analyse doit tenir compte du contexte. Une même implémentation peut donc exiger deux raisonnements documentés, pas une case unique dans la CMP.

Le consentement doit être libre, spécifique, éclairé et univoque. Il doit être recueilli par finalité avant toute lecture ou écriture non autorisée. Refuser puis retirer son choix doit être aussi simple que l’accepter. Au retrait, la collecte doit cesser et les traceurs concernés doivent être neutralisés ; l’entreprise doit pouvoir prouver le choix et auditer le fonctionnement.

Avant la collecte, définissez une finalité concrète : diagnostiquer des erreurs techniques, améliorer l’ergonomie d’un parcours ou assister un utilisateur. « Comprendre les comportements » est trop large pour piloter la minimisation. La CNIL recommande aussi de privilégier une technique moins intrusive lorsqu’elle suffit et d’éviter toute réutilisation individuelle, par exemple pour le reciblage, sans justification distincte.

Le masquage visuel ne rend pas automatiquement les données anonymes. Le projet de la CNIL les traite comme personnelles, directement ou indirectement, quels que soient les réglages annoncés. Distinguez quatre protections : blocage avant collecte, masquage dans le navigateur, contenu chiffré ou caché chez le fournisseur, et démasquage exceptionnel. Les mots de passe, données bancaires et informations sensibles ne doivent jamais être collectés. Images, texte dynamique, formulaires et champs libres méritent un masque protecteur par défaut.

Les rôles ne se déduisent pas du contrat commercial. L’éditeur du site est en principe responsable du traitement qu’il détermine. Le fournisseur peut être sous-traitant s’il agit uniquement sur instruction. S’il réutilise les données pour ses propres finalités, son rôle peut changer. Les acteurs doivent examiner les sous-traitants ultérieurs, l’hébergement, les transferts, la sécurité et les possibilités de réutilisation, pas seulement le prix et les fonctionnalités.

L’information peut être organisée en deux niveaux dans la CMP. Le premier nomme la finalité de façon intelligible. Le second décrit le mécanisme, les catégories de données, les acteurs concernés, les destinataires, la durée, les droits et la manière de retirer son choix. Les utilisateurs doivent comprendre qu’une reconstruction de leur navigation peut être consultée ; « mesure d’audience » ne suffit pas à l’expliquer.

La minimisation agit sur le volume autant que sur le contenu : échantillonnage aléatoire, déclenchement par événement utile et suppression rapide des enregistrements sans rapport avec l’analyse. Pour un diagnostic d’erreur ou d’ergonomie, préférez un identifiant aléatoire, court et limité au domaine plutôt qu’un rapprochement avec le compte client. Une liaison pseudonyme avec un dossier d’assistance ne se justifie que si la finalité de support l’exige.

La durée doit suivre la finalité, pas la limite technique du fournisseur. L’annexe du projet de la CNIL évoque des durées de l’ordre de quelques heures pour l’assistance et de quelques mois pour l’ergonomie ou les erreurs. Ce sont des propositions provisoires, pas des durées automatiquement conformes. La solution doit permettre l’exercice des droits applicables au traitement, avec un identifiant suffisamment minimal pour retrouver les données concernées. La portabilité ne s’applique que dans les conditions de l’article 20 du RGPD, notamment pour un traitement automatisé fondé sur le consentement ou un contrat.

Enfin, le responsable évalue si une analyse d’impact relative à la protection des données est requise, notamment en cas de risque élevé, de grande échelle ou de contexte sensible. Le DPO conseille ; l’entreprise reste responsable de la décision et de sa documentation.

Lire les signaux automatiques sans les surinterpréter

Les outils de rejeu de session proposent parfois une fonction de détection des clics répétés, des clics sans effet et de l’agitation du curseur. Ces filtres peuvent accélérer les analyses. Les appellations anglaises rage click, dead click et cursor thrashing varient cependant selon les fournisseurs. Chaque fournisseur fixe ses propres fenêtres temporelles, seuils, événements et fonctionnalités. Vérifiez la définition de la version et de l’offre utilisées avant de comparer des taux.

Ces outils ne prouvent jamais la frustration des utilisateurs. Leurs marqueurs servent à constituer un lot de sessions potentiellement intéressant. Si un service n’expose pas ou ne documente pas l’agitation du curseur, n’inventez pas ce signal à partir d’une trajectoire qui vous semble désordonnée.

Détecter un bug sans confondre symptôme et cause

Une relecture peut montrer qu’après un clic, l’affichage ne change pas et l’utilisateur quitte. Elle ne montre pas à elle seule pourquoi. L’origine peut être une erreur JavaScript, une requête refusée, une ressource absente, un problème de validation, une latence ou un retour affiché hors de la zone visible.

Le diagnostic technique exige de rapprocher l’instant observable des journaux du navigateur, des requêtes réseau, des erreurs serveur et de la version déployée. Une solution comme LogRocket ou une fonction de relecture associée à la supervision peut faciliter ce rapprochement. Elle peut aussi capturer des en-têtes, corps de requêtes, états applicatifs ou messages de console contenant des secrets. Une liste d’autorisation et une politique de nettoyage explicite restent indispensables.

La réponse doit être proportionnée à l’hypothèse. Un défaut reproductible se corrige puis passe en test de non-régression. Une ambiguïté de contenu se confronte à des utilisateurs. Une variation susceptible de modifier la conversion se teste sur un échantillon dimensionné. La séquence enregistrée déclenche l’enquête ; elle ne remplace aucune de ces preuves.

Choisir un outil de rejeu de session : Clarity, Hotjar ou solution technique

Commencez par une grille de décision, pas par un classement universel. Les outils ne répondent pas tous au même besoin : une équipe produit cherche une friction, tandis qu’une équipe technique corrèle un incident avec des traces applicatives. Une entreprise doit aussi vérifier l’intégration au consentement, les protections de la vie privée et la possibilité d’exercer les droits.

Microsoft Clarity. Clarity est décrit dans la documentation consultée le 26 juillet 2026 comme un service de rejeu de session qui reconstruit les actions et le HTML, pas comme une vidéo. Les enregistrements sont conservés 30 jours ; après ce délai, Clarity indique conserver 1 % des enregistrements ou 10 par jour, selon le nombre le plus élevé, jusqu’à neuf mois. Les favoris peuvent aussi rester neuf mois. Sa FAQ précise qu’un enregistrement particulier ne peut pas être supprimé ou téléchargé isolément : une demande relative à un utilisateur peut imposer la suppression de ses données ou du projet selon le cas. Les entrées et listes sont masquées par défaut dans le mode équilibré, mais le texte et les images de l’interface demandent une configuration adaptée. Les changements de masquage ne sont pas rétroactifs.

Hotjar. Hotjar convient aux analyses UX lorsqu’il est correctement paramétré. Sa documentation indique que la désactivation de la capture empêche de nouvelles collectes, mais qu’il n’est pas possible d’arrêter par programmation un enregistrement déjà actif. Les frappes et données de saisie sont protégées par défaut, tandis que le texte, les images et les vidéos des pages demandent des règles supplémentaires. Un nouveau réglage de masquage n’efface pas ce qui a déjà été collecté.

LogRocket et outils techniques comparables. Leur avantage est la corrélation entre la relecture, le réseau, la console et l’état de l’application. Cette richesse augmente la surface de collecte. La documentation LogRocket demande de configurer la protection du DOM, du réseau et des états enregistrés. Pour Sentry ou une autre solution de supervision, contrôlez la documentation de la version et de l’offre retenues au lieu de transposer les réglages d’un concurrent.

Ces outils, leurs fonctionnalités et leurs durées peuvent évoluer. Rejouez les tests de confidentialité et relisez les sources du fournisseur avant chaque déploiement majeur. Une interface d’administration promettant « tout masquer » ne remplace pas l’inspection de ce qui quitte effectivement le navigateur.

Configurer la collecte en conformité

Une configuration sérieuse se valide sur les sites web équipés, avec leur gestionnaire de consentement, leurs sous-domaines, leurs applications mobiles et leurs composants dynamiques. Les points clés suivants transforment les principes en contrôles observables.

1. Fixer la finalité et la durée du dispositif. Nommez le problème à étudier, le périmètre, les responsables, le critère d’arrêt et l’alternative moins intrusive examinée.
2. Cartographier les intervenants et les flux. Documentez responsable, sous-traitants, réutilisations, sous-traitants ultérieurs, hébergement, transferts et clauses de sortie. Le contrat doit refléter les opérations réelles.
3. Paramétrer la CMP par finalité. Aucun traceur concerné ne lit ni n’écrit avant le choix. Refus et retrait stoppent la collecte, neutralisent les identifiants et restent aussi accessibles que l’acceptation.
4. Bloquer plutôt que masquer les données interdites. Mots de passe, paiement et catégories sensibles ne doivent jamais atteindre le fournisseur. Le masquage de restitution arrive trop tard s’il reçoit d’abord la valeur.
5. Appliquer un masque protecteur par défaut. Couvrez formulaires, texte libre, adresses électroniques, numéros de téléphone, images, vidéos et contenu dynamique. N’ouvrez qu’un élément indispensable, après revue, et consignez l’exception.
6. Exclure les parcours sensibles. Les outils ne doivent pas enregistrer paiement, santé, ressources humaines, messagerie privée et espaces authentifiés par simple commodité. Une priorité commerciale n’annule pas les problèmes de confidentialité.
7. Réduire le volume. Combinez échantillonnage aléatoire, déclencheur utile et suppression rapide des cas hors sujet. Ne reliez pas l’identifiant au compte lorsque le diagnostic fonctionne sans ce lien.
8. Régler la conservation par finalité. La valeur la plus courte compatible avec l’analyse prime sur le maximum de l’offre. Testez aussi la suppression individuelle et consignez les limites, notamment lorsqu’une plateforme ne supprime qu’un projet entier.
9. Limiter et tracer les accès. Rôles au moindre privilège, authentification multifacteur, interdiction des liens publics, journaux, revue régulière des comptes et retrait immédiat des anciens collaborateurs.
10. Sécuriser le cycle de vie. Chiffrement, gestion d’incident, sauvegardes, export, suppression contractuelle et sortie du fournisseur doivent être couverts avant la mise en production.
11. Tester tous les états. Inspectez le réseau et la reconstruction avant choix, après accord, après refus, après retrait et lors d’une nouvelle visite. Recommencez sur les domaines, les navigateurs équipés d’extensions, les mobiles, les modales, les iframes et les composants dynamiques.
12. Maintenir la preuve. Registre, information, règles de masquage, version du script, résultats de test, durées, procédure de droits et décision d’AIPD sont datés. Toute nouvelle fonctionnalité ou tout nouveau formulaire relance le contrôle.

Cette liste ne remplace pas l’analyse juridique de votre cas. Elle permet au DPO, au juriste, au produit et aux équipes techniques de discuter de la même implémentation au lieu de valider une promesse commerciale abstraite.

Mesurer l’impact sur les performances

Un script de rejeu de session doit initialiser un état, observer les mutations, écouter des événements, sérialiser des données et les envoyer. Le chargement asynchrone limite le blocage initial ; il ne supprime ni le travail CPU, ni la mémoire, ni les requêtes ultérieures. L’impact dépend du DOM, des interactions, de l’appareil, du réseau, de l’échantillonnage et des options activées.

Mesurez avant et après sur les mêmes scénarios et des appareils réels : nombre et poids des requêtes, temps CPU, tâches longues, consommation mémoire, erreurs et indicateurs INP, LCP et CLS. Sur les sites et applications web, comparez notamment une page produit, une page de formulaire et une page de confirmation. Séparez la décision de performance de la décision de minimisation. Enregistrer 10 % du trafic peut réduire le volume transmis ; cela ne garantit pas que chaque visite échantillonnée soit légère ou conforme.

Ne choisissez pas les zones les plus sensibles sous prétexte qu’elles ont la plus forte valeur commerciale. Commencez là où le symptôme est mesuré, la collecte proportionnée et la protection testable. Si le comportement reste ambigu, les micro-sondages de sortie peuvent apporter une réponse déclarée, avec leurs propres biais et obligations.

Questions fréquentes

Vincent Duquesne

Expert Google Ads Certifié depuis 2011 : j’ai audité et restructuré des centaines de comptes dans des dizaines de thématiques différentes. +20M€ gérés.

Google Partner Premier 2026