Hotjar, Clarity, Contentsquare : ce que le session replay coûte vraiment à vos pages

L’outil a été installé pour comprendre les visiteurs : voir où ils cliquent, où ils hésitent, où ils abandonnent le panier. Des mois ou des années plus tard, il tourne toujours, sur toutes les pages, pour tous les visiteurs, et il ralentit précisément ceux qu’il devait aider à comprendre. Bien souvent, plus personne ne regarde les enregistrements.

Le session replay, ou enregistrement de session, est un script tiers à part. Au-delà du chargement, son coût croît avec la durée de la visite et avec chaque interaction, c’est-à-dire exactement dans la fenêtre que mesure l’INP, la métrique de réactivité des Core Web Vitals.

Les outils de laboratoire le voient mal, parce que leur robot ne clique pas, ne défile pas et ne donne pas son consentement. Ce guide explique le mécanisme, montre comment mesurer le coût réel sur votre site, compare Hotjar, Microsoft Clarity et Contentsquare, et propose une gouvernance qui garde l’outil utile sans le laisser coûter en permanence.

Une question avant de commencer, à poser à l’équipe qui a installé l’outil : combien de sessions enregistrées ont été visionnées le mois dernier ?

Qu’est-ce que le session replay et comment fonctionne-t-il ?

Le session replay reconstitue la visite d’une personne à partir du DOM, la structure de la page, sans aucune vidéo. Le script capture un instantané complet de la page, puis enregistre chaque modification et chaque interaction ; l’outil rejoue ensuite ces événements dans l’ordre. Le projet libre rrweb documente ce mécanisme en détail.

Un instantané, puis un flux de mutations

rrweb, bibliothèque sous licence MIT, sert ici de référence pour expliquer le principe, sans préjuger de l’implémentation de chaque éditeur. Au démarrage, le module d’enregistrement sérialise le DOM entier et son état : chaque nœud, ses attributs, le texte, les feuilles de style. Il observe ensuite le document par un MutationObserver posé sur toute l’arborescence, et des écouteurs captent les mouvements de souris, les clics, le défilement et les saisies. Chaque modification de la page devient un événement, horodaté, mis en mémoire tampon, puis envoyé par lots au serveur de l’éditeur.

Le lecteur fait le chemin inverse : il reconstruit l’instantané dans une iframe, puis applique les événements un à un. Un enregistrement contient donc une description de la page et de ses changements, sans aucun pixel ni image de l’écran. Les champs de saisie y sont masqués par défaut chez les principaux éditeurs, ce qui évite d’enregistrer ce que le visiteur tape, sans rien changer au coût de l’observation.

Heatmaps et cartes de défilement

Les cartes de chaleur (heatmaps) reposent sur la même collecte : coordonnées des clics, positions de la souris, profondeur de défilement, envoyées au serveur et agrégées sur des milliers de pages vues. Le coût côté visiteur est celui des écouteurs et de l’envoi ; l’agrégation, elle, a lieu chez l’éditeur. Une heatmap sans enregistrement de session coûte donc moins cher, mais l’outil installé fait souvent les deux.

Pourquoi un outil de session replay coûte-t-il plus que son poids ?

Parce que deux de ses trois postes de coût sont continus : l’instantané initial se paie une fois, l’observation et l’envoi durent toute la visite. Plus la page est grande et dynamique, plus la visite est longue et interactive, plus l’outil travaille sur le même fil que vos réponses aux clics.

L’instantané initial, proportionnel à la taille du DOM

Sérialiser une page de 3 000 nœuds coûte plus cher que sérialiser une page de 800 nœuds, et ce travail a lieu au démarrage, souvent pendant le chargement. Lighthouse 13 signale une page trop lourde par l’insight dom-size-insight, qui a remplacé l’ancien audit dom-size dans la version publiée le 10 octobre 2025. Un DOM allégé profite à tout, et en particulier au premier coût d’un enregistreur de session.

L’observation continue

