Analyse d’impact relative à la protection des données (art. 35 du RGPD) – MousePlayer Session Replay

1. Pourquoi cette analyse est requise

L’art. 35(1) du RGPD exige une analyse d’impact lorsqu’un type de traitement, en particulier par le recours à de nouvelles technologies et compte tenu de sa nature, de sa portée, de son contexte et de ses finalités, est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes physiques. MousePlayer enregistre le comportement des visiteurs de sites web en continu et par défaut : mouvements du pointeur, clics, défilement, appuis et changements d’onglet, avec un instantané complet de la page vue par le visiteur et chacune de ses modifications ultérieures, ainsi que le texte que le visiteur saisit dans les formulaires. Les éléments enregistrés sont stockés, relus, notés et peuvent être partagés. Il ne s’agit pas d’un cas marginal de l’art. 35(1) ; il en constitue le cœur.

Un point de qualification doit être énoncé avec précision plutôt que répété. L’art. 35(3) énumère trois cas dans lesquels une AIPD est requise en particulier, et aucun des trois ne correspond exactement. Le point (a) couvre l’évaluation systématique et approfondie fondée sur un traitement automatisé sur la base de laquelle sont prises des décisions produisant des effets juridiques ou affectant de manière similaire de façon significative une personne — l’évaluation existe ici (voir le risque R8), mais aucune décision de ce type visant un visiteur n’a été constatée. Le point (b) couvre le traitement à grande échelle de catégories particulières au titre de l’art. 9 — ce n’est pas l’objectif ici, bien que des catégories particulières parviennent dans l’enregistrement par une voie non intentionnelle (risque R1), et les volumes mesurés sur ce système ne relèvent pas de la grande échelle. Le point (c) couvre la surveillance systématique d’une zone accessible au public à grande échelle, ce qui vise l’observation physique, et non un site web. Invoquer le point (b) comme fondement pour la relecture de sessions serait erroné, et une citation erronée est la première chose qu’une autorité écarte.

Le fondement correct est l’art. 35(1) lui-même, appliqué à travers les neuf critères des lignes directrices du G29 sur l’AIPD (WP248 rev.01, approuvées par le CEPD). Deux critères sont généralement considérés comme indiquant un risque élevé. Ce traitement en remplit six ou sept.

• Évaluation ou notation — rempli. Chaque session reçoit engagement_score (0-255), session_quality et is_bot ; lors du relevé d’août 2026, il existait 4 043 lignes de caractéristiques et 3 203 récits de sessions rédigés par une machine. D’autres scores et éléments déduits ont été ajoutés depuis (voir R8).
• Prise de décisions automatisée avec effet juridique ou similaire — non établie pour les visiteurs. Elle est établie à l’encontre des clients et des adresses IP (auto-ban, is_suspicious), qui constituent un autre groupe de personnes concernées.
• Surveillance systématique — rempli sous sa forme la plus poussée. L’enregistrement est continu, méthodique et invisible pour la personne observée une fois la bannière disparue.
• Données sensibles ou données à caractère hautement personnel — rempli. Saisies dans les formulaires, texte intégral de la page telle qu’elle est rendue pour cet individu, et relevé minute par minute de ce qu’il a lu et de ce qui l’a fait hésiter.
• Grande échelle — non rempli au regard des chiffres mesurés sur ce système de développement (relevé d’août 2026 : 706 sessions, 329 identifiants de visiteurs distincts, 7 projets, 4 comptes. État au 16 octobre 2026 : 8 648 sessions humaines avec 7 363 identifiants de visiteurs distincts depuis le 21 juillet 2026, dont 3 515 identifiants distincts au cours des 30 derniers jours, dans 3 des 75 projets créés ; en outre, 186 163 sessions marquées comme des robots provenant des 14 derniers jours, qui sont supprimées à l’expiration de leur délai ; 24 comptes, dont 19 reconnaissables comme des comptes de test). Il est rempli au regard de l’objectif de conception, et la conception ne comporte aucune limite supérieure.
• Croisement ou combinaison d’ensembles de données — rempli. MousePlayer.setUserId() et le chemin automatique dataLayer 'uid' rattachent l’identifiant propre au client à l’enregistrement ; l’export BigQuery envoie visitor_id, custom_user_id et ip_address dans l’entrepôt de données propre au client.
• Personnes concernées vulnérables — il peut être considéré comme rempli. Le visiteur ne peut pas voir ce qui a été enregistré, ne peut pas le vérifier et, dans 92 cas lors du relevé d’août 2026, ne pouvait pas du tout être relié à ses propres enregistrements (état au 16 octobre 2026 : aucune session de ce type ; voir R9).
• Utilisation innovante — rempli. La relecture du DOM complet combinée à des récits comportementaux générés par une machine n’est pas une technique établie et bien comprise.
• Empêchement de l’exercice d’un droit ou de l’utilisation d’un service — rempli de deux manières limitées : le blocage automatique de l’adresse IP met fin à tout accès ultérieur, et la lacune d’identification (R9) rend les art. 15 et 17 techniquement impossibles à satisfaire pour une partie des données stockées.

L’art. 35(4) oblige chaque autorité de contrôle à publier une liste des opérations de traitement pour lesquelles une AIPD est obligatoire. L’autorité compétente ici est l’UODO polonais. à compléter : quelles entrées de la liste actuelle de l’UODO au titre de l’art. 35(4) s’appliquent à la relecture de sessions, et date de la version de la liste vérifiée

2. Rôles : à qui incombe cette obligation, et pour quoi

MousePlayer occupe deux positions à la fois, et la réponse à presque chaque question de ce document dépend de celle dont il est question. La distinction n’est pas un choix de présentation ; elle est inscrite dans le code. class/Server.class.php:416 l’énonce dans le code source lui-même : « REGEL B ... Hier sind wir AUFTRAGSVERARBEITER » — ici, nous sommes le sous-traitant.

Données	Rôle de MousePlayer	Responsable du traitement	Conséquence
Visiteurs sur les sites web des clients : enregistrements, contenu des pages, saisies dans les formulaires, identifiants, scores déduits	Sous-traitant (art. 28)	Le client de MousePlayer qui exploite le site web	L’obligation prévue à l’art. 35 incombe formellement au client. L’obligation de MousePlayer est de fournir une assistance au titre de l’art. 28(3)(f).
Les propres clients de MousePlayer : comptes, facturation, assistance, journaux d’accès au portail, piste d’audit	Responsable du traitement (art. 24)	LW IT Solutions Company Lukas Wójcik	MousePlayer est tenu en son nom propre à l’analyse prévue à l’art. 35 pour ce traitement — bien que cette partie, à elle seule, n’en déclencherait pas une.

Cela produit un résultat qui mérite d’être énoncé clairement, car il est fréquemment mal compris dans les deux sens. Le traitement qui requiert une AIPD est celui pour lequel MousePlayer n’est pas le responsable du traitement. Un sous-traitant ne peut pas effectuer à sa place l’analyse du responsable du traitement, ne peut pas trancher pour lui la question de la nécessité et ne peut pas consulter à sa place l’autorité de contrôle au titre de l’art. 36. Ce qu’un sous-traitant peut et doit faire, c’est fournir au responsable du traitement tout ce dont celui-ci a besoin — la description au titre du point (a), les faits mesurés au titre du point (c), et une liste sincère des états d’avancement au titre du point (d). Voilà ce qu’est ce document : la propre analyse de MousePlayer sur ses propres opérations, et le socle factuel dont le client a besoin pour la sienne.

3. Délégué à la protection des données : le test de l’art. 37

Aucun délégué à la protection des données n’est désigné. L’art. 37(1) lie aussi bien « le responsable du traitement et le sous-traitant » ; la question appartient donc à MousePlayer lui-même et ne peut pas être renvoyée aux clients. Les trois cas prévus par la loi :

Art. 37(1)	Test	Résultat au regard des faits mesurés
(a)	Traitement par une autorité publique ou un organisme public	Sans objet. LW IT Solutions Company est une entreprise privée.
(b)	Les activités de base exigent un suivi régulier et systématique à grande échelle des personnes concernées	Activité de base : oui, sans discussion — le suivi est le produit, et non une fonction de soutien. Régulier et systématique : oui — continu, méthodique, selon un système organisé à l’avance. Grande échelle : non, au regard des chiffres mesurés (relevé d’août 2026 : 706 sessions, 329 identifiants, 4 comptes ; état au 16 octobre 2026 : 3 515 identifiants distincts de visiteurs humains en 30 jours ; une instance de développement).
(c)	Les activités de base consistent en un traitement à grande échelle de données relevant de l’art. 9 ou de l’art. 10	Ce n’est pas prévu par la conception. Des catégories particulières entrent néanmoins dans le contenu des pages stocké par la voie décrite au risque R1. Cela est accessoire plutôt que constitutif ; le cas n’est donc pas établi aujourd’hui — mais il devient défendable dès qu’un client du secteur de la santé, du droit ou de la finance est accueilli.

WP243 (approuvé par le CEPD) évalue la « grande échelle » au regard du nombre de personnes concernées, du volume et de l’éventail des données, de la durée et de l’étendue géographique. Trois de ces quatre facteurs sont déjà à leur maximum ici : l’éventail est une reconstitution complète de la session de l’individu, la durée est continue et l’étendue géographique correspond aux publics des clients, quels qu’ils soient. Seul l’effectif est faible. Pour que le seuil ne soit pas remarqué trop tard, srv/cron_status.php compte une fois par jour, depuis le 19 août 2026, les identifiants distincts de visiteurs humains des 30 derniers jours (hors 'unknown' et sessions marquées comme des robots), compare le chiffre au seuil de 100000 utilisateurs finaux par mois, et signale par e-mail tout dépassement ainsi que l’échéance de l’examen annuel. État au 16 octobre 2026 : 3 515.

Deux conséquences en découlent, et toutes deux sont des recommandations plutôt que des énoncés du droit. Premièrement, consigner dès maintenant une évaluation écrite du seuil, avec un nombre indiqué d’utilisateurs finaux suivis à partir duquel la désignation intervient automatiquement et un intervalle d’examen fixe — afin que la décision soit documentée comme ayant été prise, et non simplement comme n’ayant pas encore été prise. Deuxièmement, noter que l’art. 37(4) permet au droit des États membres d’exiger une désignation dans d’autres cas. à compléter : confirmation juridique quant à savoir si le droit polonais au titre de l’art. 37(4) crée une obligation de désignation au-delà de l’art. 37(1). Le seuil et l’intervalle d’examen sont décidés : plus de 100000 utilisateurs finaux observés par mois, au moins une fois par an

L’art. 35(2) exige que le responsable du traitement demande conseil au délégué à la protection des données, lorsqu’il est désigné, pour la réalisation d’une AIPD. Aucun délégué n’étant désigné, cette étape est sans objet et son omission ne constitue pas un défaut. Approuvé par Lukas Wójcik, propriétaire, le 17 août 2026. Aucun conseil externe en matière de protection des données n’a été obtenu. Réexaminé chaque année et à chaque modification du traitement ; les versions datées sont conservées dans le système de gestion des versions sous ai/cms/.

4. Méthode, sources et limites de ce projet

Chaque affirmation factuelle de ce document a été mesurée au regard du système en fonctionnement — code source, schéma de base de données, décomptes de lignes, liste des processus, valeurs de configuration et fichiers journaux — plutôt que reprise de descriptions du produit ou de ce que le logiciel est censé faire. Lorsqu’une mesure contredit une intention, la mesure est rapportée. Lorsqu’un fait n’a pas pu être établi, un espace réservé figure à sa place ; aucun chiffre n’a été estimé et aucune durée de conservation n’a été inventée.

• Le système mesuré est l’instance de développement (APP_ENV=dev). Plusieurs chiffres sont donc des artefacts de données de test et sont signalés comme tels — surtout les enregistrements du consentement, où 671 sessions sur 706 portent consent_source='testdata' avec un horodatage NULL, inscrits par ai/devdata/001_altsitzungen_markieren.sql (relevé d’août 2026 ; état au 16 octobre 2026 : 566 sessions sur 8 648 sessions humaines).
• Certaines mesures ont été effectuées à quelques minutes d’intervalle et diffèrent légèrement en conséquence (705 contre 706 sessions ; 36 409 lignes de journal contre 36 542 adresses vérifiées). Les deux chiffres sont rapportés tels que mesurés, plutôt que rapprochés après coup.
• L’accès au niveau root n’était pas disponible. La configuration des jails fail2ban, les crontabs de root et de www-data, ainsi que l’arrivée de la sauvegarde hors site à destination n’ont donc pas pu être vérifiées. Chacun de ces points est signalé comme non vérifié plutôt que présumé. Ajout depuis lors : l’exploitant a entre-temps effectué le basculement de la sauvegarde avec les droits root, et l’arrivée de la sauvegarde hors site à destination est attestée depuis le 11 août 2026, car l’exécution quotidienne la journalise et la vérifie elle-même — elle est consignée pour les 11 et 12 août 2026 (voir R5). Nouvelle vérification le 16 octobre 2026 : fail2ban exécute neuf jails, dont mp-nginx-429 pour les adresses qui déclenchent de façon répétée la limitation de débit nginx. Les exécutions planifiées de MousePlayer figurent dans /etc/cron.d/mouseplayer et passent par srv/cron_run.sh sous le compte dédié mouseplayer-dev ; les services workers s’exécutent également sous ce compte. La sauvegarde quotidienne est toujours lancée depuis le cron de root, et la suppression quotidienne s’exécute toujours à l’intérieur du processus db_worker.
• Les répertoires des fournisseurs (Stripe SDK, Google Cloud SDK, PHPMailer, Symfony) n’ont pas été examinés à la recherche de points de terminaison sortants. Le code propre au produit a été recherché exhaustivement pour curl_init, curl_exec, file_get_contents sur http, fsockopen et stream_context_create, ainsi que pour tous les littéraux https.
• Un chiffre de cette analyse — 92 sessions avec visitor_id 'unknown' — a été repris comme mesure établie lors du relevé d’août 2026, car il ne pouvait pas être mesuré à nouveau à l’époque. Nouvelle mesure le 16 octobre 2026 : plus aucune session ne porte visitor_id 'unknown'. Le code peut encore écrire cette valeur lors de la création d’une session (srv/db_worker.php) ; R9 reste donc possible.

