Mesures techniques et organisationnelles (TOM)

1. Champ d’application et finalité

Ce document décrit les mesures techniques et organisationnelles (TOM) que MousePlayer met en œuvre pour assurer un niveau de sécurité adapté au risque, conformément à l’article 32 du RGPD. Il s’applique à tous les traitements de données d’Utilisateurs finaux effectués pour le compte d’un Responsable du traitement (Client).

Exploitant du service : LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82 lok. 301, 90-437 Łódź, Poland · NIP PL7252266190.

2. Confidentialité – contrôle d’accès

2.1 Accès physique

Le service fonctionne sur du matériel que nous possédons et exploitons, situé à Łódź, en Pologne. Aucun centre de données tiers, fournisseur de services en nuage ou hébergeur n’intervient dans l’exploitation elle-même. Les serveurs sont exploités en interne, dans des locaux fermés en Pologne. L’accès est réservé exclusivement au responsable du traitement. La pièce est fermée à clé et sous vidéosurveillance ; aucune autre personne — y compris les propriétaires des locaux ou les services de nettoyage — n’y a accès (déclaration du responsable du traitement, 17 août 2026). L’adresse précise n’est délibérément pas indiquée ici.

2.2 Accès au système

• L’accès à l’application nécessite un compte utilisateur individuel avec un mot de passe ; les mots de passe sont stockés sous forme d’empreintes salées, jamais en clair.
• Les interfaces d’administration sont séparées de l’application destinée aux clients et ne sont accessibles qu’aux superadministrateurs ; l’autorisation est vérifiée sur le serveur.
• Les requêtes de l’interface web connectée qui modifient l’état sont protégées par des jetons CSRF ; les interfaces de programmation s’authentifient avec leurs propres clés.
• L’administration du serveur s’effectue par SSH avec une authentification par clé.
• La connexion peut facultativement être protégée par un second facteur (codes à usage unique basés sur le temps selon RFC 6238). Le secret est stocké chiffré et les codes de récupération uniquement sous forme d’empreintes ; un code déjà utilisé n’est pas accepté une seconde fois, et des tentatives infructueuses répétées bloquent temporairement le second facteur du compte.
• Chaque connexion est suivie individuellement (login_sessions). Le titulaire du compte voit la liste dans les paramètres et peut révoquer des connexions individuelles ou toutes les autres ; la révocation met également fin à une session en cours et à un jeton de connexion persistante stocké. Un changement de mot de passe met fin à toutes les autres connexions. Si un compte se connecte depuis un appareil inconnu (empreinte constituée du navigateur, du système d’exploitation, du type d’appareil et de la plage réseau /24 ou /48 de l’adresse IP), le titulaire reçoit un e-mail.

2.3 Accès aux données (autorisation)

• Un modèle de rôles (owner, admin, viewer) régit ce qu’un utilisateur peut voir et faire au sein d’un espace de travail. La suppression et le partage sont réservés à owner et admin ; la restriction est appliquée sur le serveur, pas seulement dans l’interface.
• Chaque requête de données de session est liée à l’espace de travail du compte demandeur. Un enregistrement d’un autre client ne peut pas être adressé même si son identifiant est connu.
• Les liens de partage (voir 4.3) constituent la seule voie d’accès à un enregistrement sans compte. Ils sont créés délibérément par un utilisateur autorisé, peuvent être révoqués et peuvent comporter une date d’expiration.

2.4 Séparation

• Les données des clients sont séparées logiquement par espace de travail et par projet (canal). Chaque chemin de lecture et d’écriture applique cette restriction.
• Le développement et la production fonctionnent dans des installations séparées avec des bases de données distinctes.

3. Pseudonymisation et minimisation des données

