Session replay : masquer les formulaires sensibles

Masquez les données avant leur transmission à l’outil de rejeu, puis contrôlez tous les endroits où le formulaire les réaffiche. Une adresse cachée dans le champ de saisie peut rester visible dans une confirmation, un message d’erreur ou l’URL. Lorsque ce périmètre ne peut pas être maîtrisé, excluez le formulaire ou le parcours du rejeu.

Le bon critère n’est pas « la vidéo paraît floutée ». Il faut déterminer ce que le prestataire reçoit, ce qu’il conserve et ce que les utilisateurs de l’outil peuvent consulter. Voici une méthode de réception centrée sur les formulaires Web, avec une spécification remplie à adapter à votre site. Elle ne constitue pas un essai d’un produit ni une garantie de conformité de son installation.

Commencer par la question à résoudre

« Comprendre pourquoi le formulaire de devis est abandonné » reste trop large. Distinguez un bouton inaccessible sur mobile, une règle de validation incomprise et une interruption lors du changement d’étape. Le premier problème peut se reproduire sur un appareil de démonstration ; le deuxième peut être étudié à partir des catégories d’erreurs ; aucun n’exige, par nature, de lire les coordonnées du prospect.

Les Art. 5(1)(b)-(c) imposent des finalités déterminées et des données limitées au nécessaire. L’Art. 25(1)-(2) exige leur prise en compte dès la conception et par défaut, y compris pour l’accessibilité et la conservation. Il faut donc justifier le besoin de rejeu avant d’affiner ses réglages. RGPD, principes et protection dès la conception.

Une décision exploitable serait : observer le passage entre deux étapes et l’apparition d’un message générique de validation, sans recevoir le contenu des champs ni le dossier du demandeur. Si un essai sur des données fictives suffit à comprendre le défaut, corrigez-le sans enregistrer les visiteurs. Si un suivi en production reste nécessaire, limitez son périmètre et documentez ce que les autres moyens ne permettent pas d’établir.

Séparer masquage, consentement et sécurité

Pour les lectures ou inscriptions dans le terminal relevant de l’Art. 82 de la loi Informatique et Libertés, le consentement préalable est la règle. Les exceptions concernent la finalité exclusive de permettre ou faciliter la communication électronique, ou la stricte nécessité pour un service demandé expressément. L’intérêt de l’éditeur à améliorer ses conversions ne rend pas, à lui seul, le rejeu nécessaire au service demandé. Le masquage ne crée pas d’exception. Art. 82.

Le traitement de données personnelles nécessite également une base légale au titre de l’Art. 6(1), une information adaptée et le respect des droits. Pour un dispositif d’analyse facultative fondé sur le consentement, expliquez le rejeu et sa finalité avant activation ; une autorisation pour une autre opération ne suffit pas. Le retrait doit être aussi simple que l’accord selon l’Art. 7(3). Il faut contrôler l’arrêt des scripts après retrait, pas seulement le changement d’apparence du bouton.

La CNIL a publié le 25 février 2026 une consultation sur un projet de recommandation relatif au rejeu, close le 22 avril. Ce document de consultation est présenté ici comme un projet, sans lui attribuer la valeur d’une recommandation définitive. Les obligations légales précédentes s’appliquent indépendamment de ce travail.

Enfin, une session masquée n’est pas nécessairement anonyme : identifiant, horodatage ou contexte peuvent permettre de retrouver une personne. Restreignez les habilitations, la durée et les possibilités d’export. Le consentement éventuel ne dispense ni de minimisation ni de sécurité.

Lire les fonctions du fournisseur dans leur périmètre exact

La documentation Web de Contentsquare illustre pourquoi « les champs sont masqués » est une réponse incomplète. Elle décrit le retrait de contenus dans le navigateur avant envoi et des protections des saisies, mais les listes déroulantes peuvent nécessiter un masquage spécifique. Les modifications du contenu de la page alimentent aussi le rejeu. Un attribut ajouté tardivement ne protège donc pas rétroactivement le premier envoi. La même documentation décrit une fonction distincte de collecte chiffrée permettant une exposition contrôlée : le chiffrement n’est pas l’absence de collecte. Documentation technique, traitement des données personnelles.

Sa documentation des règles par élément distingue le masquage d’un composant et celui d’un attribut. Elle précise que les changements ne s’appliquent qu’aux nouvelles sessions et que ces règles ne sont pas prises en charge sur les pages de paiement Shopify. Ce sont des limites propres au périmètre décrit, à rapprocher de la plateforme effectivement utilisée. Règles de masquage par élément.

Ne transposez pas automatiquement ces fonctions à un autre fournisseur ou à une application mobile. Dans votre dossier, notez la plateforme, le module activé, la version de configuration et les options qui autorisent une collecte supplémentaire. Une réponse commerciale globale sur la confidentialité ne remplace pas cette description.

Une spécification remplie pour un formulaire de devis

Voici une proposition de conception, sans résultat d’essai allégué. Un organisme de formation souhaite comprendre une difficulté de passage de l’étape « coordonnées » à l’étape « calendrier ». Son formulaire contient une zone libre ; certains demandeurs pourraient y décrire une situation personnelle que l’analyse ergonomique n’a aucune raison de recevoir.

La décision proposée est de conserver seulement l’observation des étapes et des messages génériques nécessaires. L’espace connecté et la page qui présente le dossier nominatif sont exclus. Le tableau définit des résultats attendus : chaque ligne doit ensuite recevoir une preuve de contrôle sur l’installation réelle.