Chaque mutation du DOM est sérialisée. Une page statique en produit peu ; une page dynamique en produit en continu : carrousel qui tourne, compteur qui défile, contenu injecté au défilement, publicités qui se rechargent, application monopage qui remplace son contenu à chaque navigation. Sur ces pages, l’outil travaille même quand le visiteur ne fait rien, et son travail s’additionne à celui de la page.

L’envoi réseau

Les événements partent par lots, souvent compressés dans le navigateur avant l’envoi, et en tâche de fond. Le poids transféré reste modeste, mais la compression et la préparation des lots consomment du processeur sur le fil principal ou dans un worker, selon l’implémentation. Sur un mobile d’entrée de gamme, ce coût se lit dans la batterie autant que dans les métriques.

L’effet sur l’INP

L’INP mesure le délai entre une interaction (clic, toucher, frappe) et l’affichage qui la suit. Or l’enregistreur réagit précisément aux interactions : il capte le clic, puis sérialise les mutations que le clic provoque. Son travail se loge dans la même boucle que la réponse de votre page, et l’allonge. Notre article sur l’INP et son amélioration détaille cette fenêtre.

Mesuré par l’agence le 15 octobre 2026 sur un article de site média, en émulation mobile : Clarity laisse l’INP de laboratoire à 72 ms, Contentsquare le porte de 72 à 88 ms en médiane, avec un passage défavorable à 184 ms. Sur cette page légère, l’écart reste sous le seuil de 200 ms ; sur la vôtre, la mesure décrite plus loin donne le chiffre.

Pourquoi Lighthouse et PageSpeed Insights le sous-estiment-ils ?

Parce que leur robot ne clique pas, ne défile pas et ne donne pas son consentement. Il voit un outil au repos, parfois même pas chargé si le site attend l’accord du visiteur, et mesure un plancher, jamais le coût d’une vraie visite.

Ce que publie third-party-web

Le projet third-party-web agrège les audits Lighthouse que HTTP Archive lance chaque mois en émulation mobile, et publie le temps d’exécution moyen de chaque service tiers par page. Le jeu de données le plus récent publié au 15 octobre 2026 date du 1er mars 2026. Pour les enregistreurs de session, il donne : Microsoft Clarity, 405 ms par page sur 1 226 624 pages ; Hotjar, 732 ms sur 504 590 pages ; FullStory, 911 ms sur 21 307 pages ; Mouseflow, 52 ms sur 14 518 pages. Contentsquare n’y apparaît pas sous un domaine propre dans ce jeu.

Ces moyennes se lisent avec trois précautions. Elles décrivent une implémentation typique, que des réglages soignés peuvent alléger. Elles proviennent d’un robot sans interaction ni consentement : c’est un plancher, et le Web Almanac 2025 reconnaît lui-même, dans son chapitre sur les tiers, que ses relevés sont une borne basse. Enfin, l’effectif compte : une moyenne sur 14 518 pages n’a pas la solidité d’une moyenne sur 1,2 million. Le classement par impact total, souvent repris, est une somme mondiale et jamais un coût par page.

Notre banc a relevé 68,5 ms de script pour Clarity, loin des 405 ms de third-party-web. Les deux chiffres décrivent deux choses : third-party-web reprend le temps d’exécution compté par Lighthouse sur tout le chargement de pages réelles, souvent chargées ; le banc compte les frames longues d’un parcours sur une page légère. Chacun donne un ordre de grandeur, dans son propre cadre.

Lighthouse 13 n’alerte plus

Jusqu’à la version 12, l’audit Third-Party Summary échouait quand le code tiers bloquait le fil principal plus de 250 ms. Lighthouse 13 l’a remplacé par l’insight « 3rd parties », qui liste les tiers et leur coût, sans seuil ni échec. Un enregistreur de session peut donc coûter cher sans que le rapport le signale. Seules deux mesures voient le coût réel : le parcours scripté et les données de terrain. Notre article pilier sur l’impact des JavaScript tiers détaille ces méthodes pour l’ensemble des tiers.

