Verticale Toys¶

Statut¶

TARGET — verticale projetée, non certifiée comme module Runtime actif.

Cette page décrit le cadre de préparation d'une future verticale Toys. Elle ne prouve pas qu'un module métier Toys existe actuellement dans le Runtime.

La présence d'un univers ou de feuilles « Jeux & Jouets » dans la navigation publique ne constitue pas une preuve d'activation d'un moteur métier spécialisé.

Rôle attendu¶

La verticale Toys doit isoler les règles propres aux jouets, jeux de société et produits assimilés sans introduire de logique spécifique dans le Domain Core.

Les familles visées pourront notamment inclure :

jeux de construction ;
figurines ;
poupées ;
véhicules miniatures ;
jouets électroniques ;
jeux de plateau ;
jeux de cartes ;
puzzles ;
loisirs créatifs.

Le périmètre exact doit être validé sur les données réelles avant industrialisation.

Difficulté métier principale¶

Contrairement à certaines verticales techniques, l'identité produit peut reposer sur des signaux plus hétérogènes :

marque ou licence ;
gamme ;
nom commercial ;
numéro de set ou référence fabricant ;
édition ;
langue ;
nombre de pièces ;
âge recommandé ;
personnage ou franchise ;
format de boîte ou variante commerciale.

Aucun de ces attributs ne doit être considéré comme universellement structurant sans audit.

Frontière architecturale¶

Données normalisées
        ↓
Détection Toys
        ↓
Règles locales
        ↓
preuves / candidats / conflits
        ↓
Resolver générique
        ↓
Projection

La verticale Toys ne doit pas :

modifier le Domain Core ;
écrire directement en base ;
déduire une identité uniquement depuis une licence ou un personnage ;
confondre un produit principal avec un accessoire ou une extension ;
forcer une résolution lorsque plusieurs éditions restent plausibles.

Attributs à auditer¶

Candidats typiques :

Attribut	Exemple	Risque
marque	LEGO, Hasbro, Mattel	utile mais insuffisant seul
référence fabricant	numéro de set, SKU constructeur	signal d'identité fort si fiable
licence	Star Wars, Pokémon	famille, pas identité unique
édition	standard, collector, extension	peut créer une vraie variante produit
langue	FR, EN, multilingue	parfois variante commerciale structurante
contenu	nombre de pièces, cartes, figurines	contrôle de cohérence
âge	6+, 8+, 14+	attribut secondaire sauf cas particuliers

Conflits à préserver¶

Exemples de conflits à traiter explicitement :

référence fabricant différente ;
jeu de base contre extension ;
édition standard contre collector ;
produit complet contre accessoire ;
langue ou contenu incompatible lorsque l'édition est distincte ;
licence identique mais produit différent ;
données trop génériques pour départager plusieurs produits.

Les statuts canoniques restent :

resolved ;
unknown ;
ambiguous ;
conflict.

Reason codes¶

Une future implémentation devrait exposer des raisons stables, par exemple :

toys.reference.exact
toys.reference.unknown
toys.edition.ambiguous
toys.expansion.excluded
toys.language.conflict
toys.product_type.conflict

Ces codes sont des exemples TARGET, pas des identifiants Runtime certifiés.

Projection¶

La projection Toys doit refléter une identité déjà résolue et présenter les attributs utiles à la comparaison.

Elle ne doit pas :

fusionner des éditions ;
masquer une différence de langue structurante ;
transformer une extension en produit principal ;
corriger silencieusement une référence.

La navigation publique peut organiser les familles de jouets selon l'intention utilisateur. Cette organisation n'a pas vocation à remplacer les règles d'identité métier.

Une branche de navigation comme « Jeux de société » ou « Figurines » sert à la découverte publique ; elle n'est pas automatiquement une preuve suffisante pour résoudre l'identité d'un produit.

Industrialisation¶

Avant activation :

échantillonner plusieurs marchands et familles ;
mesurer la qualité des références fabricant ;
séparer produits complets, extensions et accessoires ;
analyser éditions et langues ;
définir les règles locales ;
auditer en lecture seule ;
inspecter les cas ambigus et conflictuels ;
simuler les changements ;
valider les KPI et les régressions ;
activer le module uniquement après preuve suffisante.

Diagnostic¶

Lorsqu'un jouet ou jeu est mal regroupé :

source marchande
    ↓
normalisation
    ↓
type produit / référence
    ↓
règles Toys
    ↓
Resolver
    ↓
projection
    ↓
Frontend

Ne pas utiliser la catégorie marchande ou le rendu Frontend comme substitut à une identité non résolue.

Invariants¶

La licence ne vaut pas identité produit.
Les extensions et accessoires restent distincts du produit principal.
Les éditions ambiguës restent ambiguës.
Aucune règle Toys n'écrit directement.
La navigation publique ne prouve pas l'activation du module.
Toute règle doit rester déterministe et auditable.