Rejeu de session : quand une application enregistre l’écran de ses utilisateurs

Ce qu’un outil de rejeu de session enregistre dans une application

Un outil de mesure d’audience classique compte des écrans et des événements. Un outil de rejeu de session, lui, reconstitue la session pour la revoir. La CNIL en donne la portée : au-delà de la collecte d’informations sur les pages ou écrans visités, il permet « de visionner l’ensemble des actions de navigation, telles que les mouvements de souris, clics ou interactions tactiles, défilement des pages, saisies de l’utilisateur et autres interactions ». Dans une application, cela veut dire les appuis, les balayages, le texte tapé dans les champs et ce qui s’affiche à l’écran au moment où l’utilisateur agit.

Deux risques, écrit la CNIL. D’une part, un suivi permanent de la navigation, qui donne des informations précises sur la vie privée des personnes, leurs habitudes, leurs centres d’intérêt, parfois des données sensibles. D’autre part, une collecte excessive, au-delà de ce qu’exige la finalité d’origine. Le niveau de risque dépend de la nature du service : une application de santé ou de rencontre n’expose pas ce qu’expose un jeu. La CNIL avait déjà posé le cadre du terrain mobile dans sa recommandation sur les applications mobiles ; le rejeu de session en est un cas particulièrement intrusif.

Un enregistrement, donc un consentement préalable

La CNIL rattache ces outils à l’article 82 de la loi Informatique et Libertés, qui transpose l’article 5.3 de la directive ePrivacy et gouverne toute lecture ou écriture d’information dans le terminal d’un utilisateur. La conséquence est directe : « les finalités poursuivies par le déploiement des outils de rejeu de session sont soumises au consentement préalable des utilisateurs », parce que l’enregistrement n’a pas pour finalité la communication et n’est pas strictement nécessaire au service, que l’éditeur pourrait rendre sans lui.

Encore faut-il savoir pourquoi on enregistre. La recommandation retient trois finalités : détecter et comprendre des erreurs techniques, améliorer l’expérience utilisateur, et traiter les demandes du support client. Elles doivent être « déterminées, explicites et légitimes », définies avant le déploiement de l’outil, et la CNIL ferme une porte : elles « ne peuvent pas être déterminées postérieurement à la collecte des données, ni dépendre de ce que le responsable du traitement est amené à visualiser grâce à l’outil ». Autrement dit, on ne déploie pas un enregistrement large pour décider ensuite de ce qu’on en fait.

La minimisation va plus loin. Le responsable du traitement doit d’abord « privilégier l’usage d’outils alternatifs, traitant moins de données » lorsqu’ils atteignent le même but. Et la CNIL cite l’usage à exclure : « un outil de rejeu de session ne devrait pas être utilisé à des fins de reciblage publicitaire », des solutions moins intrusives existant pour cela.

Entre l’éditeur et le fournisseur, les rôles sont posés. L’éditeur qui choisit de poser l’outil sur son application en détermine les finalités et les moyens : il en est responsable. Le fournisseur qui se contente de fournir la solution est sous-traitant ; s’il réutilise les données recueillies pour ses propres besoins, par exemple pour améliorer son outil, il devient responsable conjoint des opérations de lecture et d’écriture, dans la ligne de la jurisprudence Fashion ID. Une clause qui ferait porter le recueil du consentement au seul éditeur ne suffit alors pas.

Le masquage par défaut, et ce qui ne doit jamais être collecté

C’est le cœur technique de la recommandation, et c’est là que le mobile change tout. La CNIL demande qu’un « outil de masquage » soit « systématiquement mis à disposition », pour retirer de l’enregistrement ce qui n’est pas nécessaire : les images, les formulaires, les champs de texte, les champs remplis dynamiquement (ceux qui contiennent des informations de compte), les mouvements de souris et clics sur des claviers numériques, et le contenu des échanges avec un agent conversationnel. La règle de repli est nette : « en cas d’absence de configuration, le masquage devrait par défaut s’appliquer à toutes les catégories envisagées ». Le masque est posé d’abord ; on le lève écran par écran, pas l’inverse.

Deux fonctions ne souffrent aucune exception. La sécurité du traitement impose le « blocage de la collecte de tout mot de passe, information bancaire, ou autre donnée soumise à des conditions particulières de collecte ». Et au titre de la protection des données par défaut (article 25 du RGPD), la CNIL recommande au fournisseur de « [proposer] toujours le paramétrage par défaut le plus protecteur possible ».

