Comment le masquage de confidentialité de la relecture de session vous maintient conforme au RGPD et au CCPA

Bien réalisé, le masquage de confidentialité de la relecture de session est ce qui distingue un outil d’enregistrement conforme d’un passif en matière de protection des données, et c’est la première chose qu’un acheteur prudent demande avant qu’une seule session ne soit stockée.

L’objection est raisonnable. Une relecture reconstitue ce qu’une personne réelle a vu et saisi. Sans contrôles, cela peut inclure une adresse e-mail, un numéro de carte, une adresse personnelle ou un détail de santé. Le RGPD et le CCPA n’interdisent pas la relecture de session, mais ils traitent cette reconstitution comme une donnée personnelle, ce qui signifie qu’elle doit être minimisée, sécurisée, conservée pour une durée limitée et, dans de nombreux cas, couverte par un consentement.

La bonne nouvelle, c’est que tout le risque s’effondre lorsque vous le gérez à la bonne couche. Si la valeur sensible ne quitte jamais le navigateur du visiteur, il n’y a rien sur vos serveurs à divulguer, à réquisitionner ou à conserver trop longtemps.

Masquer avant la capture, pas après

Il existe deux moments fondamentalement différents où le masquage peut se produire, et un seul d’entre eux protège réellement l’utilisateur.

Le masquage avant la capture s’exécute dans le navigateur du visiteur. L’enregistreur parcourt la page, remplace le texte et les valeurs de saisie sensibles par des caractères de substitution, et seule la version masquée est sérialisée et envoyée. La valeur brute n’est jamais transmise. PostHog le documente directement : ses contrôles de confidentialité « s’exécutent dans le navigateur ou l’application mobile », de sorte que « les données masquées ne sont jamais envoyées sur le réseau ». Microsoft Clarity énonce le même principe : il « ne capture jamais rien qui soit masqué ou envoyé sur le fil ».

Le masquage après la capture enregistre les valeurs réelles, les expédie vers un serveur, puis les floute ou les censure au moment de la lecture. Les données non masquées ont tout de même traversé le réseau et ont tout de même atterri dans une base de données. Si ce stockage est compromis, une règle de censure dans le lecteur ne fait rien.

Pour une conversation sur la conformité, la distinction constitue tout l’argument. La minimisation des données selon l’article 5 du RGPD consiste à ne pas collecter les données, pas à les cacher plus tard.

	Masquage avant la capture	Masquage après la capture
Où s’exécute le masquage	Navigateur du visiteur	Serveur ou lecteur du fournisseur
Les données personnelles brutes quittent-elles l’appareil	Non	Oui
Ce qu’une compromission expose	Uniquement des substituts	Valeurs réelles
Aligné sur la minimisation des données	Oui	Faiblement
Modifications de règles rétroactives	Inutiles	Nécessaires, et ne peuvent pas corriger les données passées

Les quatre contrôles qui vous protègent réellement

Censure des saisies par défaut

Tout outil sérieux masque les champs de formulaire dès le départ, car c’est là que résident les mots de passe, les numéros de carte et les e-mails. Dans PostHog, toutes les saisies sont masquées par défaut et les champs de mot de passe sont toujours masqués quelle que soit la configuration. Dans Clarity, les zones de saisie et les listes déroulantes sont masquées dans tous les modes, y compris le plus permissif. Considérez tout outil livré avec les saisies visibles par défaut comme un signal d’alarme.

Masquage d’éléments et de texte

Les données sensibles apparaissent aussi en dehors des champs de formulaire : une confirmation de commande, un solde de compte, le nom d’un patient dans un titre. Vous les masquez avec des sélecteurs CSS ou un attribut de données sur l’élément, qui se propage à ses enfants. PostHog utilise des classes comme ph-no-capture ; Clarity utilise data-clarity-mask. La posture la plus sûre pour une application à haute sensibilité consiste à tout masquer et à ne démasquer sélectivement que les éléments dont vous avez confirmé qu’ils sont sûrs.

Exclusion de pages et d’itinéraires

Certains écrans ne devraient jamais être enregistrés du tout, comme une étape de paiement, un formulaire de coordonnées bancaires ou un écran d’authentification rendu par un tiers. Arrêter et redémarrer l’enregistreur autour de ces itinéraires retire l’écran entier de la capture plutôt que d’essayer de le masquer champ par champ.

Limites de rétention

Une rétention conforme signifie que les enregistrements expirent selon un calendrier défini au lieu de vivre éternellement. Une rétention plus courte réduit à la fois votre surface de compromission et vos obligations lorsqu’un utilisateur exerce un droit à l’effacement. Réglez-la sur la fenêtre la plus courte qui réponde encore à vos questions produit.

