Master Data Management grossiste food PrestaShop : table souveraine

Le Master Data Management pour grossiste food est le maillon manquant de PrestaShop B2B : DLC, lots, calibres, allergènes, conditionnements variables — aucun de ces objets ne tient dans les Features natives. Après 193 projets PrestaShop, j'ai constaté qu'un grossiste agroalimentaire qui s'appuie uniquement sur Features et Combinations finit avec une donnée fragmentée, des libellés concurrents (« PAYS-BAS » vs « PAYS BAS », « RPC » vs « Chine »), et zéro capacité de filtrage côté front.

Sur la migration Palimex v2 (1 082 références sourcées Asie/Afrique), nous avons remplacé 4 features PrestaShop par une seule table MDM souveraine normalisée en lecture, avec 98 % de coverage produits. Cet article décrit le design ps_ac_product_spec, l'arbitrage flat-vs-EAV, le canonicalizer pays et le détecteur regex des 14 allergènes UE INCO.

Les problématiques MDM courantes chez le grossiste food

Cet article fait partie de notre dossier PrestaShop Headless › architecture.

Problématique	Cause principale	Impact métier
49 valeurs « pays d'origine » concurrentes pour 1 082 produits	Saisie libre dans Features sans contrôle vocabulaire	Filtres inutilisables, fiches incohérentes, défiance acheteur B2B
Allergènes stockés en JSON brut hétérogène	Champ libre fournisseur recopié sans normalisation	Non-conformité INCO 1169/2011, risque sanitaire, exposition juridique
DLC, lots et conditionnements absents du modèle PS	PrestaShop pensé B2C retail, pas grossiste alimentaire	Traçabilité lot impossible, FIFO inopérant, gaspillage
Calibres et poids variables non gérés	Combinations PS = SKU fixe, pas de tare variable	Facturation manuelle, écart commande / livraison, litiges
Données fournisseurs dispersées (Excel, mails, ERP)	Aucun référentiel central, pas de table autoritative	Time-to-market long, doublons SKU, marge érodée

Pourquoi les Features PrestaShop ne tiennent pas pour le grossiste food

PrestaShop a été conçu pour le retail B2C : un produit = un SKU = un prix = une fiche. Le grossiste agroalimentaire vit dans un autre monde. Une caisse de mangues séchées Vietnam 1 kg n'a pas la même DLC que la caisse arrivée trois semaines plus tôt, son poids brut varie de plus ou moins 3 %, son lot fournisseur conditionne la traçabilité sanitaire, et son origine doit respecter le Règlement INCO UE 1169/2011 sur l'étiquetage des denrées alimentaires.

Les Features PrestaShop (table ps_feature_value_lang) stockent un attribut texte par produit, sans contrôle vocabulaire, sans typage, sans index sur la valeur normalisée. Sur Palimex v2, j'ai trouvé en production :

• 49 valeurs distinctes pour le seul attribut « pays d'origine » sur 1 082 produits — dont « PAYS-BAS », « PAYS BAS », « Pays-Bas (UE) », « NL », « Hollande » désignant la même origine ;
• Acronymes politiques (« RPC » pour République Populaire de Chine) coexistant avec « Chine », « China », « CN » ;
• Composites parasites (« Vietnam / Thaïlande », « UE diverses ») qui cassent tout GROUP BY origin ;
• Bruit pur : libellés copiés depuis « voir liste des ingrédients » au lieu d'une vraie origine.

Ajoutez les Combinations PrestaShop, conçues pour décliner taille/couleur d'un t-shirt et inadaptées à un poids variable au gramme près ou à un lot/DLC hebdomadaire. Le verdict est sans appel : sans couche MDM dédiée, le catalogue dérive en quelques mois.

Design de ps_ac_product_spec : table flat plutôt qu'EAV

La tentation classique en PIM agroalimentaire est l'EAV (Entity-Attribute-Value) : une row par paire (product_id, attribute, value). Puissant mais pénible : chaque attribut affiché demande un JOIN ou un sous-select, et l'index sur 6 colonnes EAV coûte plus cher qu'on ne l'imagine. Pour un catalogue de 1 082 références avec environ 25 attributs métier stables, j'ai tranché en faveur d'une table flat :

1. Une row par produit dans ps_ac_product_spec, clé id_product (FK vers ps_product) ;
2. Un champ par spécification métier : origin_country_iso2, origin_country_label_fr, dlc_days, caliber_mm_min, caliber_mm_max, weight_net_grams_avg, allergens_inco_csv, lot_ref, packaging_unit, packaging_qty ;
3. Index ciblés sur les colonnes filtrables côté front (origin_country_iso2, allergens_inco_csv, dlc_days) ;
4. Aucune logique métier en colonne JSON : la doctrine DB-Only impose un champ scalaire par spec.

