1. Responsable du traitement

Service :

Exploitant actuel :

Statut actuel :

Pays :

Site :

Contact :

Adresse postale : [À CONFIRMER AVANT PUBLICATION]

2. Données de compte

CardMatch utilise Supabase Auth pour l’identifiant d’authentification, l’adresse email, le hash du mot de passe et les métadonnées Auth minimales. L’email est présenté au titulaire dans les réglages et n’est pas destiné au profil public.

3. Profil

Le profil comprend le pseudo, un avatar CardMatch prédéfini, les préférences d’échange, le rayon et le statut de matching. Le pseudo, l’avatar et les éléments expressément projetés peuvent être visibles par d’autres collectionneurs ; les paramètres privés ne sont pas destinés au public.

4. Collection de cartes

Les cartes possédées comprennent des références de catalogue, un nom snapshot, la langue, l’état et la quantité. Elles servent à gérer la collection, la disponibilité et les correspondances.

5. Wishlist

La Wishlist contient les cartes recherchées, leur langue, leur état et les préférences utiles au matching.

6. Préférences trade / buy / sell

Les préférences d’échange, d’achat et de vente sont utilisées pour calculer et présenter des compatibilités. Elles peuvent apparaître dans les projections nécessaires aux participants concernés.

7. Localisation privée

Une position exacte, sa date de mise à jour et une zone générale peuvent être stockées. Le point exact sert au matching géographique côté serveur et n’est pas projeté vers les autres utilisateurs. Seule une zone générale ou un statut est exposé selon le contrat actuel. La fraîcheur de matching est de sept jours ; un point ancien reste stocké jusqu’à actualisation ou suppression du compte.

8. Matching

CardMatch traite les participants, statuts, compatibilités et snapshots nécessaires pour trouver et présenter des correspondances entre collections et Wishlist.

9. Matchs, propositions et transactions

Les propositions peuvent contenir des cartes, quantités, un montant CHF éventuel, un payeur, un statut et des confirmations. Elles sont accessibles aux participants concernés. CardMatch facilite la mise en relation mais ne réalise pas lui-même la remise ou le paiement des cartes physiques.

10. Messages

Les conversations liées à un match comprennent le corps, l’auteur, le match, l’horodatage et, après suppression de compte, un marqueur structurel. Les participants accèdent aux messages selon les autorisations du service. Une copie ponctuelle d’un message signalé peut être accessible à la modération autorisée.

11. Friendships

CardMatch stocke les paires d’utilisateurs et le statut nécessaires aux relations sociales. Ces informations sont limitées aux personnes concernées selon les fonctions prévues.

12. Utilisateurs bloqués

Le bloqueur, l’utilisateur bloqué et la date permettent d’empêcher certaines interactions. Le sens du blocage n’est pas divulgué à l’autre partie par le contrat de lecture prévu.

13. Signalements et modération

Un signalement peut comprendre le rapporteur, la personne signalée, une catégorie, une description facultative, un contexte et un snapshot facultatif du message. L’accès est limité au rapporteur et/ou aux administrateurs autorisés selon le contrat. La politique opérationnelle liée à l’expiration des preuves doit être définie.

14. Boutiques et Card Spots

CardMatch traite les comptes business, rôles, établissements, adresse publique, canaux officiels, profil, services, horaires, offres et éléments de vérification. Les Card Spots sont des lieux publics avec provenance, jeux/services et géométrie publique. Les données de workflow restent limitées aux membres et administrateurs autorisés.

15. Données techniques

Le code actuel contient des avertissements et erreurs techniques ponctuels. Un email de support initié par l’utilisateur peut inclure seulement la version de l’application, la plateforme et le système d’exploitation. Aucun SDK dédié d’analytics ou de crash reporting n’a été identifié dans les dépendances actuelles. Les journaux réseau, de build, Supabase ou d’hébergement doivent être vérifiés séparément.

16. Prestataires et infrastructure

Les composants confirmés ou préparés incluent Supabase (Auth, base, Realtime, Edge Functions), TCGdex (catalogue), GeoAdmin/swisstopo (recherche géographique et données publiques), Resend lorsque la vérification email boutique est utilisée, Google Maps lorsqu’un utilisateur ouvre volontairement une recherche externe, ainsi qu’Expo/EAS et les plateformes Apple/Google pour le build et la distribution.

Les régions, sous-traitants, contrats, transferts, journaux et durées propres à chaque fournisseur restent à vérifier.

17. Finalités

Les données servent à fournir l’authentification, le profil, la collection, la Wishlist, le matching, les propositions, les messages, les relations sociales, la sécurité, la modération, les fonctions boutique, le support et le fonctionnement technique. Les bases juridiques applicables doivent être déterminées lors de la revue juridique.

18. Conservation et suppression

Le dépôt confirme certains événements de suppression mais ne définit pas toutes les durées générales. Les durées des sauvegardes, logs, messages, activités, signalements, preuves, OTP et historiques doivent être validées avant publication.

19. Account Deletion

La suppression passe principalement par Réglages → Compte → Supprimer mon compte. L’identité Auth, le profil, la localisation privée, les cartes, la Wishlist et les relations personnelles couvertes par les cascades sont supprimés. Les matchs et propositions ouverts sont annulés. La suppression est bloquée si la personne est le dernier propriétaire actif d’une boutique.

Plus de détails figurent sur la page Suppression de compte.

20. Historiques partagés et anonymisation

Les matchs et transactions terminaux peuvent rester comme historique partagé après nullification des acteurs. Les snapshots de cartes peuvent rester sans référence personnelle. Pour les messages de l’auteur supprimé, l’auteur devient nul, le corps est vidé et un marqueur de suppression conserve la chronologie. Les références d’audit nullifiables peuvent disparaître tandis que l’événement, le statut, la méthode et l’horodatage restent.

21. Droits des utilisateurs

Selon le droit applicable et la situation, des droits relatifs à l’accès, la rectification, la suppression, la limitation, l’opposition ou la portabilité peuvent s’appliquer. La procédure, la vérification d’identité, les exceptions et l’autorité compétente doivent être validées juridiquement.

22. Contact confidentialité

Email confidentialité :

À défaut d’un contact distinct validé, le canal support ne doit être utilisé qu’après sa configuration et sa vérification.

23. Modifications de la politique

Les changements importants devront être datés, versionnés et communiqués selon une procédure validée. La version publiée ne devra pas contenir de marqueur de revue ou de valeur non configurée.