Sommaire
- Problème des variantes
- Des solutions ?
Bonjour
Ce journal s'adresse aux intégrateurs et utilisateurs d'ERP (Odoo, Frappé, Tryton, Dolibarr, Noalyss, …) ou de systèmes e-commerce (Prestashop, Magento, …). Voici la description d'un problème dans la conception des créations de variantes sur les articles. J'aimerai votre avis, chers collègues, sur la clarté de mon propos et sur la réflexion derrière.
Si vous n'êtes pas concerné, il est fort probable que vous n'y compreniez rien.
Problème des variantes
Les variantes sont basées sur des champs Attributs avec plusieurs valeurs possibles. C'est cohérent pour un fabricant ou un grossiste et ça convient pour vendre sur une marketplace. En revanche, ça crée des problèmes pour un détaillant avec un magasin physique. Et encore d'autres problèmes si le détaillant a un site e-commerce.
Dans la suite, je ne parle que du point de vue du détaillant, parfois vendeur en ligne. Il est utilisateur et veut du pratique.
Situation
Les variantes ont été imaginées avec des cas simples limités à des changement de couleur ou de taille (pour reprendre un exemple fréquent dans les docs). Les attributs sont donc des caractéristiques du produit. Ces caractéristiques deviennent automatiquement des filtres de recherche sur le site ecommerce.
Rigidité de conception
Les caractéristiques sont arbitraires, limitées et ne prévoient pas l'avenir
- Si on choisit la couleur pour définir une variante de chemise, on doit créer un nouvel article pour une chemise rayée.
- Des combinaisons couleur et taille n'existent pas toujours, et la disponibilité peut changer avec les années.
- Quand des nouvelles nuances de couleurs sont disponibles, faut-il les créer (bleu ciel, bleu turquoise, bleu outremer, bleu marine) au risque de multiplier les filtres n'aboutissant qu'à un ou deux articles ? Quelques années plus tard, on a tellement de nuances de couleur que le marchand fait des erreurs de sélection. Sans parler du fait que certaines nuances ne passent pas à l'écran. Du coup, est-il plus malin de les rassembler sous des termes englobant (bleu clair, bleu foncé) ? Mais dans ce cas on risque de se retrouver avec 3 bleus foncés sur le même article (marine, outremer, cobalt, …).
Ces caractéristiques ne tiennent pas compte de l'utilisation de l'article
Par exemple, sur une chemise de très grande taille on voudrait ajouter une caractéristique nommée "pour les géants" sur une chemise particulière ; autre exemple, les boulons dans les tailles extrêmes, n'ont pas les mêmes acheteurs.
On ne peut pas changer d'avis
Ces deux exemples précedents amènent à créer des articles différents au lieu de variantes. Donc définir des variantes d'articles avec des caractéristiques trop simples peut conduire à créer des articles différents, ce n'est pas très cohérent.
Si le détaillant décide de sortir une variante pour en faire un article isolé, il perd son historique d'achats-ventes, et là c'est absurde dans un ERP (il doit faire appel à l'intégrateur).
Problèmes pour le détaillant
(Le détaillant fait évoluer son bidule sans faire appel aux intégrateurs.)
Usage
On ne doit pas multiplier les attributs/caractéristiques, pour ne pas aboutir à des combinaisons inexistantes, particulièrement gênantes en e-commerce.
Usines, fabricant et fournisseurs n'ont pas la même vision des variantes que le détaillant. Dans les cas simples, c'est seulement un peu casse-pied.
On voudrait des filtres partout
Comme les caractéristiques créent automatiquement des filtres e-commerce, c'est tentant d'en ajouter pour créer facilement des filtres. Au delà d'aboutir à des fiches produits complexes, devoir compliquer une fiche produit pour créer des filtres de recherche est absurde.
Les attributs n'englobent pas toutes les caractéristiques
Les caractéristiques d'un article ne se limitent pas aux attributs, il y a le poids, le code-barre… et les champs créés par les intégrateurs. Résultat, les caractéristiques d'un article sont souvent réparties sur plusieurs onglets, c'est mauvais pour l'ergonomie. Et en plus c'est confus.
C'est non-seulement confus, mais les attributs finissent par avoir un comportement bizarroïde.
- Par exemple dans Odoo, on peut les rentrer sur plusieurs lignes pour ne pas créer de variantes (les attributs apparaissent séparées par des virgules).
- On les utilise pour créer un tableau comparatif sur le site ecommerce, mais ce tableau n'inclut ni les champs existant (poids, code-barre, référence interne, …) ni les champs créés par les intégrateurs. On en vient à se demander pourquoi certains trucs sont dans des champs et d'autres dans des caractéristiques et comment décider de ce qui va où.
Problèmes liés aux approvisionnement et à l'évolution B2B
C'est là que ça devient grave. L'évolution du commerce pousse les détaillants à ne jamais avoir de stocks nuls, à se renouveler et à proposer du choix, sinon les clients vont sur Amazon.
Pour garder du stock, il faut recommander souvent. Or c'est difficile, soit parce que le fabricant n'a pas toujours de stock, soit qu'il ait un minimum de commandes élevé. La solution c'est de multiplier les fournisseurs d'articles équivalents. Voire identiques ou avec des différences très mineures, puisque on a de plus en plus d'articles créés par les usines pour plusieurs "fabricants". Cette multiplication des fournisseurs est encouragée par les nouvelles plateformes B2B dédiées aux détaillant (Ankorstore, Faire.com et Orderchamp en Europe). Sur ces plateformes, le minimum et le franco sont très bas (jusqu'à 100€), le catalogue gigantesque et les fournisseurs n'ont pas d'exclusivité régionales. On y découvre régulièrement d'autres fournisseurs possibles.
Bref, il devient plus rapide, plus facile et avantageux d'utiliser des articles légèrement différents en variantes. Voici quelques avantages, avec 3 points qui sont important pour un détaillant :
- on suit les ventes sur un seul article ;
- cet article n'est jamais en rupture de stock, ni en boutique, ni sur le site ecommerce ;
- on évite le duplicate content dans les descriptions sur le site ecommerce (le duplicate content est très mauvais pour le SEO).
Seulement les variantes n'ont pas été conçues pour fonctionner aussi librement, il faut avoir prévu d'avance la caractéristique qui va les différencier. Et comme il est commode d'utiliser les attributs pour décrire ces articles légèrement différents, on se retrouve avec plusieurs attributs pour caractériser des variantes. C'est au mieux un casse-tête.
Des solutions ?
Un palliatif
On peut réserver un seul attribut à la création de variantes. On l'appelle "Modèle" et on y marque ce qu'on veut, pourquoi pas un texte utile en SEO (usine, marque, référence…). Les autres attributs donnent les caractéristiques communes aux variantes. Quelques acrobaties (et des modules OCA) permettent de réserver certains attributs à certaines variantes. Je le teste depuis un an, c'est imparfait mais nettement mieux.
Un avenir possible
On aurait plus de souplesse avec une case à cocher "a des variantes" ou "est une variante de" et une relation One2many/Many2one. Si on veut pouvoir réunir des produits en variantes, il faut aussi réunir le contenu de la page web, mais c'est faisable avec des onglets ou en concaténant provisoirement.
Les attributs décrivent alors les articles et les variantes. Il faut donc pouvoir réserver un attribut à une seule variante parmi d'autres ("cette chemise est rayée").
Sur le site ecommerce, les filtres restent faciles à créer.
On n'a plus besoin d'ajouter des champs pour décrire un article (cf les intégrations verticales), ou alors ces champs seront considérés comme des attributs et affichés dans le comparateur et dans les filtres.
# Des exemples ?
Posté par rycks . Évalué à 5 (+3/-0).
Hello,
peux tu donner des exemples concrets au delà du t-shirt bleu outremer taille L col en V et manches mi-courtes ?
je suis très intéressé par cette réflexion du fait que je suis justement en train de bosser sur l'ajout futé des variantes sur mon module de boutique en ligne pour dolibarr :-)
jusqu'à présent j'ai pris soins de ne pas m'engager sur ce terrain mais la pression des utilisateurs monte et ce message serait l'occasion de réfléchir à des aspects divers et variés.
eric.linuxfr@sud-ouest.org
[^] # Re: Des exemples ?
Posté par orfenor . Évalué à 4 (+2/-0). Dernière modification le 02 juin 2026 à 16:17.
Prenons un jouet, un baton à grelot. Au bout d'un moment tu décides de faire le 2ème modèle du fabricant.
Il vaut mieux les mettre sur la même page pour un bon référencement web, ou parce que c'est pas dispo toute l'année ou parce que tu penses ne pas les avoir tous les deux tout le temps en stock, etc. Quel attribut choisir pour les caractériser ? Va pour couleur bois et couleur multicolore (pas idéal, mais ça passe).
Puis le fournisseur sort un 3ème modèle, en velours… l'attribut couleur ne convient plus.
Puis un autre fournisseur propose exactement les mêmes (l'usine travaille pour les deux) mais te permet d'acheter en plus petite quantité… Tu l'intègres parce que ça dépanne quelquefois.
Puis le nombre de clochettes change et passe de 13 à 7, mais le deuxième fabricant a encore du stock des modèles à 13 clochettes, mais pas en couleur.
Tu ajoutes un attribut nombre de clochettes mais comme les gens préfèrent le modèle couleur, le sélecteur n'arrête pas d'afficher que ça n'existe pas.
Puis certains modèles n'existent plus…
Et ainsi de suite.
On a des variantes de plus en plus complexes dont la moitié n'existe plus, difficile à gérer si on veut les désactiver temporairement. Sans parler des variations de prix.
Alors qu'avec un attribut «Modèle» et des valeurs comme
on peut réécrire le texte des valeurs ou en supprimer pour que ça corresponde à la situation :
Et c'est très facile de gérer les prix avec des variantes directement liées au produit de chaque fournisseur.
Est-ce que c'est l'exemple que tu voulais ? J'en ai évidemment bien d'autres possibles, on peut échanger sur des cas réels.
[^] # Re: Des exemples ?
Posté par rycks . Évalué à 5 (+3/-0).
Arg je crois que j'ai oublié de double confirmer mon message … je la refait en version courte.
Chaque article un une référence unique (sku / numéro de série) non ? donc on est un peu contraint de gérer ça … question liée est-ce que le numéro est différent selon les variantes ?
eric.linuxfr@sud-ouest.org
[^] # Re: Des exemples ?
Posté par orfenor . Évalué à 3 (+1/-0).
Oui, le sku est différent pour chaque variante, le code-barre aussi. Mais on a plusieurs cas où le fabricant met un code barre unique pour plusieurs couleurs. On s'en sort en bricolant (ajout de lettres au code barre), mais ça vaut le coup de prévoir le cas du code barre identique pour toutes les variantes.
# Lien attributs et variantes
Posté par Cédric Krier (site web personnel, Mastodon) . Évalué à 3 (+1/-0). Dernière modification le 02 juin 2026 à 17:22.
Il me semble que le problème est le lien fort entre les valeurs des attributs et les variantes.
Il faudrait que le système ne crée pas nécessairement une variante pour chaque combinaison de valeur possible d'attribut (surtout que ça peut vite exploser).
[^] # Re: Lien attributs et variantes
Posté par orfenor . Évalué à 3 (+1/-0).
c'est le cas avec les nouvelles versions d'Odoo, mais ça ne règle rien :
Comme tu es un «historique» d'Odoo et que tu as le source de Tryton entre les mains, ce serait intéressant d'étudier le problème et de trouver une solution.
[^] # Re: Lien attributs et variantes
Posté par Cédric Krier (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Je ne vois pas pourquoi le site web ne pourrait pas désactiver les options des attributs non-compatibles avec celles déjà sélectionnée.
Pour ce qui est des fournisseurs, il me parait important de pouvoir définir au choix le/les fournisseurs sur le produit ou la variante.
Mes remarques correspondent à la modélisation dans Tryton. Les variantes et attributs ne sont pas vraiment liés. On peut créer des variantes sans le module d'attributs et on peut définir des attributs sans créer de variantes.
[^] # Re: Lien attributs et variantes
Posté par orfenor . Évalué à 2 (+0/-0). Dernière modification le 02 juin 2026 à 19:05.
Ça dépend de ton affichage : avec des listes déroulantes c'est moins ergonomique pour l'utilisateur. Mais ça se fait oui.
absolument, l'OCA a tout de suite rajouté des modules Odoo pour ça
J'ai cru comprendre ça en testant, mais ta documentation dit le contraire. Je vais revoir.
[^] # Re: Lien attributs et variantes
Posté par orfenor . Évalué à 2 (+0/-0).
Correction
avec des listes déroulantes c'est moins ergonomique pour le visiteur du site.
[^] # Re: Lien attributs et variantes
Posté par orfenor . Évalué à 2 (+0/-0).
Effectivement, ça marche très bien !
Je n'ai pas réussi à déplacer une variante d'un modèle de produit à un autre, bien que ça semble possible. Si on peut aussi réunir des produits en variantes c'est tout ce que je souhaite!
[^] # Re: Lien attributs et variantes
Posté par Cédric Krier (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Il est interdit de changer le modèle d'une variante sur Tryton (il y a trop de risque d'incompatibilité comme le changement de bien en service qui pose problème s'il y a déjà du stock etc.).
Par contre dans ce cas, je suggérerai de remplacer le produit/variant par un autre. Tryton se charge même de désactiver l'ancien une fois qu'on n'a plus de stock.
Pareil j'utiliserai aussi le remplacement de produit.
Et si on veut convertir le stock existant, on pourra bientôt utiliser https://discuss.tryton.org/t/new-module-for-light-production-or-product-transformation/9184
[^] # Re: Lien attributs et variantes
Posté par orfenor . Évalué à 3 (+1/-0).
Mais avec le remplacement de produit tu perd ton historique.
Il existe une astuce pour le faire sur Odoo, ce n'est pas aisée mais j'ai pu former des gens à ça. Ça doit fonctionner pareil sur Tryton.
[^] # Re: Lien attributs et variantes
Posté par Guillaume Rossignol . Évalué à 2 (+1/-0).
Je ne comprend pas l'argument. Si je veux un veste manche longue anthracite et que le fabricant ne l'a jamais produite, ce n'est pas le site qui n'est pas pratique, c'est l'univers qui est contre moi. Et il n'y a pas de palliatif.
[^] # Re: Lien attributs et variantes
Posté par orfenor . Évalué à 4 (+2/-0). Dernière modification le 03 juin 2026 à 00:34.
L'acheteur se retrouve fréquemment avec deux listes de choix, dont certaines combinaisons n'existent pas. Par exemple
Couleur
- bleu ciel
- bleu outremer
- jaune citron
- rose flamand
- rose bonbon
- rouge cerise
- rouge bordeaux
Taille
- 36
- 38
- 40
- 42
- 43
- 44
Mais la taille 44 n'existe qu'en bleu outremer, ou bien le jaune citron n'existe qu'en 38, 40 et 42. Au niveau ergonomie du site ce n'est pas pratique.
# Établissement recevant du public
Posté par cévhé . Évalué à 4 (+2/-0).
Je confirme. Mais bon, le canard a levé mon incompréhension du sigle ;-)
# Ce n'est jamais qu'une question de Vue
Posté par Guillaume Rossignol . Évalué à 4 (+3/-0).
Mon avis sur la question c'est que «les articles qu'on commande» et «les articles qu'on vend» sont deux concepts qui n'ont rien à voir dans le cas général, et donc le modéle doit refléter ça.
Par exemple, sur les bâtons à grelots, mon article «Bâton à 13 grelots» (si je considère que le nombre de grelots est pertinent) qui est vendu sur le site peut tout aussi bien être du fournisseur 1 ou 2, ça ne changera rien pour mon client.
Pareil pour des t-shirts uniformes : le client achète une couleur et une taille, la tambouille du fournisseur n'est pas le sujet.
Mais on peut aussi avoir des références qu'on veut dans plusieurs catégories. Par exemple, on peut avoir du matériel de randonnée pédestre qui est vachement utile pour les voyages à vélo. Mais on ne va peut être pas vouloir mettre les mêmes photos, descriptions, critère de recherche en fonction des clients qu'on cible.
Donc in-fine, on est sensé avoir une logique très différente entre «comment je gére mes articles vis à vis de mes fournisseurs» et «comment j'organise mon stock pour le vendre». Parce que parfois, distinguer plusieurs modèle, ca a du sens, parfois non, et parfois, avoir une matrice à la con couleur/taille ça a du sens, et parfois non.
Tout ça me rappel qu'il y a quelques années, je bossai dans une boite qui vendait une solution de marketplace, et on avait comment à regarder ce que faisait Sylius. Ils avaient annoncés qu'ils etaient en train de se pencher sur le modéle de la marketplace, et que les gens qui voulaient se tenir au courant pouvait s'inscrire à une newsletter spécifique.
On n'en a plus entendu parler pendant un moment…
Jusqu'au jour où on a reçu un message disant grosso modo «Ceux qui font déjà de la marketplace sont au courant, mais globalement, avoir une marketplace est largement plus complexe qu'un site B2B/B2C classique», et c'est exactement parce que les questions de comment on veut vendre des produits de différentes sources est particulièrement complexe.
[^] # Re: Ce n'est jamais qu'une question de Vue
Posté par orfenor . Évalué à 3 (+1/-0).
C'est justement le cas général que je mets en cause. Ce qu'on appelle "Cas général" c'est la vision du gros marchand, pas celle du détaillant. Or il y a (pour l'instant) beaucoup plus de détaillants que de gros marchands.
Pourquoi ? l'informatique est censé nous aider, faciliter le travail. Or avoir deux fiches d'articles à créer au lieu d'une c'est plus de boulot, plus de maintenance.
Je le pensais aussi, l'expérience montre que non : l'article n'a pas le même code-barre, ni les mêmes agréments Europe, même si le fabricant est le même.
Mais le problème n'est pas là, il est dans l'évolution perpétuelle de la gamme des fournisseurs et dans la multiplication des choix pour le détaillant. C'est pour ça que :
Ça ne marche pas vraiment sauf à tout refaire chaque année, à cause de l'évolution des produits. Ce qu'un détaillant n'a pas le temps de faire (le cas trop simple couleur/taille vaut pour la mode qui change tout le temps et pour laquelle on est organisé).
Par exemple, le détaillant veut proposer un bon détachant :
Il l'obtient en deux volumes (variante), il fait une fiche produit, un argumentaire, sur son site il décrit l'avantage d'avoir en permamence un bon détachant à portée de main, il met en place des liens vers la page du détachant, il fait bien son SEO.
Puis il apprend que l'approvisionnement n'est pas garantit.
Qu'à cela ne tienne, il trouve un deuxième détachant, aussi efficace mais formulé différement, celui-ci est solide quand le premier était liquide et il n'est dispo qu'en une seule taille. Il n'a pas l'intention de vendre les deux, il veut proposer le deuxième en cas de rupture de stock.
S'il fait une deuxième fiche produit, la première apparait en rupture sur le site, ce qui fait chuter le référencement. Donc il crée une nouvelle variante liquide/solide.
Mais un peu plus tard, nouveau changement, etc.
Je rappelle que j'écris du point de vue du détaillant.
[^] # Re: Ce n'est jamais qu'une question de Vue
Posté par Earered . Évalué à 2 (+1/-0).
Il y a deux concepts produits là :
- logistique
- fiche
Il ne faut pas faire de fiche produit pour le client mais des fiches "catégories marketing pour les fiches"
Par défaut, une fiche catégorie a un seul produit.
Il faut que ces "catégories marketing pour les fiches" soient à la main du vendeur.
Et, oui, ce n'est pas automatique, chaque vendeur faisant des choix différents de présentation, les fournisseurs ne peuvent pas anticiper la présentation des variantes ou combinaisons avec d'autres fournisseurs.
[^] # Re: Ce n'est jamais qu'une question de Vue
Posté par orfenor . Évalué à 2 (+0/-0).
Oui, j'en connais qui font ça. Mais ce n'est pas optimal :
- quand un article n'est plus en stock, ça se voit et ce n'est bon ni pour le SEO, ni pour emmener le visiteur sur autre site ;
- dans le site, c'est impossible de parcourir les catégories, il y en a trop, donc on parcours les articles dans la catégorie mère et du coup on rate les textes descriptifs ;
- pour le SEO, j'ai constaté que mettre ces textes descriptif en billet de blog au lieu des catégories est plus efficace (avec les mêmes inconvénients) ;
- pour le gestionnaire la multiplication des catégories est source d'erreurs et fait perdre du temps.
Sur Tryton, Cedric Krier a conçu les variantes autrement et c'est exactement ce qu'il faut (voir ses billets un peu plus bas).
Bien sûr et alors ? au niveau présentation dans les boutiques en dur, ça ne pose pas de problème puisqu'on gère la mise en rayon et le conseil «à la main». Pourquoi ça devrait en poser en utilisant un outil informatique conçu pour aider ?
[^] # Re: Ce n'est jamais qu'une question de Vue
Posté par Earered . Évalué à 3 (+2/-0).
Je n'ai pas été clair, désolé, c'est plus quelque chose qui s'exprime bien sur un tableau..
Je sépare la notion de "produit fournisseur" de la notion de "produit client", dans les modèles.
De façon caricaturale si un grossiste vend des régimes de bananes, des vendeurs pourraient vendre à l'unité ou au poids ou en smoothie.
Dans certains cas, la création de produit client, (l'étiquette dans le magasin en dur) peut être automatisé pour toute une gamme (fruits et légumes, on debale, on dépose) avec quelques variantes (au poids, à l'unité), mais dans d'autres ça nécessite un process exceptionnel (smoothie ou ananas en tranches)
Sur du pneumatique on peut tout automatiser, sur de l'attelage (boule de traction, faisceau 7 ou 13 voies en fonction de ce qu'on tracte, faisceau additionnel pour le modèle véhicule et main d'œuvre) il vaut mieux vendre des packages à tarif forfaitaire, et le contenu est déterminé au moment de l'assortissage.
Dans mon expérience, c'est quelque chose qui se règle au moment de la conception de la fiche "produit client" si la recette ou le fournisseur est susceptible de changer, c'est à traiter dans la définition même de "produit client"
[^] # Re: Ce n'est jamais qu'une question de Vue
Posté par orfenor . Évalué à 2 (+0/-0).
Je pense que tu es assez clair. Comme le raconte Cedric Krier ci-dessous, il a fait un module pour découpler la fiche produit de la fiche client. C'est idéal. Mais ce n'est pas comme ça que fonctionnent Odoo, Prestashop, Noalyss, Dolibarr, Magento, etc.
# Variantes ERP vs E-commerce
Posté par Cédric Krier (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
Cette problématique me rappel un projet sur le quel j'ai travaillé où l'on a clairement dissocié la notion de variante pour l'ERP et l'e-commerce.
L'utilisation de variante dans l'ERP existe pour simplifier la création et partager les informations communes.
Or l'utilisation de variante pour l'e-commerce a un but différent qui est de proposer des choix/options différentes au client.
La solution utilisé pour ce projet a été de créer une application de gestion de produit (PIM) unique pour alimenter les différents site d'e-commerce. Le lien avec l'ERP se faisait uniquement via le SKU.
[^] # Re: Variantes ERP vs E-commerce
Posté par orfenor . Évalué à 2 (+0/-0).
Pas con, c'est une bonne idée. Je vais regarder les modules PIM qui existent pour m'en inspirer.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.