Comment structurer un catalogue à attributs variables ?

Un catalogue de vis, un catalogue de vins et un catalogue de logiciels n'ont pratiquement aucune caractéristique en commun, hormis un prix et une référence, et un catalogue qui contient les trois pose un problème de modélisation que peu de plateformes traitent correctement. Le catalogue à attributs variables est la règle plutôt que l'exception dès qu'une boutique dépasse une seule famille de produits, et le modèle retenu décide de ce qu'on pourra faire ensuite : filtrer, comparer, exporter vers une place de marché, produire des données structurées. Choisir ce modèle par défaut, en subissant celui de la plateforme, revient à découvrir ses limites au moment où l'on en a le plus besoin, c'est à dire au moment précis où le catalogue s'étend et où l'on aurait le plus besoin de souplesse.

Les trois modèles possibles

Il n'existe que trois façons de représenter des caractéristiques qui varient d'un produit à l'autre, et chacune a des propriétés très différentes. Les connaître, avec leurs forces et leurs limites, permet de choisir en connaissance de cause plutôt que de subir un héritage, dans le prolongement de ce que nous exposons dans la rubrique e-commerce sur la structure des catalogues.

Les colonnes fixes

Le modèle le plus simple consiste à prévoir une colonne par caractéristique possible. Il est rapide, permet des requêtes efficaces et se prête bien aux filtres, mais il ne tient que si le nombre de caractéristiques reste limité et connu à l'avance. Sur un catalogue multi familles, il produit une table de cinquante colonnes majoritairement vides, et chaque nouvelle famille impose une modification de structure, opération coûteuse et risquée sur une table volumineuse, qu'aucune équipe n'accepte de mener tous les mois.

La table d'attributs

Le deuxième modèle stocke chaque caractéristique comme une ligne rattachée au produit, avec un nom et une valeur. C'est le modèle retenu par la plupart des plateformes du commerce, et il accepte tout : n'importe quel produit peut porter n'importe quel attribut, sans modification de structure. Son défaut est le coût de reconstitution : afficher une fiche complète suppose de rassembler des dizaines de lignes, et filtrer sur trois critères combinés produit des requêtes lourdes qui deviennent le premier facteur de lenteur d'une boutique un peu fournie, ce que l'on constate immédiatement au profilage d'une page de catégorie.

Le document structuré

Le troisième modèle range les caractéristiques dans un document unique rattaché au produit, sous forme de structure imbriquée. Il combine la souplesse de la table d'attributs et le coût de lecture des colonnes fixes, puisque tout arrive d'un bloc, en une seule lecture, sans jointure ni recomposition. Il rend en revanche le filtrage difficile sans index dédié, ce qui explique qu'il soit presque toujours accompagné d'un index séparé destiné à la recherche et au filtrage. Les bases relationnelles récentes savent stocker et interroger ces documents nativement, ce qui rend ce modèle bien plus accessible qu'il ne l'était il y a quelques années, sans imposer de changer de technologie de base de données.

Le modèle mixte, en pratique le plus répandu

La solution qui fonctionne sur les catalogues réels combine les trois : quelques colonnes fixes pour ce que tout produit possède, prix, référence, stock, disponibilité, et un document pour les caractéristiques propres à chaque famille, doublé d'un index destiné au filtrage. Ce découpage n'a rien d'inélégant, il reflète simplement que toutes les données n'ont pas le même statut. Les champs communs méritent des colonnes parce qu'ils sont toujours présents et toujours interrogés ; les autres n'ont pas cette régularité et gagnent à être traités comme un ensemble ouvert.

Ce qui doit rester une colonne quoi qu'il arrive

Cinq données ne doivent jamais migrer dans un document ou une table d'attributs : la référence, le prix, le stock, la disponibilité et l'identifiant de famille. Ce sont celles qui conditionnent l'affichage d'une liste, le tri, les décisions d'achat et les écritures concurrentes. Les ranger avec les caractéristiques descriptives, par facilité de modélisation, produit des listes lentes et des mises à jour de stock coûteuses, ce qui est le contraire de l'objectif. Cette règle vaut aussi pour les données de mesure d'audience et de flux, qui interrogent ces mêmes champs à chaque affichage.

Séparer ce qui décrit de ce qui distingue

Une confusion revient sur presque tous les projets et mérite d'être levée tôt : un attribut peut décrire un produit sans pour autant le distinguer de ses déclinaisons. La matière d'un vêtement décrit le produit entier, sa taille distingue une variante précise. Les deux sont des caractéristiques, elles ne vivent pas au même endroit : la première appartient au produit, la seconde à la combinaison vendable, et confondre les deux produit soit des fiches qui répètent la même information vingt fois, soit des variantes dont on ne peut plus savoir ce qui les différencie. Le test est simple : si deux articles portant des valeurs différentes pour cet attribut ont des stocks distincts et des références distinctes, il s'agit d'un axe de variation ; sinon, c'est un attribut descriptif du produit.

