Ce que Clarity enregistre réellement

Le SDK Clarity (chargé depuis www.clarity.ms/tag/{project_id}) initialise un objet clarity global et identifie les visiteurs avec un cookie appartenant à Microsoft appelé _clck, ainsi qu'un cookie de session _clsk. À partir de ce moment, le script capture un flux comportemental dense :

• Saisie souris et tactile — chaque mouvement, clic, tap, défilement et geste est enregistré avec un horodatage et des coordonnées.
• Interactions avec les formulaires — événements de focus, de flou et d'entrée sur chaque champ de formulaire, plus le texte des champs non sensibles si le masquage n'est pas configuré.
• Instantanés du DOM — des instantanés complets périodiques du DOM de la page afin que la relecture de session puisse reconstruire l'état visuel exact à n'importe quel moment.
• Événements personnalisés — tous les événements que l'application émet explicitement via des appels clarity("event", "name").
• Données de performance et d'erreur — erreurs JavaScript, défaillances réseau et mesures des indicateurs web essentiels.
• Données d'identification — le cookie appartenant à Clarity ainsi que la géolocalisation dérivée de l'IP et l'empreinte de l'agent utilisateur.

La combinaison — notamment les instantanés du DOM et la capture des champs de formulaire — rend Clarity fonctionnellement équivalent à un enregistrement vidéo de la session du visiteur. La classification réglementaire en vertu du GDPR est simple : il s'agit d'un traitement de données personnelles, les cookies ne sont pas essentiels, les données traversent les frontières vers l'infrastructure américaine de Microsoft et la base juridique requise est le consentement. Les lignes directrices 2024 de la CNIL sur l'enregistrement de session sont sans ambiguïté sur ce point et nomment explicitement les outils dans la catégorie de Clarity.

Le risque des données sensibles

Les outils d'enregistrement de session comportent un risque de vie privée spécifique que les autres outils d'analyse n'ont pas : ils peuvent capturer accidentellement des données personnelles sensibles. Un utilisateur saisissant un numéro de carte de crédit, un état de santé, une appartenance religieuse ou un identifiant national dans n'importe quel champ de formulaire est enregistré par Clarity si le champ n'est pas explicitement masqué. En vertu du GDPR, il s'agit d'un traitement de données personnelles sensibles au titre de l'Article 9, qui nécessite un consentement opt-in explicite et est rarement couvert par une décision générale de consentement marketing.

Clarity prend en charge une configuration de masquage du contenu qui cache des champs spécifiques de l'enregistrement, mais le comportement par défaut capture tout. L'approche défendable lors d'un audit est de masquer de manière agressive — supposez que chaque champ de formulaire est sensible jusqu'à preuve du contraire — et de documenter explicitement les décisions de masquage.

Contrôles de confidentialité natifs de Clarity

Microsoft a investi dans les contrôles de confidentialité de Clarity au cours des deux dernières années. La plateforme expose désormais plusieurs primitives qu'une intégration CMP peut exploiter.

L'attribut mask

L'ajout de data-clarity-mask="true" à un élément DOM masque son contenu de l'enregistrement de session. L'ajout de data-clarity-unmask="true" à un élément enfant remplace le masque pour ce sous-arbre. La valeur par défaut appropriée pour tout champ de formulaire susceptible de contenir des données personnelles est de masquer, puis de démasquer explicitement là où c'est sûr.

L'API de consentement

Clarity expose un appel clarity("consent") qui, lorsqu'il est invoqué, signale que le consentement a été accordé et que le SDK doit procéder. Sans cet appel, le SDK peut être configuré pour s'arrêter après le chargement initial. C'est la bonne primitive pour l'intégration CMP du côté activation.

Masquage IP et gestion des identifiants

Les paramètres du projet Clarity exposent des options pour la troncature IP et le masquage des identifiants. Les activer constitue une mesure de défense en profondeur en plus du filtrage CMP ; cela ne remplace pas le consentement.

Masquage automatique des contenus sensibles

Les versions récentes de Clarity tentent de détecter automatiquement les champs sensibles (modèles de carte de crédit, champs de mot de passe, champs nommés "ssn" ou similaires) et de les masquer par défaut. La détection est heuristique et incomplète ; ne vous y fiez pas comme seule ligne de défense.

Intégration CMP étape par étape

L'architecture fiable consiste à différer entièrement le SDK Clarity jusqu'à ce que le consentement soit accordé, puis à l'activer explicitement via l'API de consentement.

1. Supprimer la balise par défaut de l'en-tête du document

Le snippet d'installation de Clarity est un script inline unique qui initialise le SDK au chargement de la page. Remplacez-le par un élément script de substitution dont le type est text/plain et dont le data-category est analytics ou marketing selon la façon dont votre CMP catégorise les outils d'enregistrement de session.

2. Décider du mappage de catégorie

L'enregistrement de session est une catégorie contestée. La CNIL l'a traité tantôt comme de l'analytique (lorsque les données sont utilisées pour la recherche UX interne) et tantôt comme du marketing (lorsque les données alimentent des décisions de personnalisation ou un partage externe). Le mappage conservateur est le marketing ; la position défendable lors d'un audit exige que vous soyez précis sur la façon dont les enregistrements sont réellement utilisés.

