Concevez un catalogue produit avec variantes et kits en utilisant des règles SKU claires, une logique d'inventaire et des modèles d'UI qui évitent les mauvaises combinaisons et la surfacturation.
Un catalogue a l'air simple quand chaque produit est un article unique avec un prix et un stock. Ajoutez la couleur, la taille, la durée d'abonnement ou un conditionnement spécifique à une région, et cette simplicité disparaît. Une seule table "Produit" ne peut plus répondre aux questions de base : quel est l'article exact que nous vendons et comment le suivons‑nous ?
Les acheteurs s'attendent aussi à ce que les détails soient exacts. Ils veulent choisir des options, voir le bon prix immédiatement et savoir si leur choix peut être expédié aujourd'hui. Si la page indique « en stock » mais que la taille sélectionnée est épuisée, la confiance chute vite. Si le prix change seulement au moment du paiement, les tickets support et les retours suivent.
Les bundles ajoutent une couche de complexité car ils ressemblent à des produits mais se comportent comme des règles. Un « Starter Kit » peut inclure une bouteille, une pompe et un jeu de filtres. Sa disponibilité dépend des pièces, et vos coûts et rapports doivent rester cohérents.
Signes que votre catalogue commence à craquer :
La solution est surtout de la discipline : un modèle de données cohérent et des modèles d'interface qui rendent la sélection d'options et la disponibilité évidentes pour les clients et votre équipe.
Quand on parle de « variantes », on mélange souvent plusieurs idées. Clarifier le vocabulaire tôt facilite ensuite les décisions (schéma, UI, inventaire).
La plupart des équipes utilisent ces définitions :
Les identifiants se confondent aussi en pratique. Un ID interne est ce que la base de données utilise. Un SKU est votre code opérationnel (préparation, réapprovisionnement, rapports). Un code barres (UPC/EAN) est ce que lisent les scanners. Un SKU peut avoir plusieurs codes barres (régions différentes), et certains articles n'ont pas de code barres du tout.
Une bonne règle pour décider si quelque chose doit être une variante vendable : si cela peut avoir un prix, un inventaire, un poids ou des règles d'expédition différents, traitez‑le comme vendable. Le même T‑shirt en Taille M et Taille XL a généralement besoin de comptes de stock séparés, donc ce sont des SKUs séparés.
Avant de choisir un schéma, commencez par les questions que l'entreprise doit pouvoir répondre chaque jour. Quand on regarde un article, peut‑on dire avec confiance : est‑il disponible maintenant, quel est son prix, comment sera‑t‑il expédié et quelles règles fiscales s'appliquent ?
Une façon utile de réfléchir est de décider où vit chaque « fait ». Mettez les informations partagées sur le produit, et les faits qui changent sur la variante (SKU). Si vous mélangez, vous finirez par corriger le même bug à deux endroits.
Questions qui décident généralement si un champ est au niveau produit ou variante :
Gardez une source de vérité. Par exemple, ne stockez pas le « prix » à la fois sur le produit et la variante à moins que les rôles soient clairs (produit = PDSF, variante = prix de vente réel).
Prévoyez le changement. Vous pouvez ajouter une option plus tard (par exemple « Longueur »), retirer une variante ou fusionner des SKUs après un changement de fournisseur. Cela se passe mieux lorsque les variantes sont des enregistrements de première classe, pas de simples étiquettes.
Si vous construisez dans AppMaster, un nommage clair des entités dans le Data Designer facilite la maintenance quand les exigences évoluent.
Un schéma propre garde le catalogue compréhensible quand un simple produit devient des dizaines de combinaisons vendables. L'objectif est de modéliser les choix (ce que le client choisit) séparément des éléments vendables (ce que vous stockez et expédiez).
Un ensemble d'entités fiable :
L'unicité des variantes est là où beaucoup de catalogues se plantent. L'approche la plus sûre est normalisée : faites respecter une OptionValue par Option pour chaque Variant, et empêchez les combinaisons dupliquées. Si vous voulez aussi de la vitesse, stockez une « clé de variante » calculée comme color=red|size=m (ou un hash) sur Variant et imposez‑la comme unique par Product.
Gardez les champs qui changent par combinaison sur Variant, pas Product : SKU, code barres, prix, prix de référence, coût, poids, dimensions, statut (actif/abandonné), et images (une image principale ou un petit ensemble d'images).
Pour les attributs personnalisés (comme « matériau » ou « instructions d'entretien »), évitez d'ajouter sans cesse de nouvelles colonnes. Un champ JSONB sur Product ou Variant fonctionne bien en PostgreSQL, associé à une petite couche de validation dans votre application.
Un SKU est un identifiant pour une unité vendable que vous vous engagez à garder stable. Il doit répondre à une question : « Quel article exact avons‑nous vendu ? » Il ne doit pas porter votre nom marketing, le texte complet des options, la saison ou toute une histoire. Si vous surchargez le SKU, il devient difficile de changer quoi que ce soit plus tard sans casser les rapports.
Décidez tôt si les SKUs sont assignés manuellement ou générés. Les SKUs manuels sont plus sûrs si vous avez déjà un ERP, des codes barres ou des SKUs fournisseurs à faire correspondre. Les SKUs générés sont pratiques si vous avez beaucoup de variantes et que vous avez besoin de cohérence, mais seulement si les règles ne changent pas en cours d'année. Un compromis courant est un SKU de base fixe que vous contrôlez, plus un suffixe court généré pour les attributs de variante.
Règles lisibles et durables :
Les SKUs supprimés ne doivent pas être effacés. Marquez‑les inactifs, conservez leur historique de prix et laissez‑les consultables dans les commandes passées, remboursements et rapports. Si vous remplacez un SKU, conservez un champ « remplacé par » pour que le support puisse tracer l'historique.
Les règles de validation évitent la détérioration lente : imposez l'unicité SKU sur tous les éléments vendables, autorisez seulement lettres, chiffres et tirets, définissez une longueur maximale claire (souvent 20–32 caractères) et réservez des préfixes pour des cas spéciaux (par exemple « BND- » pour bundles). Dans AppMaster, ces vérifications s'expriment bien comme contraintes de données plus un Business Process qui bloque les sauvegardes quand une règle est enfreinte.
L'inventaire devient confus quand le même « produit » peut signifier plusieurs unités vendables. Avant d'écrire des règles, choisissez votre unité d'inventaire : suivez‑vous le stock au niveau produit, variante ou les deux ?
Si les clients choisissent la taille ou la couleur, le niveau variante est généralement le plus sûr. Un T‑shirt peut être « en stock » globalement, mais la variante Petit‑Noir peut être épuisée. Le niveau produit fonctionne pour les articles où les variantes ne changent pas ce que vous stockez physiquement (par exemple une licence numérique avec différents plans de facturation). Certaines équipes gardent les deux : niveau produit pour le reporting, niveau variante pour la vente.
La prévention de la surfacturation n'est pas une option magique mais des états clairs. La plupart des catalogues ont besoin de réservations (retenir des unités brièvement pour les paniers ou commandes non payées), de précommandes (autoriser la vente avec date d'expédition claire), de buffers de stock (quantité cachée pour couvrir des délais de synchronisation) et de mises à jour atomiques (réduire le stock dans la même opération qui confirme la commande).
Les cas limites produisent du « stock mystère ». Les retours doivent réintégrer le stock seulement après inspection, pas quand une étiquette de retour est créée. Les articles endommagés doivent passer à un statut ou emplacement séparé pour ne pas apparaître vendables. Les ajustements de stock nécessitent une piste d'audit (qui a changé quoi et pourquoi), surtout si plusieurs canaux mettent à jour l'inventaire.
Les bundles et kits imposent une règle clé : ne décrémentez pas un enregistrement « bundle » si le bundle n'est qu'un regroupement. Décrémentez les composants à la place. Un 3‑pack doit réduire trois unités du même SKU ; un kit doit réduire une unité de chaque composant.
Exemple : un « Starter Kit » inclut 1 bouteille et 2 filtres. Si vous avez 10 bouteilles et 15 filtres, la disponibilité du kit est 7 parce que les filtres sont la limite. Le calcul basé sur les composants garde cohérence pour les rapports, les remboursements et le réapprovisionnement.
Dans AppMaster, cela se mappe proprement aux tables de variantes dans le Data Designer et à la logique de réservation/décrément dans le Business Process Editor, de sorte que chaque paiement suit les mêmes règles.
Les bundles sont l'endroit où les catalogues dérivent souvent vers des cas spéciaux. L'approche la plus simple est de modéliser les bundles comme des articles vendables normaux, puis d'attacher une liste claire de composants.
Une structure propre : Product (article vendable) plus BundleLines. Chaque BundleLine pointe vers un SKU composant (ou un produit composant plus une variante requise) et stocke une quantité. Les commandes affichent toujours « un article », mais vous pouvez l'étendre en pièces quand vous avez besoin du coût, de l'inventaire et du détail d'exécution.
La plupart des configurations de bundle correspondent à l'une de ces catégories :
Le prix est là où les équipes cassent souvent les rapports. Décidez d'avance ce qui apparaît sur la ligne de commande et ce qui alimente les rapports de marge et d'inventaire. Approches courantes : prix fixe du bundle, somme des pièces, ou somme des pièces remise selon des règles (par exemple « choisissez 3 articles, le moins cher à -50% »).
L'inventaire doit être tout aussi strict : un kit est disponible seulement si chaque composant requis est disponible en quantité suffisante. Pour le reporting, conservez deux vues de la vente :
Dans AppMaster, cela s'exprime naturellement : une table Bundle plus des lignes BundleLine, avec des Business Processes qui développent les composants au paiement et écrivent à la fois la vente du bundle et la consommation des composants dans une seule transaction.
Une bonne UI pour les options fait avancer les gens. Une mauvaise UI les fait deviner, rencontrer des erreurs et partir. L'essentiel est de guider les acheteurs vers une variante réellement achetable tôt, tout en montrant clairement ce que leurs choix changent.
Un modèle fiable présente les options (Taille, Couleur, Matériau), puis calcule et n'affiche que les choix qui restent possibles.
Au lieu de laisser le client choisir n'importe quelle combinaison et échouer au moment de l'ajout au panier, désactivez les combinaisons impossibles dès que l'utilisateur fait un choix. Par exemple, une fois que quelqu'un choisit Couleur = Noir, les tailles qui n'existent pas en Noir doivent devenir désactivées (sans être supprimées), pour que le client comprenne ce qui est indisponible.
Au fur et à mesure que la sélection change, mettez à jour les éléments les plus importants : prix (y compris le prix soldé et les remises de bundle), images principales (correspondant à la couleur ou au style sélectionné), statut de stock (stock exact de la variante, pas le stock générique du produit), délai de livraison estimé (s'il varie par variante) et éventuellement le SKU ou « code article » pour le support.
Gardez l'interface calme. Affichez quelques groupes d'options à la fois, évitez les énormes menus déroulants quand des boutons ou des pastilles fonctionnent mieux, et rendez la sélection courante évidente.
En admin, les utilisateurs ont besoin de rapidité, pas de jolies cartes. Une grille de variantes fonctionne bien : chaque ligne est un SKU, chaque colonne est une option ou une règle (prix, code barre, poids, stock, actif/inactif). Ajoutez des actions en masse pour les tâches courantes comme mise à jour des prix, basculement de disponibilité ou affectation d'images.
Si vous construisez cela dans AppMaster, une configuration pratique est une grille liée à votre table Variant avec des filtres (valeur d'option, statut actif, faible stock), plus une action de mise à jour en masse qui valide les règles avant sauvegarde.
Un flux de sélection doit sembler simple, mais il a besoin de règles strictes en coulisse. L'objectif est de toujours savoir quelle SKU exacte le client configure et s'il peut l'acheter tout de suite.
Chargez plus que le nom du produit et des images. Vous avez besoin de l'ensemble complet des valeurs d'option (Taille, Couleur) et de la liste des combinaisons valides qui existent en tant que SKUs.
Un flux fiable :
Un petit détail UI qui évite la frustration : désactivez les valeurs d'option impossibles dès que des choix précédents sont faits. Si Taille=M n'existe qu'en Noir, affichez les autres couleurs comme indisponibles une fois M sélectionné.
Pour les bundles, « en stock » n'est pas un seul nombre. Cela dépend des composants. La règle habituelle est :
bundle_available = minimum sur les composants de floor(stock_composant / qty_composant_par_bundle)
Exemple : un « Starter Kit » nécessite 1 bouteille et 2 filtres. Si vous avez 10 bouteilles et 9 filtres, la disponibilité du kit est min(floor(10/1)=10, floor(9/2)=4) = 4 kits.
Les messages d'erreur doivent être concrets. Préférez « Seulement 4 kits disponibles (les filtres limitent ce bundle) » plutôt que « En rupture ». Dans AppMaster, ce type de vérification s'exprime simplement dans un Business Process : calculez d'abord la variante correspondante, puis les limites du bundle, puis renvoyez un statut clair que l'UI affichera.
Les catalogues se cassent quand vous modélisez pour « tout ce qui pourrait exister » plutôt que « ce que vous vendrez réellement ». La façon la plus rapide de vous enfermer est de générer toutes les combinaisons d'options possible dès le départ, puis d'essayer de garder cela propre à mesure que le catalogue grandit.
Créer des variantes qui ne seront jamais stockées est le piège classique. Si vous avez 4 couleurs × 6 tailles × 3 matériaux, cela fait 72 variantes. Si seulement 10 seront vendues, les 62 autres enregistrements créent du désordre, invitent aux erreurs et ralentissent les rapports.
La tarification est une autre source silencieuse de bugs. Les problèmes commencent quand un même prix existe à plusieurs endroits (produit, variante, table de prix, table promo) sans source de vérité unique. Une règle simple aide : stockez le prix de base une seule fois, puis stockez des overrides seulement là où c'est réellement nécessaire (par exemple, une variante a un prix différent).
Les bundles et kits échouent dans l'inventaire quand vous décrémentez à la fois le bundle et ses composants. Si vous vendez un « Starter Kit » qui inclut 1 bouteille et 2 filtres, soustraire 1 kit et aussi 1 bouteille et 2 filtres rend le stock trop bas trop vite. Conservez le bundle comme article vendable, mais calculez la disponibilité et les décréments à partir de ses composants.
Les outils d'administration peuvent causer des dégâts s'ils permettent des données invalides. Ajoutez des garde‑fous tôt :
Enfin, prévoyez le changement. Ajouter une nouvelle option plus tard (par exemple « Largeur » pour les chaussures) est une migration, pas une simple case à cocher. Décidez ce qui arrive aux variantes existantes, comment les valeurs par défaut sont définies et comment les anciennes commandes conservent leur SKU et leur snapshot d'options.
Avant de lancer, passez en revue les choses qui cassent en conditions réelles : retrouver les SKUs, mettre à jour le stock et bloquer les achats impossibles.
Assurez‑vous que chaque SKU vendable est facile à trouver. La recherche doit le retrouver par nom, code SKU, code barre/GTIN et attributs clés (comme taille ou couleur). Si vous utilisez le scan en entrepôt, testez quelques scans physiques et confirmez qu'ils pointent vers le SKU exact, pas seulement le produit parent.
Soyez strict sur les endroits où le stock change. Choisissez une source de vérité (votre logique de mouvements d'inventaire) et assurez‑vous que chaque événement l'utilise : commandes, annulations, remboursements, ajustements manuels et assemblage de bundles. Si le stock peut être édité dans deux écrans ou deux workflows, la dérive est garantie.
Vérifications de lancement à effectuer :
Si vous construisez dans AppMaster, gardez les règles de mise à jour du stock dans un seul Business Process et appelez‑le depuis tous les chemins. Cette habitude simple évite la plupart des bugs d'inventaire.
Imaginez une boutique de prêt‑à‑porter qui doit encore sérieusement organiser son catalogue.
Vous vendez un T‑shirt avec deux options : Taille (S, M, L) et Couleur (Noir, Blanc). Chaque combinaison vendable est sa propre variante avec son SKU, son prix (si nécessaire) et son inventaire.
Dans le schéma, gardez un enregistrement Product pour « Classic T‑shirt », deux enregistrements Option (Taille, Couleur) et plusieurs enregistrements Variant. Chaque Variant stocke ses valeurs d'option sélectionnées (par exemple : Taille=M, Couleur=Noir) et le SKU (par exemple : TSH‑CL‑M‑BLK). L'inventaire est suivi au niveau Variant, pas Product.
Sur l'UI, réduisez les choix et évitez les impasses. Un bon modèle est : affichez d'abord toutes les couleurs, puis n'affichez que les tailles qui existent pour la couleur choisie (ou l'inverse). Si « Blanc + L » n'existe pas, n'autorisez pas sa sélection ou affichez‑la désactivée avec une notice claire.
Ajoutons un bundle : « Gift Set » qui inclut :
La disponibilité du bundle est limitée par le composant le plus contraint. Si le stock du Pack d'autocollants est 5, vous ne pouvez pas vendre plus de 5 bundles, même si les T‑shirts sont abondants. Si le bundle requiert une variante précise de T‑shirt (par exemple Noir M), la disponibilité du bundle est min(StockStickerPack, StockNoirM).
Étapes pratiques dans AppMaster :
Si vous voulez prototyper rapidement de bout en bout, AppMaster (appmaster.io) est conçu pour construire des applications complètes avec une logique métier réelle, ce dont dépend la sélection de variantes et les règles d'inventaire des bundles.
21 janv. 2026
8 min
20 janv. 20268 min
20 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
