Verticale Wellness¶

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 Wellness. Elle ne prouve pas qu'un module Wellness existe actuellement dans le Runtime ni qu'il est utilisé pour les résolutions de production.

Une catégorie de navigation liée à la beauté, à la santé ou au bien-être ne constitue pas une preuve d'activation métier.

Rôle attendu¶

La verticale Wellness doit encapsuler les règles propres aux appareils de bien-être, de beauté et de santé grand public lorsqu'ils présentent une vraie valeur de comparaison produit.

Le périmètre potentiel peut couvrir, selon validation des données :

rasoirs électriques ;
tondeuses ;
sèche-cheveux ;
lisseurs ;
brosses coiffantes ;
balances connectées ;
tensiomètres ;
thermomètres ;
appareils de massage ;
autres équipements électriques ou connectés de bien-être.

Le périmètre exact doit être fixé avant industrialisation afin d'éviter une verticale fourre-tout.

Frontière architecturale¶

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

La verticale Wellness ne doit pas :

modifier le Domain Core ;
écrire directement en base ;
mélanger des familles de produits incompatibles uniquement parce qu'elles partagent un univers public ;
inférer une fonction médicale ou une conformité réglementaire non présente dans les données ;
forcer une identité lorsque la référence produit reste ambiguë.

Attributs à auditer¶

Les attributs structurants varient fortement selon la sous-famille. Ils doivent donc être validés sur des échantillons réels plutôt qu'imposés globalement.

Candidats fréquents :

Attribut	Exemples	Usage possible
marque	Philips, Braun, Dyson, Withings	conflit fort si incompatible
modèle	référence commerciale précise	identité principale
type de produit	rasoir, tondeuse, balance, tensiomètre	séparation de familles
alimentation	batterie, secteur	variante ou enrichissement
connectivité	Bluetooth, Wi-Fi	enrichissement ou variante selon produit
accessoires inclus	sabot, base, embout	peut distinguer un bundle
couleur / finition	noir, rose, chrome	variante commerciale éventuelle

Sous-familles¶

Une industrialisation robuste doit probablement distinguer plusieurs sous-familles plutôt que construire une logique unique trop large.

Par exemple :

Wellness
├── Grooming
├── Hair care
├── Connected health
└── Massage / comfort

Ce découpage est conceptuel. Il doit être confirmé par les données et l'architecture des verticales avant implémentation.

Conflits à préserver¶

Exemples de cas à laisser ambiguous ou conflict :

type de produit différent ;
référence de modèle incompatible ;
produit principal contre accessoire ou tête de remplacement ;
bundle contre appareil seul lorsque le contenu est structurant ;
sous-familles différentes partageant une marque ou un nom marketing ;
données trop génériques pour identifier le modèle.

Les statuts canoniques restent :

resolved ;
unknown ;
ambiguous ;
conflict.

Reason codes¶

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

wellness.model.exact
wellness.product_type.conflict
wellness.accessory.excluded
wellness.bundle.ambiguous
wellness.reference.unknown

Ces codes sont des exemples TARGET uniquement.

Projection¶

La projection Wellness doit refléter une décision métier déjà calculée.

Elle peut exposer le type de produit, la référence, les fonctions et attributs utiles à la comparaison, mais elle ne doit pas :

attribuer une fonction médicale non prouvée ;
fusionner appareil et consommable/accessoire ;
résoudre une identité à partir du seul univers public ;
masquer une ambiguïté de bundle.

Précaution sémantique¶

Les informations commerciales liées à la santé doivent rester exactement au niveau de preuve disponible dans les sources et les contrats métier.

La verticale ne doit pas transformer :

une description marketing en diagnostic ;
une caractéristique produit en promesse médicale ;
une catégorie marchande en classification réglementaire.

Cette règle protège à la fois la qualité des données et le rôle strictement comparatif de la Platform.

Industrialisation¶

Avant activation :

définir précisément les sous-familles couvertes ;
inventorier les données multi-marchands ;
mesurer les références fabricant et les collisions de modèles ;
séparer appareils, accessoires et consommables ;
définir les règles locales par sous-famille ;
auditer en lecture seule ;
examiner unknown, ambiguous et conflict ;
simuler les règles ;
mesurer les KPI et les régressions ;
intégrer au Runtime uniquement après validation.

Diagnostic¶

Pour une restitution incorrecte :

source
  ↓
normalisation
  ↓
type produit / sous-famille
  ↓
règles Wellness
  ↓
Resolver
  ↓
projection
  ↓
Frontend

Ne pas corriger une ambiguïté métier dans le thème ou dans la navigation.

Invariants¶

Wellness ne devient pas une verticale fourre-tout.
Les sous-familles incompatibles restent séparées.
Appareils, accessoires et consommables ne sont pas fusionnés par défaut.
Aucune propriété médicale n'est inventée.
Aucune règle Wellness n'écrit directement.
La navigation publique ne prouve pas l'existence d'un module Runtime actif.
Toute règle doit être déterministe, auditée et explicable.