5. (a) Description systématique des opérations de traitement et des finalités

5.1 Fonctionnement de l’enregistrement

Le client intègre un fichier JavaScript statique (www/mp.js) à son site web. Avant tout enregistrement, deux verrous doivent être levés. Une vérification des robots s’exécute en premier et interrompt le processus pour les navigateurs automatisés. Derrière elle se trouve la machine à états du consentement mpEinw, qui n’autorise la construction du traceur qu’en présence d’un signal positif de consentement — provenant de l’appel API propre au client, de Google Consent Mode, d’une CMP prise en charge ou d’une chaîne TCF. Toute autre issue, y compris l’absence totale de signal, une CMP qui ne se charge pas, une erreur de script et une origine inconnue, conduit à l’absence d’enregistrement. Le principe directeur est consigné dans les propres notes de travail du projet et s’applique dans tout le code : en cas de doute, ne pas enregistrer.

Une fois autorisé, le script ouvre un WebSocket chiffré (/mp_wss/) vers le serveur d’enregistrement. Le chiffrement TLS se termine dans nginx ; le serveur WebSocket lui-même (srv/server.php) n’écoute que sur l’adresse de bouclage 127.0.0.1:8081 et reçoit de là la connexion sans chiffrement au sein de la même machine. Le serveur applique une deuxième fois le verrou, indépendamment du navigateur : class/Server.class.php:977-1004 n’admet que GRANTED ou GRANTED_LATE, ou une exemption régionale explicite, et ferme la connexion avec le code 1008 en cas de retrait, de pays inconnu et de toute situation peu claire. Une liste d’exclusion de chemins s’exécute avant cela, avec une correspondance sur le chemin uniquement plutôt que sur l’URL complète. Si le WebSocket ne peut pas être établi trois fois de suite (un proxy ou un pare-feu bloquant la négociation), le script envoie à la place les mêmes messages par HTTPS POST à /mp_wst ; ce point de terminaison ne décide de rien et les transmet au même processus serveur, où ils passent par le même verrou (www/api/ws_tunnel.php, class/HttpTunnel.class.php). Un instantané de page supérieur à 1 MB est téléversé par le script par HTTPS POST vers /mp_dom (www/api/dom_upload.php) ; ce point de terminaison vérifie un jeton d’accès à durée limitée signé par le serveur, conserve l’instantané dans Redis pendant au plus 120 secondes et ne décide de rien d’autre — il est récupéré par la même connexion qui a déjà franchi les verrous. De plus, /mp_wsfail compte les connexions WebSocket échouées par projet, sans identifiant de visiteur ; l’adresse IP n’y est utilisée que sous forme d’empreinte pour la déduplication et expire après une heure. Les événements passent en file d’attente par Redis et sont écrits dans MariaDB par un worker de longue durée (srv/db_worker.php).

Ce qui est stocké n’est pas une vidéo. C’est la page elle-même : une copie sérialisée du DOM au moment de la page vue, plus chacune de ses modifications ultérieures, relue ensuite dans une iframe avec les positions enregistrées du pointeur dessinées en surimpression. Cette distinction compte pour l’évaluation des risques, car elle signifie que les éléments stockés contiennent tout ce que contenait la page — y compris du texte que le visiteur n’a jamais saisi et n’a jamais considéré comme des « données ».

5.2 Registre des opérations de traitement

Finalité	Rôle	Tables principales	Effacement (état au 23 septembre 2026)
Enregistrement du comportement : mouvements, clics, défilement, appuis, changements d’onglet	Sous-traitant	mouse_events (225 892 lignes, 322,6 MB), session_pageviews, visitor_sessions	Purge quotidienne selon le forfait, surveillée (voir R7)
Contenu des pages : instantané du DOM et mutations en direct, pour relire la page telle qu’elle a été vue	Sous-traitant	session_pageviews.payload_blob (1 848 lignes, 162,9 MB), mouse_events.target_selector pour les mutations (66 153 lignes)	Même purge
Saisies dans les formulaires, caractère par caractère, masquées selon le niveau configuré	Sous-traitant	mouse_events.target_selector pour les événements de saisie (599 lignes)	Même purge ; pour les 173 lignes héritées, voir R2
Reconnaissance du même visiteur entre les sessions et les pages vues	Sous-traitant	visitor_sessions.visitor_id / custom_user_id, visitor_nicknames (329 lignes)	visitor_nicknames : avec la dernière session du visiteur
Détermination du réseau et de la localisation approximative	Sous-traitant	visitor_sessions.ip_address, country, city, asn_number, asn_org ; ip_lifetime_stats (446 lignes)	ip_lifetime_stats : 365 jours
Preuve du consentement et de ses modifications (art. 7(1))	Sous-traitant, conservation pour la charge de la preuve incombant au client	consent_events (120 lignes), visitor_sessions.consent_*	730 jours à compter de the withdrawal ; conservés intentionnellement jusque-là, car ils constituent la preuve du retrait du consentement
Événements personnalisés, signaux de frustration, erreurs JavaScript	Sous-traitant	session_custom_events (823), session_custom_event_params (1 264)	Même purge
Caractéristiques déduites et récits de sessions rédigés par une machine	Sous-traitant	ai_session_features (4 043), ai_timelines (3 203 lignes, 5,5 MB)	Avec la session, dans la même chaîne de suppression
Gestion des propres comptes clients de MousePlayer	Responsable du traitement	users (4), user_ip_history (5), workspace_users, workspace_invites	Avec le compte ; comptes inactifs après 24 mois et un avertissement remis
Journalisation des accès, de la sécurité et des modifications du portail	Responsable du traitement	mouseplayer_logs (36 409), security_access_logs (1 354), audit_logs (666), banned_ips	60 jours / 72 heures / 60 jours / à l’expiration
Demandes d’assistance	Responsable du traitement	support_requests	730 jours
Collaboration sur une relecture : commentaires et liens de partage	Mixte — responsable du traitement pour l’auteur, sous-traitant pour le contenu enregistré	session_comments (12), session_shares (9)	Commentaires avec la session ; liens de partage 90 jours après leur expiration
Acceptation par le client des règles régionales d’enregistrement	Responsable du traitement	consent_region_acceptances (0 lignes)	730 jours

5.3 Base juridique

Pour tout ce qui relève du parcours d’enregistrement, la base est le consentement, et le raisonnement est documenté dans la migration qui a introduit l’architecture du consentement (ai/migrations/018_consent.sql) : l’enregistrement est une observation comportementale au sens du considérant 24 et un accès à l’équipement terminal au titre de la transposition polonaise des règles ePrivacy, il exige un consentement, et l’intérêt légitime ne le justifie pas. Les 7 projets sont tous réglés sur consent_mode='required'. Le coupe-circuit site_settings.consent_gate_active est activé. Cette analyse est correcte et exceptionnellement bien documentée ; elle n’est atténuée nulle part dans le code.

Pour quatre opérations, le code n’énonce aucune base : la gestion des propres comptes de MousePlayer, les journaux d’accès et de sécurité du portail, les demandes d’assistance et les commentaires de relecture. Ce sont les opérations relevant du rôle de responsable du traitement. L’intérêt légitime (art. 6(1)(f)) et l’exécution du contrat (art. 6(1)(b)) sont les candidats évidents, mais une possibilité n’est pas une détermination, et l’art. 6(1)(f) exige une mise en balance documentée. Réponse apportée le 17 août 2026 : données de compte et de facturation, art. 6(1)(b), pour la conservation des factures (c) (cinq ans à compter de la fin de l’année civile au cours de laquelle est tombée l’échéance de paiement de l’impôt). Journaux d’accès, de sécurité et de modifications, ainsi que reCAPTCHA et journaux serveur : (f), finalité de défense contre les abus et de responsabilité ; les mises en balance figurent dans le registre sous B.2 et B.5. Démonstration de la page d’accueil : consentement, (a). Demandes d’assistance : (b) lorsque le demandeur est un Client et que la demande concerne le contrat, sinon (f) (registre, B.3). Les commentaires de relecture et les liens de partage sont traités par MousePlayer sur instruction du Client (registre, A.9).

5.4 Destinataires et transferts vers des pays tiers

Dans le parcours d’enregistrement, aucun appel sortant vers un tiers n’a été constaté. La géolocalisation se résout à partir de fichiers locaux de la base de données MaxMind plutôt que d’un service web — un choix de conception délibéré consigné dans le code, afin qu’aucun tiers ne soit contacté avant l’existence du consentement. Les polices, drapeaux et scripts sont servis localement. C’est un résultat véritablement positif, et il devrait être présenté comme tel.

Destinataire	Ce qui est transféré	État actuel
Le client	Tout ce qui est enregistré, via le tableau de bord et les trois points de terminaison du lecteur	Actif — c’est la finalité
Tout détenteur d’un lien de partage, sans aucune connexion	La relecture complète d’une session	Actif ; état au 16 octobre 2026 : 5 liens de partage créés ; chaque accès est journalisé avec l’heure, l’adresse IP et l’identifiant du navigateur (share_views)
Google Cloud Storage, Varsovie (jusqu’au 5 septembre 2026 : Google Drive, États-Unis)	Une copie complète quotidienne de chaque base de données et de toute l’arborescence web. Jusqu’au 11 août 2026 sans chiffrement. Depuis le 11 août 2026 chiffrée sur notre propre serveur avant son transfert	Actif quotidiennement. Le transfert en clair a pris fin le 11 août 2026 ; les anciens éléments non chiffrés chez Google ont été supprimés le 12 août 2026. Depuis le 5 septembre 2026, compte d’entreprise, région europe-central2 (Varsovie), couvert par le Google Cloud Data Processing Addendum ; les copies sur l’ancien compte Drive ont été supprimées le 6 septembre 2026 — voir le risque R5
Stripe (États-Unis / Irlande)	E-mail, nom, adresse de facturation et données de paiement du client — aucune donnée de visiteur	Uniquement des clés de test ; clés de production vides
Namecheap Private Email (envoi d’e-mails par SMTP)	Adresse du destinataire, objet et contenu des e-mails sortants adressés aux clients et à l’exploitant, tels que confirmation de compte, réinitialisation du mot de passe, invitations, avis de connexion pour de nouveaux appareils, avertissement avant la suppression des comptes inactifs, notifications de modification des documents contractuels, rapport hebdomadaire, réponses de l’assistance, avis sur les marquages et anomalies, et alertes système	Actif depuis le 23 septembre 2026, expéditeur office@mouseplayer.com ; figure parmi les sous-traitants ultérieurs
Telegram (hors UE)	Jusqu’au 11 août 2026 : demandes d’assistance dans leur intégralité, y compris l’adresse IP non tronquée et le texte complet du message. Depuis le 11 août 2026 : une seule phrase fixe — « MousePlayer: es liegt eine neue Supportanfrage vor. » — aucune variable, aucun numéro de dossier, aucun lien ; plus aucune donnée à caractère personnel ne quitte le système par ce canal	Canal toujours actif (jetons définis dans .env), mais depuis le 11 août 2026 ne reçoit pas de données à caractère personnel et n’est donc pas un sous-traitant
Google reCAPTCHA (États-Unis)	Pages de connexion, d’inscription, d’assistance et de facturation	Désactivé sur ce système (APP_ENV=dev) ; actif en production
Google BigQuery (projet propre au client)	session_id, visitor_id, custom_user_id, ip_address, country, referrer, agent utilisateur, taille d’écran, horodatages, type d’appareil	Inactif : désactivé sur les 7 projets, et le processus ne s’exécute pas
URL de webhook définie par le client (destination sans restriction)	Données d’événement et lien direct vers la session dans le lecteur	Inactif : désactivé sur les 7 projets, processus de distribution en cours d’exécution

5.5 Conservation, telle que mesurée plutôt que prévue

Il existe une routine de suppression automatique, et elle s’exécute. Elle se trouve dans le processus worker qui s’exécute en permanence (srv/db_worker.php), s’exécute au démarrage du processus puis une fois par jour calendaire ; le même processus purge toutes les heures les sessions marquées comme des robots dont les délais sont expirés. La suppression n’a pas sa propre entrée cron. Son absence ne passe toutefois plus inaperçue : le worker consigne son résultat, et srv/cron_status.php — un autre processus — l’évalue, signale par e-mail une exécution remontant à plus de 48 heures et inscrit le défaut dans les Urgent Logs de la zone d’administration. Les autres exécutions planifiées figurent dans /etc/cron.d/mouseplayer ; leurs échecs et leurs pauses excessivement longues sont également signalés par le même processus de suivi (état au 16 octobre 2026).

