Comment gérer les variantes sans démultiplier les fiches produit ?

Un catalogue de mille produits déclinés en cinq tailles et quatre coloris peut compter mille fiches ou vingt mille, et ce choix engage tout le reste : le référencement, la navigation, la gestion des stocks, les flux marchands et le temps passé chaque semaine par l'équipe. La gestion des variantes produit est rarement traitée comme une décision, elle est le plus souvent héritée de la plateforme ou d'un import initial, puis subie pendant des années. Elle mérite pourtant un arbitrage explicite, parce que les deux options sont défendables selon le contexte et que passer de l'une à l'autre après coup coûte cher.

Nommer les axes avant de modéliser

Le travail commence par un exercice qui semble théorique et qui décide de tout : identifier ce qui varie réellement, et distinguer ce qui relève d'une déclinaison de ce qui relève d'un produit distinct. Cette clarification conditionne l'ensemble du modèle de données, et rejoint les questions que nous traitons dans la rubrique e-commerce à propos de la structure des catalogues.

Ce qui est une variante et ce qui n'en est pas

Une variante est une déclinaison qui ne change ni la nature du produit, ni son usage, ni sa description : une taille, un coloris, une contenance. Dès que la différence porte sur la fonction, la compatibilité ou le public visé, il s'agit de produits distincts, même si le fabricant les présente dans une même gamme. Le test pratique consiste à se demander si un client cherchant l'un accepterait l'autre : si la réponse est non, ce sont deux produits, et les regrouper nuira autant à la navigation qu'au référencement.

Limiter le nombre d'axes

Chaque axe de variation multiplie le nombre de combinaisons, et trois axes suffisent à produire des centaines de références pour un seul produit. Au delà de deux ou trois, l'interface devient pénible pour le client et la gestion ingérable pour l'équipe. Quand un troisième axe s'impose, il vaut souvent mieux le traiter comme un produit configurable, avec une saisie plutôt qu'un choix dans une liste, ou le remonter au niveau du produit en créant des gammes distinctes.

Déclarer les axes, pas les déduire

Une erreur de modélisation fréquente consiste à déduire les axes disponibles des variantes existantes. Le jour où la dernière variante rouge est supprimée, l'axe coloris perd une valeur sans que personne ne le décide, et le retour du rouge en stock demande de recréer une information qui aurait dû rester. Les axes et leurs valeurs possibles doivent être déclarés au niveau du produit, indépendamment des combinaisons réellement disponibles.

Prévoir les combinaisons impossibles

Le produit cartésien de tous les axes n'existe presque jamais en totalité : certaines tailles n'existent pas dans certains coloris, certaines contenances ne sont pas proposées dans certains parfums. Un modèle qui suppose que toutes les combinaisons existent produit des fiches vides, des sélections qui n'aboutissent pas et des flux rejetés. Il faut donc que l'existence d'une combinaison soit une donnée explicite, et non le résultat d'un calcul.

Un identifiant par combinaison vendable

Chaque combinaison réellement vendable doit porter sa propre référence, son propre stock et, quand il existe, son propre code à barres. C'est elle qui figure dans une commande, dans un bon de préparation et dans un flux marchand, jamais le produit parent. Ce principe est le socle de tout le reste, et son absence explique la majorité des incohérences que l'on retrouve entre la boutique, l'entrepôt et les places de marché.

Le cas des variantes qui changent le prix

Un axe qui fait varier le prix mérite un traitement particulier, parce qu'il change la nature de la fiche aux yeux du client comme des moteurs. Tant que l'écart reste faible, un supplément pour une grande taille par exemple, la fiche unique fonctionne bien avec un prix de base et un ajustement affiché à la sélection. Dès que l'écart devient important, une contenance de cent millilitres et une de cinq litres, la fourchette affichée sur les listes devient trompeuse et la comparaison avec les concurrents impossible. Dans ce cas, il vaut souvent mieux traiter les extrémités de la gamme comme des produits distincts, quitte à les relier par des liens explicites, plutôt que de les faire cohabiter derrière un seul prix affiché qui ne correspond à presque aucune vente réelle.

Fiche unique ou fiches séparées

Une fois les axes posés, reste la question de l'affichage : regroupe t on les déclinaisons sur une page unique, ou leur donne t on chacune sa page ? Les deux réponses existent sur des sites qui fonctionnent bien, et le bon choix dépend de la manière dont les clients cherchent, ce qui rejoint les considérations de navigation exposées dans notre article sur la navigation à facettes.

Ce que la fiche unique apporte

