Objectif
Ce modèle propose un référentiel article prêt à l’emploi. Il décrit un produit sous toutes ses facettes : identification, classification commerciale, caractéristiques techniques, logistique, médias, fournisseurs, catalogues, prix et historiques. Ce n’est qu’un exemple : la structure est volontairement générique pour être adaptée à de multiples secteurs (industrie, BTP, négoce, retail) en quelques ajustements de libellés et de listes de valeurs.
Consolidé ou centralisé : deux usages possibles
Le modèle est neutre vis-à-vis du mode d’exploitation. Il peut être utilisé :
- En mode consolidé (golden record / vue 360°) : les données restent maîtrisées dans les applications source (plusieurs ERP, e-commerce, catalogues, PIM, etc.). Phoenix les rapatrie (tous les jours, complètement ou en mode différentiel suivant les sources), les réconcilie et les met en qualité, et met à disposition un référentiel agrégé, enrichi de lineage (mais aussi de fraîcheur et de date de modification), interrogeable par les autres applications. Aucune saisie n’est faite dans Phoenix : l’outil sert de point de vérité toujours à jour du référentiel article.
- En mode centralisé (MDM / PIM) : Phoenix devient la source de vérité. Les articles sont créés, enrichis et validés dans la plateforme, puis diffusés vers les systèmes consommateurs (site marchand, ERP, marketplace, partenaires EDI). Les workflows de validation, la gestion des attributs par sous-famille et les classifications ETIM trouvent ici tout leur sens (à activer dans le modèle).
Le passage d’un mode à l’autre — fréquent dans les projets MDM — ne nécessite pas de refonte du modèle : seules les règles d’écriture et les flux changent.
Modèle de données
Le modèle s’articule autour d’une table centrale article (identification, désignations courte/moyenne/longue, EAN, unité, conditionnement, gamme, tarif, statut, références de remplacement) à laquelle sont rattachées plusieurs grappes fonctionnelles :
- Classification commerciale :
familyetsubfamilystructurent l’arborescence produit. Chaque sous-famille pilote son propreattribute_group. - Marque et fournisseurs :
brandpour le constructeur,supplierpour les distributeurs, et la table de liensrelation_supplier_subfamilyqui précise quels fournisseurs sont habilités sur quelles sous-familles. - Attributs techniques :
attribute(tension, intensité, IP, calibre, couleur, dimensions…) et leurs valeurs par article dansattribute_value. Chaque attribut est rendu obligatoire ou non, avec ou sans liste de valeurs contrôlée. - Classification ETIM :
etim_classetetim_featurepermettent d’aligner le catalogue sur le standard international utilisé en e-commerce technique, via la table de jonctionetim. - Logistique :
storage(entrepôts) etlogistic(dimensions, poids, GTIN-14, unités par carton, volume) couvrent l’aval physique. - Catalogues et canaux :
catalogetarticle_cataloguegèrent l’appartenance d’un article à un ou plusieurs catalogues datés ;canaldécrit les couples (canal d’achat × canal de distribution) avec leur chaîne de prix net / brut / cession / TTC. - Médias et marketing :
media(images, PDF, vidéos, 3D) ettags(NEW, BEST_SELLER, PROMO, FIN_DE_VIE…). - Historiques de prix :
sale_price_historyetpurchase_price_historyconservent la trace des évolutions tarifaires par canal et par période.
L’ensemble représente une vingtaine d’entités reliées par des clés étrangères standard Phoenix, et se prête aussi bien à un import initial qu’à une synchronisation incrémentale.
Le modèle est traduit en français, anglais, allemand, espagnol, italien et polonais.
Règles qualité embarquées
Le modèle est livré avec quelques contrôles d’exemple, immédiatement opérationnels et faciles à étendre :
- Code EAN : contrôle de longueur et de format (13 chiffres).
- Unité de vente : liste de valeurs fermée pour éviter les variantes Un / Unité / unite.
- Quantité minimale de commande : bornée sur [0 ; 100].
- Poids : borné sur [0 ; 1000] (en kilogrammes).
- Statut article : valeurs contrôlées (Actif, Diffusé, Supprimé…) avec date de changement de statut.
- Date de tarif : format ISO obligatoire.
Le jeu de données fourni sur demande contient volontairement quelques anomalies (formats de date invalides, statuts hors liste, valeurs aberrantes) pour servir de cas d’école aux ateliers de qualité de données.
Règles de dédoublonnage
Un dédoublonnage applicable côté fournisseurs est livré, paramétré sur les zones suivantes :
- Code Article — valeur exacte — coefficient 1
- Désignation — distance de Levenshtein — coefficient 2
- Code EAN 13 — valeur exacte — coefficient 1
- Marque — valeur exacte — coefficient 1
Seuils de rapprochement : 89 % pour les suspicions de doublons, 97 % pour le rapprochement automatique. La même logique se transpose facilement à la table article si l’on souhaite détecter les doublons produit en provenance de plusieurs sources.
Traçabilité
Toutes les modifications, pour toutes les sources, sont tracées nativement par défaut.
Préalables techniques
- Version Phoenix minimale : 7.1.0.
- Créer un schéma dans une des bases de données supportées par le module et mettre à jour en conséquence le support physique fourni.
- Générer puis compléter la workplace avec le mda du modèle généré. Livrer l’ensemble du projet sur un environnement.
- Le jeu de données d’exemple est fourni sur demande
Pour quel projet ?
Ce référentiel constitue un bon point de départ pour :
- Un projet PIM à dominante technique (matériel électrique, plomberie, BTP, industrie).
- Une vue 360° article alimentée par plusieurs ERP ou pays/filiales (intégrant lineage et qualité au service de la gouvernance).
- Une migration ou une fusion de catalogues nécessitant un dédoublonnage outillé.
- La publication vers un site e-commerce ou une marketplace, avec gestion ETIM et médias.
Le jeu de données d’exemple, disponible sur demande avec les injecteurs MDM, comprend environ 2 000 articles, 30 marques, 50 sous-familles, 60 fournisseurs et plus de 4 000 médias — suffisant pour qualifier les écrans, les flux et les règles de gestion avant tout déploiement.
Modèle de données

