RGPD

Cette page décrit l'application du règlement (UE) 2016/679 (RGPD) dans BlockLucky : qui est responsable, sur quelles bases les données sont traitées, combien de temps elles sont gardées, et surtout ce que le code fait réellement quand un citoyen exerce ses droits. Le détail traitement par traitement est dans le registre des traitements ; les questions propres à la chaîne sont dans Blockchain et données personnelles. Elle ne constitue pas un avis juridique.

#Responsable et contacts

Ces informations figurent aussi dans la politique de confidentialité, commune au web (/confidentialite) et à l'application mobile (écran Legal) et rédigée dans frontend-web/src/content/legal.ts, ainsi que dans l'export JSON (controller). La désignation effective du DPO et l'adresse dpo@etherbay.fr sont à confirmer par la Ville.

#Données traitées

Aucune donnée bancaire n'est collectée. Le prénom et le nom ne sont saisis que si le citoyen les renseigne dans l'écran Données personnelles du mobile ; ils servent à l'affichage des paramètres et aux messages envoyés au support. La date de naissance, le numéro du document et, le cas échéant, l'adresse ne sont pas saisis, mais ils figurent sur les photos de la pièce d'identité jusqu'à la décision de la Mairie : ce sont alors des données d'identité civile, à protéger en conséquence. Le modèle complet est décrit dans Modèle de données.

#Bases légales

Le choix de l'exécution du contrat pour un service public communal, plutôt que la mission d'intérêt public, est à confirmer par le DPO (voir Points à valider).

#Durées de conservation

#Droits des personnes

#Accès et portabilité

GET /api/user/gdpr/export (authentifié) renvoie un document JSON construit par exportGdprData de backend/src/api/user/user.services.ts. Le web le propose depuis Profil, puis Données personnelles (frontend-web/src/app/(citoyen)/profil/rgpd/page.tsx) ; le mobile depuis Paramètres, puis Données personnelles, bouton « Télécharger mes données » (mobile-app/src/screens/settings/PersonalDataScreen.tsx).

L'export ne contient ni la clé privée chiffrée, ni l'empreinte du mot de passe, ni le secret TOTP, ni les empreintes des codes de secours. Il omet aussi des données qui devraient y figurer : préférences et quêtes stockées dans Redis, parrain et liste des filleuls, motif d'un refus de la pièce d'identité et dates de la demande. Les photos de la pièce n'y figurent pas ; elles sont de toute façon effacées dès la décision.

#Effacement

sequenceDiagram
    participant C as Citoyen
    participant A as API
    participant DB as PostgreSQL
    participant M as Email
    C->>A: "POST /api/user/gdpr/delete-request"
    A->>DB: "Token ACCOUNT_DELETION, SHA-256 du jeton, expire dans 24 h"
    A->>M: "Lien CONFIRM_URL et jeton TOKEN"
    C->>A: "POST /api/user/gdpr/confirm-delete (token)"
    A->>DB: "Transaction : anonymisation du compte, suppression du jeton"
    A->>A: "revokeAllForUser"
    A-->>C: "deleted, anonymized"

Le jeton de 32 octets aléatoires est stocké haché en SHA-256 ; seul l'email le contient en clair. Hors production, la réponse de delete-request contient aussi confirmationToken, pour faciliter les tests.

L'anonymisation, faite par anonymizeUserAccount de backend/src/api/user/user.repo.ts, modifie la ligne User :

La même transaction supprime la ligne IdentityDocument du compte, avec ses photos si la demande était encore en attente.

Ce qui n'est pas effacé :

Une fois l'email supprimé, ces données restantes ne permettent plus d'identifier directement la personne à partir de la base. Elles restent cependant pseudonymes, et non anonymes au sens strict : un tiers qui connaîtrait l'adresse du portefeuille du citoyen pourrait la retrouver dans Ticket.payerWallet. Le parcours est détaillé dans Suppression RGPD.

#Rectification

Le citoyen peut modifier son thème, sa langue et ses notifications. Sur le mobile, il peut aussi rectifier lui-même :

Le web ne propose aucun de ces deux écrans. Les autres rectifications passent par une demande au DPO, avec une réponse sous un mois.

#Consentement à la mesure d'audience

Sur le web, la mesure ne fonctionne qu'après un accord donné dans le bandeau de consentement. Le choix est enregistré dans bl.consent.choice du localStorage, avec sa date, pour 182 jours ; il se modifie à tout moment par « Gérer mes traceurs » (pied de page, /traceurs, /confidentialite). Tant que l'accord manque, trackEvent de frontend-web/src/lib/analytics.ts n'envoie aucun événement et la source UTM n'est pas enregistrée ; un refus efface celle déjà enregistrée. Le choix est propre à l'appareil et au navigateur. Il ne couvre pas les événements USER_LOGIN et USER_SIGNUP, enregistrés par le serveur à chaque connexion et inscription. L'application mobile n'envoie pas d'événement de parcours. Voir Analytique et consentement.

#Délai de réponse

Les droits d'accès, de portabilité et d'effacement sont en libre-service et immédiats. Les autres demandes sont traitées par le DPO dans le délai d'un mois prévu par le RGPD.

#Mineurs

La participation est réservée aux majeurs. Deux mécanismes coexistent :

Le citoyen envoie depuis /profil/identite sur le web, ou depuis l'application mobile, une photo du recto et du verso, après avoir coché sur le web une case de consentement à la consultation par la Mairie. Les images sont chiffrées à la réception, consultées par un agent sur la page Identités de l'espace Mairie, puis effacées à la décision ; le citoyen reçoit la décision par email, avec le motif en cas de refus, et peut envoyer une nouvelle pièce. Chaque consultation et chaque décision sont journalisées. Le détail technique est dans Autorisations.

Le contrôle a des limites à faire connaître :

• l'agent juge sur photo : aucun contrôle ne vérifie que la pièce est authentique ni qu'elle appartient à la personne qui joue ;
• l'API ne connaît pas la date de naissance : la décision est entièrement humaine et n'est pas réexaminée ;
• un achat direct sur le contrat, sans passer par BlockLucky, échappe au contrôle ;

La collecte d'une copie de pièce d'identité est un traitement sensible pour la CNIL, qui recommande de la limiter au strict nécessaire et de privilégier des solutions de vérification d'âge qui ne transmettent pas l'identité au service. La proportionnalité de ce choix et la nécessité d'une analyse d'impact sont à valider (voir Points à valider).

#Sous-traitants et transferts

Le fournisseur RPC voit passer les adresses de portefeuille et l'adresse IP du serveur, pas l'email.

#Sécurité du traitement

Les mesures de sécurité (article 32) sont décrites dans la partie Sécurité. En cas de violation de données, la procédure de notification à la CNIL sous 72 heures et d'information des personnes figure dans le plan de réponse aux incidents.

#Ce qui reste à faire