Regrouper concentre les signaux : une seule adresse reçoit tous les liens, tous les avis et toute l'autorité, au lieu de les disperser sur vingt pages quasi identiques. Elle évite mécaniquement la concurrence interne entre variantes et supprime la question du contenu dupliqué. Elle simplifie la maintenance éditoriale, une seule description à écrire et à mettre à jour, et elle correspond au comportement de la plupart des clients, qui choisissent leur taille après avoir choisi le produit.

Ce que les fiches séparées apportent

Séparer devient pertinent quand la variante est elle même l'objet de la recherche. Si des clients tapent le nom du produit suivi d'un coloris précis, une page dédiée à ce coloris peut se positionner sur cette requête, ce qu'une fiche regroupée fait mal. Séparer permet aussi d'afficher un prix et une disponibilité sans interaction, ce qui compte pour les comparateurs, et de proposer des visuels et des descriptions réellement différents quand les déclinaisons le méritent.

Le critère qui tranche

La question à poser est celle de la demande : les variantes font elles l'objet de recherches distinctes ? Les données des outils pour webmasters et des estimateurs de volume répondent en une demi heure. Sur un catalogue de vêtements courants, la réponse est presque toujours non, et la fiche unique s'impose. Sur des produits techniques où la référence exacte est recherchée, comme une pièce détachée ou une cartouche compatible, la réponse est oui, et la séparation se justifie.

La solution intermédiaire

Une troisième voie consiste à conserver une fiche unique tout en donnant une adresse propre à chaque variante, sous forme de paramètre, chaque adresse affichant la variante présélectionnée et déclarant la fiche principale comme canonique. On obtient des liens partageables et un affichage correct depuis un flux, sans disperser les signaux. C'est le compromis retenu par la plupart des grandes boutiques, et il demande simplement que la canonique soit correctement posée. Le paramètre retenu doit rester le même partout et ne jamais être combiné à des paramètres de suivi dans les liens internes, sous peine de multiplier les adresses distinctes pour un même affichage.

Ce qu'il ne faut pas faire

Le pire des deux mondes consiste à créer une page indexable par variante, avec la même description répétée à l'identique, sans canonique et sans contenu propre. On obtient alors des dizaines de pages en concurrence directe, dont le moteur retiendra une seule de manière imprévisible, et un budget d'exploration dépensé sur des quasi doublons. C'est pourtant la configuration par défaut de plusieurs imports de catalogue, et le symptôme se lit dans les journaux serveur avant de se lire ailleurs : une part disproportionnée du crawl consacrée à des adresses de variantes que personne ne visite jamais.

La contrainte de la plateforme

Le choix théorique se heurte souvent à ce que la plateforme sait faire. Certaines gèrent nativement les produits à déclinaisons avec un stock par combinaison, d'autres ne connaissent que des produits simples et obligent à simuler les variantes par des champs personnalisés, ce qui fonctionne jusqu'au moment où un flux ou une extension de logistique s'en mêle. Avant d'arrêter un modèle, il faut donc vérifier trois points concrets : la plateforme tient elle un stock par combinaison, sait elle exporter un flux au niveau de la combinaison, et le logiciel de gestion ou l'entrepôt reçoivent ils la référence exacte. Une réponse négative sur l'un de ces trois points ne condamne pas le projet mais transforme la modélisation en développement spécifique, ce qu'il vaut mieux savoir avant de s'engager.

Faire fonctionner le sélecteur

Sur une fiche unique, tout se joue dans le sélecteur de variantes. C'est un composant modeste en apparence qui concentre une part importante des abandons quand il est mal conçu, et son amélioration est souvent plus rentable qu'une refonte complète de la fiche.

Ne jamais proposer une combinaison indisponible

Un sélecteur qui laisse choisir une taille puis annonce qu'elle n'existe pas dans le coloris retenu fait revenir le client en arrière, ce qu'une part d'entre eux ne fera pas. Les valeurs impossibles doivent être visuellement désactivées dès la première sélection, et non retirées de la liste, afin que le client comprenne que l'option existe mais pas dans cette combinaison. La différence entre désactiver et masquer est importante : masquer donne l'impression que le produit n'existe pas.

Distinguer l'indisponible du définitivement absent

Une taille en rupture temporaire et une taille qui n'a jamais existé ne demandent pas le même traitement. La première mérite une alerte de réapprovisionnement, qui capte une adresse et un intérêt précis, la seconde doit simplement être inactive. Confondre les deux fait perdre une occasion de contact sur des demandes très qualifiées, et brouille l'information donnée au client. La distinction se tient dans les données, par un statut explicite de la combinaison, jamais par un stock à zéro qui ne dit rien de l'intention.

Mettre à jour l'affichage sans recharger