Comment mesurer le coût réel du session replay sur votre site ?

Par trois mesures complémentaires, de la plus rapide à la plus probante : le blocage du domaine en laboratoire, le parcours scripté avec attribution par domaine, et la comparaison, dans les données de terrain, des sessions enregistrées et des sessions non enregistrées.

Le blocage de domaine en laboratoire

Bloquer le domaine de l’outil, recharger, comparer : c’est le chiffre qui clôt un débat entre équipes. Dans Chrome, le panneau Réseau permet de bloquer un domaine ; en ligne de commande, Lighthouse accepte l’option --blocked-url-patterns. Un outil à la fois, sur une fiche produit ou un article plutôt que sur l’accueil, et plusieurs passages par variante. La commande ci-dessous a été vérifiée avec Lighthouse 13.5.0 le 15 octobre 2026.

# Lighthouse avec puis sans le domaine de l'outil, extraction des métriques par jq
URL="https://www.exemple.fr/produit/chaise-bois/"
DOMAINE="*hotjar*"   # motif du domaine à bloquer (ex. *clarity.ms*, *contentsquare*)

for variante in avec sans; do
  bloque=""
  [ "$variante" = sans ] && bloque="--blocked-url-patterns=$DOMAINE"
  npx lighthouse "$URL" --quiet --only-categories=performance \
    --output=json --output-path="lh-$variante.json" $bloque
  # variante, TBT (ms), LCP (ms), temps d'exécution JavaScript total (ms)
  jq -r --arg v "$variante" '[$v,
    (.audits["total-blocking-time"].numericValue | round),
    (.audits["largest-contentful-paint"].numericValue | round),
    (.audits["bootup-time"].numericValue | round)] | @tsv' "lh-$variante.json"
done

Cette mesure garde les limites du robot : sans consentement simulé et sans interaction, elle sous-estime le coût. Elle reste utile pour le chargement, et pour vérifier qu’un outil censé attendre le consentement ne se charge pas avant.

Le parcours scripté, avec attribution par domaine

L’API Long Animation Frames, disponible depuis Chrome 123, enregistre chaque frame de plus de 50 ms et attribue son temps aux scripts qui l’ont occupée, avec leur URL d’origine (sourceURL), leur durée et le temps de style et de mise en page forcés (forcedStyleAndLayoutDuration) ; la documentation de Chrome précise que seuls les scripts de plus de 5 ms sont attribués. Regroupé par domaine après un parcours réaliste (consentement donné, défilement, clics, ajout au panier, en émulation mobile), c’est le coût de l’outil pendant une vraie visite.

// Temps de thread principal par domaine tiers, d'après les Long Animation Frames (Chrome 123+).
// À lancer dans la console après un parcours (consentement, clics, défilement).
(() => {
  const tiers = (u) => { try { return new URL(u).hostname !== location.hostname; } catch { return false; } };
  const parDomaine = {};
  for (const f of performance.getEntriesByType('long-animation-frame')) {
    for (const s of f.scripts) {
      if (!tiers(s.sourceURL)) continue;
      const d = (parDomaine[new URL(s.sourceURL).hostname] ??= { frames: 0, execution_ms: 0, style_layout_force_ms: 0 });
      d.frames += 1;
      d.execution_ms += Math.round(s.duration);                               // durée du script dans la frame
      d.style_layout_force_ms += Math.round(s.forcedStyleAndLayoutDuration);  // style et mise en page forcés
    }
  }
  console.table(parDomaine);
})();

Vérifié le 15 octobre 2026 dans Chromium 141 sur un banc local, avec un script d’une autre origine qui ajoute 120 ms de travail à chaque clic : 627 ms attribués à son domaine sur 6 frames, après cinq clics. Deux limites : le tampon du navigateur conserve un nombre limité de frames, et les frames de moins de 50 ms ne sont pas enregistrées. Le chiffre est donc un minimum ; il se compare d’une variante à l’autre, avec et sans l’outil, sur le même parcours.