Organiser les attributs par famille

La technique ne règle pas tout : sans une organisation éditoriale des attributs, le catalogue devient rapidement incohérent, avec plusieurs noms pour la même notion et des valeurs saisies dans des formats différents. Cette discipline rejoint celle décrite dans notre article sur la manière de gérer les variantes sans démultiplier les fiches produit.

Définir des familles, pas seulement des catégories

La catégorie sert à la navigation, la famille sert au modèle de données, et les deux ne coïncident pas nécessairement. Une catégorie peut regrouper des produits aux caractéristiques très différentes, et un même type de produit peut apparaître dans plusieurs catégories selon les besoins de la navigation commerciale. Déclarer explicitement des familles, chacune avec la liste des attributs qu'elle attend, sépare proprement ces deux préoccupations et permet de contrôler la complétude des fiches, contrôle qui devient possible parce qu'on sait enfin ce qui est attendu.

Un attribut, un nom, une définition

Le catalogue doit disposer d'un dictionnaire d'attributs, où chaque entrée porte un identifiant technique stable, un libellé affiché, une unité et un type de valeur. Sans ce dictionnaire, on trouve rapidement trois attributs distincts pour la même notion, saisis par trois personnes différentes, ce qui rend tout filtrage et tout export impossibles. Le dictionnaire se tient dans un simple tableau versionné avec le reste du projet, il compte quelques dizaines d'entrées sur un catalogue simple et quelques centaines sur un catalogue technique, et il constitue le premier livrable de tout projet de structuration de catalogue, avant même la première ligne de code.

Typer les valeurs

Une longueur n'est pas un texte, une compatibilité n'est pas un nombre, une couleur n'est pas une valeur libre. Déclarer le type de chaque attribut, nombre avec unité, liste de valeurs fermée, texte libre, booléen, conditionne tout ce qui suit : les filtres numériques par tranche, le tri, la comparaison entre produits et la validité des exports. Une valeur numérique stockée en texte, avec l'unité collée dedans, interdit toute recherche par tranche et se retrouve dans une majorité de catalogues repris. La conversion est heureusement mécanique dès lors qu'un format récurrent se dégage, ce qui est presque toujours le cas.

Fermer les listes quand c'est possible

Un attribut dont les valeurs possibles sont connues doit être une liste fermée, avec des valeurs déclarées. Cela évite les variantes d'écriture, majuscules, accents, abréviations, qui multiplient les entrées dans les filtres et donnent l'impression d'un catalogue mal tenu dès le premier coup d'œil sur la colonne de gauche. La saisie libre ne se justifie que pour les attributs réellement ouverts, une référence de compatibilité ou une mention de conditionnement par exemple, et même dans ce cas, un contrôle de similarité au moment de la saisie évite la plupart des doublons en proposant les valeurs déjà existantes au fur et à mesure de la frappe.

Gérer les unités explicitement

Les unités doivent être stockées séparément de la valeur, et normalisées à l'enregistrement. Un catalogue où les longueurs sont saisies tantôt en millimètres, tantôt en centimètres, avec l'unité dans le texte, ne permet ni tri ni filtre. La règle qui fonctionne consiste à stocker toujours dans une unité de référence et à afficher dans l'unité attendue par le client, ce qui règle aussi la question des marchés utilisant d'autres systèmes de mesure, sans dupliquer la moindre donnée.

Rendre le catalogue interrogeable

Un catalogue bien structuré et impossible à filtrer n'a servi à rien. La recherche à facettes est l'usage principal de ces attributs, et elle impose ses propres contraintes techniques, que nous détaillons dans notre article consacré à la navigation à facettes.

Construire un index séparé

Quel que soit le modèle de stockage, le filtrage doit s'appuyer sur une structure dédiée, reconstruite à chaque modification, contenant pour chaque produit uniquement les attributs filtrables et leurs valeurs normalisées. Cette séparation nette entre la source de vérité et l'index de recherche est le principe qui rend le filtrage rapide sur des catalogues importants, quelle que soit la technologie retenue derrière. Elle introduit une question de cohérence, résolue par une reconstruction complète périodique en plus des mises à jour ponctuelles, la comparaison entre l'index reconstruit et l'index en place servant de contrôle.

Choisir les attributs réellement filtrables

Tous les attributs n'ont pas vocation à devenir des filtres. Un filtre qui ne renvoie qu'un seul produit, ou qui n'est jamais utilisé, encombre l'interface et alourdit l'index. Le tri se fait par l'usage réel plutôt que par l'exhaustivité : les données de recherche interne et les statistiques de clic sur les filtres existants disent lesquels servent réellement. Sur la plupart des boutiques, cinq à huit filtres par famille couvrent la quasi totalité des usages, le reste relevant de la fiche produit, où il est consulté sans être filtré. Un filtre supprimé peut toujours revenir si la demande apparaît, alors qu'un filtre inutile reste rarement remis en question.

