Cycle de vie des données

Consentement, exports et cycle de vie des données

Ce que Reylin collecte, ce que le retrait du consentement arrête, le contenu d’un export analytique et les limites de la suppression locale.

Pseudonyme ne veut pas dire anonyme

Le traceur utilise un identifiant aléatoire de visiteur dans le stockage de session du navigateur, uniquement après consentement. Il ne crée pas d’empreinte de l’appareil et ne lit pas automatiquement les valeurs des formulaires ou le texte des pages. Un identifiant de visiteur reste une donnée pseudonyme : un site peut l’associer à un paiement. Ne décrivez pas les parcours individuels comme anonymes.

Les libellés explicites de pages, campagnes sources, noms d’événements et valeurs énumérées ne doivent contenir ni données personnelles ni secrets. Les contrôles de syntaxe et listes de valeurs autorisées réduisent la collecte accidentelle, sans prouver qu’un libellé est anonyme. Le propriétaire du projet contrôle ces libellés. Le pays et l’identité des personnes ne sont pas déduits.

Accorder et retirer le consentement délibérément

N’appelez reylin.consent(true) qu’après autorisation de cette collecte par votre propre processus de consentement. Le traceur ne prend jamais cette décision à votre place. Le consentement n’est déduit ni d’un clic, ni d’une connexion à un compte, ni d’un achat. Les files de suivi constituées avant chargement ou avec consentement refusé sont abandonnées, pas conservées pour un rejeu ultérieur.

L’appel reylin.consent(false) déconnecte les observateurs de visibilité, efface l’identifiant du visiteur dans le navigateur et interrompt les requêtes en attente lorsque cela est pris en charge. Une requête déjà reçue par le serveur ne peut être rappelée en interrompant la requête du navigateur. Le retrait arrête le suivi futur dans ce navigateur ; il n’efface ni les enregistrements serveur existants ni les e-mails déjà acceptés.

// Connect these calls to your own consent manager.
reylin.consent(true);  // only after permission
reylin.consent(false); // withdrawal: stops future collection

Ce que contient l’export du projet

L’export JSON du projet est un export d’enregistrements analytiques : paramètres de collecte du projet, événements consentis, écritures du registre des paiements et remboursements. Il inclut un manifeste de périmètre explicite. Ce n’est pas un export complet du compte et il ne contient ni mots de passe, ni identifiants de session, ni secrets de jetons API, ni identifiants chiffrés de prestataires.

Les notes du stockage complémentaire, rapports enregistrés, enregistrements de livraison de notifications, historique de réception et de nouvelles tentatives des prestataires, lignes Google mises en cache et marqueurs de reçus supprimés sont exclus de cet export. Un Viewer disposant d’un accès au projet peut exporter ses données analytiques ; seul un propriétaire peut supprimer ou modifier les paramètres de collecte. Gardez les exports téléchargés privés et supprimez les copies lorsqu’elles ne sont plus nécessaires.

Exporter le compte section par section

Le panneau Data export inventorie séparément les sections du compte et des stockages complémentaires conservées localement. Il peut exporter les sections prises en charge en pages JSON bornées, notamment la configuration privée de l’espace de travail, les enregistrements de livraison des rapports, les lignes de recherche en cache, les instantanés d’abonnement et certaines métadonnées d’intégration. Seul le propriétaire connecté peut utiliser cette route de compte ; les rôles Viewer et les jetons API en lecture seule ne le peuvent pas.

Chaque page inclut la couverture et une liste explicite d’exclusions. Une base de données absente ou dont le schéma est incompatible est signalée comme indisponible, pas silencieusement comme une section vide. Mots de passe, empreintes d’identifiants, secrets de jetons, identifiants chiffrés des prestataires, données internes des workers et sauvegardes physiques sont exclus. Les notes et libellés rédigés par les utilisateurs peuvent eux-mêmes contenir des informations personnelles : protégez les fichiers téléchargés.

Il s’agit d’un export local délimité, pas d’une certification universelle d’exhaustivité juridique. Les pages sont générées séparément pendant que les écritures peuvent continuer, et non sous forme d’un instantané atomique de plusieurs bases. Téléchargez chaque page, conservez sa couverture et son horodatage, et n’utilisez la procédure de sauvegarde hors ligne que lorsqu’un opérateur a besoin d’un instantané système restaurable.

Conservation et suppression sont des opérations différentes

La conservation prévue par le forfait et l’action manuelle de conservation retirent les anciens JSON d’événements. Elles ne retirent ni les écritures du registre financier ni tous les reçus : identifiants d’événements, heures de réception d’ingestion et empreintes de contenu peuvent subsister pour préserver l’idempotence et éviter le double comptage de consommation. Cela ne promet pas que toutes les données pseudonymes expirent à la limite de conservation des événements.