Lors du relevé d’août 2026, la routine n’avait encore rien supprimé : tous les projets appartenaient à un propriétaire bénéficiant du niveau enterprise avec 365 jours de conservation, et la session la plus ancienne avait 20 jours. Au 16 octobre 2026, elle supprime de manière démontrable : les délais des journaux et des éléments déduits prennent effet (l’entrée la plus ancienne d’audit_logs se situe au délai de 60 jours), les sessions marquées comme des robots sont supprimées après 14 jours et leurs enregistrements vidés après leur propre délai (délai en jours : 1). Le délai du niveau de forfait pour les sessions humaines n’a encore atteint aucune session, car les deux projets avec un véritable trafic de visiteurs appartiennent toujours à un propriétaire bénéficiant du niveau enterprise avec 365 jours, et leurs sessions les plus anciennes datent du 21 juillet 2026.

6. (b) Évaluation de la nécessité et de la proportionnalité

La nécessité et la proportionnalité sont évaluées au regard de la finalité déclarée : permettre à l’exploitant d’un site web de comprendre comment les visiteurs utilisent son site, où ils rencontrent des difficultés et pourquoi ils l’abandonnent. Cette finalité est légitime et la technique générale permet de la servir. La question posée par l’art. 35(7)(b) est plus étroite et plus difficile : ce traitement, à ce niveau de détail, est-il nécessaire à cette finalité — et l’intrusion est-elle proportionnée au bénéfice ?

Composant	Nécessaire à la finalité ?	Proportionné tel que construit ?
Mouvements du pointeur, clics, défilement, appuis	Oui. C’est le signal auquel se rapporte la finalité.	Oui.
Structure et mise en page de la page visitée	Oui. Les coordonnées n’ont aucun sens sans la mise en page à laquelle elles se rapportent.	Oui en principe.
L’intégralité du contenu textuel de la page, mot pour mot	Non — pas de manière générale. Comprendre où un visiteur a rencontré des difficultés nécessite la structure et les libellés, et non le contenu personnel qui y est affiché.	Non, dans la construction actuelle. Le masquage doit être demandé pour chaque élément ; par défaut, tout est stocké. Voir R1.
Saisies dans les formulaires	Cela se discute. Savoir qu’un champ a été abandonné est utile ; savoir ce qui y a été saisi est rarement nécessaire.	En partie. Le niveau minimal de masquage est élevé et tous les projets utilisent le niveau le plus strict — mais la conception permet encore des niveaux plus faibles, et le libellé de ce paramètre est inversé (le niveau 0 est le plus strict, l’indication du tableau de bord affirme le contraire).
État des cases à cocher et des boutons radio	Cela se discute.	Non. Ils ne sont jamais masqués, quel que soit le niveau — et une case à cocher peut porter une déclaration de santé, une affiliation politique ou un consentement à une finalité sensible.
Reconnaissance entre les sessions	Oui pour l’analyse des visiteurs récurrents ; pas pour la finalité principale.	Sous conditions. La reconnaissance pseudonyme est proportionnée ; l’identifiant fourni par le client est le point où la proportionnalité s’arrête. Voir R6.
Adresse IP	Oui pour l’attribution d’une localisation approximative (pays ; ville uniquement à partir de l’adresse déjà tronquée) et la défense contre les abus.	Oui, pour l’avenir : l’adresse est tronquée immédiatement après sa lecture, avant qu’un quelconque consommateur ne la voie. Les anciennes données du parcours d’enregistrement ont été nettoyées le 17 août 2026 ; voir R3.
Notation et récits de sessions	Non. Il s’agit de commodités pour le processus d’examen du client.	Contestable, et la partie la moins examinée du système — aucune base juridique n’est énoncée pour elle nulle part dans le code.
Copie complète hors site (auprès d’un fournisseur d’un pays tiers jusqu’au 5 septembre 2026)	Une sauvegarde hors site, oui — elle sert la disponibilité (art. 32(1)(c)). Son périmètre dépasse ce service : elle contient chaque base de données de la machine.	Depuis le 5 septembre 2026, oui, avec une réserve sur le périmètre. La copie est chiffrée avant le transfert et conservée dans une région européenne dans le cadre d’un accord au titre de l’art. 28. Jusqu’au 5 septembre 2026, non : aucun contrat établi, et sans chiffrement jusqu’au 11 août 2026. Voir R5.

S’agissant de la minimisation des données (art. 5(1)(c)), le système présente deux faces opposées. Une minimisation délibérée est visible à plusieurs endroits et est bien justifiée dans le code : les noms de champs sont classifiés plutôt que transmis, parce qu’un nom de champ brut dans une boutique est souvent assez descriptif pour identifier la personne ; la chaîne TCF n’est stockée que sous forme d’empreinte SHA-256 ; la charge utile de relecture est délibérément exclue de l’API publique. À cela s’oppose le choix central de conception de stocker par défaut la page entière mot pour mot, ce qui est l’inverse de la minimisation et n’est compensé par aucun des éléments précédents.

S’agissant de la limitation de la conservation (art. 5(1)(e)), l’évaluation était sans ambiguïté et défavorable jusqu’au 17 août 2026. Treize tables contenant des données à caractère personnel n’avaient aucun délai d’effacement, dont les deux qui contiennent les éléments les plus lisibles : ai_timelines, qui contient chaque session rendue sous forme de prose lisible, et visitor_nicknames. La routine qui existait n’avait jamais été exécutée sur de véritables données. Un concept de conservation qui n’a jamais supprimé un enregistrement est un plan, pas une garantie. Depuis le 17 août 2026 les treize tables ont un délai, la purge supprime de manière démontrable et son absence est signalée (voir R7).

7. (c) Évaluation des risques pour les droits et libertés des personnes concernées

Les risques sont évalués pour la personne concernée, et non pour l’entreprise. La probabilité est qualifiée de faible, possible, probable ou réalisée — ce dernier terme signifie que l’événement n’est pas une prévision, mais un état actuel et mesuré des données. La gravité est qualifiée de limitée, significative, grave ou très grave, selon ce que la personne touchée risque de perdre : pas de l’embarras, mais l’exposition de caractéristiques de santé, financières ou d’autres caractéristiques protégées, la perte de contrôle sur l’identification et l’impossibilité d’exercer un droit.

ID	Risque	Probabilité	Gravité	Niveau
R1	Catégories particulières de données dans le contenu des pages enregistrées	Probable	Très grave	Très élevé
R2	Saisies de formulaires non masquées dans les anciennes données (173 lignes) — évaluation issue du relevé ; les lignes ont été supprimées le 17 août 2026, une réévaluation par le responsable du traitement reste à effectuer	Réalisée	Significative	Élevé
R3	Adresses IP non tronquées dans les anciennes données et les journaux du portail — évaluation issue du relevé ; les anciens éléments ont été tronqués le 17 août 2026 et les journaux du portail sont soumis à des délais depuis lors, une réévaluation reste à effectuer	Réalisée	Significative	Élevé
R4	Les liens de partage exposent une relecture complète sans aucune connexion	Possible	Grave	Élevé
R5	Copie complète quotidienne hors site — sans chiffrement jusqu’au 11 août 2026, chiffrée sur notre propre serveur avant le transfert depuis le 11 août 2026 ; les anciens éléments non chiffrés ont été supprimés chez le fournisseur le 12 août 2026. Depuis le 5 septembre 2026, la copie est conservée dans un bucket Google Cloud Storage de la région europe-central2 (Varsovie) sous un compte d’entreprise, couvert par le Google Cloud Data Processing Addendum ; les copies sur l’ancien compte Drive ont été supprimées le 6 septembre 2026. Le périmètre est inchangé. Si les deux fichiers de clés sont perdus, la sauvegarde est irrécupérable ; des copies imprimées sont conservées dans un coffre-fort	Faible (réévaluée le 17 septembre 2026). Auparavant : transfert en clair jusqu’au 11 août 2026, transfert sans base juridique établie jusqu’au 5 septembre 2026 — tous deux réalisés et terminés	Très grave	Moyen — réévalué le 17 septembre 2026 ; très élevé jusqu’au 5 septembre 2026. La condition issue de l’analyse (suppression des anciens scripts) a été remplie le 16 octobre 2026 ; la réévaluation de R5 relève du responsable du traitement
R6	Reconnaissance entre les sessions et fusion avec les propres enregistrements du client	Probable	Grave	Élevé
R7	Aucun délai d’effacement pour treize tables ; corrigé depuis le 17 août 2026, la purge s’exécute quotidiennement et fait l’objet d’un suivi	Faible (réévaluée le 23 septembre 2026). Jusqu’au 17 août 2026 : réalisée	Grave	Faible — réévalué le 23 septembre 2026 ; élevé jusqu’au 17 août 2026
R8	Notation et classification automatisées de chaque session	Probable	Significative	Moyen
R9	92 sessions inaccessibles par quelque identifiant que ce soit ; aucune voie de la personne à l’enregistrement — évaluation issue du relevé ; état au 16 octobre 2026 : aucune session de ce type, recherche en libre-service depuis le 17 août 2026, une réévaluation reste à effectuer	Réalisée	Significative	Élevé
R10	Aucun chiffrement au repos, aucun TLS vers la base de données, Redis sans protection d’accès (jusqu’au 16 août 2026 ; accès restreint depuis lors, base de données et Redis également accessibles sur le réseau local — une réévaluation reste à effectuer)	Possible	Très grave	Moyen à élevé
R11	Aucun relevé indiquant qui a consulté quel enregistrement	Réalisée	Significative	Moyen à élevé
R12	Qualité de la preuve du consentement ; adaptateurs CMP non testés	Réalisée (données de développement)	Grave	Moyen
R13	Demandes d’assistance envoyées à Telegram avec l’adresse IP non tronquée — jusqu’au 11 août 2026 ; depuis le 11 août 2026, seul un texte de notification fixe sans aucune variable est envoyé. Il reste le stockage local de la demande avec l’adresse e-mail et l’adresse IP dans support_requests ; depuis le 17 août 2026, avec un délai de 730 jours (voir R7)	Transfert : corrigé le 11 août 2026. Stockage local : réalisé	Significative — jusqu’au 11 août 2026 pour le transfert, depuis lors pour le stockage local uniquement	Corrigé le 11 août 2026 en ce qui concerne le transfert ; le stockage local restant est suivi sous R7 (y est évalué comme faible depuis le 23 septembre 2026)
R14	Sortie vers des destinataires choisis par le responsable du traitement lui-même — une demande d’effacement ne leur parvient pas	Possible (selon que le responsable du traitement active ou non une passerelle ; dans les données actuelles : aucune activée)	Substantielle	Moyen

R1 — Catégories particulières de données dans le contenu des pages enregistrées

C’est le risque le plus sérieux du système et le moins visible, car rien à son sujet ne ressemble à un défaut. Le masquage de l’instantané de page fonctionne uniquement à l’intérieur des zones marquées (www/mp.js:3934-3970) : dans un élément portant data-mp-mask ou la classe .mp-masked, chaque caractère autre qu’un espace blanc est remplacé et les attributs ne figurant pas dans une liste de conservation sont définis sur [FILTERED]. Tout le reste est stocké mot pour mot. Le masquage est donc une annotation à activer explicitement que le client doit appliquer, élément par élément, à une page qu’il ne contrôle peut-être pas entièrement.

La conséquence est que la protection couvre ce que le visiteur saisit et non ce que la page lui renvoie. Une page de confirmation d’un cabinet médical affichant un rendez-vous avec une spécialité nommée ; un panier de pharmacie ; un devis d’assurance énumérant des affections préexistantes ; un relevé bancaire ; un résumé de prise en charge d’aide juridique — tous ces éléments sont produits par la page, hors de tout champ de saisie, et tous arrivent dans payload_blob sans modification. Ce n’est pas hypothétique : 1 848 lignes sont renseignées, avec une moyenne de 90,3 kB, et un échantillon confirme que la valeur stockée commence par le document <html> complet. Il en va de même de chaque modification ultérieure de la page, sérialisée sous forme de fragments HTML dans mouse_events.target_selector sur 66 153 lignes de mutations.

Probabilité — Probable. Le mécanisme de protection exige une action délibérée d’une personne autre que celle exposée au risque, stocke tout par défaut et n’a ni détection, ni avertissement, ni rapport indiquant au client que du contenu personnel non masqué est capturé. Rien dans le système n’échantillonne la charge utile stockée à la recherche des motifs qui le révéleraient. La probabilité qu’au moins une page client affiche des données de catégories particulières est proche de un sur toute période d’exploitation significative.

Gravité — Très grave. Les données relevant de l’art. 9(1) bénéficient de la protection la plus élevée, et aucune des exceptions de l’art. 9(2) n’est applicable ici. Le consentement du visiteur à l’enregistrement de sessions n’est pas un consentement explicite au traitement de données de santé, et il ne pourrait pas l’être — ni le visiteur, ni le client, ni MousePlayer ne sait à ce moment-là que de telles données sont capturées. Les éléments sont stockés mot pour mot, peuvent être entièrement relus, sont exportables, sont inclus dans la copie quotidienne hors site (R5) et peuvent être remis à un tiers non identifié au moyen d’un lien de partage (R4).

R2 — Saisies de formulaires non masquées dans les anciennes données

