productdb.json : Source de vérité unique pour les données produits

Cet article explique comment productdb sert de source de vérité unique pour toutes les données produits, définissant les composants, les fonctionnalités, les règles de compatibilité et les nomenclatures dans un fichier centralisé.

Le problème : des données produits éparpillées

Les données produits peuvent être dispersées entre plusieurs systèmes :

  • Système d'inventaire : Coûts des pièces et niveaux de stock

  • Système ERP : Nomenclatures et données de fabrication

  • Site web : Descriptions et spécifications des produits

  • Comptabilité : Règles de tarification et de calcul des coûts

Lorsque les données sont dispersées, des incohérences apparaissent :

  • Le site web indique 16 Go de RAM, mais l'ERP dit 8 Go

  • La tarification utilise d'anciennes données de coût

  • Les nomenclatures ne sont pas synchronisées avec les produits réels

  • Les fonctionnalités ne correspondent pas à la réalité

Nous avons besoin d'une source de vérité unique que tous les systèmes consultent.

La solution : productdb.json

productdb.json est un fichier JSON qui définit chaque composant, ses fonctionnalités, ses règles de compatibilité et ses constituants. Tous les systèmes chargent ce fichier au démarrage.

Ce fichier est versionné dans Git, garantissant que tous les changements sont tracés et audités.

Structure du fichier

Le fichier est organisé par catégorie de composant :

