Mis à jour le 12 octobre 2026
Cookies et traceurs
Version cookies-draft-2026-10-12 — texte provisoire, en cours de validation par un juriste
1. Ce que recouvre le stockage sur ton appareil
Un cookie est une information enregistrée par ton navigateur. Le stockage de session, le stockage local, IndexedDB et certains identifiants peuvent aussi relever des règles sur les traceurs. L’absence de cookie publicitaire ne suffit pas à conclure qu’aucun consentement n’est requis.
Cette page décrit le code et le dossier actuels, sans lecture de la configuration réelle ni audit réseau. [À VÉRIFIER : inventaire effectif des cookies, clés, durées et requêtes en production, y compris chez les prestataires].
2. Connexion et fonctionnement nécessaires de l’application
Les cookies de session liés à Supabase Auth servent à conserver la connexion, renouveler la session et protéger l’accès à ton compte. Ils sont nécessaires au service que tu demandes et ne servent pas à suivre ton activité publicitaire. [À VÉRIFIER : noms et durées réelles des cookies de session, dépendant du paramétrage de production].
La photo choisie peut être gardée temporairement dans IndexedDB de l’application, afin de reprendre l’analyse après connexion Google. Stockage identifié dans le code : base « berry », magasin « pending-photo », entrée « current ». Une heure correspond à l’expiration logique ; l’effacement intervient à la visite suivante de l’app et aux étapes prévues du parcours, pas automatiquement lorsque le navigateur est fermé. Les accords et leurs versions sont conservés côté service pour respecter tes choix.
La base invoquée pour le stockage de photo est sa nécessité au parcours expressément demandé ; [À VALIDER : qualification exacte au regard des règles de stockage terminal]. Cela ne dispense pas de recueillir l’accord requis avant l’analyse et l’envoi de la photo.
3. Mesure de la landing : fonctionnement actuel
Si PostHog est configuré, la landing mesure des événements explicites : visites, clics d’analyse, sélection/refus de photo, transfert vers l’application et étapes d’accès anticipé. L’identifiant PostHog est conservé en mémoire pour la durée de la page, sans cookie ni stockage persistant du SDK. Capture automatique, replay, heatmaps et profils identifiés sont désactivés dans le code. Les photos et e-mails ne sont pas destinés aux événements d’audience.
Le sessionStorage conserve séparément les paramètres de campagne, le site/page référent et la page d’arrivée afin de connaître la provenance de la visite. Cette conservation dure la session du navigateur, selon son comportement de fermeture/restauration. L’identifiant exact et les paramètres du projet doivent être vérifiés avant publication. Le code prévoit PostHog UE ; la suppression des IP dépend d’un réglage projet à confirmer.
Le démarrage actuel de la mesure landing dépend de la configuration PostHog, sans mécanisme préalable d’accord dans le code inspecté. Une mesure agrégée ou un identifiant en mémoire ne rendent pas automatiquement le traitement anonyme ou exempté. [À VALIDER : conformité, éventuelle exemption, base légale et nécessité d’un mécanisme d’accord/refus avant la mesure et le stockage d’attribution]. Si l’exemption n’est pas établie, la mesure concernée doit rester désactivée jusqu’à la mise en place de ce mécanisme. Aucun retrait landing opérationnel n’est affirmé ici.
4. Audience facultative dans l’application
L’application prévoit PostHog UE uniquement après ton accord dans « Compte » → « Accords ». Refuser ou retirer cet accord ne bloque pas le service. Les événements sont limités et pseudonymes, sans e-mail, photos, résultats ni réponses personnelles. Aucun enregistrement de session ou capture automatique n’est prévu.
Tu peux retirer ton accord dans le même menu. Le retrait bloque les futures transmissions concernées ; il ne supprime pas automatiquement les événements passés. Une demande d’effacement peut être adressée au contact de confidentialité. [À VÉRIFIER : activation réelle du SDK, modes de stockage et durées de conservation dans le projet PostHog de l’application].
5. Google, Stripe et réglages du navigateur
La connexion Google et les pages de paiement/portail Stripe se déroulent aussi sur les domaines de ces prestataires. Ils peuvent utiliser leurs propres cookies pour la connexion, la sécurité et le paiement, selon leurs politiques. Berry ne décrit pas ces cookies comme étant tous sous son contrôle. [À VÉRIFIER : liens vers leurs politiques applicables et inventaire des éléments intégrés au parcours].
Tu peux supprimer les données de www.berryskin.app et app.berryskin.app dans les réglages de ton navigateur. Cette suppression peut retirer la photo en attente et te déconnecter ; elle ne vaut pas suppression du compte serveur ni résiliation de l’abonnement. Bloquer les stockages nécessaires peut empêcher la connexion ou la reprise du parcours photo.
Pour toute question ou demande : contact@thinkber.com. Cette page sera mise à jour si les outils, finalités ou durées changent ; un nouvel accord sera demandé lorsqu’il est requis.