Snag : confidentialité, cookies et documents juridiques

Date : 3 octobre 2026.

Périmètre : site vitrine, application mobile, future application desktop et backend. Hypothèse : société française proposant ses services dans l'Union européenne.

Cette synthèse constitue une feuille de route, pas une certification de conformité ni un avis juridique. Les documents doivent décrire les traitements réels et être validés juridiquement avant commercialisation.

Document complémentaire : Checklist MEP, automatisations et SRE.

1. Documents à prévoir

Document	Rôle et statut	Emplacement recommandé
Mentions légales	Obligatoires sur le site professionnel : société, immatriculation, coordonnées, directeur de publication et hébergeur.	Pied de page du site ; accès depuis les applications.
Politique de confidentialité	Information sur les données, finalités, bases légales, destinataires, durées, transferts éventuels et droits.	URL publique, accessible sans compte ; paramètres des applications ; liens depuis les formulaires.
Cookies et autres traceurs	Description des stockages et traceurs effectivement utilisés et de leur gestion. Peut être une section de la politique de confidentialité.	Site et paramètres des applications, selon les technologies utilisées.
CGU	Recommandées pour encadrer comptes, collections, scans, partage et limites des estimations de prix.	Site et applications ; accessibles avant acceptation contractuelle.
CGV / conditions d'abonnement PRO	Conditions de vente adaptées au canal : prix TTC, essai, renouvellement, résiliation, rétractation, garanties applicables et médiation.	Avant souscription ; site et applications concernés.

Une politique commune est possible, avec des sections distinctes pour la vitrine, le mobile et le desktop. Elle doit expliquer leurs différences réelles.

Sources : Service Public : mentions obligatoires, CNIL : information et transparence.

2. Quand faut-il un consentement aux traceurs ?

• Stockages strictement nécessaires au service expressément demandé : exemption de consentement pour ces opérations. Documenter pourquoi elles sont nécessaires.
• Publicité, suivi marketing et mesure d'audience non exemptée : consentement préalable, avant activation.
• Certaines mesures d'audience peuvent être exemptées, uniquement si toutes les conditions applicables sont respectées.
• Une solution annoncée comme "sans cookies" n'est pas automatiquement dispensée de consentement.
• Les règles concernent aussi les SDK mobiles et les lectures ou écritures dans le terminal desktop.

Lorsqu'un consentement est nécessaire :

• proposer accepter, refuser et personnaliser, sans rendre le refus plus difficile ;
• laisser les finalités facultatives désactivées avant le choix ;
• bloquer réellement les traitements concernés avant accord ;
• conserver une preuve du consentement et mémoriser également le refus ;
• permettre de retirer le consentement facilement depuis le site ou les paramètres.

Le cache Redis des prix côté serveur n'entraîne pas, à lui seul, un besoin de bandeau cookies : ce n'est pas un traceur déposé dans le terminal de l'utilisateur.

Source : CNIL : cookies et autres traceurs.

3. Parcours à prévoir dans Snag

Créer un espace Paramètres > Confidentialité dans les applications mobile et desktop :

• politique de confidentialité et documents juridiques ;
• gestion des traitements facultatifs, s'ils existent ;
• accès à la procédure d'exercice des droits et à l'export lorsque le droit à la portabilité s'applique ;
• suppression du compte et explication des éventuelles conservations justifiées.

Informer clairement les utilisateurs sur :

• les données qui restent sur l'appareil et celles envoyées au backend ;
• l'envoi des photos de scan au serveur, les destinataires et leur conservation ;
• les photos conservées pour le diagnostic et toute éventuelle réutilisation pour l'amélioration des modèles ;
• la synchronisation des collections, les journaux et les identifiants de compte ou d'appareil ;
• le calcul et l'historique de valorisation de la collection ;
• les statistiques de scans, en distinguant compteurs agrégés et éventuel suivi individuel ;
• les informations rendues visibles par le partage public d'une collection ;
• les prestataires qui reçoivent effectivement des données.

Demander la permission caméra au moment utile. Une permission Android/iOS ne remplace pas automatiquement un consentement RGPD. La politique de confidentialité informe : son acceptation ou celle des CGU ne constitue pas un consentement global aux traitements facultatifs.

