Un client industriel commande une armoire électrique. Il choisit une puissance, une tension et un environnement, puis ajoute des accessoires. Le configurateur accepte une combinaison que l’usine ne sait pas produire. Le tarif contractuel couvre l’armoire standard mais pas l’option marine. Le commercial corrige le devis dans un tableur ; au checkout, le site recalcule le prix public et promet une date impossible.
Ce problème ne vient pas d’un « gros catalogue ». Il vient du mélange entre identité produit, offre commerciale, assortiment client, configuration techniquement valide et prix négocié. Le risque devient visible lorsqu’une matrice de variantes, suffisante pour des tailles et couleurs, doit aussi créer une nomenclature, modifier un délai, exiger une validation ou changer la règle de prix.
Le vrai enjeu est de produire une décision prouvable : cette configuration était compatible, vendable à ce client, à cette date, pour ce montant et avec ce délai. Catalogue, configurateur et moteur de prix doivent partager identifiants et versions sans devenir une seule table impossible à faire évoluer.
Dans un projet de développement web sur mesure, cette séparation donne une architecture testable au commerce, à l’industrie et au support. Elle permet d’automatiser les cas déterministes tout en conservant devis et validation humaine pour les exceptions légitimes.
Séparer produit, offre et assortiment
Le produit décrit ce qui existe : identité, caractéristiques intrinsèques, unités et relations techniques. Une variante physique possède une identité distincte si elle change stock, fabrication, logistique ou conformité. Une traduction ou une photo ne crée pas un nouveau produit. Une configuration peut générer une référence connue ou un objet fabriqué à la demande.
L’offre décrit ce qui est proposé par une organisation, sur un canal, dans une zone et une période. Elle porte disponibilité commerciale, minimum, délai annoncé et conditions. L’assortiment limite les offres visibles ou commandables pour un client, un établissement ou un contrat. Il ne duplique pas les fiches produits pour cacher les autres.
Le modèle Product et Offer de Schema.org illustre la différence entre objet et proposition commerciale, sans dicter le schéma interne. Cette distinction reste utile pour éviter qu’une modification de contenu change un engagement de vente.
Nommer la configuration comme un objet
Une configuration conserve produit de départ, choix, règles évaluées, résultat, version et statut. Elle peut être brouillon, validée, expirée ou commandée. La traiter comme une chaîne JSON dans le panier empêche de contrôler ses transitions et de retrouver pourquoi elle était valide au moment du devis.
Stabiliser références et unités
Chaque produit possède un identifiant interne stable. GTIN, code ERP, référence fournisseur et code client vivent dans des espaces nommés, avec période de validité. Les spécifications générales de GS1 définissent le GTIN comme identifiant d’un article de commerce ; il ne remplace pas automatiquement l’identifiant d’une offre, d’un devis ou d’une configuration.
Les unités sont explicites. Un prix par cent mètres ne se compare pas à un prix par rouleau sans conversion possédée. Les dimensions portent unité, précision et règles d’arrondi. Une option modifiant le conditionnement peut changer l’unité commandable sans changer l’unité technique. Le calcul conserve les deux et leur conversion.
Les remplacements et fins de vie ne suppriment pas les anciennes références. Une relation indique successeur, compatibilité et date. Les commandes historiques restent rattachées à l’objet vendu. Un message tardif utilisant l’ancienne référence est résolu ou rejeté explicitement, jamais fusionné par similarité.
Composer des catalogues par contexte
Un catalogue est une sélection publiée, pas le référentiel universel. Il peut combiner marque, pays, organisation, segment, contrat et période. La résolution part du contexte authentifié et retourne les offres éligibles. Le filtre est appliqué côté serveur à la recherche, à la fiche, à l’export et au panier.
L’héritage réduit les répétitions : un assortiment reçoit le catalogue groupe puis exclut ou ajoute des offres selon une règle bornée. L’écran affiche source, surcharge et valeur effective. Retirer une surcharge revient à l’héritage ; il ne recopie pas la valeur actuelle et ne crée pas une divergence future.
Les dates d’effet et statuts permettent de préparer une publication. Une offre future n’apparaît pas dans les caches actuels. Deux publications incompatibles sur le même périmètre déclenchent un conflit. Le fuseau et la convention de borne sont décidés pour éviter qu’un tarif expire différemment selon le canal.
Modéliser un configurateur explicable
Le configurateur reçoit un produit de base, un contexte et une version de règles. Il propose les choix encore possibles, explique les incompatibilités et calcule un résultat. Il ne masque pas une option après coup sans motif. Chaque décision peut être rejouée depuis les entrées conservées.
Les règles sont classées : contrainte dure, recommandation, calcul, dépendance et validation humaine. « Tension 400 V incompatible avec moteur X » bloque. « Accessoire conseillé en extérieur » informe. « Au-delà de cette puissance, étude requise » bascule vers un devis. Mélanger ces niveaux transforme toute exception en message générique.
Contre-intuitivement, afficher toutes les options ne donne pas plus de liberté. Il oblige le client à découvrir les contraintes par erreurs successives. Une progression guidée, fondée sur les choix encore valides, réduit le bruit tout en laissant visible la raison technique.
Versionner sans invalider le passé
Une règle corrigée ne réécrit pas les configurations commandées. Les brouillons peuvent être migrés ou demander une revalidation. La configuration porte la version évaluée et un hash des choix utiles. Le système sait distinguer changement de libellé, modification de compatibilité et retrait d’une option.
Fermer contraintes et compatibilités
Les contraintes simples utilisent tables, domaines et relations. Les règles combinatoires appartiennent à un service de domaine testable. Une expression stockée en base n’est acceptable que si son langage, sa validation, son propriétaire et son débogage sont maîtrisés. L’interface ne doit pas devenir un langage de programmation sans gouvernance.
Les jeux de tests couvrent paires compatibles, exclusions, bornes, dépendances circulaires et absence de valeur. Pour chaque règle, un cas positif et un contre-exemple sont conservés. Les tests de propriété vérifient par exemple qu’aucune configuration validée ne contient deux options exclusives.
Une nomenclature générée porte composants, quantités, pertes éventuelles et version. Elle est comparée aux capacités de fabrication ou de stock. Le configurateur commercial ne promet pas un assemblage dont l’ERP ou le PLM refuse la structure. Les écarts entrent dans une file qualifiée avec la règle concernée.
Relier tarifs négociés et devis
Le prix final résulte d’un contexte : offre, client, quantité, contrat, configuration, devise, date et canal. Le moteur conserve prix de base, options, remises, surcharges, conversion, taxes et total. La priorité est explicite. L’ordre d’insertion des lignes ne doit jamais décider quelle remise gagne.
Un tarif négocié possède période, périmètre et version. Un devis capture une proposition calculée et peut autoriser certaines modifications. L’acceptation fige les éléments opposables. Si le client change quantité ou configuration au-delà de la tolérance contractuelle, le devis revient en révision au lieu d’être recalculé silencieusement.
Les règles incompatibles produisent un conflit. Par exemple, une remise de contrat exclusive peut interdire une promotion. Une surcharge de fabrication peut rester applicable. Le métier décide ces compositions. Le moteur les explique en composants lisibles par le commercial et par le support.
Figer la preuve au passage de commande
Le panier reste mutable. Avant commande, le backend revalide assortiment, configuration, prix, crédit et disponibilité nécessaires. Le résultat inclut version et délai. Une commande conserve le snapshot accepté : lignes, unités, options, composants de prix, devise, taxes, règle de livraison et références du devis.
Le paiement possède un identifiant stable. Après timeout, le système consulte le prestataire avant de retenter. La commande et la publication vers l’ERP sont idempotentes. Une réponse tardive ne crée pas une seconde commande. Les états « pris en charge », « accepté » et « à confirmer » ne sont pas confondus.
Un changement ultérieur devient une modification de commande, un avenant ou un retour selon le domaine. Il ne réécrit pas le snapshot. Cette chronologie permet d’expliquer au client pourquoi la fiche actuelle diffère du produit commandé sans qualifier arbitrairement l’historique d’erreur.
Cas concret : équipements et accessoires
Cas hypothétique : un fabricant vend des pompes avec moteur, joint, alimentation et capteurs. Les clients disposent d’assortiments contractuels et de tarifs négociés. Certaines combinaisons exigent une validation technique. L’ancien site stocke chaque combinaison comme une variante ; deux cent mille lignes sont générées, dont la majorité ne sera jamais commandée.
La cible conserve les composants stockés comme produits et représente la pompe configurable comme modèle. Les règles éliminent les choix incompatibles. Une configuration validée produit une nomenclature et un identifiant. Les offres définissent pays, segments et délais. Le contrat calcule prix de base, options et remise.
Le pilote couvre trois modèles, deux cents accessoires et vingt clients. Par exemple, si une configuration impossible atteint le panier, alors l’ouverture de la famille est suspendue et la version de règle est isolée. Les autres seuils locaux couvrent fuite d’assortiment, différence inexpliquée entre devis et commande et temps d’explication compatible avec le support.
La charge est testée sur les recherches et les changements d’option les plus fréquents. Le go est suspendu si la projection dépasse son budget de fraîcheur ou si une règle ne peut être reliée à un propriétaire. La réussite n’est pas le nombre maximal de combinaisons générées, mais le nombre de décisions sûres et explicables.
Implémenter modèles et projections
Le backend PHP et Symfony expose catalogue, configuration, devis et commande comme cas d’usage. Les entrées, sorties, responsabilités et contrats sont versionnés ; Doctrine protège identifiants et périodes. Messenger publie les changements avec idempotence, seuil de retry et journalisation des refus.
La recherche utilise une projection optimisée, reconstruisible depuis les sources. Elle contient contexte, version et fraîcheur. Ses dépendances, son budget de cache et son seuil d’écart alimentent l’instrumentation et le monitoring. Le rollback restaure la projection précédente sans modifier les commandes acceptées.
Les API retournent des erreurs actionnables : option incompatible, assortiment absent, version expirée ou devis à réviser. Elles ne retournent pas seulement « produit invalide ». La corrélation relie recherche, configuration, calcul, paiement et commande afin que le support retrouve le dossier depuis une référence client.
Sécuriser les droits et les données
Un prix négocié n’est jamais exposé par un cache partagé ou un identifiant devinable. Le contexte client est construit côté serveur. Les exports et tâches asynchrones répètent le contrôle. Les journaux conservent règle et version sans copier toutes les conditions commerciales sensibles.
Exploiter imports, conflits et reprises
Les imports portent schéma, lot, source et version. Ils valident références, unités, périodes et droits avant publication. Les rejets restent consultables avec un motif. Un lot corrigé reprend les lignes en erreur sans dupliquer celles déjà acceptées. Une balance rapproche nombre d’objets, offres, configurations et tarifs.
Le monitoring suit offres sans produit, règles en conflit, configurations expirées, prix sans provenance, files d’événements et actions manuelles. Chaque seuil déclenche une action : suspendre une publication, réduire le périmètre ou demander une validation. Un tableau rouge sans owner ne constitue pas une exploitation.
Le rollback retire une version future ou ferme une nouvelle règle. Il ne recalcule pas les commandes acceptées. Le retour au nominal traite d’abord configurations et paiements au verdict inconnu, puis l’arriéré. Le support dispose d’une vue de résolution avant toute réouverture générale.
Pour qui cette architecture est utile
Elle concerne fabricants, grossistes et distributeurs dont les produits, assortiments ou conditions varient par client. Produit, commerce, bureau d’études, supply, finance, data et support participent. Le métier possède compatibilité et prix ; la technique garantit modèle, performance et reprise.
Pour des variantes finies et peu nombreuses, une matrice standard suffit. Un moteur de règles serait disproportionné. Le configurateur devient utile lorsque les combinaisons ne peuvent pas être pré-générées raisonnablement, que leurs contraintes évoluent ou qu’elles produisent une nomenclature et un prix.
Le nombre de références n’est pas le seul critère. Cent produits hautement configurables peuvent être plus complexes qu’un million de références simples. La décision suit nombre de règles, responsabilités, contextes commerciaux et conséquences d’une erreur.
Éviter les erreurs fréquentes
Générer toutes les combinaisons
La croissance combinatoire crée des lignes inutiles et des mises à jour lentes. Pré-générez les variantes réellement stockées ; calculez les configurations à la demande avec contraintes, version et cache maîtrisé.
Dupliquer le catalogue par client
Les corrections se dispersent et les prix fuient. Composez assortiment et offre depuis un produit partagé, avec contexte et héritage visibles. Une exception contractuelle reste une règle datée.
Recalculer un devis accepté
Les règles actuelles ne prouvent pas le montant passé. Conservez le snapshot et la version. Une modification demandée déclenche une nouvelle proposition ou un avenant selon le contrat.
Décider le niveau de sophistication
Bloc de décision. Utilisez des variantes lorsque les combinaisons sont finies et stockées. Utilisez un assortiment pour limiter des offres existantes. Si les choix interagissent et produisent un résultat, alors utilisez un configurateur. En revanche, utilisez un devis lorsque validation, engagement ou négociation exigent une décision humaine.
Priorisez identité, compatibilité et preuve de commande avant la fluidité du configurateur. Différez l’automatisation d’une règle sans propriétaire. Refusez une combinaison lorsqu’aucun délai ou prix fiable ne peut être produit. Conservez plutôt un canal assisté pour les études rares que de simuler une certitude.
- Séparer produit, offre, assortiment, configuration et devis.
- Versionner contraintes, prix et snapshots acceptés.
- Automatiser uniquement les choix déterministes et testables.
- Étendre par famille et par client après une reprise prouvée.
Plan d’action sur huit semaines
Semaines 1 et 2 : reconstituer le réel
Choisissez vingt commandes, dix devis et cinq configurations refusées. Reconstituez produit, offre, assortiment, choix, prix et preuve. Nommez les propriétaires, identifiants, unités et règles. Mesurez corrections, délais et combinaisons réellement utilisées.
Semaines 3 à 5 : fermer le modèle
Construisez les concepts, périodes et versions. Implémentez les contraintes de trois familles. Faites calculer prix et nomenclature en observation. Comparez aux devis et commandes. Provoquez incompatibilité, règle future, unité erronée, message répété et tarif expiré.
Les écarts rejoignent des catégories : donnée, règle, mapping, prix ou propagation. Le support explique chaque cas depuis une référence. Une balance vérifie les imports. Les droits sont testés avec deux clients aux assortiments proches.
Semaines 6 à 8 : ouvrir une tranche
Ouvrez trois familles et vingt clients. Surveillez incompatibilités, temps de réponse, devis révisés, différences de prix et actions manuelles. Jouez rollback et reprise. Étendez lorsque le cycle commande complet reste explicable pendant une période représentative.
Le bilan ferme d’abord les configurations impossibles, puis les fuites d’assortiment, puis les divergences de prix. Une règle dont le propriétaire manque reste assistée. Les anciennes variantes sont retirées après observation de leurs consommateurs.
La revue finale reprend aussi cinq commandes anciennes et cinq configurations encore actives. Elle vérifie les unités, la version des contraintes, le tarif appliqué et la capacité à reconstruire la nomenclature. Toute divergence reçoit un owner et une date avant l’extension suivante.
- Partir de configurations et commandes réelles.
- Fermer identités, règles, unités et versions.
- Comparer la cible en observation avant l’écriture.
- Ouvrir par famille avec balance, support et rollback.
Approfondir prix et plateforme
Le guide des règles de prix B2B approfondit priorité, contrat et preuve. Le guide des limites de plateforme aide à décider ce qui reste standard ou devient une capacité dédiée.
L’observabilité métier complète l’ensemble pour relier règle, calcul et commande dans le run. Ces guides doivent être éprouvés sur une famille et un contrat réels.
- Relier chaque option à une contrainte et à une version.
- Conserver le devis accepté avec le snapshot de commande.
- Ouvrir une famille seulement après la reprise d’un import rejeté.
Conclusion : vendre une configuration prouvable
Un catalogue B2B complexe reste maîtrisable lorsque produit, offre, assortiment, configuration et devis ont chacun une identité et un cycle de vie. La complexité devient dangereuse lorsqu’une fiche ou un panier prétend porter toutes ces décisions.
Le configurateur doit expliquer ses contraintes, le moteur de prix ses composants et la commande le snapshot accepté. Les versions permettent de faire évoluer les règles sans réécrire le passé. Les cas non déterministes conservent une voie de devis possédée.
Le meilleur indicateur est la capacité du support à répondre : pourquoi cette combinaison était-elle vendable, à ce client, pour ce montant et ce délai ? Si la réponse exige un tableur privé, la chaîne reste incomplète.
Dawap peut vous accompagner pour concevoir et éprouver cette chaîne dans une démarche de développement web sur mesure : modèle catalogue, configurateur, tarifs négociés, migration, tests de compatibilité et préparation du run.
