Dès qu’un produit web doit gérer plusieurs catalogues, plusieurs tarifs et plusieurs organisations, le sujet n’est plus seulement fonctionnel. Il devient structurel. Le modèle de données détermine ce qui peut être réutilisé, personnalisé, audité et synchronisé.
Le danger consiste à dupliquer rapidement : un catalogue par pays, une table de prix par marque, une règle par entité. Cela fonctionne au début, puis chaque correction doit être répétée, chaque reporting devient fragile et chaque intégration demande une exception.
Un site e-commerce sur mesure ou une application métier connectée doit donc choisir un socle de données qui distingue les objets communs, les variantes locales et les règles d’application.
Pourquoi le modèle de données devient le vrai sujet
Les écrans peuvent masquer la complexité pendant quelques mois. Mais la donnée finit toujours par révéler les compromis : produit dupliqué, prix contradictoire, stock incohérent, référence absente, règle locale cachée.
Le catalogue porte plus que des fiches produit
Il porte des familles, attributs, médias, variantes, disponibilités, règles de publication, traductions, segments clients et relations avec les systèmes sources.
Le tarif porte plus qu’un montant
Il peut dépendre d’un client, d’un pays, d’une devise, d’une période, d’un volume, d’une promotion, d’un contrat ou d’un canal.
Clarifier ce qu’est un catalogue
Un catalogue peut désigner une base produit globale, une sélection par marque, une offre par pays ou une vue commerciale. Il faut choisir les mots avant de choisir les tables.
Distinguer produit, offre et publication
Le produit décrit ce qui existe. L’offre décrit ce qui est vendu à un public. La publication décrit ce qui est visible sur un canal. Les mélanger crée des doublons.
Prévoir les attributs communs et locaux
Certains attributs sont universels, d’autres dépendent du pays, de la réglementation ou du canal. Le socle doit les séparer sans rendre l’administration impossible.
Nommer les règles de visibilité
Un produit peut être actif dans le référentiel, mais invisible dans un pays, indisponible pour un segment ou réservé à un canal.
Séparer prix, règles tarifaires et conditions commerciales
Le prix affiché est souvent le résultat d’une chaîne de règles. Stocker seulement le résultat rend le système difficile à expliquer.
Identifier le prix de base
Le prix de base doit être relié à une devise, une période, une unité, une entité propriétaire et une source.
Modéliser les règles de transformation
Remise, majoration, taxe, frais, promotion et prix contractuel doivent être lisibles. Sinon, personne ne sait pourquoi deux clients voient deux montants.
Tracer le prix calculé
Pour le support, le commerce et la finance, il faut pouvoir expliquer quel prix a été appliqué, avec quelles règles et à quel moment.
Représenter les organisations sans dupliquer le produit
Pays, filiales, marques, business units, agences, entrepôts et canaux peuvent s’additionner. Le socle doit représenter ces niveaux sans créer une copie complète pour chacun.
Utiliser des périmètres
Un périmètre permet de dire qu’une règle s’applique à une entité, une marque, une région ou un canal, sans réécrire toute la donnée.
Prévoir l’héritage contrôlé
Une entité peut hériter d’une règle groupe, puis la surcharger. Cette surcharge doit être visible, justifiée et limitée.
Éviter les exceptions invisibles
Une exception cachée dans un champ libre devient presque impossible à tester, documenter et maintenir.
Choisir la source fiable par type de donnée
Le socle web ne doit pas forcément devenir la source de tout. Il doit savoir quelle donnée il possède, quelle donnée il consomme et quelle donnée il expose.
ERP pour certaines vérités
Stock, comptabilité, facturation, fournisseurs ou prix contractuels peuvent rester dans l’ERP. L’application web connectée ERP / CRM doit gérer synchronisation, erreurs et reprises.
Back-office pour enrichir
Des données de présentation, de segmentation, de visibilité ou de parcours peuvent être administrées dans le produit web si elles sont absentes du SI.
Référentiel pour stabiliser
Quand plusieurs outils consomment la même information, un référentiel clair évite les recalculs et incohérences.
Prévoir les écrans de gestion et de reprise
Un bon modèle de données peut échouer si les équipes ne savent pas l’administrer. Les écrans doivent rendre les relations compréhensibles.
Montrer l’héritage
Dans un back-office métier sur mesure, l’utilisateur doit voir si un prix vient du groupe, d’une entité locale ou d’une règle client.
Contrôler les modifications sensibles
Changer un tarif, une visibilité ou une règle de catalogue doit être tracé, validé si nécessaire et testable avant publication.
Prévoir les reprises
Un import en erreur, une règle mal appliquée ou une donnée source indisponible doit pouvoir être repris sans intervention technique lourde.
Gérer les variantes sans casser le socle
Le but n’est pas de refuser les différences. Le but est de les ranger au bon endroit.
Variante de contenu
Traduction, média, argumentaire ou description peuvent varier sans changer le produit lui-même.
Variante commerciale
Offre, prix, disponibilité et canal doivent être associés à un périmètre clair.
Variante réglementaire
Une règle imposée par un pays doit être identifiée comme telle pour éviter de la généraliser par erreur.
Les erreurs de modélisation qui coûtent cher
Les erreurs de socle sont rarement visibles le premier mois. Elles apparaissent quand le volume, les pays ou les équipes augmentent.
Copier les produits au lieu de factoriser
La duplication accélère le démarrage, puis ralentit chaque correction. Il devient difficile de savoir quelle fiche est la référence.
Mélanger prix calculé et règle
Stocker seulement le résultat empêche d’expliquer l’écart. Stocker seulement la règle empêche parfois l’audit. Les deux niveaux ont un rôle.
Créer des paramètres sans propriétaire
Un paramètre sans responsable devient dangereux. Personne ne sait s’il peut être modifié, supprimé ou étendu.
Guides complémentaires pour données et règles locales
Ces guides prolongent le sujet catalogue, prix et organisation.
Règles locales et devises
Le guide Comment gérer devises, taxes et règles locales dans une application web ? détaille les impacts prix, taxes et conformité.
Variantes produit
Le guide Comment modéliser des variations locales sans casser le cœur produit ? aide à choisir le bon niveau d’adaptation.
KPI comparables
Le guide Comment garder des KPI comparables entre entités qui ne travaillent pas pareil ? montre comment mesurer sans perdre le contexte.
Conclusion : le socle doit expliquer les différences
Un socle multi-catalogue et multi-tarif n’a pas vocation à rendre toutes les organisations identiques. Il doit permettre de comprendre ce qui est commun, ce qui varie et pourquoi.
Le bon modèle sépare produit, offre, publication, prix, règle, périmètre et source. Il donne aux équipes la capacité d’administrer, d’auditer et de corriger sans repartir de zéro.
Dawap accompagne les projets de site e-commerce sur mesure, d’application métier sur mesure et de back-office catalogue avec modélisation des données, intégration SI, règles tarifaires, écrans d’administration et supervision.