• Aucun traitement avant le consentement. Le script de suivi n’effectue aucune identification, aucun stockage, aucun dépôt de cookie ni aucune connexion réseau tant qu’un signal de consentement n’est pas présent. L’absence de signal est traitée comme un refus, pas comme une autorisation.
• Global Privacy Control. Un signal GPC du navigateur est respecté dans le monde entier et prévaut sur tout autre signal.
• Identifiants pseudonymes. Les visiteurs sont distingués par des jetons générés aléatoirement. Le Service lui-même ne collecte aucun nom, adresse e-mail ou numéro de téléphone.
• Adresses IP. L’adresse IP complète d’un visiteur est utilisée dans la mémoire de travail du serveur d’enregistrement pour établir la connexion, déterminer le pays, la ville et le fournisseur de réseau et lutter contre les abus ; elle n’est écrite dans la base de données que sous forme tronquée (pour IPv4 a.b.c.xxx), et le tableau de bord n’affiche jamais une adresse IP complète de visiteur. Exceptions : pour détecter les afflux massifs de connexions, une adresse est comptabilisée dans Redis pendant dix secondes ; si elle déclenche le blocage automatique, elle est conservée intégralement pendant au plus 24 h comme entrée de blocage dans Redis (mp_autoban:), et cette instance Redis écrit sur disque par AOF. Les accès par liens de partage sont consignés avec l’adresse IP complète (share_views) et sont supprimés avec le lien.
• Occultation des URL. Les valeurs des paramètres qui contiennent habituellement des données à caractère personnel ou des identifiants d’accès (par exemple ?email=, ?token=, ?code=) sont supprimées avant le stockage – dans la chaîne de requête comme après le #, où les services de connexion placent des identifiants d’accès (par exemple #access_token=). Les routes des applications monopages et les ancres internes à la page sont conservées.
• Saisies de formulaire – trois niveaux, le plus strict par défaut. Le masquage intégral (le réglage par défaut) remplace chaque caractère de chaque saisie avant qu’elle ne quitte le navigateur. Le masquage sélectif maintient intégralement masqués les noms, adresses, e-mails, numéros de téléphone, champs de paiement et zones de texte libre, et ne remplace que les chiffres ailleurs, de sorte que les termes de recherche restent utilisables. L’absence de masquage enregistre les saisies telles qu’elles ont été effectuées. Les deux niveaux moins protecteurs ne sont pas accessibles en libre-service : chacun nécessite notre approbation écrite pour cette propriété précise, consignée avec sa date et son auteur. L’application s’effectue côté serveur – un projet dont le niveau enregistré dépasse son approbation est ramené à celle-ci avant même que la valeur ne parvienne au navigateur, de sorte que définir directement le champ ne permet rien.
• Le seuil minimal qu’aucune approbation ne lève. Les champs reconnus comme des mots de passe ou des données de paiement restent intégralement masqués à tous les niveaux. La reconnaissance compare le nom, l’identifiant, le type et l’attribut autocomplete du champ et couvre les termes anglais, allemands et polonais. Rien de cela ne s’étend au contenu que le site web lui-même affiche dans la page ; les zones marquées data-mp-mask sont entièrement exclues de l’enregistrement.
• Liste d’exclusion. Le Responsable du traitement peut exclure de l’enregistrement des chemins complets (par exemple les pages de paiement ou de compte). L’exclusion est appliquée sur le serveur et s’applique également lorsqu’une application monopage navigue vers un chemin exclu sans ouvrir de nouvelle connexion.

4. Intégrité – contrôle des transferts et des saisies

4.1 Transport

• Les connexions depuis internet sont chiffrées par TLS ; TLS se termine dans nginx sur le serveur. Les requêtes non chiffrées sur le port 80 sont redirigées vers HTTPS. Le script de suivi se connecte par WSS par défaut (/mp_wss/). Si la connexion WebSocket ne s’établit jamais, il utilise à la place un tunnel HTTP sur HTTPS (/mp_wst) qui passe par les mêmes contrôles côté serveur ; les captures de page très volumineuses sont téléversées par HTTPS avec un jeton signé et limité dans le temps (/mp_dom), et les échecs de connexion WebSocket sont comptés par un point de terminaison de mesure sans aucun identifiant de visiteur (/mp_wsfail). Derrière nginx, le serveur WebSocket n’écoute que sur l’interface de boucle locale du serveur, sans TLS.
• Au sein de notre propre réseau local sur le même site, les connexions à la base de données (MariaDB) et au cache (Redis) ne sont pas chiffrées ; le chiffrement du transport de ces connexions n’est pas configuré. Toutes deux sont soumises à des restrictions d’accès et accessibles uniquement depuis notre propre réseau local (aucune redirection de port) ; l’instance Redis de l’application n’écoute que sur l’interface de boucle locale.
• Les certificats sont renouvelés automatiquement. Un certificat expiré de l’application serait détecté par le contrôle effectué chaque minute depuis une seconde machine (voir section 5), qui interroge par HTTPS avec vérification du certificat ; il n’existe pas de surveillance distincte de la durée de validité des certificats.