Cette spécification ne demande pas de masquer l’envoi fonctionnel du devis au service commercial : elle sépare le destinataire nécessaire au traitement de la demande du prestataire d’analyse ergonomique. Les règles s’appliquent au circuit de rejeu, sans casser la remise du formulaire ou empêcher le demandeur de corriger ses informations.

Pour la zone libre, ne cherchez pas à détecter uniquement quelques mots jugés sensibles. Son contenu est inutile à la finalité retenue : excluez-le en entier. Si la confirmation ne peut pas être séparée du dossier nominatif, excluez cette page plutôt que de conserver un périmètre dont la protection reste incertaine. La revue des pages sensibles à exclure du suivi aide à préparer cette cartographie.

Recevoir la configuration sur plusieurs états de la page

Le développeur prépare un parcours avec des données fictives reconnaissables. Il le réalise sur les états réellement disponibles : formulaire vide, informations préremplies, correction d’une erreur, ajout d’un participant, retour à l’étape précédente, confirmation. Un contrôle du seul chargement initial ne couvre pas un composant qui apparaît ensuite.

Pour chaque état, rapprochez trois éléments : le contenu affiché au visiteur, les données effectivement envoyées à l’outil et la restitution consultable. Cette comparaison évite deux erreurs : prendre une absence de texte à l’écran pour une absence de collecte, ou considérer qu’un composant non rejoué ne fonctionne pas sur le site réel. Les traces du contrôle doivent identifier la configuration examinée.

Inscrivez dans la fiche de réception, pour la ligne « validation », par exemple : « Saisie fictive incorrecte ; message générique conservé ; valeur personnelle absente de la requête de rejeu ; référence de la trace à compléter après vérification ». Ce libellé constitue une attente, pas une preuve déjà obtenue.

Réalisez aussi les parcours sans choix, après refus et après retrait. Pour le dispositif facultatif soumis au consentement décrit ici, la collecte de rejeu ne doit pas commencer avant accord et doit cesser après retrait. Contrôlez une navigation vers une autre page et le chargement des éléments différés. Le formulaire doit rester utilisable lorsque l’internaute refuse l’analyse.

Si une valeur apparaît dans une requête alors qu’elle devrait être exclue, suspendez le rejeu du périmètre concerné. Faites corriger la configuration avec le développeur ou le fournisseur, puis reprenez les états affectés et les parcours de consentement. Tant que l’effet du réglage n’est pas démontré, conservez le diagnostic par reproduction sur données fictives ou par informations agrégées appropriées ; n’ouvrez pas les données réelles pour « voir ce qui passe ».

Traiter l’historique et préparer les évolutions

Une correction prospective laisse ouverte la question des sessions déjà recueillies. Recherchez la période, les composants concernés et les accès ou exports possibles. Demandez au prestataire le mécanisme adapté de suppression et son périmètre ; distinguez la demande reçue de l’action exécutée. Les journaux serveur peuvent aussi contenir des copies qu’une correction du rejeu ne traite pas.

Une collecte excessive impose une correction de conformité. Si les circonstances révèlent également une violation de sécurité entraînant notamment une divulgation ou un accès non autorisés, appliquez l’analyse des Art. 33 et 34 : documentation, notification à l’autorité sauf risque improbable, et information des personnes en cas de risque élevé selon les conditions légales. N’attendez pas une purge achevée pour décider ; la notification doit intervenir dans les meilleurs délais et, si possible, sous soixante-douze heures après connaissance de la violation. RGPD, Art. 33(1)-(5) et 34.

Attribuez enfin la fiche au propriétaire du formulaire. Une modification de composant, de confirmation, d’URL ou d’outil déclenche une revue du périmètre affecté. Conservez les preuves nécessaires à cette vérification, sans accumuler des sessions réelles pour documenter les versions. Avant une nouvelle utilisation présentant un risque élevé, examinez l’analyse d’impact requise par l’Art. 35(1) ; tous les formulaires ne relèvent pas automatiquement de la même conclusion.

Ce qu’il faut retenir

• Le masquage doit couvrir les réaffichages et les données envoyées, pas seulement la saisie visible.
• Une finalité précise permet de choisir les éléments utiles et ceux à exclure.
• Consentement, minimisation, historique et habilitations restent des décisions distinctes.
• La réception porte sur des résultats observables, puis doit suivre les évolutions du site.

FAQ

Peut-on démasquer les champs pour comprendre une erreur ?

Commencez par reproduire l’erreur avec des valeurs fictives et observer sa catégorie. Une extension de collecte réelle demande une justification, une base légale et des garanties adaptées ; elle ne se déduit pas du besoin de corriger un défaut.

Un champ masqué peut-il rester identifiable par son URL ?

Oui, si l’URL comporte une référence ou un texte permettant un rapprochement. Examinez les informations transmises par les différents circuits ; le masquage du contenu de la page n’apporte pas, à lui seul, cette réponse.

Que demander si le prestataire ne documente pas le moment du masquage ?

Une explication technique et un moyen de contrôler la donnée reçue. Si vous ne pouvez pas établir que le périmètre est maîtrisé, maintenez l’exclusion du formulaire et choisissez une autre méthode de diagnostic.

Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.

Thiébaut Devergranne est docteur en droit et fondateur de donneespersonnelles.fr. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données personnelles.