Aller au contenu

Verticale Smartphone

La verticale Smartphone est la première implémentation industrielle complète de l’architecture CMonChoix Platform.

Elle spécialise les mécanismes génériques du Domain Core sans les remplacer et sert de référence pour les verticales suivantes.

Sommaire

  • Rôle
  • Frontières architecturales
  • Entrées et sorties
  • Attributs métier
  • Variantes et conflits
  • Résolution
  • Projection
  • Media Quality
  • Industrialisation
  • Invariants
  • Validation
  • Voir aussi

Rôle

La verticale Smartphone fournit les règles propres aux téléphones mobiles :

  • interprétation des modèles et générations ;
  • normalisation du stockage et de la mémoire ;
  • gestion des couleurs commerciales ;
  • distinction des variantes réseau ou matérielles ;
  • détection des conflits propres au domaine ;
  • enrichissement des résultats génériques du Resolver.

Elle réutilise les contrats et services communs de la Platform. Elle ne redéfinit ni le Domain Core, ni le Pipeline, ni les services d’écriture.

Frontières architecturales

Données normalisées
        │
        ▼
Domain Core
        │
        ▼
Verticale Smartphone
        │
        ├── règles métier
        ├── candidats spécialisés
        ├── conflits Smartphone
        └── attributs de projection
        │
        ▼
Resolver / Projection Builder

La dépendance reste orientée vers les composants génériques :

  • le Domain Core ne dépend jamais de Smartphone ;
  • Smartphone ne pilote pas le Runtime ;
  • Smartphone n’écrit pas directement en base ;
  • Smartphone ne contient aucun composant Frontend ;
  • Smartphone ne masque pas les états unknown, ambiguous ou conflict.

Entrées et sorties

Entrées

La verticale peut exploiter :

  • les identifiants normalisés ;
  • le titre et les attributs marchands ;
  • la marque et la famille produit ;
  • les candidats produits par le Core ;
  • les métadonnées de source ;
  • les signaux de qualité disponibles.

Sorties

Elle produit des éléments interprétables par les couches génériques :

  • attributs Smartphone normalisés ;
  • candidats enrichis ;
  • signaux de compatibilité ou de conflit ;
  • codes de raison déterministes ;
  • métadonnées d’audit ;
  • données spécialisées destinées à la projection.

La verticale ne produit pas seule une vérité persistée. La décision finale appartient au Resolver, puis l’écriture éventuelle aux Write Services.

Attributs métier

Les principaux attributs Smartphone comprennent notamment :

Attribut Exemples Usage
marque Apple, Samsung, Google garde-fou d’identité
modèle iPhone 16 Pro, Galaxy S25 identité principale
génération 15, 16, S24, S25 distinction de famille
stockage 128 Go, 256 Go, 1 To variante structurante
mémoire vive 8 Go, 12 Go variante matérielle
couleur noir, titane naturel, bleu variante commerciale
connectivité 4G, 5G, Wi-Fi compatibilité produit
état neuf, reconditionné contexte commercial

Une information absente reste inconnue. Elle ne doit pas être inventée à partir d’une valeur par défaut ou d’un rapprochement faible.

Variantes et conflits

Une variante Smartphone est généralement définie par une combinaison d’attributs tels que :

modèle + stockage + couleur + configuration matérielle

Les règles doivent distinguer :

  • un enrichissement compatible ;
  • une différence de variante ;
  • une ambiguïté ;
  • un conflit bloquant.

Exemples de conflits bloquants :

  • Pro contre Pro Max ;
  • Galaxy S25 contre Galaxy S25 Ultra ;
  • stockage explicitement incompatible ;
  • marque différente ;
  • famille produit différente.

Les couleurs proches ou synonymes peuvent être normalisées, mais une couleur incertaine ne doit jamais provoquer une résolution forcée.

Résolution

La verticale contribue à la résolution en fournissant des preuves métier au Resolver.

Les états de sortie restent ceux du contrat commun :

État Signification
resolved identité et variante suffisamment établies
unknown preuves insuffisantes
ambiguous plusieurs interprétations compatibles subsistent
conflict des preuves incompatibles empêchent la résolution

Chaque décision doit être accompagnée de codes de raison stables, par exemple :

smartphone.model.exact
smartphone.storage.compatible
smartphone.color.unknown
smartphone.variant.ambiguous
smartphone.model.conflict

Deux exécutions sur les mêmes données et la même version de règles doivent produire le même résultat.

Projection

La verticale fournit au Projection Builder les attributs spécialisés nécessaires à une représentation cohérente.

Exemple :

Canonical Identity
Apple / iPhone 16 Pro / 256 Go / Titane noir

Projection Frontend
Apple iPhone 16 Pro 256 Go — Titane noir

La projection :

  • ne résout pas l’identité ;
  • ne corrige pas silencieusement les données ;
  • n’invente pas une variante absente ;
  • conserve les états d’incertitude utiles à l’audit.

Media Quality

Les contrôles Media Quality appliqués aux smartphones suivent le modèle commun de la Platform :

observation → classification → rapport → décision explicite

Ils sont audit-first et non destructifs par défaut.

Une règle peut vérifier, par exemple, la cohérence entre :

  • la couleur normalisée ;
  • les signaux présents dans l’URL ou les métadonnées de l’image principale ;
  • les éléments disponibles dans la galerie.

Elle doit produire un résultat auditable tel que :

matched
mismatched
unknown_actual
ambiguous
replacement_not_found

La règle ne doit pas effacer ou remplacer directement une image. Toute mutation éventuelle passe par un chemin d’écriture explicite, gouverné et observable.

Industrialisation

La verticale Smartphone a servi à établir le cycle industriel de référence :

1. Définition du périmètre
2. Audit des données réelles
3. Implémentation des règles locales
4. Simulation
5. Comparaison avant/après
6. Validation des KPI
7. Activation contrôlée
8. Surveillance des régressions

Les Read Services doivent permettre d’examiner les résultats sans mutation. Les Write Services n’interviennent qu’après validation explicite.

Invariants

La verticale Smartphone doit toujours respecter les invariants suivants :

  1. aucune règle Smartphone dans le Domain Core ;
  2. aucune écriture directe depuis une règle métier ;
  3. aucune résolution forcée en cas de conflit fort ;
  4. aucun attribut inventé lorsque la preuve manque ;
  5. mêmes entrées et même version de règles, même résultat ;
  6. chaque décision importante possède une raison auditable ;
  7. Media Quality reste non destructif par défaut ;
  8. une évolution locale ne doit pas modifier le comportement des autres verticales.

Validation

Une évolution Smartphone est considérée comme validée lorsque :

  • les cas représentatifs sont couverts par des tests ;
  • les états unknown, ambiguous et conflict sont conservés correctement ;
  • les résultats sont déterministes ;
  • les KPI avant/après sont disponibles ;
  • les régressions sur les identités déjà résolues sont mesurées ;
  • les mutations éventuelles sont séparées de l’audit ;
  • les rapports permettent d’identifier chaque règle et chaque code de raison.

La verticale Smartphone reste une référence architecturale, mais elle ne doit pas devenir une source de conventions globales non prouvées sur plusieurs domaines.

Voir aussi