3. Configurer un masquage agressif avant l'activation

Ajoutez data-clarity-mask="true" à chaque élément de formulaire, chaque champ de saisie, chaque conteneur susceptible de contenir des données personnelles. La politique par défaut est le masquage par défaut avec des exceptions de démasquage explicites pour les éléments connus comme sûrs (titres de page, étiquettes de navigation, blocs de contenu public).

4. Activer Clarity depuis le callback de consentement

Lorsque le CMP déclenche l'événement de catégorie acceptée pertinent, réécrivez la balise script de substitution et appelez clarity("consent") pour accorder au SDK la permission de continuer. Les événements mis en file d'attente qui ont été mis en mémoire tampon pendant la période pré-consentement seront alors vidés.

5. Gérer la révocation explicitement

Si l'utilisateur révoque son consentement, le SDK Clarity ne dispose pas d'un appel propre "arrêter l'enregistrement" équivalent à l'API d'activation. Le schéma pratique consiste à appeler clarity("consent", false) si cela est pris en charge dans votre version du SDK, et à effacer en outre les cookies Clarity côté client. Pour la suppression complète des enregistrements historiques, utilisez le workflow de suppression des données de l'interface d'administration Clarity ou l'API de suppression.

Pièges courants

Quatre erreurs d'intégration représentent la majorité des constatations d'audit sur les déploiements Clarity.

Installer Clarity "juste pour voir ce que font les visiteurs"

Le schéma le plus courant : un chef de produit installe Clarity pour étudier un problème UX, n'active jamais le filtrage du consentement, ne configure jamais le masquage et oublie le script. La surface d'enregistrement continue de s'accumuler. La solution consiste soit à supprimer complètement Clarity, soit à le soumettre à la même architecture de consentement que tout autre traceur.

Faire confiance au masquage automatique

La détection heuristique des champs sensibles de Clarity capture les cas évidents mais passe à côté des cas spécifiques au domaine — la zone de texte "symptômes" d'un site de santé, le champ "numéro de compte" d'un site financier avec un nom idiosyncrasique. Masquez explicitement ; ne vous fiez pas à la détection.

Traiter l'enregistrement de session comme de l'analytique

La CNIL a été explicite sur le fait que la catégorie d'enregistrement de session est plus proche du marketing que de l'analytique en propre du point de vue du consentement. Conditionner Clarity au seul consentement analytique n'est défendable que si les enregistrements sont utilisés exclusivement pour la recherche UX interne et ne sont jamais partagés en dehors de l'organisation.

Oublier les charges utiles des événements personnalisés

Le code d'application qui appelle clarity("event", "name", customProperties) peut laisser fuir des données personnelles dans le flux Clarity via la charge utile customProperties. Auditez chaque site d'appel et évitez de transmettre des identifiants d'utilisateur, des adresses e-mail ou toute donnée personnelle dans les propriétés d'événement.

Liste de contrôle d'audit

Six questions concrètes auxquelles répondre pour tout déploiement Clarity touchant le trafic EU, UK, brésilien ou californien.

• Clarity attend-il le consentement ? Ouvrez la page dans une fenêtre privée et confirmez qu'aucune requête clarity.ms ne se déclenche avant l'acceptation de la bannière.
• Le masquage est-il agressif ? Confirmez que chaque champ de formulaire et chaque conteneur avec du contenu potentiellement personnel a data-clarity-mask appliqué.
• Le mappage de catégorie est-il documenté ? Confirmez qu'il existe un enregistrement écrit indiquant si Clarity est soumis à un filtrage analytique ou marketing, avec le raisonnement.
• L'API de consentement est-elle connectée ? Confirmez que le callback CMP appelle clarity("consent") lors de l'octroi et l'équivalent lors de la révocation.
• Les événements personnalisés sont-ils audités ? Confirmez que les appels clarity("event", ...) ne transmettent pas de données d'identification ou sensibles dans leurs charges utiles de propriétés.
• La suppression est-elle automatisée ? Confirmez que les demandes DSAR déclenchent le workflow de suppression de Clarity, et non un ticket de support manuel.

La place de Clarity dans une pile axée sur le consentement

L'enregistrement de session est la surface de suivi comportemental à la plus haute densité d'information dans les déploiements courants, et Clarity est l'outil qui l'a démocratisée le plus agressivement. Le niveau tarifaire gratuit et l'installation sans friction en font le chemin de moindre résistance pour toute équipe souhaitant une visibilité sur le comportement UX. Cette même installation sans friction est ce qui fait de Clarity l'outil d'analyse le plus couramment mal configuré dans les audits 2026. La bonne architecture traite Clarity comme tout autre traceur identifiant : soumettez-le à un consentement explicite, masquez les champs de formulaire de manière agressive par défaut, documentez le mappage de catégorie et connectez l'API de consentement afin que les propres primitives du SDK appliquent ce que le CMP a enregistré. Fait correctement, la valeur de recherche UX pour laquelle l'outil a été acheté est préservée tandis que l'exposition réglementaire tombe à une fraction de ce qu'un déploiement par défaut implique.