Le prix, la disponibilité, la référence et l'image doivent changer immédiatement au choix d'une variante. Cette mise à jour doit reposer sur des données déjà présentes dans la page quand le nombre de combinaisons est raisonnable, ce qui la rend instantanée, et sur un appel au serveur seulement au delà de quelques centaines de combinaisons. L'erreur fréquente est d'appeler le serveur à chaque changement de sélection sur un produit qui n'a que douze combinaisons. Le second réflexe utile est de préparer côté serveur une structure compacte contenant, pour chaque combinaison, son identifiant, son prix, son stock et l'index de son image, ce qui évite d'embarquer dans la page l'intégralité des données produit.

Rester utilisable sans script

Un sélecteur bâti sur un formulaire classique fonctionne même quand les scripts échouent, alors qu'un composant entièrement construit en JavaScript laisse une page inerte. Ce point compte pour l'accessibilité, pour les connexions dégradées, et pour l'indexation quand des adresses de variantes sont exposées. Il ne coûte presque rien à respecter si l'on part d'un formulaire et qu'on l'enrichit, et il devient très coûteux à rattraper si l'on part d'un composant. Le même raisonnement vaut pour la navigation au clavier, qui découle naturellement d'un formulaire correctement balisé et qui doit sinon être reconstruite entièrement.

Ce que les variantes changent en aval

Le choix de modélisation ne s'arrête pas à la fiche. Il se propage à tout ce qui consomme le catalogue, et c'est souvent là que les mauvaises décisions se paient. Tout repose alors sur la stabilité des références, sujet que nous avons détaillé dans notre article sur les identifiants produit stables, SKU, GTIN et cohérence des flux.

Les flux marchands attendent la variante

Les places de marché et les régies publicitaires travaillent au niveau de la combinaison vendable, avec un identifiant, un prix et une disponibilité par référence, et regroupent elles mêmes les variantes au moyen d'un identifiant de groupe. Un flux construit au niveau du produit parent, avec un prix moyen et une disponibilité globale, sera rejeté ou produira des annonces qui envoient vers des produits en rupture. C'est le point où une modélisation approximative se voit immédiatement, et où le coût se chiffre directement, puisqu'une annonce menant à un produit indisponible est payée comme les autres.

Les données structurées de la fiche

Une fiche unique regroupant plusieurs variantes doit décrire chaque offre séparément dans son balisage, avec son prix, sa disponibilité et son identifiant, plutôt qu'une offre unique portant une fourchette de prix. Ce balisage détaillé est prévu par le vocabulaire employé et il évite l'incohérence entre ce que la page affiche après sélection et ce que le moteur a compris. Les affichages enrichis dépendent directement de cette précision, une fourchette large étant beaucoup moins susceptible d'être reprise qu'un prix exact rattaché à une référence.

Le stock et la préparation de commande

Le stock se tient à la variante, sans exception, et la commande doit conserver la référence exacte commandée plutôt que le nom du produit et les options choisies. Un bon de préparation qui indique le produit et laisse le préparateur déduire la déclinaison à partir d'un libellé produit des erreurs, et ces erreurs coûtent des retours, qui coûtent bien plus cher que le travail de modélisation évité.

Les statistiques et l'analyse

Les rapports de ventes doivent pouvoir être lus aux deux niveaux : par produit pour les décisions d'assortiment, par variante pour les décisions de réassort. Cela suppose que l'identifiant de variante et celui du produit parent soient tous deux enregistrés au moment de la vente, y compris dans les événements envoyés aux outils de mesure. Reconstituer ce lien après coup est possible tant que la table de correspondance existe, et impossible dès qu'une variante a été supprimée. C'est une raison de plus de ne jamais supprimer une référence vendue, mais de la marquer comme retirée de la vente, ce qui conserve l'historique intact.

Migrer d'un modèle à l'autre

Le passage de fiches séparées à une fiche unique, ou l'inverse, est une opération lourde qui se prépare comme une refonte. Le regroupement supprime des adresses, ce qui impose des redirections vers la fiche unique et une vérification que les liens entrants importants sont bien captés. La séparation, elle, crée des adresses nouvelles qui n'ont aucun historique, et le temps qu'elles s'installent, le trafic baisse. Dans les deux sens, la précaution la plus utile consiste à conserver la table de correspondance entre l'ancien et le nouveau modèle, référence par référence, y compris pour les combinaisons qui disparaissent au passage. Sans elle, aucun rapprochement d'historique de ventes n'est possible après la bascule, et l'analyse des effets se résume à des impressions. Cette table se conserve indéfiniment, son coût de stockage étant dérisoire au regard du service rendu, et elle se révèle utile bien au delà de la bascule, notamment lors du premier inventaire annuel qui suit.