Enrichissement¶

Status: CURRENT

Vue d'ensemble¶

L'enrichissement complète les données normalisées avec des informations dérivées, explicables et reproductibles avant leur consommation par les composants métier, de qualité et de projection.

Il n'altère jamais la donnée source et ne décide pas à lui seul d'une identité produit. Son rôle est de produire des signaux supplémentaires, accompagnés de leur provenance et de leur niveau de confiance.

Stage
  ↓
Normalisation
  ↓
Enrichissement
  ↓
Identité / Qualité / Projection

Responsabilités¶

L'enrichissement peut :

extraire un attribut implicite depuis un titre ou une caractéristique ;
compléter un champ normalisé à partir d'une source autorisée ;
produire des indices techniques ou métier ;
préparer les entrées des Vertical Modules ;
fournir des éléments de preuve aux moteurs de qualité ;
signaler une ambiguïté ou un manque de donnée.

Chaque résultat doit rester attribuable à une règle, une source et une version d'algorithme.

Ce que l'enrichissement ne fait pas¶

Il ne doit pas :

fusionner des produits ;
choisir une identité canonique ;
masquer ou écraser silencieusement une valeur marchande ;
reconstruire une projection comme effet de bord ;
lancer une synchronisation ;
appliquer une règle d'affichage ;
transformer un score ou une hypothèse en mutation persistante implicite.

Modèle de données¶

Un enrichissement industriel distingue au minimum :

valeur observée
valeur dérivée
source / règle
confiance
reason codes
horodatage ou version de calcul

La valeur dérivée ne doit jamais rendre la valeur observée inaccessible. Lorsqu'une persistance est nécessaire, les deux niveaux doivent rester auditables.

Déterminisme et reproductibilité¶

À données, configuration et version de règles identiques, l'enrichissement doit produire le même résultat.

Toute dépendance externe doit être explicitement maîtrisée : version, cache, date de référence ou snapshot. Une réponse externe changeante ne doit pas rendre un audit historique impossible à reproduire.

Relation avec les Vertical Modules¶

Le mécanisme général appartient au Pipeline. Les règles spécifiques appartiennent aux Vertical Modules.

Exemples :

Smartphone : stockage, couleur commerciale, réseau ou SIM ;
Photo : monture, focale, ouverture ;
Printer : technologie d'impression ou consommable ;
Gaming : plateforme, édition ou compatibilité.

Une règle verticale ne doit pas fuiter dans le noyau générique sous forme de condition spéciale non documentée.

Relation avec Quality et Media Quality¶

Les enrichissements peuvent produire des éléments de preuve consommés par les composants Quality.

Pour Media Quality :

l'analyse doit être audit-first ;
un indice couleur, modèle ou variante reste une preuve, pas une autorisation d'écriture ;
l'image principale ne doit jamais être effacée sur la seule base d'un doute ;
une proposition de remplacement doit conserver ses raisons et son niveau de confiance ;
toute mutation éventuelle doit passer par un Write Service explicite et une politique validée.

Le moteur de qualité mesure et explique. Il ne doit pas transformer automatiquement une incertitude en perte de donnée.

Gestion des ambiguïtés¶

Lorsqu'une valeur ne peut pas être déterminée de manière fiable, le résultat attendu est une incertitude explicite :

unknown lorsque l'information est absente ou inexploitable ;
ambiguous lorsque plusieurs interprétations crédibles existent ;
conflict lorsque des preuves incompatibles sont observées ;
review_required lorsqu'une validation humaine est nécessaire.

Une valeur arbitraire ne doit jamais être choisie uniquement pour remplir un champ.

Exécution dans le Pipeline¶

L'enrichissement doit être chargé uniquement dans les contextes qui en ont besoin.

Le frontend public, les lectures admin simples et les commandes CLI purement informatives ne doivent pas charger l'ensemble du Pipeline par défaut. Le Runtime ou l'adapter ciblé déclenche la capacité d'enrichissement lorsqu'une action l'exige.

Observabilité¶

Une exécution d'enrichissement doit pouvoir exposer des métriques réconciliables, par exemple :

lignes analysées ;
valeurs déjà présentes ;
valeurs enrichies ;
inconnues ;
ambiguïtés ;
conflits ;
erreurs ;
temps d'exécution ;
répartition par règle et par verticale.

Les totaux doivent pouvoir être rapprochés du périmètre d'entrée.

Tests attendus¶

Les tests doivent couvrir :

le déterminisme ;
l'absence d'écriture implicite ;
la conservation de la valeur source ;
les cas inconnus, ambigus et conflictuels ;
les frontières entre Pipeline, Vertical Modules et Quality ;
les métriques et reason codes ;
l'idempotence lorsqu'une persistance contrôlée existe ;
la non-régression sur les verticales déjà certifiées.

Invariants¶

Une donnée observée reste accessible après enrichissement.
Toute valeur dérivée est explicable et versionnable.
L'enrichissement ne résout pas l'identité à la place du Domain Core.
Une incertitude reste explicite ; elle n'est pas remplacée par une valeur inventée.
Les règles verticales restent confinées dans leur module.
Les analyses Quality et Media Quality sont non destructives par défaut.
Toute écriture persistante est explicite, traçable et portée par un Write Service.
À entrée et configuration identiques, le résultat est reproductible.

Workflow de validation¶

Audit des données
  ↓
Règle d'enrichissement en simulation
  ↓
Mesure des inconnues / ambiguïtés / conflits
  ↓
Validation des KPI et des régressions
  ↓
Activation contrôlée
  ↓
Nouvel audit

Aucune règle importante ne doit être activée directement sur un historique déjà altéré sans régénérer d'abord les projections ou données nécessaires à une mesure fiable.