Documentation

Appearance

Architecture des moteurs produit ​

Date : 2026-05-13. Statut : direction produit et carte d'implémentation.

SKN n'est pas seulement un scanner de cartes. La cible produit est une plateforme de collection, scan et pricing pour collectionneurs Pokémon-first et investisseurs en scellé. La marketplace arrive volontairement plus tard. Elle ne devient saine que lorsque l'identité des objets, la propriété en collection et la confiance pricing sont assez solides.

Thèse produit ​

L'avantage durable du produit :

  • identifier rapidement les cartes raw, les cartes gradées et les produits scellés ;
  • stocker la collection utilisateur comme un inventaire privé fiable ;
  • produire des prix pondérés transparents à partir de plusieurs sources marché ;
  • expliquer la confiance au lieu de prétendre que chaque prix marché est exact ;
  • rendre les futures actions marketplace naturelles, parce que SKN connaît déjà l'objet, le contexte de possession et la fourchette de prix juste.

Le "wow" utilisateur doit être : "cette app explique pourquoi le prix est celui-là."

Exemple :

SignalValeur
Estimation SKN42,00 EUR
Tendance Cardmarket39,50 EUR
Moyenne eBay vendu45,20 EUR
Liquidité EU récenteMoyenne
Confiance82 %

Les quatre moteurs produit ​

1. Identity Engine ​

L'Identity Engine répond : "Quel est cet objet ?"

Il couvre :

  • cartes raw ;
  • slabs et cartes gradées ;
  • produits scellés.

Les cartes raw utilisent la stack de reconnaissance actuelle : crop carte, embedding visuel, retrieval ANN, puis OCR/rerank plus tard.

Les slabs demandent deux reconnaissances :

  • l'identité de la carte intérieure ;
  • le label de grading : organisme, grade, numéro de certificat et texte du label.

Les produits scellés sont une classe d'objet séparée. Ils ont besoin de leur propre catalogue produit et de leur propre index. Les ETB, displays, booster bundles, tins, blisters et collections ne doivent pas être forcés dans la table des cartes.

2. Collection Engine ​

Le Collection Engine répond : "Que possède cet utilisateur, et quel est l'historique fiable de cette possession ?"

Il doit modéliser :

  • holdings possédés par l'utilisateur ;
  • type d'item : carte raw, slab, produit scellé ;
  • quantité ;
  • langue ;
  • condition ;
  • prix d'acquisition ;
  • date d'acquisition ;
  • emplacement de stockage ;
  • photos et preuves utilisateur ;
  • notes de provenance ;
  • snapshots de valorisation actuels ;
  • historique des changements.

La sécurité compte ici, car la base de collection peut révéler des actifs de valeur liés à une adresse physique. Posture par défaut :

  • les holdings utilisateur sont privés ;
  • les exports sont explicites ;
  • une mise en vente marketplace est opt-in ;
  • l'audit trail protège contre les modifications accidentelles ou malveillantes ;
  • le partage public ne doit jamais exposer le prix d'achat privé ni les métadonnées d'emplacement.

3. Pricing Engine ​

Le Pricing Engine répond : "Combien ça vaut, et avec quelle confiance ?"

Il doit ingérer des observations, les normaliser, puis publier des estimations explicables.

Sources candidates d'observation :

  • Cardmarket ;
  • eBay vendu ;
  • eBay listings actifs ;
  • TCGPlayer ;
  • PriceCharting ou providers de marché gradé ;
  • Vinted et Leboncoin plus tard pour les signaux peer-to-peer français ;
  • sources spécialisées graded quand disponibles.

Chaque observation doit garder :

  • source ;
  • URL source ou identifiant externe ;
  • prix observé ;
  • devise ;
  • traitement du shipping ;
  • traitement des frais si connu ;
  • condition ;
  • langue ;
  • classification raw / graded / sealed ;
  • grader et grade quand pertinent ;
  • date de vente ou date de listing ;
  • région ;
  • flags de confiance.

L'estimation ne doit pas être une moyenne magique. Elle doit être un résultat pondéré avec une explication :

  • les ventes récentes pèsent plus que les anciennes ;
  • les données vendues pèsent plus que les listings actifs ;
  • les données même langue et même région pèsent plus que les données mismatchées ;
  • les estimations gradées sont séparées des estimations raw ;
  • les estimations scellées sont séparées des estimations carte raw ;
  • les prix à faible liquidité doivent afficher une confiance faible.

4. Marketplace Engine ​

Le Marketplace Engine répond : "Cet item fiable peut-il être vendu ou acheté dans SKN ?"

C'est volontairement plus tard. Cela introduit :

  • réputation vendeur ;
  • modération des listings ;
  • preuves obligatoires de l'objet ;
  • paiement et payout ;
  • litiges ;
  • prévention de fraude ;
  • état d'expédition ;
  • possibles obligations KYC ou réglementaires.

La marketplace doit seulement se construire au-dessus des autres moteurs. Si l'identité, les preuves de collection et la fourchette de prix juste sont faibles, la confiance marketplace sera faible.

Posture data sources et licensing ​

1niceroli/ptcg-assets est utile pour un POC interne de produits scellés. Au 2026-05-13, le repo GitHub se décrit comme une collection d'images produits Pokémon TCG incluant packshots, Elite Trainer Boxes, collections, blisters, pins, logos, symboles, banners, mini-tins, tins et coins. Il n'a pas de licence GitHub déclarée.

Donc :

  • bon pour exploration locale et expériences d'indexation internes ;
  • pas sûr comme source d'assets redistribuables en production sans permission ou source de remplacement ;
  • utile comme référence de forme catalogue pour les types de produits scellés et les noms de fichiers ;
  • insuffisant seul, car c'est image-first, pas une base structurée de produits.

Pour la production, SKN a besoin soit d'une permission, soit d'assets sous licence, soit d'images uploadées par l'utilisateur, soit d'une stratégie asset légalement sûre.

Les sources pricing demandent la même posture. Le scraping et les APIs de pricing tierces doivent être évalués contre leurs conditions, quotas et droits de redistribution avant de devenir des dépendances production.

Premières slices d'implémentation ​

  1. Scanner lab UX : garder les cinq endpoints, mais rendre la surface de scan camera-first et déplacer la comparaison endpoints dans une bottom sheet.
  2. Boucle de feedback scan-case : stocker les cas correct / wrong / picked-match issus des vrais scans Android pour améliorer l'accuracy avec des preuves.
  3. POC produits scellés : créer un catalogue scellé séparé et un path /scan-sealed-lab en utilisant d'abord des assets sûrs pour usage interne.
  4. Schéma pricing : créer le modèle observation et estimate avant d'intégrer beaucoup de providers.
  5. Fondation sécurité collection : modéliser les holdings privés, l'historique de possession et les limites de partage avant les features marketplace.

Non-objectifs pour maintenant ​

  • Pas de marketplace production.
  • Pas de paiement.
  • Pas de redistribution publique d'assets issus de repos non licenciés.
  • Pas d'affirmation qu'un prix marché unique est une vérité absolue.
  • Pas de mélange des produits scellés dans l'index des cartes raw.

Docs liées ​