Le session replay — rejouer la visite d'un internaute comme un film — est l'outil le plus parlant de la panoplie analytics. C'est aussi celui qui soulève le plus de questions RGPD, et à juste titre : mal configuré, il peut enregistrer des mots de passe, des données bancaires ou des informations de santé. Voici comment l'utiliser en toute légalité.
Quick Answer : le session replay est-il légal ?
Oui, à trois conditions :
- Masquage à la collecte — aucune saisie de formulaire ne doit être transmise en clair ; le masquage se fait dans le navigateur, avant envoi.
- Anonymisation — IP tronquée dès la collecte, pas d'identifiant persistant qui suivrait le visiteur entre ses sessions.
- Hébergement UE — les enregistrements ne doivent pas partir sur des serveurs soumis au Cloud Act américain.
Un outil qui remplit ces trois conditions et ne dépose aucun traceur soumis à consentement peut fonctionner sans bandeau, dans le même cadre que la mesure d'audience exemptée. Un outil qui ne les remplit pas exige un consentement — et ne verra que les sessions des 50 à 70 % de visiteurs qui l'acceptent.
À noter : la CNIL a lancé une concertation en 2025, puis publié début 2026 un projet de recommandation dédié au session replay — le cadre se précise, dans le sens des exigences ci-dessus.