173 lignes de mouse_events contiennent des valeurs saisies dans des formulaires en clair. Elles ont été localisées par une recherche de motif dans la structure stockée ('"v":"' suivi d’un caractère autre que le caractère de masquage), se situent dans la fenêtre du 21 au 27 juillet 2026 et comprennent des saisies telles que le nom complet d’une personne. Les lignes écrites le 10 août 2026 sont masquées, de sorte que le comportement actuel est désormais correct : les 7 projets utilisent smart_masking=0, qui, malgré son libellé, est le paramètre le plus strict et remplace chaque caractère de chaque champ, tandis qu’un niveau minimal inconditionnel remplace les mots de passe et les données de paiement quel que soit le paramètre.

Probabilité — Réalisée. Ce n’est pas une prévision. Les lignes existent actuellement et, parce que mouse_events n’est nettoyée que par la purge liée au niveau de forfait — qui ne supprime rien avant qu’un enregistrement ait 365 jours et n’a jamais été exécutée —, elles resteront au moins jusqu’en juillet 2027 à moins d’être supprimées manuellement. La probabilité de réapparition à l’avenir est faible.

Gravité — Significative. Les échantillons connus sont anodins, mais le contenu des lignes restantes n’a pas été classifié, et les catégories de champs reconnues par le système incluent e-mail, téléphone, paiement, adresse et nom. Il n’a pas été établi si le niveau minimal inconditionnel pour les mots de passe et les paiements était déjà présent pendant cette fenêtre. Effectué le 17 août 2026 : les lignes ont été supprimées sans examen (décision du responsable du traitement). Après mesure, il s’agissait de 174 lignes provenant de 18 sessions d’un seul projet, du 21 juillet au 6 août 2026 ; après l’exécution, il en reste 0. La lacune elle-même avait déjà été corrigée : depuis le 7 août 2026, aucune valeur ne contient de texte en clair. Une deuxième erreur de mesure a failli se produire : le caractère de masquage est l’astérisque, et non la puce — une recherche sur la puce a trouvé 862 lignes dont la correspondance la plus récente datait d’aujourd’hui, donnant ainsi l’impression d’une fuite toujours en cours. Une suppression fondée sur ce nombre aurait emporté 688 lignes correctement masquées.

R3 — Adresses IP non tronquées dans les anciennes données et les journaux du portail

La troncature des adresses IP dans le parcours d’enregistrement est mise en œuvre correctement et au bon endroit : class/Server.class.php:432-435 remplace le dernier octet IPv4 ou le dernier groupe IPv6 immédiatement après la lecture de l’adresse, avant qu’il n’existe un quelconque consommateur de la valeur. Son efficacité est vérifiée pour les nouvelles données — chaque session enregistrée depuis le 7 août 2026 est tronquée. Elle n’est pas rétroactive, et il n’existe aucune routine de reprise des données ; les anciennes données ont été nettoyées à la place une fois, manuellement, le 17 août 2026 — voir la note d’état sous le tableau.

Table	Adresses non tronquées (état lors de l’analyse, avant le 17 août 2026)	Délai d’effacement
visitor_sessions	236 sur 705, datées du 21 juillet au 7 août 2026, adresses publiques complètes	Purge liée au niveau de forfait — jamais exécutée
ip_lifetime_stats	291 sur 446	Aucun nulle part
mouseplayer_logs	Aucune des 36 542 adresses vérifiées n’était tronquée	60 jours
audit_logs	Les 666 lignes	Aucun
user_ip_history	Les 5 lignes	Aucun
security_access_logs	1 004 sur 1 354	72 heures
support_requests	Toutes, et transmises à leur tour — voir R13	Aucun
Journal d’accès Apache	Toutes	14 rotations quotidiennes

Probabilité — Réalisée. Gravité — Significative. Une adresse IP seule constitue une exposition limitée. Dans visitor_sessions, elle n’est pas seule : elle se trouve dans la même ligne que l’enregistrement, reliant ainsi une identité réseau et, à travers elle, un individu à une relecture complète du comportement de cette personne — y compris tout ce qui relève de R1. Les journaux du portail présentent un risque moins aigu, mais sont beaucoup plus volumineux, et ils relèvent du traitement en tant que responsable du traitement, pour lequel MousePlayer répond directement du choix.

Effectué le 17 août 2026 : les anciennes adresses dans audit_logs (681) et user_ip_history (7) ont été tronquées rétroactivement, sous la même forme que celle écrite par l’enregistreur ; il en reste 0. Les délais futurs sont en place depuis le même jour. (décision du responsable du traitement, 17 août 2026)

État au 17 août 2026. Les anciennes données du parcours d’enregistrement sont réglées : après mesure, 267 sur 267 adresses dans ip_lifetime_stats ont été tronquées, ainsi que 881 sur 901 dans visitor_sessions; les 20 restantes portent 0.0.0.0 et proviennent des données de test de l’analyse de formulaires ; ce ne sont donc pas des adresses de visiteurs. Dans les journaux du portail, l’adresse complète reste — délibérément, et depuis le 17 août 2026 avec un délai indiqué : mouseplayer_logs 60 jours, security_access_logs 72 heures, audit_logs 60 jours, user_ip_history 90 jours à compter de la dernière observation d’une adresse (depuis le 24 septembre 2026), support_requests 730 jours. La raison pour laquelle l’adresse complète est nécessaire pour les demandes d’assistance est exposée dans le registre de l’art. 30 sous B.3.

R4 — Les liens de partage exposent une relecture complète sans aucune connexion

Une règle de réécriture dirige /s/<40 hex characters> directement vers le lecteur. Le jeton constitue toute la barrière, et la conception le reconnaît honnêtement : le jeton se compose de 20 octets issus de random_bytes (160 bits, impossible à deviner), les identifiants de canal et de session proviennent exclusivement du jeton plutôt que de la requête, la chaîne de requête restante est remplacée plutôt qu’ignorée, le rôle reste NULL afin que la suppression et le repartage soient impossibles côté serveur, les trois points de terminaison du lecteur sont limités à la session du jeton et les jetons inventés, expirés et révoqués produisent une réponse identique afin que les tentatives de sondage ne révèlent rien. La durée de vie par défaut est de 7 jours, au minimum 1, au maximum 90 ; la révocation existe. C’est un mécanisme soigneusement construit.

L’exposition résiduelle est humaine plutôt que cryptographique, et deux détails de mise en œuvre l’élargissent. Premièrement, la page qui montre l’enregistrement via un lien de partage (player.php en mode partage) porte bien les en-têtes Referrer-Policy: no-referrer et Cache-Control: no-store, mais aucun en-tête X-Robots-Tag ; noindex n’apparaît que dans www/share.php, qui n’est désormais que la page d’erreur, et robots.txt autorise tout (vérifié le 16 octobre 2026). Deuxièmement, depuis le 17 août 2026, le système enregistre chaque accès à un lien de partage — heure, adresse IP non tronquée et identifiant de navigateur dans share_views (voir aussi R11) —, mais cela ne permet pas de déterminer la personne à l’origine de l’accès.

Probabilité — Possible. Le jeton ne sera pas découvert par force brute. Il sera transmis — collé dans un ticket, une discussion de groupe, un fil d’e-mails auquel un destinataire s’ajoute — et il peut fuir par un en-tête Referer. Gravité — Grave : un seul lien expose une session entière à un public illimité et non identifié, y compris tout ce qui relève de R1 et R2, et, après coup, seuls l’adresse et le navigateur depuis lesquels l’accès a eu lieu peuvent être établis (share_views), pas l’identité de la personne qui l’a vue. Une question connexe est consignée comme ouverte dans les propres notes du projet et reste non vérifiée : mesure du 17 août 2026 : la limite de spectateurs n’est pas contournée par les liens de partage — elle ne s’applique pas du tout à eux. Les spectateurs en direct sont comptés au moyen du drapeau IS_LIVE_VIEWER de la connexion WebSocket (class/Server.class.php, zaehleLiveViewers). www/player.php ne contient aucun code WebSocket ; le lecteur ne fait que relire. Un lien de partage mène au lecteur, et non à la vue en direct. Ce qui est véritablement illimité est autre chose : le nombre de personnes qui ouvrent le même lien en même temps. Il n’existe aucune limite à cela et, contrairement à la vue en direct, aucun compteur non plus. Depuis le 17 août 2026, au moins chaque accès est journalisé (share_views, registre B.6), ce qui permet d’établir après coup à quelle fréquence et depuis où un lien a été utilisé.

R5 — Copie complète quotidienne hors site (vers Google Drive jusqu’au 5 septembre 2026, vers Google Cloud Storage à Varsovie depuis lors ; transférée sous forme chiffrée depuis le 11 août 2026 ; anciens éléments supprimés le 12 août 2026)

Ce risque ne figure pas dans la base factuelle technique ; il a été établi à partir du propre fichier des points ouverts du projet et y est documenté en détail. Jusqu’au 11 août 2026 un ancien script de sauvegarde s’exécutait depuis le cron de root à 02:00 chaque jour. Il exécutait mysqldump sur toutes les bases de données et créait une archive tar de toute l’arborescence web, puis téléversait le résultat via rclone vers gdrive:backups/rpi-ls5/daily — sans chiffrement à aucun stade. Localement, le résultat est confirmé à 653 MB de base de données et 678 MB de fichiers par jour. Depuis le 11 août 2026 la ligne cron a été changée : l’exécution quotidienne utilise un nouveau script de sauvegarde conservé dans le projet, qui couvre le même périmètre mais le chiffre sur notre propre serveur avant le transfert (rclone crypt) et écrit dans son propre dossier de destination distinct ; elle est programmée à 03:00. Les noms des fichiers et des répertoires sont eux aussi chiffrés, de sorte que le fournisseur ne conserve que des blocs sans signification. L’exécution du 11 août 2026 a été lancée manuellement et est arrivée à destination (733 MB de base de données, 678 MB de fichiers) ; celle du 12 août 2026 s’est achevée comme prévu à 03:00. Les deux sont journalisées, et la vérification à destination y a trouvé le dump de la base de données avec le même nombre d’octets dans les deux cas.

Ce qui quitte la machine n’est donc pas une sauvegarde des enregistrements de sessions. C’est une copie complète de chaque base de données et de chaque système de l’hôte — y compris les enregistrements avec leurs instantanés du DOM, les 173 saisies de formulaires en clair, les 236 adresses non tronquées et chaque fichier .env avec ses secrets de production. Le périmètre est inchangé ; le chiffrement n’y change rien. Ce qui a changé, c’est la lisibilité chez le fournisseur : jusqu’au 11 août 2026 aucune couche de chiffrement ne précédait le téléversement et le texte en clair arrivait en clair ; depuis le 11 août 2026 le chiffrement a lieu sur notre propre serveur avant toute sortie, et les clés se trouvent dans deux fichiers avec le mode 600 sur ce même serveur — Google ne les possède pas. Les anciens éléments n’étaient pas couverts par cela : le nouveau script ne nettoie que son propre dossier de destination, et le dossier précédent conservait des copies hebdomadaires pendant au plus 364 jours. Il a été supprimé le 12 août 2026 ; il ne reste donc plus chez le fournisseur de copies complètes non chiffrées antérieures au 11 août 2026.

• Le transfert est réel et quotidien. Jusqu’au 11 août 2026 il n’était pas vérifié s’il arrivait à destination : l’exécution utilisait la configuration rclone de root, le script ne journalisait rien et cron rejetait sa sortie. Depuis le 11 août 2026 l’exécution écrit un journal et vérifie elle-même après le transfert si le dump de la base de données est présent à destination avec le nombre d’octets attendu ; pour le 11 août 2026 (manuellement) et le 12 août 2026 (planifiée, à 03:00), les deux sont consignés, chacun avec une vérification réussie. Le fonctionnement quotidien est donc attesté, pas seulement la première tentative. Le risque pour la disponibilité n’est pas réglé par cela, mais déplacé : si les deux fichiers de clés sont perdus, l’intégralité de la sauvegarde hors site est irrécupérable. Une mesure qui supprime la lisibilité chez le fournisseur crée ainsi une nouvelle dépendance à la garde des clés ; en dehors de cette machine, elles sont, selon le responsable du traitement, conservées imprimées dans un coffre-fort (section 8.3). L’exploitant a testé le déchiffrement — c’est sa déclaration, pas une mesure effectuée par ce document.
• Jusqu’au 5 septembre 2026, aucun instrument de transfert n’était établi. La copie était conservée chez Google Drive sous un compte privé (réponse du 17 août 2026), sans possibilité de choisir une région européenne pour les données et sans accord avec un sous-traitant. Depuis le 5 septembre 2026, elle est conservée dans un bucket Google Cloud Storage de la région europe-central2 (Varsovie) sous un compte d’entreprise et est couverte par le Google Cloud Data Processing Addendum ; les copies sur le compte Drive ont été supprimées le 6 septembre 2026.
• L’ancien script constituait une élévation de privilèges. Jusqu’au 11 août 2026 il appartenait à root, était exécuté par le cron de root et son mode de fichier était 777 : quiconque détenait le compte SSH pi avait les droits root à 02:00. Depuis le 11 août 2026 l’exécution quotidienne ne passe plus par ce script ; le transfert vers Google Drive en a été retiré le 9 septembre 2026. Les anciens scripts de sauvegarde ont été supprimés le 16 octobre 2026. La réévaluation de R5 relève du responsable du traitement.
• Jusqu’au 5 septembre 2026, la copie était en dehors de toute instruction du client. L’art. 28(3)(a) exige que le sous-traitant n’agisse que sur des instructions documentées ; une copie quotidienne des enregistrements de visiteurs du client vers un service cloud américain grand public n’était couverte par aucune instruction consignée. Depuis lors, la section 9 de l’accord de traitement des données et la liste des sous-traitants ultérieurs nomment la sauvegarde auprès de Google Cloud Storage.

