Appearance
Sources data et stratégie pricing
Date : 2026-05-13. Statut : stratégie canonique data et pricing. Migration source : condensé depuis poc-tcg-collector/doc/COMPETITOR_DATA_SOURCES.md, POKEMON_API_REVIEW.md et PTCG_ASSETS_REVIEW.md.
Modèle de base
Il n'existe pas une source TCG parfaite. Les apps sérieuses combinent quatre couches :
- Feeds communautaires metadata : cartes, sets, noms, numéros, images.
- Feeds marketplace : SKUs, prix, produits scellés, prix graded, contexte vente/listing.
- Sources de gap-filling : pages éditeurs, wikis communautaires, repos d'assets, curation manuelle.
- Boucle de correction utilisateur : les utilisateurs signalent les items manquants ou faux, et construisent le long tail dans le temps.
SKN doit assumer ce modèle explicitement. Le moat produit n'est pas de posséder chaque feed upstream. Le moat est de les normaliser, expliquer la confiance et rendre les corrections opérationnelles.
Rôles des sources actuelles
| Couche | Source | Rôle |
|---|---|---|
| Metadata cartes | TCGdex | Catalogue Pokémon primaire et multilingue |
| Images cartes | TCGdex / cache local | Source image carte actuelle, rehostée depuis notre stack |
| Exploration scellés | 1niceroli/ptcg-assets | Imagerie POC interne et référence de forme catalogue uniquement |
| Scellés + pricing candidat | pokemon-api.com / RapidAPI tcggopro | Source commerciale candidate pour scellés, Cardmarket, TCGPlayer et graded |
| Sold comps | APIs eBay ou ingestion contrôlée | Future source pour pricing basé ventes et confiance |
| Marché EU | Cardmarket | Cible long terme en direct, aujourd'hui via options provider/upstream |
| Peer-to-peer FR | Vinted / Leboncoin | Signaux premium plus tard, pas dépendance MVP |
| Sanity checks graded | PriceCharting, providers graded, signaux last-sold type GCC | Inputs futurs pour estimations graded |
Posture Pokémon
Pour les cartes Pokémon :
- TCGdex reste le feed catalogue primaire parce qu'il est gratuit, multilingue et déjà intégré.
- pokemon-api.com est un candidat fort pour scellés, données graded et prix marché, mais les termes, la forme réponse, les droits de cache et les quotas doivent être vérifiés avant dépendance production.
ptcg-assetsest utile pour des expériences internes de scan scellé, mais pas pour distribuer des assets en production sans permission ou changement de licence.
Pour les produits scellés :
- ne pas forcer les items scellés dans le schéma carte raw ;
- modéliser type produit, set, langue, région, source image et identifiants produit séparément ;
- garder la provenance source sur chaque produit et image ;
- cacher les assets seulement quand les conditions l'autorisent.
Principes pricing
SKN doit publier des estimations, pas des prix magiques.
Chaque observation de prix doit garder :
- source ;
- URL ou identifiant externe ;
- prix observé ;
- devise ;
- date de vente/listing ;
- vendu vs listing actif ;
- condition ;
- langue ;
- région ;
- classe item raw / graded / sealed ;
- grader et grade quand pertinent ;
- traitement shipping et frais quand connu ;
- flags de confiance.
Règles d'estimation :
- les données vendues pèsent plus que les listings actifs ;
- les données récentes pèsent plus que les anciennes ;
- les données même région et même langue pèsent plus que les données mismatchées ;
- Cardmarket asks, eBay sold comps et sources graded sont des signaux différents, pas des vérités interchangeables ;
- les estimations raw, graded et sealed doivent être séparées ;
- les estimations à faible liquidité doivent afficher une confiance plus faible ;
- chaque estimation doit être explicable dans l'UI.
Risques provider
| Risque | Impact | Mitigation |
|---|---|---|
| Pas de licence sur un repo d'assets | Impossible de redistribuer proprement en production payante | Usage POC interne seulement, demander permission ou remplacer |
| Changement quota/prix API | Imports ou pricing live instables | Cacher les observations, abstraction provider, sources backup |
| Outage provider | Prix ou scellés deviennent stale | Stocker snapshots et afficher fraîcheur data |
| Risque terms scraping | Fragilité légale et opérationnelle | Préférer APIs ou permission explicite en production |
| Hotlink protection | Images cassées ou usage contraire aux termes | Rehost seulement si autorisé, sinon assets sûrs/licenciés |
| Mismatch région | Prix non pertinents pour l'utilisateur | Pondérer EU/FR au-dessus d'US pour utilisateurs FR |
Guidance d'implémentation
Construire les intégrations provider derrière des contrats normalisés :
CatalogSourcepour cartes et scellés ;ImageSourcepour provenance image et règles de cache ;PriceObservationSourcepour observations marché ;PricingEstimatorpour estimations pondérées.
Les écrans mobile ne doivent pas dépendre de formes réponse provider. Le backend doit retourner des objets normalisés SKN avec métadonnées de source/provenance.
Prochaines étapes immédiates
- Pinner le feedback scan-case pour transformer les mauvais IDs en données de training et régression.
- Construire un catalogue lab scellé à partir d'un petit subset contrôlé.
- Créer les tables observation et estimate pricing avant d'ajouter beaucoup de providers.
- Vérifier la forme réponse scellé, les termes, les droits image et les quotas de pokemon-api.com.
- Décider la stratégie d'assets production-safe avant release publique payante.