Journal critique des variantes d'articles dans un ERP ou un système de vente

Sommaire

• Problème des variantes
  • Situation
  • Rigidité de conception
    • Les caractéristiques sont arbitraires, limitées et ne prévoient pas l'avenir
    • Ces caractéristiques ne tiennent pas compte de l'utilisation de l'article
    • On ne peut pas changer d'avis
  • Problèmes pour le détaillant
    • Usage
    • On voudrait des filtres partout
    • Les attributs n'englobent pas toutes les caractéristiques
  • Problèmes liés aux approvisionnement et à l'évolution B2B
• Des solutions ?
  • Un palliatif
  • Un avenir possible

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.