Afficher le nombre de résultats par valeur

Un filtre qui indique combien de produits correspondent à chaque valeur, et qui masque ou désactive celles qui n'en ont aucun, évite le cul de sac de la sélection vide. Ce comptage est coûteux et constitue souvent le vrai enjeu technique de la recherche à facettes, ce qui justifie l'index séparé. Sur un catalogue modeste, il se calcule à la volée sans qu'on s'en aperçoive ; au delà de quelques milliers de produits, il demande une structure adaptée, capable de renvoyer les comptes en même temps que les résultats plutôt que par une série de requêtes séparées.

Maîtriser les adresses produites

Chaque combinaison de filtres produit une adresse, et le nombre de combinaisons croît de manière explosive. Sans traitement, ces adresses se retrouvent explorées par les moteurs et consomment l'essentiel du budget d'exploration. La réponse combine plusieurs leviers : ordre canonique des paramètres, canonique déclarée vers la page de catégorie pour les combinaisons multiples, et sélection explicite des quelques combinaisons à forte demande que l'on souhaite voir indexées comme pages à part entière, avec un contenu propre qui justifie leur existence.

Alimenter les flux et les données structurées

Les attributs ne servent pas qu'à la boutique. Les flux marchands attendent des champs normalisés, dont la liste et le vocabulaire sont imposés par chaque destinataire, et le vocabulaire des données structurées attend lui aussi des propriétés précises. Un catalogue dont les attributs sont typés et normalisés se transpose vers ces formats par une simple table de correspondance ; un catalogue dont les caractéristiques sont noyées dans un texte descriptif ne s'y transpose pas du tout, et l'écart de traitement se compte en jours de travail à chaque nouveau canal. C'est l'argument le plus concret pour justifier l'effort de structuration auprès d'une direction : il ne s'agit pas d'élégance technique, mais de la capacité à ouvrir un nouveau canal de vente en une semaine plutôt qu'en un trimestre.

Migrer un catalogue existant

La situation courante est celle d'un catalogue déjà rempli, avec des attributs incohérents accumulés sur plusieurs années. La migration se mène en quatre temps, et le premier n'implique aucune modification du catalogue, ce qui permet de la démarrer sans autorisation particulière.

Inventorier l'existant

La première étape consiste à extraire la liste de tous les attributs présents, avec leur nombre d'occurrences et un échantillon de valeurs. Ce relevé fait apparaître les doublons de nommage, les attributs utilisés sur trois produits, les valeurs saisies dans dix formats différents. Il s'obtient par une requête d'agrégation, tient dans un tableur et constitue la base de discussion avec l'équipe qui gère le catalogue, laquelle découvre en général son propre désordre avec surprise, et devient dès lors bien plus coopérative sur la suite.

Construire le dictionnaire cible

La deuxième étape produit le dictionnaire d'attributs souhaité, avec pour chaque entrée retenue la correspondance vers les attributs existants qu'elle remplace. Ce document est le cœur de la migration : il se relit, se discute et se corrige avant toute exécution, et il vaut mieux y passer trois jours que trois heures. Les attributs qui ne trouvent pas leur place doivent faire l'objet d'une décision explicite, conservation en l'état ou abandon, plutôt que d'être oubliés dans un coin du catalogue où ils réapparaîtront un an plus tard.

Convertir par lots vérifiables

La conversion se fait famille par famille, avec un contrôle après chaque lot : nombre de produits traités, nombre de valeurs non converties, échantillon relu à la main. Traiter tout le catalogue d'un coup rend impossible de savoir ce qui s'est mal passé, et impose de tout reprendre au premier écart constaté. Chaque lot doit être réversible, ce qui suppose de conserver les valeurs d'origine plutôt que de les écraser, au moins jusqu'à la validation finale, qui n'intervient qu'après plusieurs semaines d'exploitation sans incident.

Verrouiller la saisie ensuite

Une migration réussie se dégrade en quelques mois si rien n'empêche de recréer des attributs libres. La dernière étape consiste donc à restreindre la saisie aux attributs du dictionnaire, à imposer les listes fermées là où elles existent, et à valider les unités à l'enregistrement. Ce verrou se pose dans l'interface de saisie et se double d'un contrôle à l'import, les alimentations automatiques étant la principale source de réintroduction du désordre. Sans lui, le travail de structuration devra être refait, et la seconde fois l'équipe l'acceptera bien moins volontiers, ayant déjà donné une fois sans voir le bénéfice durer. Ce rôle n'exige aucune compétence technique particulière, seulement une autorité claire pour refuser un nouvel attribut quand un attribut existant fait déjà l'affaire, ce qui constitue l'essentiel du travail au quotidien.