Source : CNIL : permissions dans les applications mobiles.

4. Déclarations dans les stores

• Apple : politique accessible dans l'application et sa fiche ; déclarations App Privacy conformes au fonctionnement réel, SDK compris.
• Google Play : politique accessible dans l'application et sa fiche ; formulaire Data Safety exact et tenu à jour, SDK compris.
• Pour les applications permettant de créer un compte : prévoir la suppression dans l'application. Google demande également une ressource Web externe permettant d'engager la suppression.
• Une désactivation ne remplace pas une suppression. Expliquer les éventuelles données conservées pour des motifs légitimes.

Sources : Apple : App Review Guidelines, Apple : App Privacy, Google Play : données utilisateur.

5. Organisation et backend

Les pages juridiques ne suffisent pas. Il faut aussi :

• inventorier les traitements et tenir le registre applicable ;
• documenter les finalités et bases légales ;
• identifier les sous-traitants, prévoir les contrats nécessaires et encadrer les éventuels transferts hors EEE ;
• fixer puis appliquer les durées aux données, scans, journaux et sauvegardes ;
• gérer effectivement les demandes d'accès, rectification, effacement et autres droits applicables ;
• protéger les accès, communications et sauvegardes ;
• prévoir une procédure de gestion des violations, avec notification à la CNIL sous 72 heures lorsqu'elle est requise.

Le public TCG peut comprendre des mineurs. En France, pour les traitements concernés fondés sur le consentement dans les services en ligne, les moins de 15 ans nécessitent un consentement conjoint de l'enfant et du titulaire de l'autorité parentale. Ce seuil n'est pas une interdiction générale d'utiliser Snag avant 15 ans ; les règles contractuelles et celles des autres pays doivent aussi être examinées.

Sources : CNIL : premières étapes RGPD, CNIL : violations de données, CNIL : consentement des mineurs.

6. Valorisation des collections et statistiques de scans

Les fonctionnalités décrites ci-dessous sont des besoins à encadrer, pas une confirmation de leur implémentation actuelle. Elles doivent avoir des finalités distinctes dans le registre et la politique de confidentialité.

6.1. Valorisation privée de la collection

Calculer la valeur pour l'utilisateur peut généralement relever de l'exécution du contrat lorsque ce traitement est objectivement nécessaire au service demandé. La simple présence d'une fonctionnalité dans les CGU ne suffit pas à justifier cette base légale.

Documenter les données réellement utilisées : cartes possédées, quantités, état, langue, gradation, prix d'achat et éventuel historique de valorisation. Une collection et sa valeur rattachées à un compte constituent des données personnelles, même si le compte utilise un pseudonyme ou un identifiant technique.

• Garder la valorisation privée par défaut ; ne pas l'inclure automatiquement dans un partage public.
• Préciser les destinataires, la conservation, les modalités d'effacement et les droits applicables.
• Pour obtenir un prix externe, transmettre uniquement les caractéristiques nécessaires de la carte, sans identité du propriétaire ni inventaire complet si cela n'est pas nécessaire.
• Décrire les estimations et leurs limites dans les CGU : une valeur indicative n'est pas une garantie de prix de vente.

6.2. Compteurs agrégés de scans par carte

Pour mesurer la popularité des cartes, privilégier un compteur côté backend indépendant des comptes, par exemple :

Identifiant de carte | Jour | Nombre de scans

Ce compteur n'a pas besoin de contenir l'identifiant utilisateur, son adresse IP, un identifiant d'appareil ou la photo. Définir aussi ce qui est compté : scan demandé, réussi ou carte confirmée, afin de ne pas confondre tentatives et identifications.

• Éviter de conserver les événements individuels si le compteur suffit.
• Choisir une granularité et des seuils de publication qui limitent la possibilité de relier un résultat à une personne, notamment pour les cartes rarement scannées.
• Ne pas croiser ces compteurs avec les comptes, les collections ou les journaux identifiants pour reconstituer les comportements.
• Ne pas appeler les données "anonymes" sans vérifier l'absence raisonnable de possibilité de réidentification. Un identifiant haché reste généralement une donnée pseudonymisée.
• L'agrégation finale ne dispense pas d'encadrer les données personnelles éventuellement traitées en amont : finalité, base légale, minimisation et conservation.