Remplacé depuis le 5 septembre 2026 (voir ci-dessus) ; conservé ici à titre historique. Réponse du 17 août 2026 : compte privé. Aucune région européenne pour les données ne peut donc être choisie, et il n’existe aucun accord de traitement des données — pour un compte Google privé, les conditions de traitement des données ne sont pas disponibles. Décision du responsable du traitement : la sauvegarde y reste pour le moment. Tests de restauration mensuels à partir de maintenant. Les deux fichiers de clés sont conservés imprimés dans un coffre-fort accessible uniquement au responsable du traitement (déclaration du responsable du traitement, 17 août 2026) ; ils survivent donc à la perte de cette machine.

Mesure du 17 septembre 2026 : la dernière sauvegarde réussie s’est exécutée à 03:30 ce jour-là et a passé la vérification à destination. L’exercice de restauration est prévu chaque mois ; il a réussi avant la suppression des copies Drive le 6 septembre 2026, et aucun mécanisme de surveillance ne rappelle le prochain. Le 7 octobre 2026, une restauration complète des données depuis la sauvegarde cloud vers un environnement distinct a en outre été effectuée (environ 70 minutes ; échantillons de l’archive et de la base de données sans erreur). Depuis le 6 octobre 2026, la sauvegarde quotidienne contient également l’archive des enregistrements (/mnt/mouseplayer-dev-archive) ; elle se trouve sur le même disque que le système. Sauf indication contraire à cet endroit, la liste ci-dessus décrit l’état antérieur au 5 septembre 2026.

R6 — Reconnaissance entre les sessions et fusion avec les propres enregistrements du client

Un identifiant pseudonyme est créé et conservé dans le localStorage du visiteur sous mp_visitor_id. Pris isolément, cela est ordinaire et proportionné pour l’analyse des visiteurs récurrents. Deux mécanismes supplémentaires en changent la nature. MousePlayer.setUserId() permet au client de rattacher son propre identifiant — un nom de connexion, un numéro de client — à l’enregistrement, stocké dans visitor_sessions.custom_user_id avec un index dédié ; et la même valeur est récupérée automatiquement depuis un chemin dataLayer nommé 'uid', sans aucune action délibérée du client. Lorsqu’un gestionnaire de balises publie déjà un identifiant utilisateur, les enregistrements deviennent attribuables à une personne nommée par simple effet de l’installation.

À partir de ce moment, l’enregistrement n’est plus pseudonyme entre les mains du client. Il peut être joint à son CRM, et l’export BigQuery est conçu pour transporter exactement les colonnes qui rendent la jointure triviale : visitor_id, custom_user_id et ip_address sur la même ligne. Cet export est actuellement désactivé sur tous les projets et son processus ne s’exécute pas — la capacité existe, pas l’activité.

Une faiblesse de conception devrait être consignée sans être exagérée. visitor_nicknames porte une contrainte UNIQUE sur visitor_id seul, sans frontière entre locataires — la table est structurellement interprojets. En pratique, l’identifiant se trouve dans localStorage et est donc limité à une origine, de sorte que cela ne crée pas en soi un suivi intersites entre les domaines de différents clients. Il s’agit d’une frontière manquante dans le schéma plutôt que d’une fuite démontrée, et elle devrait être comblée avant tout déploiement où deux projets peuvent partager une origine.

Probabilité — Probable pour la reconnaissance entre les sessions (c’est le comportement par défaut, et 329 identifiants sont enregistrés) ; Possible à probable pour l’identification, compte tenu du chemin automatique dataLayer. Gravité — Grave : l’identification supprime le facteur d’atténuation qui rend l’enregistrement comportemental tolérable, et le fait rétrospectivement — une fois qu’un identifiant est rattaché, les sessions auparavant pseudonymes de ce visiteur deviennent elles aussi attribuables.

R7 — Aucun délai d’effacement pour treize tables ; délais fixés le 17 août 2026

La purge tenant compte du niveau de forfait supprime dans cinq tables : mouse_events, session_custom_event_params, session_custom_events, session_pageviews et visitor_sessions. Treize tables contenant des données à caractère personnel sont absentes de cette liste : ai_session_features, ai_timelines, consent_events, session_comments, session_shares, visitor_nicknames, ip_lifetime_stats, audit_logs, user_ip_history, users avec last_ip, support_requests, consent_region_acceptances et heatmap_page_stats.

La conséquence pratique est pire que ne le suggère la liste, en raison de l’ordre dans lequel les choses se produiraient. Lorsque la purge finit par se déclencher, la session disparaît et les éléments dérivés restent — ai_timelines conserverait la session sous forme de prose lisible, à raison de 3 203 lignes et 5,5 MB, décrivant une personne dont l’enregistrement sous-jacent a été supprimé. Aujourd’hui, il n’existe aucun élément orphelin de ce type, mais uniquement parce que rien n’a jamais été supprimé.

Trois autres défauts aggravent cela. La routine n’est pas planifiée par cron ou systemd mais s’exécute dans le processus worker ; si ce processus s’arrête, l’effacement s’arrête et rien ne le signale. Sa requête de sélection joint les sessions aux projets, espaces de travail, propriétaires et utilisateurs au moyen de jointures internes ; une session dont le projet a été supprimé ne peut donc jamais être sélectionnée et ne sera jamais effacée — une session sur 706 se trouve déjà dans cet état. Et la conservation réellement en vigueur est de 365 jours pour chaque projet du système, face à un jeu de données dont l’enregistrement le plus ancien a 20 jours, ce qui signifie que la chaîne de suppression n’a jamais été mise à l’épreuve de bout en bout.

Probabilité — Réalisée. Gravité — Grave, en tant que violation structurelle plutôt qu’accidentelle de l’art. 5(1)(e). Modifié le 17 août 2026. L’exécution elle-même reste dans db_worker, mais son ABSENCE est désormais remarquée : le worker consigne son résultat (mp_purge_status) et srv/cron_status.php — un processus DIFFÉRENT — l’évalue toutes les 60 secondes, écrit sys_purge pour la zone d’administration et signale par e-mail que la dernière exécution remonte à plus de 48 heures. Au plus un message par jour ; un mécanisme de surveillance envoyant un e-mail chaque minute est ignoré, puis ne signale lui non plus la véritable panne à personne. Ce mécanisme ne se trouve délibérément pas dans le worker : un processus mort ne peut pas se signaler lui-même. État au 23 septembre 2026 : l’envoi d’e-mails est en place ; le message est adressé à l’adresse d’alarme définie dans la zone d’administration.

État au 17 août 2026. Résolu. Cinq des treize tables font partie de la chaîne de suppression commune depuis le 12 août 2026, six ont reçu leur propre délai, configurable dans la zone d’administration (migration 039), et deux manquaient entièrement à la liste : ai_visitor_value et ai_insights — précisément la notation de la personne et le texte généré à son sujet. Les délais se trouvent dans site_settings et sont lus dans la même ligne que celle où le registre de l’art. 30 les lit pour son propre texte. La purge s’exécute bien ; l’exécution du 17 août 2026 à 17:37:09 est consignée dans le journal du worker. Le problème de cette section — la session disparaît et le résultat dérivé reste orphelin — ne peut donc plus survenir. L’exécution dépend toujours du processus worker et n’est planifiée ni par cron ni par systemd ; depuis le 17 août 2026, son absence est signalée par le mécanisme de surveillance du processus de suivi et, depuis le 23 septembre 2026, également par e-mail.

Réévalué le 23 septembre 2026. Mesuré le même jour : la dernière purge s’est exécutée 21 heures auparavant, la ligne la plus ancienne d’audit_logs a 60 jours — exactement le délai configuré — et aucune session n’est sans projet. La sélection utilise toujours des jointures internes ; des sessions orphelines ne se créent néanmoins pas, car la suppression d’un projet ou d’un compte emporte ses sessions par channelid. Depuis le 24 septembre 2026, user_ip_history dispose aussi de son propre délai : 90 jours à compter de la dernière observation d’une adresse, au plus tard avec le compte. Probabilité — Faible. Gravité — Grave. Niveau global — faible.

R8 — Notation et classification automatisées de chaque session

Chaque session est évaluée automatiquement. engagement_score (0-255) est calculé à partir de signaux de profondeur et d’irritation ; session_quality distingue les sessions où il s’est peu passé de choses ; is_bot, avec un code de motif, classe le visiteur comme non humain, et cette vérification s’exécute avant le verrou du consentement. Les scores sont indexés et déterminent l’ordre de la liste d’examen du client, ce qui signifie qu’ils déterminent quels individus sont observés. Lors du relevé d’août 2026, il existait 4 043 lignes de caractéristiques et 3 203 récits générés.

Il s’agit de profilage au sens de l’art. 4(11) — l’évaluation automatisée d’aspects personnels concernant une personne physique, précisément pour analyser ou prédire son comportement. Au vu des éléments constatés, il ne s’agit pas de prise de décision automatisée au titre de l’art. 22 : aucune décision de crédit, de tarification, d’accès ou d’éligibilité à l’encontre d’un visiteur n’a été constatée. Un mécanisme se situe plus près de la limite que les autres et devrait être nommé : lorsqu’un clic de rage est détecté, www/mp.js pousse un verdict comportemental dans des widgets de discussion tiers s’exécutant dans le propre navigateur du visiteur — Intercom reçoit un indicateur, LiveChat une variable de session. Un jugement formé au sujet du visiteur quitte ainsi le système en temps réel et peut changer la manière dont cette personne est traitée sur le site.

Périmètre du profilage, état au 16 octobre 2026. Depuis le relevé, d’autres scores et éléments déduits ont été ajoutés, et tous relèvent de ce risque : phrases et rapports formulés par une machine au sujet de visiteurs individuels (ai_insights, ai_besucher_bericht ; les constats sont calculés, un modèle de langage sur nos propres machines dans le même réseau local les formule) ; un modèle de sortie (régression logistique) qui estime un risque de sortie dans le navigateur du visiteur et, lorsque l’exploitant l’active, déclenche une offre de sortie dont le texte n’est affiché qu’après approbation par l’exploitant ; un indicateur de risque de perte des visiteurs récurrents fondé sur des règles (ai_churn) ; des profils de comportement regroupant les sessions selon leur déroulement (k-means, mp_profile, mp_profil_sitzung), et des motifs séquentiels ; un score de friction par session ; des sondages et un bouton de retour d’information avec les réponses du visiteur ; le suivi d’éléments, qui attribue les clics aux éléments marqués ; un index des textes affichés pour la recherche (mp_text_block, mp_text_pv, 30 jours) ; ainsi que les messages de console et les requêtes échouées ou lentes de la page du client (sans corps ni en-têtes). Au vu des éléments constatés, aucun de ces mécanismes ne prend une décision au sens de l’art. 22 à l’encontre du visiteur ; l’offre de sortie modifie toutefois directement ce qui lui est montré sur la page et constitue donc, parmi les éléments énumérés, celui qui se situe le plus près de la limite. Les détails figurent dans le registre au titre de l’art. 30.

Séparément, deux conséquences automatisées ont bien un effet réel, mais à l’encontre des clients et des adresses IP plutôt que des visiteurs : un compte automatiquement marqué is_suspicious lors de l’inscription voit sa conservation de données ramenée à 24 heures, et une adresse IP dépassant les seuils de connexion est bloquée, après quoi toute nouvelle requête est interrompue — lors du relevé d’août 2026, 24 blocages de ce type étaient enregistrés. Lors du relevé, aucun des deux n’avait de voie documentée d’examen humain ni de canal d’opposition ; pour le blocage, une telle voie existe depuis le 17 août 2026 (ci-dessous), pour le drapeau is_suspicious, il n’en existe toujours pas.

Probabilité — Probable (comportement par défaut). Gravité — Significative : aucun effet juridique pour les visiteurs, mais être noté et classé sans le savoir, et voir ce score exporté vers un widget tiers, constitue précisément la perte de contrôle décrite au considérant 75. Évalué le 17 août 2026. Depuis ce jour, le blocage automatique expirait de lui-même après 7 jours ; auparavant, il n’expirait jamais. Au 16 octobre 2026, le serveur WebSocket bloque de lui-même et le blocage expire après 24 h (configurable de 1 à 168 h) ; fail2ban bloque pendant une heure ; banned_ips n’est renseigné que manuellement. Une opposition passe par le formulaire d’assistance ou par office@mouseplayer.com et est traitée par un humain ; la zone d’administration permet de lever le blocage. La durée se trouve dans site_settings (autoban_stunden). La mesure a donc un effet limité, un examen humain sur demande et une voie nommée pour y accéder — les caractéristiques dont dépend l’art. 22. La qualification elle-même reste une question juridique ; ce qui est décidé, c’est la garantie, et non l’interprétation. (décision du responsable du traitement, 17 août 2026)

R9 — 92 sessions inaccessibles par quelque identifiant que ce soit ; aucune voie d’une personne à son enregistrement