Ce que dit le RGPD sur l'enregistrement de sessions
Le RGPD ne mentionne pas le session replay en tant que tel. Trois questions déterminent la conformité d'un enregistrement :
- Des données personnelles sont-elles collectées ? Saisies de formulaires, adresse IP, identifiants — si oui, le RGPD s'applique pleinement : base légale, information, minimisation.
- Des traceurs soumis à consentement sont-ils déposés ? Cookie d'identification, fingerprinting : c'est le terrain de la directive ePrivacy et de l'article 82 de la loi Informatique et Libertés.
- La finalité est-elle légitime et proportionnée ? Comprendre les frictions d'un parcours l'est ; profiler des individus ne l'est pas.
Le sujet est désormais explicitement sur la table du régulateur : la CNIL a lancé en avril 2025 une concertation sur les outils d'enregistrement et de relecture de session, suivie début 2026 d'un projet de recommandation dédié au session replay. Les orientations confirment la grille de lecture ci-dessus : ces outils reposent sur des traceurs, le consentement s'impose par défaut, et l'exemption ne se conçoit qu'avec une anonymisation robuste, un masquage systématique des données saisies et une finalité strictement limitée à l'amélioration du service. Autrement dit : les exigences décrites dans ce guide deviennent la norme attendue.
En complément, les positions de la CNIL sur la mesure d'audience exemptée restent la référence pour le volet traceurs : anonymisation, absence de recoupement, finalité limitée.
Les trois risques classiques (et comment les neutraliser)
1. La capture de saisies sensibles
Le risque numéro un. Un replay naïf enregistre tout ce que tape l'utilisateur — y compris mots de passe et numéros de carte. La parade est le masquage à la collecte : les champs de saisie sont remplacés par des caractères génériques dans le navigateur, avant tout envoi. Ce qui n'est jamais collecté ne peut ni fuiter ni être réclamé.
À vérifier chez votre fournisseur : le masquage des inputs est-il actif par défaut (et pas une option à cocher) ? Peut-on masquer des zones entières de la page (montants, données médicales affichées) ?
2. L'identification indirecte du visiteur
Même sans formulaire, une session peut identifier quelqu'un : IP complète + parcours + horaire suffisent parfois. Les contre-mesures : anonymisation de l'IP dès la collecte, pas d'identifiant persistant inter-sessions, pas de croisement avec un CRM.
3. Le transfert hors UE
Beaucoup d'outils de replay populaires sont américains : les enregistrements — donc potentiellement des données personnelles — partent sur des serveurs soumis au Cloud Act. Le problème est le même que pour Google Analytics : le cadre EU-US actuel est juridiquement fragile. Un hébergement UE, idéalement français, élimine la question.
Consentement ou pas : le critère décisif
Deux architectures existent sur le marché :
| Architecture | Consentement | Conséquence |
|---|---|---|
| Replay avec cookies/identifiants, données en clair | Obligatoire | Vous perdez les sessions des 30-50 % de visiteurs qui refusent — souvent celles qui vous intéressent le plus (les frustrés qui partent vite) |
| Replay anonymisé par conception : masquage à la collecte, pas de traceur soumis à consentement | Non requis | 100 % des sessions observables, dans le même cadre que la mesure d'audience exemptée |
C'est un point souvent ignoré : le replay soumis à consentement souffre d'un biais de sélection massif. Les visiteurs qui refusent le bandeau et les visiteurs qui abandonnent votre tunnel se recoupent largement. Vous n'enregistrez que les sessions des convaincus.
Panorama du marché : trois familles d'outils
Le choix de l'outil détermine votre situation juridique avant même la première configuration :
| Famille | Exemples typiques | Situation RGPD |
|---|---|---|
| Suites américaines complètes | Hotjar, FullStory, LogRocket | Consentement requis (cookies + données personnelles), transferts hors UE à auditer au cas par cas |
| Outils gratuits des géants | Microsoft Clarity | Gratuit, mais données sur infrastructure américaine et finalités croisées avec l'écosystème publicitaire |
| Privacy-first européens | Mirage et quelques acteurs UE | Masquage et anonymisation par conception, hébergement UE, exploitables sans consentement |
Le « gratuit » des géants suit la même logique que Google Analytics : vous payez en données. Pour un site européen, la troisième famille élimine le dossier juridique au lieu de le documenter.
Cas concret : le formulaire qui perdait 60 % de ses visiteurs
Un scénario que nous voyons régulièrement, ici un formulaire de demande de devis en quatre champs :
- L'entonnoir montre 60 % d'abandon entre l'arrivée sur le formulaire et l'envoi — anormal pour quatre champs.
- Dix replays suffisent à voir le motif : au champ « SIRET », les visiteurs quittent la page… pour aller chercher leur numéro. La moitié ne revient jamais.
- Le correctif : rendre le champ optionnel et le déplacer dans un second écran post-envoi. Validé par A/B test : −34 % d'abandon.
Notez ce que le replay n'a pas eu besoin de savoir : qui étaient ces visiteurs, ni ce qu'ils tapaient. Le comportement seul — masqué, anonyme — contenait tout le diagnostic.
Combien de sessions faut-il regarder ?
Le replay ne se consomme pas en continu : il s'utilise en enquête ciblée. La méthode économe :
- Partez toujours d'un signal agrégé (une marche d'entonnoir qui fuit, une zone anormale de heatmap, une page à fort rebond) — jamais du flux brut des sessions.
- Regardez 5 à 10 sessions du segment concerné. Si un motif existe, il apparaît presque toujours dans les cinq premières ; au-delà de dix sans motif, l'hypothèse est probablement fausse.
- Filtrez par comportement : sessions avec abandon de formulaire, sessions longues sans conversion, sessions mobiles uniquement. Dix sessions pertinentes battent cent sessions aléatoires.
C'est aussi la raison pour laquelle les quotas serrés des outils facturés à l'enregistrement (150 sessions/mois sur certains plans) sont si pénalisants : l'enquête a besoin du bon segment, pas d'un échantillon aléatoire.
En pratique dans Mirage — La relecture de sessions applique le masquage à la collecte par défaut : aucune saisie n'est transmise en clair, les IP sont anonymisées, aucun cookie tiers n'est déposé, et les enregistrements restent en France (Scaleway). Vous voyez 100 % des parcours, y compris ceux des visiteurs qui auraient refusé un bandeau. Essai gratuit 30 jours.
Checklist de conformité session replay
- Masquage par défaut de tous les champs de saisie, côté navigateur
- Possibilité d'exclure des éléments affichés (montants, données sensibles)
- IP anonymisée à la collecte, pas d'identifiant persistant
- Hébergement UE (bonus : France), pas de transfert hors UE
- Finalité documentée dans votre registre de traitements : amélioration UX
- Durée de conservation limitée et justifiée (quelques semaines à quelques mois)
- Mention dans votre politique de confidentialité
- Pas de croisement replay ↔ identité (CRM, support) sans base légale dédiée
Ce que le replay conforme vous apprend quand même
Le masquage n'enlève rien à la valeur d'usage. Les questions auxquelles le replay répond sont comportementales :
- Où les visiteurs hésitent-ils ? Allers-retours, pauses longues, scrolls erratiques.
- Quels éléments provoquent des clics morts ? Ces images que tout le monde croit cliquables.
- Où les formulaires perdent-ils les gens ? Le champ précis où la session s'arrête — sans voir la saisie, on voit l'abandon.
- Que font les sessions qui convertissent, que ne font pas les autres ? Croisé avec les entonnoirs de conversion, c'est la base du CRO.
Complétez avec les heatmaps pour la vision agrégée : le replay explique l'individuel, la heatmap confirme le collectif.
FAQ
Le session replay nécessite-t-il un consentement ?
Cela dépend de la conception de l'outil. Si l'enregistrement repose sur des cookies ou identifiants persistants, ou s'il capture des données personnelles, un consentement est requis. Un outil qui anonymise à la collecte, masque les champs sensibles et ne dépose pas de traceur soumis à consentement peut fonctionner sans bandeau, comme la mesure d'audience exemptée.
Peut-on enregistrer les saisies de formulaire ?
Jamais en clair. Les bonnes pratiques imposent le masquage par défaut de tous les champs de saisie (email, mot de passe, carte bancaire, texte libre) directement côté navigateur, avant tout envoi au serveur. Ce qui n'est pas collecté ne peut pas fuiter.
Le session replay est-il utile si les données sont masquées ?
Oui. L'intérêt du replay est comportemental : parcours, hésitations, clics morts, abandons de formulaire. Ces signaux restent parfaitement lisibles avec des contenus masqués — on voit qu'un champ bloque l'utilisateur sans voir ce qu'il y tape.
Quelle est la différence entre session replay et heatmap ?
Le replay rejoue une session individuelle du début à la fin ; la heatmap agrège les clics et le scroll de centaines de sessions sur une page. Le replay répond à « que s'est-il passé pour ce visiteur ? », la heatmap à « que fait la majorité sur cette page ? ». Les deux se complètent.