Un compteur construit côté serveur à partir des requêtes de scan nécessaires au service ne crée pas, à lui seul, une obligation de bandeau cookies. Cela ne constitue pas une exemption générale pour un SDK de statistiques, une télémétrie supplémentaire ou d'autres accès au terminal.

6.3. Historique et suivi individuel

Usage	Encadrement à prévoir
Historique de scans proposé à l'utilisateur	Finalité de service distincte, données nécessaires et durée expliquées ; base légale à justifier selon le fonctionnement réel.
Analyse interne des usages reliée à un compte	Finalité et base légale propres. Si l'intérêt légitime est retenu, documenter nécessité, proportionnalité, mise en balance et droit d'opposition applicable.
Profilage marketing ou suivi via des traceurs non exemptés	Consentement préalable aux opérations concernées ; refus et retrait accessibles. Ne pas conditionner les fonctionnalités essentielles à ce suivi facultatif.

L'intérêt légitime au titre du RGPD ne remplace jamais le consentement requis pour un traceur non exempté. L'exemption de mesure d'audience doit être démontrée ; elle n'est pas acquise parce que les données servent à des statistiques.

6.4. Décisions à inscrire dans le registre et la politique

• Séparer les finalités "gestion et valorisation des collections", "historique personnel des scans" s'il existe, et "statistiques d'utilisation et de scans".
• Indiquer pour chacune les données, la base légale justifiée, les destinataires, la durée ou les critères de conservation et les droits applicables.
• Décider si des événements individuels sont réellement nécessaires et, si oui, leur durée courte et justifiée avant agrégation ou suppression. Aucun délai universel n'est fixé ici.
• Inclure les données personnelles dérivées, notamment la valorisation, dans les procédures de droits et d'effacement applicables.
• Ne conserver après suppression du compte des statistiques que si elles sont effectivement anonymes ; traiter séparément les éventuelles conservations personnelles légalement justifiées.
• Faire correspondre les déclarations des stores à la collecte réelle, y compris les événements envoyés par les SDK.

Architecture recommandée : valorisation privée par compte ; compteurs de popularité agrégés sans lien avec les utilisateurs ; pas de suivi marketing implicite.

Sources : CNIL : bases légales, CNIL : intérêt légitime, CNIL : anonymisation, CNIL : mesure d'audience des sites et applications.

7. Constat local et limites de vérification

Lors de l'inspection du 3 octobre 2026, la copie locale de snag-landing/app/legal/page.tsx contenait le texte d'attente "Contenu à intégrer" pour les rubriques juridiques. Les liens existaient, mais les textes définitifs ne figuraient pas dans cette copie. Ce constat daté ne décrit pas nécessairement les autres branches ou une version ultérieure.

Ce constat n'est pas une vérification du site déployé. Aucun audit complet des SDK, traceurs, durées de conservation, déclarations des stores ou parcours de suppression n'a été réalisé pour cette synthèse.

8. Priorités avant lancement

1. Inventorier les données, stockages, SDK et destinataires réels sur chaque plateforme.
2. Documenter les bases légales, durées et prestataires ; identifier les consentements réellement nécessaires.
3. Définir la séparation entre valorisation privée, historique personnel et statistiques agrégées de scans ; vérifier la minimisation et les risques de réidentification.
4. Remplacer les textes d'attente par les documents adaptés à Snag, avec ces finalités explicitement décrites.
5. Mettre en place les accès aux documents et les parcours de consentement, de droits et de suppression, y compris pour les données de valorisation et les historiques personnels.
6. Vérifier que les déclarations Apple et Google correspondent au comportement du produit.
7. Tester le refus, le retrait du consentement et la suppression de bout en bout, puis faire valider juridiquement les documents.

Objectif : une conformité cohérente entre les textes, l'interface et le backend, sans ajouter de bandeau de consentement inutile.