92 sessions portent visitor_id 'unknown'. Pour ces enregistrements, aucune clé de quelque nature que ce soit ne permet d’y accéder : les données existent, sont à caractère personnel, contiennent une relecture et peut-être une adresse, et ne peuvent être retrouvées par aucune requête qu’une demande d’une personne concernée pourrait déclencher. L’effacement au titre de l’art. 17 ne peut pas être réalisé pour elles, et il n’est pas possible de répondre à l’accès au titre de l’art. 15. Nouvelle mesure le 16 octobre 2026 : plus aucune session ne porte visitor_id 'unknown' ; le code peut toutefois encore écrire cette valeur lors de la création d’une session.

Le problème plus large est pire que les 92 lignes et est déjà consigné comme non résolu dans les propres notes du projet. Même lorsqu’un visitor_id existe, il se trouve dans le localStorage du visiteur, et l’être humain ne le connaît pas. Il n’existe aucune voie d’une personne réelle — qui peut fournir un nom, une adresse e-mail, une date et une page — vers ses enregistrements. Un bouton d’effacement inaccessible à la personne habilitée à l’utiliser est un accessoire de décor.

L’art. 11 apporte une réponse partielle et inconfortable : lorsque le responsable du traitement peut démontrer qu’il n’est pas en mesure d’identifier la personne concernée, les art. 15 à 20 ne s’appliquent pas — mais l’art. 11(2) exige qu’il en informe la personne concernée, et celle-ci peut fournir des informations supplémentaires permettant son identification. Ce dernier point est essentiel : le visiteur peut fournir son identifiant, puisqu’il se trouve dans son propre navigateur. Une page en libre-service affichant au visiteur son propre mp_visitor_id transformerait une demande impossible en une demande courante, ce qui rend le recours à l’art. 11 difficile à défendre tant qu’une telle page n’existe pas.

Probabilité — Réalisée. Gravité — Significative, devenant grave en combinaison avec R1 : la personne la moins à même d’accéder à son enregistrement est celle qui ignore qu’il existe. Décidé le 17 août 2026 : un accès à ses propres informations pour les visiteurs sera mis en place — une page où le visiteur voit son propre identifiant et peut déclencher la suppression de ses enregistrements, accessible depuis la politique de confidentialité. (décision du responsable du traitement, 17 août 2026) En service depuis le 17 août 2026 à l’adresse /my-data (allemand /meine-daten, polonais /moje-dane), accessible depuis le pied de page de chaque page. Elle montre le nombre de sessions, la période et les domaines concernés — aucun enregistrement : l’identifiant est un jeton au porteur, et quiconque le connaît pourrait sinon voir le comportement d’une autre personne. La suppression est mise en file d’attente et effectuée par le worker avec la chaîne existante ; la page elle-même ne supprime rien.

La mesure dans laquelle cela désamorce R9 dépend de l’endroit où le visiteur a été enregistré, et cette limite est technique : le stockage du navigateur est séparé par origine. L’identifiant se trouve dans le stockage du site web sur lequel le script s’est exécuté, pas dans le nôtre. Une page de mouseplayer.com ne peut donc pas le voir d’elle-même — ce qui est vérifié par les données, où aucun identifiant n’apparaît sur plus d’un domaine. Trois voies d’accès en découlent :

• Les visiteurs de mouseplayer.com lui-même accèdent directement à leurs données, car le stockage du navigateur est ici le nôtre. Pour eux, R9 est supprimé.
• Les visiteurs d’un site web client y accèdent par un lien que le client place dans sa propre notice de confidentialité ; MousePlayer.privacyUrl() le renvoie prêt à l’emploi, identifiant compris. Il ne s’agit pas d’une esquive, mais de la répartition des rôles au titre de l’art. 28 : vis-à-vis de ses propres visiteurs, le client est le responsable du traitement, et l’information de l’art. 13 appartient de toute façon à sa politique. Nous fournissons l’outil et sommes le destinataire.
• Toute personne connaissant déjà son identifiant le saisit sur la page.

Lorsqu’un client ne place pas le lien, R9 reste pleinement applicable à ses visiteurs — la demande n’est alors pas impossible, mais passe par le client plutôt que par nous, et pour ce cas, la déclaration relative à l’art. 11 figure dans la politique de confidentialité. Quiconque a effacé le stockage de son navigateur n’est accessible par aucune des trois voies. La page ne supprime donc pas R9 ; elle le fait passer de « techniquement impossible à satisfaire » à « réalisable, à condition que le responsable du traitement indique le chemin ».

R10 — Aucun chiffrement au repos, aucun TLS vers la base de données ou vers Redis sur le réseau local

Trois lacunes d’infrastructure sont documentées comme non mises en œuvre, et elles ont été vérifiées plutôt que présumées. Le chiffrement des tables InnoDB, des journaux et des tables temporaires est désactivé et le disque n’est pas chiffré ; l’ensemble du corpus — 322,6 MB d’événements et 162,9 MB d’instantanés de pages — repose donc en clair. La connexion à la base de données fonctionne sans TLS : le serveur le prend en charge, mais aucun certificat, aucune clé ni aucune CA n’est configuré ; la connexion est locale, ce qui atténue le problème sans le supprimer. Jusqu’au 16 août 2026, Redis fonctionnait sans protection d’accès tout en persistant sur disque, et ses files d’attente contiennent l’adresse IP tronquée, l’URL complète et la charge utile DOM en transit.

Probabilité — Possible. Une exploitation à distance est peu probable : lors du relevé, Redis et la base de données n’étaient liés qu’à localhost (pour l’état actuel, voir ci-dessous), HTTPS est imposé et la connexion TLS du WebSocket se termine avec un véritable certificat dans nginx. Les voies réalistes sont physiques — vol de la machine, mise au rebut du disque — et la voie de sauvegarde de R5, qui transportait ce même texte en clair hors de la machine chaque nuit jusqu’au 11 août 2026 et transfère sous forme chiffrée depuis lors ; les copies non chiffrées antérieures à cette date ont été supprimées chez le fournisseur le 12 août 2026. Gravité — Très grave s’il se réalise, car ce qui est exposé est tout à la fois.

Réponse du 17 août 2026 : le serveur se trouve dans une pièce fermée à clé sous vidéosurveillance à Lodz ; seul le responsable du traitement en détient l’accès. Le disque de sauvegarde USB se trouve dans la même pièce que le serveur. Réponse du 17 août 2026 : le chiffrement au repos ne sera pas introduit avant la production — non réalisable dans la phase initiale sur le Raspberry Pi (décision du responsable du traitement). Ce risque demeure donc intégralement : tous les éléments reposent en clair sur le disque, et le disque de sauvegarde USB se trouve dans la même pièce. La garantie restante est physique — une pièce fermée à clé sous vidéosurveillance, accessible uniquement au responsable du traitement — et ne protège contre le vol ou la mise au rebut incorrecte d’un disque que dans la mesure où cette pièce résiste. À réévaluer dès que l’exploitation quitte le Raspberry Pi.

État au 17 août 2026. Une partie est résolue, une autre s’est déplacée. L’accès à Redis est restreint depuis le 16 août 2026 ; vérifié auprès du service, il refuse les requêtes sans authentification. Le chiffrement au repos est toujours absent. L’hypothèse atténuante de cette section n’est toutefois plus valable : depuis le 16 août 2026, Redis et la base de données n’écoutent plus uniquement sur localhost, mais également sur l’adresse du réseau local (bind-address = 127.0.0.1,192.168.20.2), pour qu’un deuxième nœud puisse accéder à l’état partagé ; les lignes ssl- de la configuration du serveur restent commentées. Tant qu’un seul nœud fonctionne, cela reste théorique. Avec le deuxième, le contenu des sessions et le trafic de base de données traversent le réseau en clair, et les voies ne sont alors plus seulement physiques. L’évaluation de ce risque doit être revue avant la mise en service d’un deuxième nœud.

État au 16 octobre 2026. Les connexions provenant d’internet sont chiffrées par TLS ; le chiffrement se termine dans nginx et le serveur WebSocket n’écoute que sur 127.0.0.1:8081, c’est-à-dire sur la même machine. MousePlayer utilise sa propre instance Redis sur 127.0.0.1:6381 avec restriction d’accès et persistance sur disque (fichier en ajout seul) ; le contenu des files d’attente et les adresses IP non tronquées conservées pendant le blocage automatique (24 h) atteignent donc également le disque. Une instance Redis plus ancienne et partagée écoute en outre, avec accès restreint, sur l’adresse du réseau local. MariaDB écoute sur 127.0.0.1 et sur l’adresse locale 192.168.20.2 sans TLS (aucun certificat configuré), et il existe des connexions depuis le réseau local. Au sein de notre propre réseau local sur le même site, les connexions à la base de données et à Redis fonctionnent donc sans chiffrement ; leur accès est restreint et elles ne sont accessibles que depuis notre propre réseau local (aucune redirection de port). Le chiffrement au repos est toujours absent.

R11 — Aucun relevé indiquant qui a consulté quel enregistrement

Le journal d’audit enregistre les actions d’écriture — création et révocation de partages, suppression de commentaires, suppression de sessions et de visiteurs, blocages automatiques, actions de superadministrateur, 666 entrées au total lors du relevé. Il n’enregistre pas la lecture. Un appel à la page du lecteur, au point de terminaison des événements ou à celui du théâtre ne laisse aucune trace. Personne ne peut établir après coup quel employé d’un client a regardé la session d’un individu nommé, à quelle fréquence ou si un administrateur MousePlayer l’a fait. Depuis le 17 août 2026, au moins les accès aux liens de partage sont journalisés (share_views) ; les appels par des utilisateurs connectés ne laissent aucune trace (état au 16 octobre 2026).

Probabilité — Réalisée en tant que lacune de contrôle. Gravité — Significative, avec un effet aggravant plus important que l’effet direct : après tout incident, les art. 33 et 34 exigent que le responsable du traitement décrive les catégories et le nombre approximatif de personnes concernées et d’enregistrements touchés. Sans journalisation des lectures, cette description ne peut pas être produite à partir de preuves, et chaque notification devient une estimation.

R12 — Qualité de la preuve du consentement et adaptateurs CMP non testés

L’art. 7(1) fait peser sur le responsable du traitement la charge de prouver le consentement, et le code l’indique explicitement comme raison de l’existence du journal de consentement. Dans les données mesurées lors du relevé (août 2026), 671 sessions sur 706 portent consent_source='testdata' avec un horodatage NULL, écrits par une fixture de développement — elles ne prouvent rien. Les véritables enregistrements étaient alors au nombre de 35 : 27 issus de l’API, 5 de Google Consent Mode, 2 consentements tardifs, 1 retrait. Au 16 octobre 2026, 566 sessions humaines sur 8 648 portent consent_source='testdata' ; les autres portent un enregistrement issu de l’API (7 451), de l’adaptateur Consented (620) ou de Google Consent Mode (9). La suppression lors du retrait existe en option et est désactivée sur tous les projets (état au 16 octobre 2026) ; un retrait arrête donc l’enregistrement futur, mais laisse les enregistrements antérieurs en place.

Parmi les six adaptateurs CMP et les trois couches de détection du consentement, seules trois voies ont été mises à l’épreuve du réel : l’API directe, Google Consent Mode et Cookiebot. TCF et cinq adaptateurs — Usercentrics, OneTrust, Consentmanager, Borlabs, Complianz — sont construits, mais n’ont jamais été exécutés contre une CMP en fonctionnement. Compte tenu du principe directeur de fermeture en cas d’échec, un adaptateur qui interprète mal un signal échoue dans le sens de l’absence d’enregistrement, ce qui est le sens sûr ; le risque est donc principalement celui de preuves non vérifiées plutôt que d’un enregistrement illicite.

Probabilité — Réalisée pour ce jeu de données. Gravité — Grave en conditions de production, car un consentement dont on ne peut apporter la preuve est, en cas de litige, un consentement qui n’a pas existé. Cette évaluation s’applique aux données de développement et doit être mesurée à nouveau. à compléter : proportion mesurée de sessions de production portant un véritable enregistrement du consentement, et date à laquelle chaque adaptateur CMP a été vérifié contre une installation en fonctionnement

R13 — Demandes d’assistance transmises à Telegram avec l’adresse IP non tronquée (transfert arrêté le 11 août 2026)

Jusqu’au 11 août 2026, lors de l’envoi d’une demande d’assistance, l’intégralité du dossier était poussée vers Telegram : état du compte, adresse e-mail, objet, texte complet du message, URL source et adresse IP non tronquée. Le paramétrage des jetons était effectué ; la branche était donc active. Le demandeur n’est souvent pas un client, et le texte d’assistance n’a pas de limites — les personnes décrivent des situations de santé, des litiges et des circonstances financières dans les tickets d’assistance parce que le champ les y invite. Depuis le 11 août 2026 cfg/lib.php envoie exactement une chaîne fixe : « MousePlayer: es liegt eine neue Supportanfrage vor. » Aucune variable n’atteint le message, il n’y a pas de parse_mode et, délibérément, aucun numéro de dossier — ce serait un identifiant relatif à une personne — ni aucun lien construit à partir du nom d’hôte demandé, car cette valeur provient de la requête elle-même. Un garde-fou (ai/pruefstand/test_telegram_signal.php) vérifie non pas le résultat, mais la possibilité : quelles variables peuvent atteindre le message tout court. Quatre sont autorisées, 15 identifiants sont interdits et le texte doit être une chaîne entre apostrophes sans interpolation ; le garde-fou a été exécuté contre deux versions délibérément défectueuses et a détecté les deux. Ce qui n’a pas été corrigé est le stockage local. La demande est stockée sans modification dans support_requests, avec l’adresse e-mail et l’adresse IP — c’est voulu, l’exploitant en a besoin pour les litiges — et support_requests n’avait aucun délai de conservation jusqu’au 17 août 2026 ; depuis lors, la demande est effacée après 730 jours (voir R7). Le sens du changement est que les données ne sortent pas, et non qu’elles disparaissent.