Consentement, adresses IP et cookies

Le fait que vous ayez besoin d’un consentement explicite dépend de la juridiction et de ce que vous stockez. Deux choix de conception réduisent considérablement la charge :

• Pas de cookies. Un enregistreur qui ne pose pas de cookies identifiants évite le déclencheur classique de consentement ePrivacy pour les cookies non essentiels.
• Pas d’adresses IP stockées. Les adresses IP sont des données personnelles selon le RGPD. Un outil qui les rejette lors de l’ingestion au lieu de les stocker retire l’un des identifiants bruts les plus courants de votre base de données.

Même avec cela en place, traitez le consentement comme une question juridique pour votre équipe, et non comme une case qu’un fournisseur peut cocher à votre place. Ce qu’un fournisseur peut faire, c’est faire du chemin conforme la valeur par défaut afin que le consentement couvre un terrain moins sensible.

Sous-traitants et localisation des données

Le masquage protège le contenu d’un enregistrement. Il ne répond pas à la question de savoir où cet enregistrement est stocké ni qui d’autre peut y toucher. Avant de vous engager, confirmez trois choses : la liste des sous-traitants que le fournisseur utilise, la région où les données de session sont hébergées, et si un contrat de traitement des données est disponible. Un discours de relecture axé sur la confidentialité s’effondre si les données circulent discrètement vers une douzaine de tiers non divulgués.

Comment Flowsery aborde cela

Flowsery est conçu selon le principe de confidentialité dès la conception plutôt que de confidentialité optionnelle. Le masquage est activé par défaut, de sorte que le texte et les saisies sensibles sont remplacés dans le navigateur avant que quoi que ce soit ne soit sérialisé. Flowsery est sans cookie et ne stocke pas les adresses IP des visiteurs, ce qui retire deux des identifiants les plus courants avant même qu’ils n’atteignent un serveur. Vous conservez un contrôle granulaire pour exclure des éléments et des itinéraires spécifiques et pour limiter la durée de conservation des enregistrements.

Le résultat est une relecture que vous pouvez défendre lors d’une revue de sécurité : la valeur sensible reste sur l’appareil du visiteur, et ce que vous stockez est déjà minimisé.

Questions fréquemment posées

La relecture de session est-elle conforme au RGPD ?

Elle peut l’être. Le RGPD n’interdit pas la relecture de session, mais il traite l’enregistrement comme une donnée personnelle. Vous restez conforme en minimisant ce que vous capturez, en masquant les données personnelles avant qu’elles ne quittent le navigateur, en limitant la rétention, en sécurisant l’accès et en recueillant le consentement là où votre juridiction l’exige.

Le masquage après la capture satisfait-il au CCPA et au RGPD ?

Il est plus faible. Si les valeurs réelles atteignent les serveurs du fournisseur et ne sont cachées qu’à la lecture, les données brutes ont tout de même été collectées et stockées, ce qui affaiblit la minimisation des données et laisse ces données exposées en cas de compromission. Le masquage avant la capture est la position la plus solide.

Qu’est-ce qui est masqué automatiquement ?

Dans les outils axés sur la confidentialité, les champs de formulaire sont masqués par défaut et les champs de mot de passe sont toujours masqués. Le texte libre, les titres et les images qui peuvent contenir des données personnelles sont masqués via des sélecteurs CSS, un attribut de données ou un paramètre global de tout masquer.

Ai-je encore besoin d’une bannière de consentement ?

Cela dépend de votre juridiction et de ce que vous stockez. Un enregistreur sans cookie qui ne conserve pas d’adresses IP réduit les déclencheurs, mais le consentement est une détermination juridique. Confirmez vos obligations auprès de votre propre conseil ou de votre équipe chargée de la confidentialité.

Puis-je modifier les règles de masquage rétroactivement ?

Non. Le masquage est appliqué au moment de la capture, donc un changement de règle n’affecte que les nouveaux enregistrements. Tout ce qui a déjà été capturé conserve le masquage qui était en vigueur à ce moment-là, ce qui est une autre raison de commencer strict et d’assouplir délibérément.

Enregistrez des sessions sans enregistrer de données personnelles avec Flowsery - masquage activé par défaut, sans cookie et sans adresses IP stockées.

Sources : Contrôles de confidentialité de la relecture de session PostHog et Masquage de contenu Microsoft Clarity. Vérifié le 24 juillet 2026.