Résultats de l’agence du 15 octobre 2026, sur un article de site média où Clarity puis Contentsquare ont été injectés par le banc : 20 passages avec l’outil et 20 sans, en alternance, Chrome 155 en émulation Moto G Power, processeur ralenti quatre fois, 4G lente. Le tableau donne les médianes, avec le minimum et le maximum entre crochets ; aucun style ni mise en page forcés par l’un ou l’autre outil.

Mesure	Clarity	Contentsquare
Script de l’outil dans les frames longues	68,5 ms [65, 76]	55,5 ms [49, 106]
Octets reçus de l’outil	28,7 Ko	164,9 Ko
Envois de données en 30 s de visite	5	2 [2, 5]
INP de laboratoire, avec l’outil	72 ms [72, 88]	88 ms [72, 184]
INP de laboratoire, outil bloqué	72 ms [72, 88]	72 ms [72, 88]

Clarity coûte peu, mais à chaque passage ; Contentsquare télécharge près de six fois plus et tombe parfois sur une interaction. L’INP du laboratoire avance par pas de 8 ms, l’arrondi de l’Event Timing : 72 et 88 ms sont deux pas voisins. Ces chiffres sont des minimums : sur une page de banc animée, Clarity a consommé environ 145 ms de processeur en 30 s sans produire une seule frame longue, un travail que seul le profileur voit.

Le terrain : sessions enregistrées contre sessions non enregistrées

La mesure la plus probante ne demande aucun test A/B à monter. Quand l’outil n’enregistre qu’une partie des sessions, tirée au hasard, le site dispose d’une expérience naturelle : deux groupes de visiteurs comparables, l’un enregistré, l’autre non. Il suffit que la mesure de terrain (le RUM, pour Real User Monitoring) porte un drapeau indiquant si la session est enregistrée, puis de comparer l’INP des deux groupes au 75e percentile, le seuil retenu par les Core Web Vitals. L’écart entre les deux groupes est le coût réel de l’outil, sur vos visiteurs et vos appareils.

Trois conditions rendent la comparaison valable. Le tirage au sort doit précéder le chargement de l’outil, et ne dépendre ni de la page ni de l’appareil ; le chargeur conditionnel présenté plus bas le fait. Les deux groupes se comparent page par page, ou gabarit par gabarit, sur la même période. Et chaque groupe doit compter assez de mesures pour que le 75e percentile soit stable : convention de l’agence, au moins 1 000 mesures d’INP par groupe et par gabarit avant de conclure.

Ce volume suppose plusieurs milliers de pages vues par jour sur le gabarit étudié, et un consentement recueilli par une CMP : seules les sessions avec consentement peuvent être enregistrées, donc seules elles se comparent. La mesure ci-dessous transmet les deux drapeaux. En dessous de ce trafic, les mesures de laboratoire donnent l’ordre de grandeur.

// Mesure de terrain : chaque INP part avec un drapeau « session enregistrée ».
// web-vitals 6 (npm), window.awpReplay et window.awpConsentement posés par le chargeur et la CMP.
import { onINP } from 'web-vitals';

onINP((mesure) => {
  navigator.sendBeacon('/rum', JSON.stringify({
    inp: Math.round(mesure.value),
    replay: window.awpReplay === true,   // groupe enregistré ou non
    consentement: window.awpConsentement?.mesure === true,   // seules ces sessions se comparent
    page: location.pathname,             // comparaison gabarit par gabarit
  }));
});

Votre site est-il aussi rapide que vos visiteurs l’espèrent ?

Découvrez comment nous pouvons vous accompagner

Hotjar, Clarity, Contentsquare : quelles différences pour la performance ?

À fonction égale, les écarts tiennent au mode de chargement, à l’échantillonnage et à la gestion du consentement. Le temps d’exécution publié par third-party-web situe les outils les uns par rapport aux autres ; le réglage fait sur votre site pèse davantage que le choix de l’éditeur.