Probabilité — Réalisée jusqu’au 11 août 2026 à chaque envoi ; depuis le 11 août 2026, le transfert n’a plus lieu. Gravité — Significative : jusqu’au 11 août 2026 parce que Telegram se trouve hors de l’UE et ne propose aucun accord de traitement pour les canaux de bots ; depuis lors, la même évaluation ne concerne que le stockage local, car il reste la conservation de l’adresse e-mail, de l’adresse IP et de texte libre sans limites dans la propre base de données de l’exploitant — limitée à 730 jours depuis le 17 août 2026. L’élément de pays tiers a disparu, la conservation est bornée ; elle est suivie sous R7. La décision a été prise et datée : le canal est conservé et, depuis le 11 août 2026, le message ne contient aucune donnée. Une base juridique et un instrument de transfert vers un pays tiers ne sont donc plus requis, car aucune donnée à caractère personnel ne parvient à Telegram ; pour cette opération, Telegram n’est pas un sous-traitant. Niveau global — moyen jusqu’au 11 août 2026, faible depuis lors.

R14 — Sortie vers des destinataires choisis par le responsable du traitement lui-même

MousePlayer propose des passerelles par lesquelles certains éléments sont transmis aux propres systèmes du responsable du traitement : gestion de la relation client, service d'assistance, marketing, publicité, stockage ou gestion des tâches, ou à une adresse qu’il nomme lui-même. Lui seul effectue la sélection, il stocke les identifiants d’accès, et la transmission constitue donc son instruction. Les détails figurent dans le registre, section 4.1.

Où se situe le risque. Pas dans le volume : ce qui est transmis, ce sont des identifiants et des noms d’événements, jamais le contenu des pages enregistrées, la trajectoire de la souris ou le texte des formulaires. Le risque se situe dans l’irréversibilité. Si une demande d’effacement au titre de l’art. 17 nous parvient, nous effaçons notre copie — nous ne pouvons pas atteindre celle du destinataire. Combien de temps il la conserve, où il l’emporte et à qui il la transmet échappe à notre influence et n’est pas quelque chose que nous pouvons surveiller. Il en va de même d’un transfert vers un pays tiers : le responsable du traitement détermine la destination et, avec elle, la garantie au titre du chapitre V.

Ce qui a été fait à ce sujet. La politique de confidentialité indique clairement les deux points — ce qui sort et le fait qu’une demande d’effacement n’y a aucun effet — et renvoie la personne concernée à l’exploitant du site web, qui a pris cette décision, pour savoir quels destinataires sont activés. L’accord de traitement des données précise que ces destinataires ne sont pas des sous-traitants ultérieurs de MousePlayer. Techniquement, le volume est maintenu faible, et le nom, l’adresse e-mail, le numéro de téléphone et l’adresse IP ne sont expressément pas envoyés aux réseaux publicitaires. Depuis le 20 août 2026, chaque projet conserve un journal de livraison (registre A.11) dans lequel le responsable du traitement peut lire ce qui est effectivement sorti — auparavant, cela ne lui était pas visible.

Ce qui reste. Un risque résiduel qui ne peut pas être éliminé par la technique tant que la fonctionnalité existe : la divulgation est voulue et ses conséquences se situent hors de notre sphère. Il est supporté par le responsable du traitement qui active la passerelle et lui est indiqué dans l’accord de traitement des données et dans cette analyse.

8. (d) Mesures envisagées pour faire face aux risques

Chaque mesure ci-dessous porte un état, et ces états ne sont pas décoratifs. Mise en œuvre signifie vérifiée dans le système en fonctionnement aujourd’hui. Partielle signifie que le mécanisme existe, mais n’atteint pas encore son objectif. Prévue signifie qu’elle n’existe pas. Une AIPD qui présente des mesures prévues comme étant mises en œuvre suscite le reproche habituel adressé à cet instrument, et c’est ce reproche qui détruit la valeur du document dans la seule situation où celui-ci compte.

8.1 Mises en œuvre aujourd’hui — vérifiées

Mesure	Risques visés	Preuve
Verrou du consentement dans le navigateur, fermé en cas d’échec : absence de signal, défaillance de la CMP, erreur de script et origine inconnue aboutissent tous à « ne pas enregistrer »	Licéité	Machine à états mpEinw dans www/mp.js, derrière la vérification des robots
Application indépendante côté serveur : seuls GRANTED ou GRANTED_LATE ou une exemption régionale explicite passent ; retrait, pays inconnu et toute situation peu claire ferment la connexion	Licéité	class/Server.class.php:977-1004 ; 24 connexions bloquées enregistrées lors du relevé
Liste d’exclusion de chemins appliquée avant le verrou, avec correspondance sur le chemin uniquement	Minimisation	class/Server.class.php:963-975 ; 71 connexions bloquées enregistrées lors du relevé
Troncature de l’adresse IP au point de lecture, avant tout consommateur de la valeur	R3, uniquement pour l’avenir	class/Server.class.php:432-435 ; toutes les sessions depuis le 7 août 2026 tronquées
Masquage des formulaires avec un niveau minimal inconditionnel pour les mots de passe et les données de paiement quel que soit le paramètre ; tous les projets au niveau le plus strict	R2, uniquement pour l’avenir	www/mp.js:4818-4853
Noms des champs classifiés plutôt que transmis	Minimisation	www/mp.js:4653-4674
Masquage du DOM à l’intérieur des zones marquées, également appliqué aux mutations en direct	R1, partiellement	www/mp.js:3934-3970 et 4732-4768
Chaîne TC stockée uniquement sous forme d’empreinte SHA-256	Minimisation	visitor_sessions.tcf_hash
Charge utile de relecture délibérément exclue de l’API publique	R4	www/api/v1_session_detail.php:25
Liens de partage : jeton de 160 bits, durée par défaut de 7 jours et maximum de 90 jours, identifiants issus du jeton uniquement, chaîne de requête remplacée et non ignorée, rôle NULL, les trois points de terminaison limités, réponse identique pour les jetons inventés, expirés et révoqués, révocation disponible	R4	cfg/lib.php mp_share_erstellen / mp_share_pruefen ; www/.htaccess
Géolocalisation à partir de fichiers de base de données locaux — aucun appel à un tiers nulle part dans le parcours d’enregistrement	Transferts vers des pays tiers	class/IP2CityLite.class.php:37 ; class/Server.class.php:724
Modèle de rôles par espace de travail ; suppression réservée au propriétaire et à l’administrateur, et toujours limitée au projet	Contrôle des accès	www/player.php:267, 275-282
Journal des événements de consentement délibérément conservé au-delà de la suppression de la session, pour prouver qu’un retrait a eu lieu	Art. 7(1)	srv/db_worker.php:257-259
Journal d’audit des actions d’écriture	Responsabilité	cfg/lib.php:2878-2890 ; 666 entrées lors du relevé
Sécurité du transport : HTTPS imposé ; TLS avec un véritable certificat se termine dans nginx, y compris pour le WebSocket (/mp_wss/), le tunnel HTTP (/mp_wst), le téléversement d’instantanés (/mp_dom) et le point de mesure (/mp_wsfail) ; le serveur WebSocket n’écoute que sur l’adresse de bouclage. Les connexions à la base de données et à Redis au sein du réseau local ne sont pas chiffrées (voir R10)	Confidentialité	www/.htaccess ; configuration nginx (srv/nginx/) ; srv/server.php lié à 127.0.0.1:8081
Jetons CSRF issus de random_bytes avec comparaison en temps constant ; cookie de session httponly, SameSite=Lax, secure ; hachage des mots de passe ; requêtes préparées sur l’ensemble des parcours d’écriture audités ; limitation du débit des connexions ; blocage automatique et limites de connexions par IP ; fail2ban en cours d’exécution	Confidentialité	cfg/lib.php:110-132 ; www/login.php ; class/Server.class.php:449-455, 660-668
Secrets hors du système de gestion des versions	Confidentialité	.gitignore couvre .env ; seul .env.example est suivi
Conservation imposée pour les journaux du portail : respectivement 60 jours et 72 heures, plus l’expiration des blocages	Limitation de la conservation	srv/db_worker.php (suppression quotidienne)
Suppression quotidienne selon le niveau de forfait et selon des délais distincts pour les autres tables, plus purge horaire des sessions marquées comme des robots dont les délais sont expirés ; son absence est signalée par un processus de suivi distinct par e-mail et dans les Urgent Logs	Limitation de la conservation, R7	srv/db_worker.php ; srv/cron_status.php (sys_purge) ; entrée la plus ancienne d’audit_logs au 16 octobre 2026 au délai de 60 jours
fail2ban avec neuf jails, dont mp-nginx-429, qui bloque les adresses déclenchant de façon répétée la limitation de débit nginx ; plus des limites de débit dans nginx	Disponibilité, prévention des abus	fail2ban-client status, vérifié le 16 octobre 2026
Archivage avant suppression définitive : la suppression de projets, d’espaces de travail et de comptes, ainsi que la suppression par adresse IP ou par visiteur, masque d’abord les données et arrête l’enregistrement ; la suppression définitive suit après 30 jours ou plus tôt sur demande, exécutée puis recomptée par le worker. La suppression des comptes inactifs n’archive pas au préalable	Intégrité, limitation de la conservation	Migration 189 ; cfg/archivierung_lib.php ; mp_loesch_archiv
Délais pour les sessions marquées comme des robots : enregistrement vidé (délai en jours : 1), ligne de session supprimée après 14 jours	Limitation de la conservation	site_settings retention_bot_recording_days et retention_bot_session_days ; srv/db_worker.php

8.2 Partielles — existent, mais n’atteignent pas encore leur objectif

Mesure	Pourquoi elle n’est pas encore efficace
Masquage du DOM	Activation explicite par élément. Protège ce que le visiteur saisit, pas ce que la page affiche — le fond de R1
Suppression lors du retrait	Mise en œuvre comme option, désactivée sur tous les projets (état au 16 octobre 2026), de sorte qu’un retrait ne supprime pas ce qui a déjà été enregistré
En-têtes noindex et no-referrer	La page qui montre l’enregistrement via un lien de partage (player.php en mode partage) porte Referrer-Policy: no-referrer et Cache-Control: no-store, mais aucun en-tête X-Robots-Tag ; noindex n’apparaît que dans www/share.php, la page d’erreur, et robots.txt autorise tout (vérifié le 16 octobre 2026)

8.3 Prévues — non mises en œuvre

Mesure	Risques visés	Priorité
Chiffrer la copie hors site avant le téléversement — effectué le 11 août 2026 : l’exécution quotidienne chiffre sur notre propre serveur avant le transfert (rclone crypt, noms compris), et les clés se trouvent dans deux fichiers avec le mode 600. Supprimer les anciens éléments non chiffrés dans le dossier de destination précédent — effectué le 12 août 2026. Déposer les fichiers de clés de manière qu’ils survivent à la destruction de la machine — effectué le 17 août 2026 : ils sont conservés imprimés dans un coffre-fort (déclaration du responsable du traitement). Établir le dispositif Google Drive ou y mettre fin – effectué le 5 septembre 2026 : depuis ce jour, la copie hors site est conservée dans un bucket Google Cloud Storage de la région europe-central2 (Varsovie) et est couverte par le Google Cloud Data Processing Addendum. Le reste présent dans le compte Drive privé a été supprimé le 6 septembre 2026, après la réussite de l’exercice de restauration depuis la nouvelle destination. Supprimer les anciens scripts de sauvegarde — effectué le 16 octobre 2026.	R5	Ne s’applique plus — effectué
Inverser le comportement par défaut du contenu des pages : stocker le texte masqué sauf autorisation explicite, et exiger un accusé de réception écrit du client avant la capture du texte des pages mot pour mot	R1	En premier
Politique sectorielle contractuelle : quels secteurs sont admis tout court, et à quelles conditions supplémentaires	R1	En premier
Troncature ou suppression ponctuelle des 236 + 291 + 666 + 5 anciennes adresses — effectué le 17 août 2026 : les anciens éléments du parcours d’enregistrement ainsi que d’audit_logs et de user_ip_history sont tronqués (voir R3)	R3	Ne s’applique plus — effectué le 17 août 2026
Examiner et effacer les 173 lignes de saisie en clair — effectué le 17 août 2026 : supprimées sans examen (décision du responsable du traitement, voir R2)	R2	Ne s’applique plus — effectué le 17 août 2026
Étendre la purge aux treize tables non couvertes ; la déplacer vers une planification surveillée ; corriger la lacune des jointures internes pour que les sessions orphelines soient accessibles	R7	Sans objet — achevé le 17 août 2026 (délais et mécanisme de surveillance) ; la sélection par jointures internes reste en place, les sessions orphelines ne se créent pas (voir R7)
Journaliser les accès en lecture au lecteur et aux deux points de terminaison des données	R11, art. 33	Élevée
Referrer-Policy et X-Robots-Tag sur la page du lecteur ; durée de partage par défaut plus courte — Referrer-Policy: no-referrer est défini en mode partage (vérifié le 16 octobre 2026) ; X-Robots-Tag et une durée par défaut plus courte (toujours de 7 jours) restent à mettre en place	R4	Moyenne
Recherche en libre-service permettant au visiteur de retrouver son propre identifiant, rendant possible une réponse aux demandes au titre des art. 15 et 17 — effectué le 17 août 2026 : /my-data (allemand /meine-daten, polonais /moje-dane), voir R9	R9	Ne s’applique plus — effectué le 17 août 2026
Ne jamais exempter du masquage l’état des cases à cocher et des boutons radio ; étendre le masquage à cet état	R1, R2	Moyenne
Chiffrement au repos ; TLS vers la base de données ; protection d’accès pour Redis — protection d’accès pour Redis effectuée le 16 août 2026 ; le chiffrement au repos et TLS vers la base de données restent à mettre en place (voir R10)	R10	Moyenne
Retirer l’adresse IP de la notification Telegram, ou remplacer le canal — achevé le 11 août 2026 : la notification se compose désormais d’un texte d’avis fixe sans aucune variable (cfg/lib.php), protégé par ai/pruefstand/test_telegram_signal.php	R13	Sans objet — achevé le 11 août 2026
Délai de conservation pour support_requests, audit_logs et user_ip_history	R7	Sans objet — achevé le 17 août 2026 pour support_requests et audit_logs, le 24 septembre 2026 pour user_ip_history
Frontière entre locataires sur visitor_nicknames	R6	Faible
Voie documentée d’examen et d’opposition pour le blocage automatique et le drapeau is_suspicious — pour le blocage automatique effectué le 17 août 2026 (expiration alors après 7 jours, désormais après 24 h, opposition via le formulaire d’assistance, levée dans la zone d’administration, voir R8) ; pour le drapeau is_suspicious, elle reste à mettre en place	R8	Faible
Vérifier chaque adaptateur CMP contre une installation en fonctionnement avant de le proposer	R12	Faible