4.2 Contrôle des saisies

• Les actions d’administration sont consignées dans un journal d’audit avec le compte, l’heure et l’action.
• Chaque changement d’état du consentement est écrit comme une preuve distincte avec sa source (API explicite, Consent Mode, TCF, adaptateur CMP, GPC), afin que l’état au moment de l’enregistrement reste vérifiable.

4.3 Transferts ultérieurs

• Le script de suivi transmet exclusivement à l’infrastructure propre de MousePlayer. Aucun tiers n’est contacté pendant l’enregistrement normal.
• Les interfaces facultatives (webhooks, BigQuery, systèmes de relation client, d’e-mail marketing et de gestion des demandes, feuilles de calcul et stockage d’objets, interfaces de conversion des réseaux publicitaires) sont configurées par le Responsable du traitement ; elles aboutissent dans des systèmes qu’il choisit, sont inactives tant qu’il ne les active pas et transmettent des éléments individuels ; seul l’export BigQuery peut, dans le forfait Enterprise et sur demande, également inclure les événements bruts de l’enregistrement (mouse_events). Lorsque le Responsable du traitement active une passerelle vers un outil qu’il a lui-même intégré à sa page (tel que la conversation en ligne, le suivi des erreurs ou l’analyse web), le script transmet à cet outil dans le navigateur des éléments individuels tels que le lien vers l’enregistrement ; le propre script de l’outil les transmet à son fournisseur. Les destinataires ne sont pas des sous-traitants ultérieurs de MousePlayer.
• Les textes générés sont rédigés par un modèle de langage sur nos propres machines équipées d’une carte graphique, dans le même réseau local et sur le même site que le serveur. Elles récupèrent les constats calculés par HTTPS, chaque requête étant signée avec son propre secret ; l’enregistrement lui-même ne leur parvient jamais et rien n’est envoyé à un service d’IA externe – pas même pendant la maintenance d’une telle machine : les tâches attendent alors et l’interface affiche la version calculée.
• Les liens de partage ne transmettent les données qu’aux détenteurs du lien. Le Responsable du traitement décide d’en créer un ou non.

5. Disponibilité et résilience