Les trois outils comparés

Hotjar appartient au groupe Contentsquare : depuis le 1er juillet 2025, la société Hotjar a fusionné dans le groupe, et ses outils (heatmaps, enregistrements, sondages) sont proposés dans la plateforme Contentsquare, avec des offres Free, Growth, Pro et Enterprise. Le tableau ci-dessous reprend les documentations des éditeurs, consultées le 15 octobre 2026 ; la dernière colonne date et pondère chaque moyenne.

Outil	Modèle	Échantillonnage documenté	Consentement	Masquage et exclusion	third-party-web (jeu du 1er mars 2026)	Banc agence (15 octobre 2026)
Microsoft Clarity	Gratuit	Suivi de toutes les sessions, enregistrement plafonné à 100 000 sessions par projet et par jour	Signal exigé dans l’EEE, au Royaume-Uni et en Suisse depuis le 31 octobre 2025	Mode « Balanced » par défaut, data-clarity-mask, data-clarity-unmask	405 ms par page, 1 226 624 pages	68,5 ms, 28,7 Ko
Hotjar (groupe Contentsquare)	Gratuit et payant	Non documenté dans les pages consultées	À intégrer à la CMP	Saisies masquées par défaut, data-hj-allow pour les autoriser	732 ms par page, 504 590 pages	Non mesuré
Contentsquare	Payant (offre gratuite annoncée)	Taux de collecte réglable, selon l’offre ; décidé dans le navigateur, après le téléchargement (mesure agence)	À intégrer à la CMP	Saisies masquées dans le navigateur, data-cs-mask, data-cs-capture	Absent du jeu sous un domaine propre	55,5 ms, 164,9 Ko

Le cas Clarity et le consentement

Microsoft Clarity exige depuis le 31 octobre 2025 un signal de consentement pour les visites venues de l’Espace économique européen, du Royaume-Uni et de la Suisse. Sans consentement, l’outil ne pose aucun cookie, se charge et ne collecte que des données sans cookie ; Microsoft prévient que les fonctions qui en dépendent, dont les enregistrements de session, peuvent être limitées. Le script se charge donc quand même : sur ces visites, son coût de chargement demeure, pour un service réduit.

Sa foire aux questions affirme que le script, asynchrone, n’a aucun effet sur la vitesse du site. L’argument confond chargement et exécution : un script asynchrone ne bloque pas l’analyse du HTML, mais il s’exécute ensuite sur le fil principal, comme tous les autres. Le chiffre de third-party-web, mesuré sans interaction, montre à lui seul que l’exécution a un coût.

Sur notre banc, Clarity a classé les sessions automatisées parmi les robots et les a exclues de l’interface, alors que chacune avait téléchargé 29 Ko, exécuté 65 à 76 ms de script et fait 5 envois. Un tri côté serveur laisse entier le coût côté navigateur, pour les robots comme pour les visiteurs.

Comment réduire l’impact du session replay sans renoncer à l’outil ?

En bornant l’outil dans le temps, en le ciblant sur les gabarits utiles, en échantillonnant avant tout téléchargement, et en le chargeant après le consentement et la première interaction. Ensemble, ces quatre réglages ramènent le coût à une fraction des sessions, sur une fraction des pages, pendant une période définie.

Une campagne plutôt qu’un abonnement permanent

Un enregistreur sert à répondre à une question : pourquoi les visiteurs abandonnent-ils à l’étape de livraison, que font-ils sur la nouvelle page de destination, où bloquent-ils dans le formulaire ? Activé deux à quatre semaines autour de cette question, puis retiré, il produit ses enseignements sans peser sur le reste de l’année. C’est la même logique que celle que nous appliquons aux outils d’A/B testing : une date de fin, inscrite dès l’installation.

Cibler les gabarits utiles