La suppression d’un projet retire ses enregistrements locaux et les données complémentaires intégrées après vérification des workers actifs. La suppression du compte exige une vérification du mot de passe et des prérequis de nettoyage des prestataires et de la facturation. Les données chez les prestataires, exports téléchargés, e-mails déjà acceptés et sauvegardes nécessitent leur propre nettoyage. Un processus distinct de nettoyage de visiteur, réservé au propriétaire, coordonne des stockages locaux délimités ; ne le remplacez pas par le retrait du consentement et n’interprétez pas son achèvement comme un effacement physique ou universel.

Nettoyage local coordonné d’un visiteur

Un propriétaire de projet vérifié peut demander le nettoyage d’un identifiant pseudonyme de visiteur exact. La requête n’identifie pas une personne. Elle conserve une empreinte SHA-256 de suppression limitée au projet, et non l’identifiant cible brut, pour empêcher le rejeu d’un identifiant connu et sa réassociation aux paiements. L’empreinte reste une donnée pseudonyme, pas un chiffrement ni une anonymisation ; une personne disposant d’identifiants candidats peut tester ses hypothèses.

Le projet suspend temporairement la nouvelle collecte et le rapprochement financier. Des barrières locales aux transactions permettent aux workers existants de se terminer avant que des lots bornés retirent les événements correspondants et les enregistrements liés de reçu ou de flux, effacent l’association visiteur des paiements, nettoient les champs visiteur normalisés de la boîte de réception des prestataires et annulent les notifications du projet en attente. Montants, devises, identifiants financiers, horodatages, consommation agrégée des quotas et libellés d’attribution figés sont conservés.

Le nettoyage peut reprendre après interruption. Une tâche peut attendre un envoi d’e-mail actif ou incertain ; les messages acceptés ne peuvent pas être rappelés, et les envois incertains abandonnés nécessitent un examen contrôlé par un opérateur plutôt qu’un nouvel envoi automatique. Les autres projets peuvent continuer.

L’achèvement ne concerne que ce périmètre local défini. D’anciens reçus déjà purgés sans index de visiteur peuvent subsister. Les notes du propriétaire, les informations personnelles encodées par erreur dans les libellés d’attribution, les copies chez les prestataires, les exports téléchargés, les pages libres et le WAL de SQLite ainsi que les sauvegardes exigent un examen distinct. De nouveaux identifiants de navigateur ne peuvent pas être reconnus comme la même personne sans suivi d’identité, que ce processus n’ajoute pas.

Rapports par e-mail et prestataires externes

Les rapports ciblent uniquement l’adresse e-mail vérifiée du propriétaire. L’envoi est désactivé séparément par défaut, même lorsqu’un adaptateur d’e-mail existe. L’interface distingue les messages en file et ceux acceptés par le prestataire ; l’acceptation ne prouve pas leur arrivée en boîte de réception. Désactiver les rapports annule les tâches en file, mais ne rappelle pas un message déjà accepté par le prestataire. Les rapports dont l’envoi n’a jamais été tenté expirent après 24 heures. Les enregistrements de file dans un état terminal deviennent admissibles au nettoyage logique après 30 jours, par lots bornés en arrière-plan ; les réservations liées aux limites de livraison expirent après 32 jours. Un ordonnanceur arrêté ou surchargé peut retarder la suppression physique des lignes, mais les rapports périmés ne peuvent plus être envoyés.

Le traitement des paiements Stripe et la facturation de l’abonnement SaaS à Reylin sont des intégrations et flux de données distincts. Déconnecter une intégration empêche les futures lectures locales, mais ne prouve pas la suppression chez le prestataire. Google Search Console utilise une propriété explicitement autorisée et présente les données de recherche du prestataire, pas des revenus observés au niveau des mots-clés.

Avant de collecter des données clients réelles

Publiez une notice de confidentialité et un parcours de consentement exacts pour le déploiement réel, indiquant l’opérateur, un moyen de contact, les finalités, les prestataires concernés, la conservation et le traitement des demandes. Aucune identité d’opérateur, juridiction, base juridique ou coordonnée d’assistance n’a été inventée ici. Ce guide technique n’est ni une politique juridique validée ni une certification de conformité.

Vérifiez les contrôles d’accès en production, les réglages déployés des prestataires, la conservation des sauvegardes, le comportement de restauration et les procédures de suppression. Une suppression logique SQLite ne prouve pas un effacement physique dans les fichiers WAL, pages libres, instantanés ou systèmes externes. L’opérateur du déploiement doit établir et tester ces contrôles du cycle de vie.

Cette documentation décrit le code et ses limites ; elle ne confirme pas une connexion active. Les exemples techniques conservent leurs identifiants d’origine.