Guide d'intégration du consentement aux cookies pour l'expérience digitale et la session replay FullStory : Playbook 2026
FullStory est la plateforme dominante dans la catégorie de l'analyse de l'expérience digitale pour une raison : elle capture tout par défaut. Là où les outils d'analyse traditionnels enregistrent des événements discrets instrumentés par le développeur, et où les plateformes d'analyse produit enregistrent les interactions plus un supplément autocapturé, FullStory capture le DOM entièrement rendu, la trace du curseur, le timing des frappes de touches, le comportement de défilement, les clics de rage, les clics morts, les requêtes réseau et les erreurs JavaScript — et les assemble en enregistrements de session que l'analyste peut parcourir image par image. Cette couverture est le produit. C'est aussi pourquoi FullStory se trouve à l'intersection des règles de consentement les plus rigoureuses dans chaque régime de confidentialité moderne. Les lignes directrices de l'EDPB sur la session replay de 2023 et les priorités de la force opérationnelle de 2026 traitent la session replay comme une catégorie de consentement distincte et plus stricte. La CNIL a été le régulateur le plus public sur le sujet, mais n'est pas seule — le Garante, l'ICO, l'AEPD espagnole et l'AP néerlandaise ont tous émis des positions alignées. Un déploiement FullStory configuré pour une capture consentement-premier, avec le masquage correct, le contrôle d'accès correct et la piste d'audit correcte, est l'un des outils les plus puissants qu'un éditeur puisse exploiter ; celui qui n'a pas été ainsi configuré est l'une des cibles les plus faciles qu'un régulateur trouvera.
Pourquoi FullStory se trouve dans la catégorie de consentement la plus stricte
Une initialisation FullStory par défaut fait ce que fait chaque outil de session replay et plus encore. Elle définit des cookies de première partie sous l'espace de noms fs_uid et fs_lua contenant l'identifiant persistant du visiteur et l'horodatage de dernière activité, génère un identifiant de session sous fs_session et commence à diffuser le DOM rendu vers rs.fullstory.com en quelques millisecondes du chargement de la page. Le flux comprend chaque événement d'entrée, chaque mouvement de souris, chaque position de défilement, chaque transition de page et — lorsque le module de capture réseau est activé — chaque réponse XHR et fetch émise par la page, avec les corps de réponse inclus sauf si l'opérateur a configuré la suppression.
Chacune de ces captures active une porte de consentement distincte. La persistance de l'identifiant du visiteur est une opération de stockage et d'accès au titre de l'Article 5(3) de la Directive ePrivacy exigeant un consentement préalable, librement donné, spécifique, éclairé et sans ambiguïté dans l'ensemble de l'EEE, du Royaume-Uni et de toute juridiction ayant importé le même standard. L'enregistrement du DOM rendu est un traitement de données personnelles au titre du GDPR car le relevé visuel est suffisant pour identifier et révéler un contenu substantiel sur l'utilisateur. La capture du flux de frappes est une sensibilité particulière : tout ce que l'utilisateur saisit dans un champ de formulaire est capturé image par image, et si le champ n'est pas masqué, l'enregistrement inclut le contenu saisi. L'EDPB a été explicite sur le fait que la capture de session replay est une catégorie nécessitant un consentement explicite et granulaire distinct du consentement générique à l'analyse — et que le masquage est un complément au consentement, pas un substitut.
Ce que FullStory écrit avant le consentement — et ce qui doit être supprimé
Le démarrage rapide standard de FullStory installe le snippet de suivi directement dans le <head> de la page. Cela fonctionne comme documenté et est la source de l'échec de conformité le plus courant : le snippet s'exécute avant que la bannière de cookies soit rendue, les cookies fs_uid et fs_session sont écrits en quelques millisecondes, et le flux de session replay commence à circuler vers rs.fullstory.com indépendamment de ce que l'utilisateur décide par la suite. Chaque régulateur européen s'étant prononcé sur ce schéma a statué de la même manière : les cookies définis avant le consentement sont illicites, l'enregistrement capturé avant le consentement est un traitement illicite, et l'éditeur porte la responsabilité.
Une intégration conforme doit donc empêcher le snippet FullStory de s'initialiser tant que la catégorie de consentement pertinente n'a pas été accordée. Le schéma qui fonctionne en production est l'API FS.consent() combinée à un enregistrement différé : le snippet est chargé avec FullStory({ orgId: 'XXX', recordOnlyThisIFrame: false }) et FS.shutdown() est appelé immédiatement, puis FS.restart() et FS.consent(true) ne sont appelés qu'après que le CMP signale que la catégorie session replay a été accordée. Le schéma alternatif est l'injection conditionnelle de script — le snippet FullStory n'est ajouté au DOM qu'après l'octroi du consentement — ce qui est plus propre mais oblige l'opérateur à perdre tout assemblage d'identité pré-consentement que FullStory aurait autrement fourni.
Les cookies et le stockage écrits par FullStory
Le snippet FullStory écrit les identifiants suivants lors de l'initialisation, tous non essentiels et nécessitant un consentement : fs_uid avec une expiration multi-annuelle contenant l'identifiant persistant du visiteur, fs_lua avec l'horodatage de dernière activité utilisateur, fs_session avec l'identifiant de session, et les marqueurs d'état d'enregistrement utilisés en interne par FullStory. La révocation du consentement doit donc à la fois faire expirer ces cookies et appeler FS.consent(false) suivi de FS.shutdown() pour arrêter toute capture ultérieure, et l'éditeur doit envoyer une demande de suppression via le point de terminaison de confidentialité de FullStory pour les enregistrements précédents de l'utilisateur.
Cartographie de FullStory sur les cadres de consentement
FullStory n'implémente pas nativement IAB TCF ou la Plateforme mondiale de confidentialité IAB — c'est une plateforme d'expérience digitale de première partie, pas un fournisseur de technologie publicitaire. Il expose une API de consentement native et prend en charge un modèle de masquage privé par défaut qui fonctionne indépendamment de l'état de consentement. Le schéma qui survit à l'examen d'un régulateur traite chaque module FullStory comme une porte distincte liée à un signal CMP spécifique.
- La session replay et le flux DOM complet sont liés à une catégorie dédiée de session replay ou de recherche distincte de l'analyse générique. Les lignes directrices de l'EDPB sont explicites sur ce point — le consentement à la relecture doit être séparé et granulaire, non regroupé avec l'analyse ou le marketing.
- La capture réseau se trouve derrière une sous-porte plus stricte au sein de la même catégorie car elle capture les corps de réponse HTTP pouvant contenir des données personnelles sans rapport avec l'interface visible. La capture réseau doit être désactivée par défaut et activée uniquement pour des chemins d'application spécifiques où l'opérateur a confirmé que les corps de réponse n'incluent pas de données sensibles.
- L'assemblage d'identité via FS.identify() peut fonctionner avec un identifiant de session éphémère sur la base d'un intérêt légitime lorsque l'utilisateur est anonyme, mais lier l'identification à un identifiant persistant de première partie entre les sessions nécessite le même consentement que la session replay.
- Les cartes de chaleur et l'analyse de conversion dérivées du flux de session replay héritent de la porte du flux en amont — ce ne sont pas des surfaces de consentement distinctes, ce sont des produits en aval des mêmes données capturées.
Le schéma d'intégration qui fonctionne
Le déploiement de référence comporte quatre parties : un CMP qui expose un événement de changement de consentement en temps réel, un bootstrap différé qui initialise FullStory avec la capture supprimée via FS.shutdown(), un écouteur de consentement qui appelle FS.consent(true) et FS.restart() lorsque la porte de session replay s'ouvre, et une configuration de masquage privée par défaut qui supprime rigoureusement chaque champ de saisie sauf s'il est explicitement activé.
Masquage privé par défaut
La couche de masquage de FullStory fonctionne indépendamment du consentement et doit être configurée de manière agressive même lorsque le consentement a été accordé. La classe CSS fs-mask sur n'importe quel élément supprime le contenu de cet élément de l'enregistrement ; la classe CSS fs-exclude exclut entièrement l'élément du flux DOM ; la classe fs-block bloque à la fois le contenu et la structure. Selon les règles de catégories spéciales du GDPR et la définition des informations personnelles sensibles de la CCPA, tout champ susceptible de capturer des informations de santé, des détails financiers, des identifiants gouvernementaux, des données biométriques, une géolocalisation précise ou le contenu de communications privées doit utiliser les attributs de masquage indépendamment de l'état de consentement de l'utilisateur. La posture recommandée est d'appliquer fs-mask au niveau du formulaire plutôt qu'au niveau du champ — un développeur ajoutant un nouveau champ à un formulaire existant est beaucoup moins susceptible de se souvenir de le masquer individuellement que s'il opère dans un wrapper de masquage au niveau formulaire qui le capture automatiquement.
Sélection de région et résidence des données
FullStory exploite des points de terminaison d'ingestion distincts pour les États-Unis et l'UE. Pour le trafic EEE et Royaume-Uni, le point de terminaison de l'UE est la bonne valeur par défaut — il maintient l'ingestion, le traitement et le stockage à l'intérieur de l'EEE et réduit l'exposition Schrems II que tout déploiement de session replay dans la région américaine porterait. Le point de terminaison est configuré par organisation FullStory et ne peut pas être modifié rétroactivement, donc le choix de la région doit être fait avant la mise à l'échelle et documenté dans l'avis de confidentialité pour que la chaîne de base juridique soit propre de la collecte au stockage.
Validation de l'intégration et de la piste d'audit
L'étape de validation est ce que vérifient les régulateurs et ce que les éditeurs omettent le plus souvent sur les outils de session replay. Un déploiement FullStory correctement intégré doit passer quatre tests en séquence. Premièrement, une session navigateur propre avec la bannière affichée mais sans choix effectué doit produire zéro requête vers rs.fullstory.com au-delà de la récupération du fichier SDK et zéro cookies fs_ dans document.cookie. Deuxièmement, refuser le consentement à la session replay doit maintenir cet état — pas de capture, pas d'identifiant, pas d'enregistrement. Troisièmement, accepter le consentement à la session replay doit produire le cookie fs_uid attendu, un unique événement FS.consent(true) et le flux DOM circulant vers le point de terminaison de région configuré, avec les champs masqués confirmés ne capturant que l'espace réservé du masque. Quatrièmement, la révocation du consentement doit immédiatement arrêter toute capture ultérieure, faire expirer les cookies fs_ et déclencher une demande de suppression via le point de terminaison de confidentialité de FullStory pour les enregistrements précédents de l'utilisateur.
L'attente de piste d'audit est l'endroit où les outils de session replay font face au contrôle le plus strict. Les lignes directrices de la bannière de cookies de l'EDPB de 2023 et les priorités renouvelées de la force opérationnelle de 2026 sont explicites sur le fait que l'éditeur doit être en mesure de prouver, pour tout enregistrement de session spécifique dans le projet FullStory, que l'utilisateur qui l'a généré avait donné un consentement valide à la session replay au moment de la capture. Le schéma standard consiste à définir la version de consentement et l'horodatage comme variables utilisateur sur l'identifiant FullStory via FS.setUserVars({ consent_version: 'v3', consent_ts: ts }) afin que tout enregistrement individuel soit traçable jusqu'à une entrée spécifique du journal de consentement. Un déploiement correctement contrôlé, couplé à des attributs de masquage qui sont privés par défaut et à un chemin de suppression s'activant à la révocation, transforme la couverture de FullStory d'un risque de concentration réglementaire en une partie défendable de la pile d'expérience digitale d'un éditeur.