Le tunnel de commande, la page de destination d’une campagne, le formulaire d’inscription : ce sont les pages sur lesquelles une question se pose. Les articles de blog, les mentions légales et la page d’accueil n’ont que rarement besoin d’être enregistrés. Les outils proposent des règles de ciblage par URL dans leur interface ; elles décident de ce qui est enregistré, souvent après le téléchargement du script. Le ciblage dans le code, avant tout chargement, est le seul qui supprime aussi le coût.

Échantillonner avant le téléchargement

Un taux d’échantillonnage réglé dans l’interface de l’outil peut être décidé après le téléchargement et l’exécution du script complet. Mesuré le 15 octobre 2026 avec Contentsquare, sur 10 sessions neuves par variante : une session non retenue télécharge 187 Ko et exécute 113 ms de script, contre 116,5 ms pour une session enregistrée ; seuls les envois disparaissent.

Le tirage au sort doit se faire dans votre code, avant d’insérer la balise de l’outil. Il sert en même temps à la mesure de terrain décrite plus haut, puisque le drapeau « session enregistrée » est le résultat de ce tirage.

Charger après le consentement et la première interaction

Le consentement est un préalable juridique ; la première interaction est un choix de performance. Attendre un clic, une touche ou un premier défilement, avec un délai maximal pour ne pas perdre le début des sessions, sort l’outil de la phase de chargement. Le déclenchement par le défilement se fait sur le premier événement seulement : un observateur continu de défilement déplacerait le pic de travail dans la fenêtre de l’INP. Le chargeur ci-dessous réunit les quatre conditions ; il a été testé le 15 octobre 2026 dans Chromium 141, avec un faux tag d’éditeur.

// Charge l'outil d'enregistrement de session seulement si quatre conditions sont réunies :
// gabarit ciblé, session tirée au sort, consentement donné, première interaction (ou délai plafonné).
(function () {
  const GABARITS = ['/panier/', '/commande/', '/inscription/']; // pages sur lesquelles une question est posée
  const TAUX = 0.2;                                             // part des sessions enregistrées
  const PLAFOND_MS = 8000;                                      // chargement au plus tard 8 s après le consentement
  const SCRIPT = 'https://outil-replay.example/tag.js';         // URL du tag de l'éditeur

  if (!GABARITS.some((g) => location.pathname.startsWith(g))) return;

  // Tirage au sort AVANT tout téléchargement, mémorisé pour la session (onglet).
  let tirage = null;
  try { tirage = sessionStorage.getItem('awp-replay'); } catch (e) {}
  if (tirage === null) {
    tirage = Math.random() < TAUX ? '1' : '0';
    try { sessionStorage.setItem('awp-replay', tirage); } catch (e) {}
  }
  window.awpReplay = tirage === '1';                            // relu par la mesure de terrain
  if (!window.awpReplay) return;

  let charge = false;
  function charger() {
    if (charge) return;
    charge = true;
    ['pointerdown', 'keydown', 'scroll'].forEach((t) => removeEventListener(t, charger, true));
    const s = document.createElement('script');
    s.src = SCRIPT;
    s.async = true;
    document.head.append(s);
  }

  function apresConsentement() {
    // Première interaction : clic, touche ou défilement, une seule fois.
    ['pointerdown', 'keydown', 'scroll'].forEach((t) => addEventListener(t, charger, { capture: true, once: true, passive: true }));
    setTimeout(charger, PLAFOND_MS);
  }

  // À adapter à la CMP : ici, un événement « awp:consentement » émis avec { mesure: true }.
  if (window.awpConsentement && window.awpConsentement.mesure) apresConsentement();
  else addEventListener('awp:consentement', (e) => { if (e.detail && e.detail.mesure) apresConsentement(); }, { once: true });
})();

Résultats du test : aucun chargement sur un gabarit non ciblé, aucun pour une session non tirée, aucun sans consentement ; chargement au premier clic après consentement, ou au bout de 8 secondes sans interaction. Sur un site dont le gestionnaire de balises charge l’outil, le même raisonnement s’applique au déclencheur de la balise, avec les précautions décrites dans notre article sur Google Tag Manager : la CMP elle-même ne se diffère jamais.