• Une sauvegarde complète de la base de données, du répertoire de l’application et – depuis le 6 octobre 2026 – de l’archive des enregistrements est créée quotidiennement à 03:00 ; jusqu’au 11 août 2026, elle s’exécutait à 02:00.
• Conservation locale des sauvegardes : 7 jours. La copie locale est conservée non chiffrée sur un disque raccordé ; le chiffrement a lieu lorsque la copie est transférée hors site. Les exports de base de données non chiffrés de la période antérieure au changement y ont été supprimés le 12 août 2026, de sorte que le dossier local ne contient désormais que les exports réalisés depuis le changement et que cette conservation s’y applique. En plus de la copie locale, la sauvegarde quotidienne est transférée hors site – depuis le 5 septembre 2026 vers un bucket Google Cloud Storage dans la région europe-central2 (Varsovie) ; auparavant vers un compte Google Drive privé ; les copies qui y étaient conservées ont été supprimées le 6 septembre 2026, après vérification d’une restauration depuis la nouvelle destination. Conservation à cet endroit : copies quotidiennes pendant 7 jours, copies hebdomadaires (dimanches) pendant 364 jours. Les deux chiffres constituent un paramètre, pas une constante dans un script : la sauvegarde les lit dans la même ligne de configuration que celle citée dans cette phrase, de sorte que la déclaration publiée et le comportement ne puissent diverger. La copie contient la base de données complète. Après 7 jours, les événements d’un enregistrement sont déplacés de la base de données vers une archive. Depuis le 6 octobre 2026, cette archive fait partie de la sauvegarde quotidienne ; auparavant, elle n’était pas sauvegardée et les enregistrements de plus de 7 jours n’avaient aucune copie de sauvegarde. L’archive réside sur le même disque que le système ; la copie locale sur un disque distinct et la copie hors site protègent contre une défaillance de ce disque. Depuis le 11 août 2026, elle est chiffrée sur notre propre serveur avant le transfert (rclone crypt) ; les noms de fichiers et de répertoires sont également chiffrés, de sorte que le fournisseur ne détient que des blocs sans signification discernable. Les clés sont conservées dans deux fichiers sur notre propre serveur, lisibles et modifiables uniquement par leur propriétaire (mode de fichier 600) ; le fournisseur ne les détient pas et ne peut pas lire le contenu. Le déchiffrement d’une telle copie a été vérifié. Le précédent dossier de destination non chiffré contenant les copies complètes antérieures au 11 août 2026 a été supprimé le 12 août 2026. Depuis le 19 août 2026, le succès du transfert est surveillé automatiquement. La sauvegarde écrit son résultat dans un fichier d’état et le processus de surveillance recherche la dernière exécution réussie plutôt que la dernière exécution – un script qui démarre chaque nuit et échoue chaque nuit a un horodatage récent mais aucune sauvegarde. Lorsqu’aucune exécution réussie n’a eu lieu depuis plus longtemps que la période configurée (36 heures par défaut, ce qui permet exactement une exécution quotidienne manquée), un avertissement est envoyé par e-mail, au plus une fois par jour.
• Les données supprimées dans le système en service demeurent présentes dans les sauvegardes jusqu’à l’expiration de la sauvegarde correspondante – au plus 364 jours après l’effacement définitif ; ensuite, elles ne sont plus non plus contenues dans aucune sauvegarde. C’est une conséquence inévitable de l’existence même de sauvegardes ; les demandes d’effacement exécutées par l’administration retirent immédiatement les données du traitement (archivées, masquées, plus enregistrées) et les effacent définitivement après 30 jours au plus tard, sans attendre lorsque cela est expressément demandé ; une demande effectuée sur la page de données /my-data est exécutée sans archivage, en règle générale en quelques minutes. Aucun effacement sélectif n’est effectué dans une sauvegarde : une copie est une archive scellée unique dont le but est d’être l’image fidèle d’un instant donné, et l’ouvrir, la modifier et la sceller à nouveau détruirait cette propriété et la possibilité de démontrer que personne ne l’a altérée. Les sauvegardes ne servent à rien d’autre qu’à restaurer le système après une perte ; elles ne font l’objet d’aucune recherche ni analyse et ne sont pas divulguées. Lorsqu’une sauvegarde est restaurée, les demandes d’effacement consignées pour les utilisateurs finaux sont exécutées à nouveau avant la remise en service du système – la trace de la demande subsiste précisément après l’effacement pour permettre sa répétition. Pour un compte client supprimé, la situation diffère : sa suppression ne laisse délibérément aucune trace permettant de l’identifier, si bien qu’une copie restaurée contiendrait un compte supprimé après la date de cette copie.
• Surveillance. Un processus de surveillance vérifie toutes les minutes la base de données et le processus de traitement des événements, le serveur WebSocket, l’interface web, l’actualité de la base de géolocalisation, l’exécution quotidienne des suppressions, le succès de la sauvegarde et l’espace disque libre sur le volume système et le volume de sauvegarde. Chaque résultat est écrit dans l’état partagé et affiché dans l’espace d’administration, et chaque contrôle en échec est signalé par e-mail au plus une fois par jour – un processus de surveillance qui envoie un e-mail chaque minute est désactivé et ne signale alors plus non plus la véritable panne. Avant le 19 août 2026, seuls les cinq premiers de ces éléments étaient contrôlés et seule l’exécution des suppressions déclenchait une alerte ; le reste était manuel et ce document l’indiquait.
• Ce que cette surveillance ne peut pas faire, indiqué explicitement plutôt que laissé à supposer : elle s’exécute sur la machine qu’elle surveille et ne peut donc pas signaler la panne totale de celle-ci. Depuis le 2 octobre 2026, une seconde machine au même endroit vérifie chaque minute si l’application accepte les enregistrements – base de données, cache, serveur WebSocket, processus en arrière-plan, file d’attente et script de suivi – et alerte par Telegram après deux contrôles consécutifs en échec. Elle atteint le serveur par le réseau local : une défaillance de la connexion internet, du routeur ou du DNS n’est pas détectée par elle et reste constatée par une personne, pas par un système de surveillance. Objectif de délai de rétablissement (RTO) : pas plus de 24 heures. Tests de restauration : la restauration depuis la sauvegarde hors site a été testée les 5 et 6 septembre 2026 et le 7 octobre 2026 (restauration complète des données) ; aucun calendrier fixe n’a été établi.
• Surcharge et attaques. nginx limite les requêtes et connexions simultanées par adresse ; une adresse dépassant la limite de manière persistante est rejetée au pare-feu par fail2ban pendant une heure. Le serveur WebSocket bloque automatiquement pendant 24 h les adresses qui provoquent des afflux massifs de connexions ; les blocages définis manuellement par l’exploitant sont conservés dans la base de données.