Ce design coûte une migration de schéma à chaque nouvel attribut, mais reste lisible, indexable, et permet à n'importe quel SQL ad hoc d'agréger sans gymnastique. Dans un projet récent pour un client épicerie fine CHR, j'ai mesuré un gain de 4× sur le temps de réponse des facettes catalogue après bascule EAV vers flat (de 480 ms à 110 ms sur un catalogue de 3 200 produits, mesure 2026).

Normalisation en lecture, pas en écriture : canonicalizer + détecteur regex

L'erreur stratégique sur ce type de migration est le backfill destructif : on lance un UPDATE ps_feature_value_lang SET value = 'Pays-Bas' WHERE value IN ('PAYS-BAS', 'PAYS BAS', 'NL') et on perd l'historique. Inacceptable dès que le fournisseur réapprovisionne avec son libellé d'origine, ou qu'un audit traçabilité réclame la valeur source.

Sur Palimex v2, j'ai inversé le flux :

• La donnée brute fournisseur reste intacte dans ps_feature_value_lang ;
• Un script Python (ac_normalize_specs.py) lit le brut, applique un canonicalizer pays (dictionnaire ISO 3166-1 + alias maison : RPC → CN, Hollande → NL, etc.) et écrit le résultat normalisé dans ps_ac_product_spec ;
• Pour les allergènes, un détecteur regex parcourt le champ ingrédients et cherche les 14 allergènes obligatoires de l'annexe II INCO 1169/2011 (gluten, crustacés, œufs, poissons, arachides, soja, lait, fruits à coque, céleri, moutarde, sésame, anhydride sulfureux, lupin, mollusques) ;
• Le résultat alimente allergens_inco_csv avec les codes normalisés, indexable, exploitable par un filtre front « sans gluten » fiable ;
• Tout produit dont la confiance regex est inférieure à 0,9 part dans une queue de validation manuelle.

Résultat sur Palimex v2 (avril 2026) : 98 % de coverage MDM sur 1 082 références, 49 valeurs pays ramenées à 31 origines ISO normalisées, 14 allergènes détectés sur 89 % des produits avec score de confiance ≥ 0,9. Les 2 % restants sont en queue manuelle catégorie producteur — donnée trop hétérogène pour un parsing automatique.

Les solutions MDM pour grossiste food sous PrestaShop

Solution	Complexité	Gain estimé
Table flat ps_ac_product_spec (1 row/produit, N colonnes scalaires)	Moyenne	4× temps de facettes, requêtes ad hoc lisibles
Canonicalizer pays ISO 3166-1 + alias maison	Faible	49 → 31 valeurs normalisées, filtres exploitables
Détecteur regex 14 allergènes annexe II INCO 1169/2011	Moyenne	89 % de détection automatique, conformité réglementaire
Champs DLC / lot / poids variable dans la table MDM	Élevée	Traçabilité sanitaire, FIFO opérant, baisse du gaspillage
Queue manuelle pour confiance regex < 0,9	Faible	Garde-fou humain sans bloquer 98 % du catalogue

« L'opérateur du secteur alimentaire responsable des informations sur les denrées alimentaires garantit la présence et l'exactitude des mentions obligatoires conformément au droit applicable, notamment la déclaration de tous les ingrédients ou auxiliaires technologiques énumérés à l'annexe II provoquant des allergies ou intolérances. »

Cette obligation impose au grossiste food une donnée allergène structurée, pas un champ texte libre. Sans table MDM normalisée, un audit DGCCRF est intenable et la responsabilité civile de l'opérateur engagée.

Conclusion : le MDM, infrastructure invisible du grossiste food

Le Master Data Management n'est pas un buzzword PIM : c'est la table souveraine qui rend possible un catalogue grossiste agroalimentaire fiable, conforme INCO, et industriellement filtrable. En remplaçant 4 features PrestaShop bricolées par une seule table flat normalisée en lecture, Palimex v2 a gagné en cohérence, en conformité et en vitesse de requête sans rien casser de l'historique fournisseur. Le pattern est réplicable pour toute épicerie fine, CHR ou import alimentaire B2B sous PrestaShop.

Pour aller plus loin, voir aussi Architecture PrestaShop B2B pour grossiste et PIM headless avec PrestaShop.

Vous souhaitez structurer un Master Data Management souverain pour votre catalogue agroalimentaire sur PrestaShop ? Discutons de votre projet : contact@alexandrecarette.fr