Exclure les zones très dynamiques

Un carrousel, un fil d’actualité qui se rafraîchit ou un widget de chat produisent des mutations en continu.

Les éditeurs proposent des attributs de masquage (data-cs-mask chez Contentsquare, data-clarity-mask chez Clarity), conçus pour la confidentialité : ils retirent le contenu de l’enregistrement, et rien dans leur documentation ne garantit qu’ils suppriment l’observation de la zone. rrweb, lui, propose une classe de blocage (rr-block) qui remplace l’élément par un espace vide de mêmes dimensions.

Mesuré le 15 octobre 2026 sur un carrousel qui change toutes les 500 ms : l’attribut de masquage de Clarity laisse le travail de l’outil intact, environ 145 ms de processeur pour 30 s de page avec ou sans masque, alors que la classe rr-block de rrweb le réduit d’un tiers et divise par 14 le volume enregistré. Masquer protège la vie privée ; seul exclure allège.

Le banc n’a pas permis de conclure pour data-cs-mask. Pour un autre outil, la vérification se fait au profileur du panneau Performance, zone masquée puis non masquée : ce travail, découpé en tâches courtes, échappe aux Long Animation Frames.

Un seul outil à la fois

Deux enregistreurs sur la même page observent les mêmes mutations, sérialisent le même DOM et envoient deux flux. Le cas se rencontre plus souvent qu’on ne le croit, notamment quand un outil a été remplacé sans que l’ancien soit retiré, ou quand une heatmap et un enregistreur viennent d’éditeurs différents. La même discipline vaut pour les autres widgets, comme le montre notre article sur les widgets de relation client : un inventaire des tiers, un propriétaire par outil.

Le session replay est-il compatible avec le RGPD ?

Il suppose le consentement des visiteurs. La CNIL a publié en février 2026 un projet de recommandation consacré aux outils de session replay, qui confirme ce principe, demande un masquage des saisies par défaut et recommande l’échantillonnage. Ce qui suit est un repère de lecture : seul un juriste tranche un cas précis.

Le projet de recommandation, soumis à consultation publique jusqu’au 22 avril 2026, indique que les finalités poursuivies par ces outils sont soumises au consentement préalable des utilisateurs.

Il recommande un masquage appliqué par défaut à toutes les catégories de données, l’absence de collecte des mots de passe et des coordonnées bancaires, une durée de conservation limitée selon la finalité, l’échantillonnage aléatoire des sessions et le recours à des outils moins intrusifs quand ils suffisent. Ses recommandations de minimisation rejoignent celles de la performance : moins de sessions, moins de données, moins de coût. Notre guide des CMP traite du consentement côté performance, et notre article sur Google Analytics des outils de mesure d’audience.

Faut-il garder un outil de session replay ?

Oui, quand quelqu’un regarde les enregistrements et en tire des décisions ; sinon, il se retire. Un enregistreur que personne ne consulte coûte à chaque visiteur, sur chaque page, pour un bénéfice nul, et cette situation est la plus fréquente que nous rencontrions en audit.

La gouvernance tient en trois règles, à poser le jour de l’installation. Un propriétaire nommé, qui consulte les enregistrements et rend compte de ce qu’il en tire. Une question écrite, qui justifie l’outil et définit les gabarits enregistrés. Une date de retrait, au terme de la campagne, sauf décision explicite de prolonger. Le nombre de domaines tiers d’une page fait un bon indicateur de suivi : un domaine de plus sans propriétaire signale une dérive, ce que repère un monitoring de performance.

Chiffrer le coût réel de l’outil sur votre site, par le parcours scripté et la comparaison de terrain, puis décider s’il reste, sur quelles pages et pour combien de temps, c’est l’objet d’un audit de performance. La question du début en devient le critère de décision : combien d’enregistrements ont été visionnés, et qu’ont-ils changé ?