6. Procédures d’examen régulier

• Les mesures de ce document sont réexaminées lorsque le traitement change et, sinon, selon l’intervalle indiqué à la section 10.
• Un contrôle d’installation vérifie pour chaque projet Client si le script est correctement intégré et si les enregistrements arrivent avec une preuve de consentement. Les projets sans preuve de ce type sont signalés dans le tableau de bord.
• Aucun test d’intrusion externe n’est actuellement commandé et aucune certification de sécurité n’est détenue. Cela est indiqué ici plutôt qu’omis : un document TOM qui garde le silence sur ce point donne l’impression que de tels tests existent.
• Le nombre d’utilisateurs finaux observés pour l’ensemble des clients est mesuré quotidiennement et comparé au seuil auquel l’évaluation au titre de l’article 37 du RGPD doit être répétée (100000 par mois ; voir la section 9 du registre des activités de traitement). Cette quantité est déterminée par le trafic sur les sites web des clients et pas par nous, si bien que ne pas la surveiller laisserait l’évaluation devenir silencieusement obsolète. La répétition annuelle est suivie par le même processus.

7. Sous-traitants ultérieurs

MousePlayer ne fait appel à des sous-traitants ultérieurs qu’avec l’autorisation écrite générale du Responsable du traitement prévue par le DPA. La liste actuelle, avec la finalité, les catégories de données et le lieu du traitement, est publiée séparément :

• Liste des sous-traitants ultérieurs

Aucun tiers ne participe à l’enregistrement lui-même : le script de suivi transmet exclusivement à l’infrastructure propre de MousePlayer. Pour les données des utilisateurs finaux, un destinataire existe au-delà : une copie quotidienne hors site de la base de données complète et de l’archive des enregistrements — y compris les enregistrements de session — est stockée chez Google (Google Cloud Storage, bucket à Varsovie). Elle y est conservée chiffrée depuis le 11 août 2026 : le chiffrement a lieu sur notre propre serveur avant le transfert (rclone crypt) et couvre également les noms de fichiers et de répertoires ; les clés sont détenues par MousePlayer. Google ne les reçoit pas et ne peut pas lire le contenu, mais demeure un sous-traitant ultérieur — le chiffrement est une mesure technique, pas un changement de rôle. Le précédent dossier de destination non chiffré contenant les copies antérieures au 11 août 2026 a été supprimé le 12 août 2026.

8. Conservation et effacement

La conservation des enregistrements de session dépend du niveau d’abonnement du Client :

• Free : 7 jours · Small : 30 jours · Business : 90 jours · Enterprise : selon l’accord contractuel individuel.
• Après un passage à un forfait inférieur, un délai de grâce d’au moins 30 jours s’applique, pendant lequel la durée de conservation plus longue du forfait précédent se poursuit. Un passage à un forfait supérieur ne raccourcit jamais la conservation.
• Le journal de l’application est effacé après 60 jours, les journaux du serveur web après 14 jours et les journaux de sécurité après 72 heures.
• Pour les sessions identifiées comme des accès automatisés, l’enregistrement est effacé après 1 jour et la session après 14 jours. Pour un compte au forfait Free signalé comme suspecté d’abus, seule une partie des visites est enregistrée et les enregistrements sont supprimés après 1 jour.
• Le journal de transmission des intégrations est effacé après 30 jours. Il réside dans Redis plutôt que dans la base de données et y expire de lui-même ; la liste est en outre plafonnée à 25 entrées par projet. Il ne fait donc pas non plus partie de la sauvegarde quotidienne.
• L’effacement à la fin d’une durée de conservation s’exécute automatiquement et sans intervention ; il n’a pas besoin d’être déclenché manuellement.