8.4 Procédures et garanties restant à établir

L’art. 35(7)(d) exige des garanties, des mesures de sécurité et des mécanismes — ce qui inclut les procédures organisationnelles, pas seulement le code. Lors du relevé, quatre étaient absents ; leur état actuel est indiqué pour chacun.

• Établi le 17 août 2026. Détection : le responsable du traitement, un Client ou un visiteur de site web. Voie de signalement auprès de nous : privacy@mouseplayer.com. Décision de notification à l’autorité de contrôle : Lukas Wójcik, propriétaire, dans les 72 heures au titre de l’art. 33(1). Information du Client : par e-mail, sans délai indu au titre de l’art. 33(2), au plus tard dans les 48 heures (accord de traitement des données, section 8). Envoi : l’envoi d’e-mails est configuré depuis le 23 septembre 2026 par SMTP chez Namecheap Private Email (expéditeur office@mouseplayer.com) ; la voie promise vers le Client est donc en place. Aucun exercice n’a eu lieu à ce jour.
• Réponse du 17 août 2026 : jusque-là, aucun test de restauration n’avait été effectué ; un test mensuel était prévu, avec un objectif de délai de reprise de 24 heures au maximum. Les deux fichiers de clés sont conservés imprimés dans un coffre-fort accessible uniquement au responsable du traitement. Effectué depuis lors : un exercice de restauration depuis la nouvelle destination dans Google Cloud Storage avant la suppression des copies Drive (5/6 septembre 2026), et, le 7 octobre 2026, une restauration complète des données depuis la sauvegarde cloud vers un environnement distinct — environ 70 minutes, échantillons de l’archive et de la base de données sans erreur. Cela atteste de la récupération des données, pas de la reconstruction d’une machine de production complète ; aucun mécanisme de surveillance ne rappelle le prochain test.
• Réponse du 17 août 2026 : il n’existe AUCUNE alerte automatique ; la vérification est manuelle. Mesuré le même jour : le code ne contient aucun dispositif de surveillance des pannes, de l’espace disque ou de la réussite des sauvegardes — les seules occurrences de Telegram se trouvent dans une bibliothèque tierce que personne n’appelle, srv/cron_status.php n’écrit qu’une valeur d’état dans Redis, et system_alerts est vide. Jusqu’au 17 août 2026, les TOM promettaient le contraire (« en cas de défaillance du système, l’administrateur reçoit une notification automatique »). C’était une assurance que le code ne tient pas ; elle a été corrigée le même jour. Résolu le 19 août 2026 : srv/backup-crypt.sh consigne désormais le résultat de chaque exécution dans un fichier d’état, et srv/cron_status.php vérifie, en plus des cinq composants existants, la réussite de la sauvegarde, l’espace disque libre sur les volumes système et de sauvegarde, et – en tant que surveillance juridique plutôt qu’opérationnelle – le seuil de l’art. 37. Chaque vérification en échec est signalée par e-mail au plus une fois par jour. La surveillance demande la dernière sauvegarde réussie plutôt que la dernière tentative : un script qui démarre chaque nuit et s’interrompt chaque nuit a un horodatage récent et aucune sauvegarde, ce qui est précisément la raison pour laquelle l’échec de la mise à jour GeoIP est passé inaperçu pendant cinq jours. Une limite subsiste et est énoncée plutôt que sous-entendue : la surveillance s’exécute sur la machine qu’elle surveille et ne peut pas signaler sa défaillance totale ; il n’existait aucune sonde externe de disponibilité. Depuis le 2 octobre 2026, une deuxième machine sur le même site vérifie l’application chaque minute (TOM, section 5) ; une défaillance de la connexion internet n’est toujours pas détectée par elle. Les TOM ont été harmonisées le même jour (version 1.2), de sorte que la correction n’est pas limitée à ce document.
• L’avis des personnes concernées n’a pas été demandé. Raisonnement : vis-à-vis des utilisateurs finaux observés, MousePlayer agit uniquement comme sous-traitant et n’a aucun canal propre vers eux — toute prise de contact passerait par les sites web des Clients et constituerait elle-même un traitement de leurs données pour une nouvelle finalité. Les intérêts des personnes concernées sont plutôt pris en compte indirectement : par le verrou du consentement, qui n’enregistre rien sans signal, par le masquage des saisies et par les délais d’effacement. Demander leur avis reste possible dès qu’un canal permet de les atteindre sans les capturer à nouveau à cette fin. (décision du responsable du traitement, 17 août 2026)

9. Risque résiduel et consultation préalable au titre de l’art. 36

L’art. 36(1) exige une consultation préalable de l’autorité de contrôle lorsqu’une AIPD indique que le traitement présenterait un risque élevé en l’absence de mesures prises pour atténuer le risque. Le test n’est donc pas de savoir si des risques élevés ont été identifiés — deux très élevés l’ont été —, mais si un risque élevé subsiste une fois les mesures du point (d) en place. Il faut répondre honnêtement à cette question pour chacun des deux.

R5, la copie quotidienne hors site, pouvait être corrigé par des moyens ordinaires — et l’a été. La couche de chiffrement avant téléversement est en place depuis le 11 août 2026, les anciens éléments non chiffrés chez le fournisseur ont été supprimés le 12 août 2026 et, depuis le 5 septembre 2026, la copie est conservée dans une région européenne dans le cadre du Google Cloud Data Processing Addendum. La question de savoir sur quoi repose le transfert quotidien a donc reçu une réponse. Réévalué le 17 septembre 2026, R5 se situe à un niveau moyen. La condition issue de l’analyse (suppression des anciens scripts) a été remplie le 16 octobre 2026 ; la réévaluation de R5 relève du responsable du traitement.

R1, les catégories particulières dans le contenu des pages, ne peut pas être entièrement corrigé. Le système ne peut pas savoir ce qu’une page client affiche, et aucune quantité de logique de masquage n’y change rien. Les mesures peuvent obtenir une inversion du comportement par défaut, de sorte que le mode d’échec devienne un enregistrement inutile plutôt qu’illicite, ainsi qu’une politique sectorielle contractuelle et un accusé de réception du client. Cela réduit substantiellement le risque. Cela ne l’élimine pas, car un client peut toujours autoriser le texte d’une page qui affiche plus tard quelque chose de sensible.

Sur l’art. 36, la conclusion comporte deux parties, qui ne doivent pas être confondues. Formellement, l’obligation de consultation incombe au responsable du traitement — le client qui exploite le site web — et non à MousePlayer, qui est le sous-traitant pour les données de visiteurs porteuses du risque élevé. MousePlayer ne peut pas consulter à la place d’un client, et un client ne peut pas déléguer la décision. Ce que MousePlayer doit au titre de l’art. 28(3)(f), c’est donner au client les faits lui permettant de la prendre, ce à quoi servent les sections (a) et (c) de ce document.

Sur le fond : une consultation préalable n’est pas indiquée si les mesures de la section 8.3 sont mises en œuvre avant le lancement en production, car le risque résiduel descend alors sous le seuil visé par l’art. 36. Une consultation préalable est indiquée dans une situation précise, qui relève d’une décision plutôt que d’un accident : si l’exploitant décide de ne pas inverser le comportement par défaut du contenu des pages tout en continuant à admettre des clients des secteurs de la santé, du droit, de la finance ou du secteur public. Le risque résiduel reste alors élevé par choix, et l’art. 36(1) s’applique selon ses termes. Une deuxième situation qui figurait ici jusqu’au 17 septembre 2026 — la poursuite de la copie quotidienne hors site sans instrument de transfert établi — n’existe plus depuis le 5 septembre 2026 (R5).

Un autre point doit figurer ici, car il est facile de le perdre de vue. L’art. 36 n’est pas une sanction et consulter n’est pas un aveu. C’est le mécanisme que le règlement prévoit précisément pour la situation où se trouve ce système — une technique véritablement utile dont le risque résiduel dépend d’un facteur que l’exploitant ne peut pas entièrement contrôler. Lorsqu’un responsable du traitement entend poursuivre avec un risque résiduel élevé, la consultation est la voie licite pour le faire.

10. Réexamen, version et approbation

L’art. 35(11) exige que le responsable du traitement examine si le traitement est effectué conformément à cette analyse, au moins lorsque le risque change. Trois événements modifient ici substantiellement le risque et devraient chacun déclencher une nouvelle exécution de l’analyse plutôt qu’une lecture : le premier client dans un secteur réglementé ; la première activation de l’export BigQuery ou d’un webhook ; et le franchissement par les utilisateurs finaux suivis du seuil consigné à la section 3.

L’analyse repose en son cœur sur des mesures effectuées les 10 et 11 août 2026 sur le système de développement ; elle a été approuvée le 17 août 2026 et mise à jour depuis, pour la dernière fois le 16 octobre 2026 par un rapprochement avec l’état technique. Restent ouverts les espaces réservés dans les sections 1, 3 et 4 et dans R12, que seul le responsable du traitement peut remplir, ainsi que la réévaluation des risques dont les causes ont été entièrement ou partiellement éliminées depuis le relevé (R2, R3, R9, R10) ; la conclusion sur le risque résiduel de la section 9 est subordonnée aux mesures encore ouvertes dans la section 8.3.

Élément	Entrée
Responsable du traitement et sous-traitant	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82 lok. 301, 90-437 Lodz, Poland - NIP PL7252266190 - office@mouseplayer.com
Délégué à la protection des données	Non désigné. Voir la section 3 pour l’analyse de l’art. 37 et la recommandation.
Documents connexes	Registres des activités de traitement au titre de l’art. 30(1) et de l’art. 30(2), mesures techniques et organisationnelles, liste des sous-traitants ultérieurs, accord de traitement des données et informations relatives à la protection des données
Base des faits	Code source, schéma de base de données, décomptes de lignes, liste des processus, valeurs de configuration et fichiers journaux du système de développement, 10-11 août 2026, mis à jour jusqu’au 16 octobre 2026
Version et date d’approbation	Approuvé par Lukas Wójcik, propriétaire, le 17 août 2026. Aucun conseil externe en matière de protection des données n’a été obtenu. Réexaminé chaque année et à chaque modification du traitement ; les versions datées sont conservées dans le système de gestion des versions sous ai/cms/. Ajouté le 17 septembre 2026 sur instruction du propriétaire : R5 réévalué (sections 5.4, 6, 7, 8.3 et 9). Ajouté le 16 octobre 2026 : rapprochement avec l’état technique (en-tête, sections 1, 3, 4, 5, 7, 8 et 10) ; niveaux de risque inchangés, réévaluation de R2, R3, R9 et R10 par le responsable du traitement en attente. Ajouté le 16 octobre 2026 (deuxième passage) : délais et durée du blocage automatique comme paramètres plutôt que chiffres fixes, bases juridiques pour les demandes d’assistance et les commentaires, garde des clés et accessibilité des anciens scripts de sauvegarde (R5), délai d’information du Client ; niveaux de risque inchangés, réévaluation de R5 par le responsable du traitement en attente. Ajouté le 16 octobre 2026 (troisième passage) : suppression des anciens scripts de sauvegarde consignée (R5), affirmations sur la protection d’accès de la base de données et de Redis harmonisées (R10) ; niveaux de risque inchangés, réévaluation de R5 par le responsable du traitement en attente.