{
  "Chassis": { ... },
  "Board": { ... },
# ... (détails d'implémentation omis)

Chaque catégorie contient des composants avec leurs propriétés.

Définition d'un composant

Chaque composant possède plusieurs propriétés :

Propriétés de base

class : Classe du composant pour l'appariement de compatibilité

"class": "THIN_MINI_ITX"

internal : Nom interne pour l'inventaire et la fabrication

"internal": "Chassis, Treo"

external : Nom client pour le site web et le marketing

"external": "Thinvent® Treo Mini PC"

weight : Poids physique en grammes

"weight": 590

Règles de compatibilité (allows)

Le champ allows définit quels composants peuvent être utilisés ensemble :

"allows": {
  "Board": [
    {"class": "THIN_MINI_ITX"}
# ... (détails d'implémentation omis)

Cela signifie :

  • Board : Seules les cartes mères de classe THIN_MINI_ITX sont compatibles

  • Flash : Seul le stockage flash de classe m.2_SATA est compatible

  • Accessories : Tous les accessoires sont compatibles

La compatibilité peut être spécifiée par :

Basée sur la classe (dynamique) :

{"class": "THIN_MINI_ITX"}

Basée sur l'ID de pièce (explicite) :

["N100", "N150", "i5-1335U"]

Nomenclature (constituents)

Le champ constituents définit les pièces qui composent ce composant :

"constituents": [
  {
    "Category": "Custom",
# ... (détails d'implémentation omis)

Cela permet :

  • Calcul des coûts : Somme des coûts de tous les constituants

  • Fabrication : Générer des listes de prélèvement pour l'assemblage

  • Inventaire : Suivre l'utilisation des composants

Fourniture de fonctionnalités (provides)

Le champ provides définit les fonctionnalités que ce composant apporte :

"provides": {
  "Operating Temperature": "0°C ~ 40°C",
  "Operating Humidity": "20% ~ 80% RH, non condensing",
# ... (détails d'implémentation omis)

Ces fonctionnalités sont agrégées parmi tous les composants d'une référence SKU pour créer la spécification complète du produit.

Exemple : Châssis Treo

{
  "Treo": {
    "class": "THIN_MINI_ITX",
# ... (détails d'implémentation omis)

Exemple : Carte mère N100

{
  "N100": {
    "class": "THIN_MINI_ITX",
# ... (détails d'implémentation omis)

Chargement de productdb.json

Le fichier est chargé au démarrage de l'application :

import json

with open(PRODUCTDB_JSON_PATH, "r", encoding="utf-8") as productdb_file:
    productdb = json.load(productdb_file)

Cela crée un dictionnaire en mémoire :

productdb = {
    "Chassis": {
        "Treo": { ... },
# ... (détails d'implémentation omis)

Tout le code consulte ce dictionnaire pour les données produits.

Accès aux données des composants

Obtenir un composant par catégorie et ID

chassis = productdb["Chassis"]["Treo"]
board = productdb["Board"]["N100"]
ram = productdb["RAM"]["8"]

Obtenir le nom externe

name = productdb["Board"]["N100"]["external"]
# Résultat : "Intel® N100 Processor"

Obtenir les fonctionnalités

features = productdb["Board"]["N100"]["provides"]
# Résultat : {"Generation": "12th", "Series": "N", ...}

Obtenir les constituants

constituents = productdb["Chassis"]["Treo"]["constituents"]
# Résultat : [{"Category": "Custom", "PartID": "base_treo", "qty": 1}, ...]

Validation des références SKU

Nous utilisons productdb.json pour valider les références SKU :

def check_sku(sku:str) -> bool:
    parts = sku.split("-")
    mapped_parts = map_parts_to_fields(parts)
# ... (détails d'implémentation omis)

Voir Structure SKU pour plus de détails.

Agrégation des fonctionnalités

Nous agrégeons les fonctionnalités de tous les composants d'une référence SKU :

def get_product_features(sku: str) -> dict:
    partids = sku.split("-")
    features = {}
# ... (détails d'implémentation omis)

Exemple :

SKU : Treo-N100-8-256-2H-W6-11P

Fonctionnalités :

- Format : Mini PC (de Treo)

- Génération : 12ème (de N100)

- Série : N (de N100)

- Cœurs : 4 (de N100)

- Mémoire principale : 8 (de 8)

- Stockage SSD : 256 (de 256)

- HDMI : 2 (de 2H)

- Système d'exploitation : Windows 11 Pro (de 11P)

Voir Extraction des fonctionnalités pour plus de détails.

Calcul des coûts

Nous calculons le coût d'une référence SKU en additionnant les coûts des constituants :

def calculate_cost(item: dict, partid: str) -> tuple:
    if "constituents" in item:
        # Article composite : somme des coûts des constituants
# ... (détails d'implémentation omis)

Ce calcul récursif gère les constituants imbriqués.

Articles composites

Certains composants sont composites (constitués d'autres composants) :

Exemple : Combo clavier + souris

{
  "KM": {
    "internal": "Keyboard + Mouse",
# ... (détails d'implémentation omis)

Cela permet :

  • Génération de nomenclature : Lister tous les composants nécessaires

  • Calcul des coûts : Somme des coûts du clavier + souris + dongle

  • Suivi des stocks : Suivre l'utilisation des composants

Mise à jour de productdb.json

Édition manuelle

Le fichier est édité manuellement dans un éditeur de texte ou un IDE. Les changements sont validés dans Git :

git add PATH_TO_FILE/productdb.json
git commit -m "Ajout de la nouvelle configuration de carte N150"
git push

Validation

Après édition, validez la syntaxe JSON :

python -m json.tool PATH_TO_FILE/productdb.json > /dev/null

Cela vérifie les erreurs de syntaxe.

Déploiement

Après le push sur Git, le fichier est déployé en production

L'application recharge le fichier au redémarrage.

Intégration avec d'autres systèmes

Site web

Le site web utilise productdb.json pour :

  • Générer les pages produits

  • Afficher les spécifications

  • Filtrer les produits par fonctionnalités

  • Générer des tableaux comparatifs

ERP

L'ERP utilise productdb.json pour :

  • Valider les références SKU

  • Générer les nomenclatures

  • Calculer les coûts

  • Suivre l'inventaire

Comptabilité

La comptabilité utilise productdb.json pour :

  • Calculer les coûts des produits

  • Générer les factures

  • Suivre le COGS (Coût des marchandises vendues)

Pipeline SEO

Le pipeline SEO utilise productdb.json pour :

Voir Vue d'ensemble du pipeline SEO pour plus de détails.

Avantages d'une source de vérité unique

1. Cohérence

Tous les systèmes utilisent les mêmes données. Aucune divergence.

2. Maintenabilité

Mettez à jour une fois, propagez partout. Pas besoin de mettre à jour plusieurs systèmes.

3. Auditabilité

Tous les changements sont tracés dans Git. Facile de voir qui a changé quoi et quand.

4. Testabilité

Les changements peuvent être testés en environnement de staging avant déploiement en production.

5. Simplicité

Un seul fichier à comprendre. Pas de schémas de base de données ou d'API complexes.

6. Performance

Le dictionnaire en mémoire fournit une recherche en O(1). Pas besoin de requêtes base de données.

7. Portabilité

Le JSON est lisible par l'homme et indépendant du langage. Facile à analyser dans n'importe quel langage.

Limitations

1. Édition manuelle

Les changements nécessitent une édition manuelle et des commits Git. Pas d'interface web pour les utilisateurs non techniques.

2. Redémarrage requis

L'application doit redémarrer pour charger les changements. Pas de rechargement à chaud.

3. Pas de validation

La syntaxe JSON est validée, mais la validation sémantique (ex : "cette pièce existe-t-elle ?") n'est pas automatique.

4. Concurrence

Plusieurs personnes éditant simultanément peuvent provoquer des conflits de fusion.

Références

Concepts techniques

Articles connexes

Résumé

productdb.json est la source de vérité unique pour toutes les données produits :

Structure :

  • Organisé par catégorie de composant (Châssis, Carte mère, RAM, etc.)

  • Chaque composant a des propriétés (classe, interne, externe, poids)

  • Règles de compatibilité (allows)

  • Nomenclature (constituents)

  • Fourniture de fonctionnalités (provides)

Avantages :

  • Cohérence entre tous les systèmes

  • Maintenabilité (mise à jour unique)

  • Auditabilité (tracé Git)

  • Testabilité (déploiement en staging)

  • Simplicité (un seul fichier)

  • Performance (recherche en mémoire O(1))

  • Portabilité (format JSON)

Cas d'utilisation :

  • Validation des références SKU

  • Agrégation des fonctionnalités

  • Calcul des coûts

  • Génération de nomenclatures

  • Pages produits du site web

  • Extraction des fonctionnalités pour le pipeline SEO

Cette approche centralisée garantit que tous les systèmes consultent les mêmes données produits, éliminant les incohérences et simplifiant la maintenance.

← Retour à l'index de la documentation