À la clôture du compte Client, toutes les données à caractère personnel associées sont effacées dans les 30 jours, à moins que le droit de l’Union ou le droit d’un État membre n’exige une conservation supplémentaire. La suppression est lancée par le Client dans les paramètres du compte ; aucune demande par e-mail n’est nécessaire. Elle archive d’abord le compte : l’accès prend fin immédiatement, plus rien n’est enregistré ni affiché, et pendant 30 jours nous pouvons encore le restaurer sur demande si la suppression était une erreur. Après ce délai, il est effacé définitivement ; lors du lancement de la suppression, le Client peut également choisir l’effacement définitif immédiat. Un projet ou un espace de travail supprimé par le Client est lui aussi d’abord archivé pendant 30 jours et peut être restauré dans le tableau de bord pendant ce délai. Trois éléments sont délibérément conservés, parce que la loi l’exige ou parce qu’ils documentent une décision plutôt qu’une personne : la preuve d’acceptation de ces documents, le journal de sécurité et des modifications (dont la référence à l’utilisateur a été supprimée), et les demandes d’assistance. Par exception, un compte au forfait Free resté inutilisé pendant 24 mois est effacé définitivement, sans archivage préalable, 30 jours après une notification remise.

Les preuves de consentement sont conservées au-delà de l’effacement de l’enregistrement lui-même. Elles ne contiennent aucune donnée comportementale, seulement le fait, l’heure et la source de la décision de consentement, et existent pour respecter l’obligation de responsabilité au titre de l’article 5, paragraphe 2, du RGPD.

9. Violation de données à caractère personnel

MousePlayer informe le Responsable du traitement sans délai indu et au plus tard 48 heures après avoir pris connaissance d’une violation de données à caractère personnel affectant les données du Responsable du traitement. La notification contient les informations dont le Responsable du traitement a besoin pour respecter ses propres obligations au titre de l’article 33 du RGPD.

Adresse de signalement des problèmes de sécurité : office@mouseplayer.com

10. État et version

• Version : 1.5 · Entrée en vigueur : 16 octobre 2026 · Prochain examen : 19 août 2027 · remplace la version 1.4 du 7 octobre 2026. Modifications : la section 2.2 nomme la connexion à double authentification, la liste des connexions actives avec révocation et l’alerte de connexion ; la section 2.3 nomme les rôles owner, admin et viewer ; la section 3 nomme les exceptions pour les adresses IP complètes ; la section 4.1 décrit les voies de transport du script et les connexions non chiffrées dans le réseau local au lieu d’affirmer qu’il n’existe aucun chemin non chiffré ; la section 4.3 nomme les autres interfaces ; la section 5 consigne que l’archive des enregistrements est sauvegardée depuis le 6 octobre 2026 et nomme les tests de restauration effectués et les limites de surcharge ; la section 8 ajoute des durées de conservation et la suppression des comptes inactifs. En outre, la section 2.2 indique l’état de la connexion SSH, et la durée du blocage automatique est donnée comme paramètre. La version 1.4 a remplacé la version 1.3 du 17 septembre 2026. Modifications : les sections 5 et 8 indiquent que l’effacement archive d’abord les données – retirées du traitement immédiatement – et les efface définitivement après 30 jours au plus tard. La version 1.3 a remplacé la version 1.2 du 19 août 2026. Modifications : la section 4.3 nomme les machines qui exécutent le modèle de langage pour les textes générés, la façon dont les constats y parviennent et ce qui se passe pendant la maintenance. La version 1.2 a remplacé la version 1.1 du 11 août 2026. Modifications : la section 5 indique la conservation des sauvegardes comme paramètre plutôt que constante, décrit le sort des effacements lors d’une restauration et consigne que le succès des sauvegardes et l’espace disque sont désormais surveillés automatiquement ; la section 6 ajoute la mesure du seuil de l’article 37.
• En cas de divergence entre les versions linguistiques, la version anglaise prévaut.