Sur une application, ces exigences se jouent écran par écran. Un champ de saisie oublié, un écran de paiement non masqué, une vue de messagerie laissée visible, et l’enregistrement emporte ce qu’il ne devrait jamais voir, sans que rien ne l’annonce à l’éditeur. La recommandation ajoute des garde-fous sur la durée, de quelques heures pour le support à quelques mois pour la détection d’erreurs, et sur les identifiants, tirés au hasard par session, pseudonymisés par hachage ou limités à un domaine, pour éviter de relier entre elles les sessions d’une même personne.

L’information, dès le premier niveau de la bannière

L’information conditionne la validité du consentement, et la CNIL y insiste parce que ces outils restent mal connus : « les utilisateurs de sites web ou d’applications mobiles ont une faible connaissance de leur existence et de leur fonctionnement ». Elle recommande donc « une information spécifique concernant les outils de rejeu de session dès le premier niveau » de la plateforme de gestion du consentement : une mention courte et explicite, présentée à part des finalités, renvoyant à un descriptif plus détaillé.

Dans une application, cela suppose que la bannière déjà en place soit mise à jour, et que le retrait du consentement soit aussi simple que son recueil. Surtout, le retrait doit être effectif : « les opérations de lecture et d’écriture ne peuvent plus intervenir postérieurement au retrait du consentement de l’utilisateur ». Un enregistrement qui se poursuit après un refus ou un retrait est précisément le défaut que la CNIL a sanctionné ailleurs, sur une application dont un traceur restait actif après « Continuer sans accepter ».

Pourquoi une application est plus difficile à vérifier

Sur le web, une partie de tout cela s’inspecte depuis un navigateur : on lit le code de la page, on voit les champs marqués comme masqués, on suit dans les outils de développement les requêtes qui partent vers le fournisseur de rejeu. Dans une application, rien de cela n’est à portée. L’outil de rejeu est un composant tiers compilé dans le binaire, son masquage se règle vue par vue dans le code, et ce qu’il envoie part chiffré vers ses serveurs. L’éditeur ne voit ni ce qui est capturé, ni ce qui est masqué, ni le moment où l’enregistrement démarre par rapport au choix de l’utilisateur : c’est, de bout en bout, plus difficile à vérifier que sur le web.

S’ajoute le propre du mobile : une version installée ne se corrige pas à distance. Un masquage ajouté aujourd’hui ne protège que les utilisateurs qui mettront l’application à jour ; les versions déjà sur les téléphones continuent d’enregistrer comme elles ont été compilées. La question n’est donc pas seulement « l’outil est-il bien réglé ? », mais « l’a-t-il été, version après version, et qu’a-t-il réellement envoyé ? ».

Ce que la recommandation demande de vérifier

Pour un DPO, la recommandation se traduit en quelques questions à poser à chaque version d’une application qui embarque un outil de rejeu de session. L’enregistrement démarre-t-il avant tout consentement, ou seulement après ? S’arrête-t-il vraiment après un refus ou un retrait ? Quels serveurs reçoivent les sessions, et qu’emportent-ils ? Les écrans sensibles, champs de saisie, paiement, messagerie, sont-ils masqués, ou laissés visibles par défaut ? Et la bannière mentionne-t-elle l’outil dès le premier niveau ?

Ces questions se répondent sur le téléphone. Skanopy pilote automatiquement l’application Android sur un vrai appareil, accepte ou refuse dans la bannière comme le ferait un utilisateur, puis relève chaque acteur tiers que le téléphone contacte, y compris le serveur d’un outil de rejeu de session, ce qu’il reçoit et à quel moment par rapport au choix. Il lit la chaîne de consentement enregistrée et la confronte aux acteurs réellement contactés, version après version. C’est tout l’objet d’une analyse d’application mobile : elle ne dit pas le droit, elle fournit la pièce datée sur laquelle le droit s’applique.

Sources

Chaque constat de cet article renvoie à l’un de ces documents.

1. Reco ’26Outils de rejeu de session, recommandationCNIL, délibération n° 2026-114 du 8 octobre 2026, publiée le 5 novembre 2026
2. CNIL ’26Outils de rejeu de session : la CNIL publie sa recommandation pour guider les acteursCNIL, 5 novembre 2026
3. Synthèse ’26Synthèse des contributions à la consultation publiqueCNIL, consultation menée entre février et mai 2026
4. LégifranceDélibération n° 2026-114 du 8 octobre 2026 portant adoption d’une recommandation concernant les outils de rejeu de sessionJournal officiel de la République française
5. CNIL ’25Recommandation relative aux applications mobilesCNIL, délibération n° 2025-024 du 27 mars 2025 (version modifiée publiée le 8 avril 2025)
6. CNIL ’20Cookies et autres traceurs : lignes directrices et recommandationCNIL, délibérations n° 2020-091 et n° 2020-092 du 17 septembre 2020