Des données produit structurées, c'est une information produit rangée dans un attribut typé, ave…
Données produit structurées : ce qu'elles changent dans le storefront
Des données produit structurées, c'est une information produit rangée dans un attribut typé, avec une unité, un identifiant stable et une place claire dans la hiérarchie des variantes, et non noyée dans un texte descriptif. Vos clients ne voient jamais le modèle de données, mais ils en voient les effets à cinq endroits : filtres, tableaux comparatifs, sélection de variantes, balisage Schema.org et flux produits. Si le modèle est fragile, chacun de ces composants doit deviner, et vos clients le remarquent.
Ce que "structuré" veut dire dans un catalogue produit
"Nous avons un PIM" et "nos données produit sont structurées" sont deux affirmations différentes. La structure naît des choix de modélisation que vous faites dans le PIM :
- Modèle d'attributs : chaque attribut a un type (texte issu d'une liste de valeurs, nombre, oui/non, plage) plutôt que du texte libre. "Blanc", "blanc " et "bl." font trois valeurs de filtre, une valeur issue d'une liste n'en fait qu'une.
- Unités : le nombre et l'unité sont stockés séparément. "env. 60 cm" dans un champ texte ne deviendra jamais un curseur de plage, 60 avec l'unité cm, si.
- Classification : dans les assortiments B2B techniques, des standards comme ETIM et ECLASS fixent ces règles pour vous. ETIM décrit les produits par classes et par caractéristiques de quatre types (alphanumérique, logique, numérique, plage), et les caractéristiques numériques et de plage exigent une unité, sauf les comptages comme le nombre de pôles. ECLASS attribue à chaque propriété un identifiant unique au niveau mondial (IRDI) et gère listes de valeurs et unités convertibles.
- Variantes : un produit parent porte les informations communes, chaque variante achetable son propre SKU, GTIN, prix et stock, et les axes de variantes (taille, couleur, tension) sont explicites.
- Multilingue : les identifiants restent indépendants de la langue, seuls les libellés et les valeurs sont traduits.
- Affectation des médias : les images sont liées à la variante ou à l'option qu'elles montrent, pas simplement déposées dans une galerie.
Filtres et facettes : là où les lacunes apparaissent en premier
Une facette ne vaut que ce que vaut l'attribut qui la porte. Dans Laioutr, Orchestr définit un contrat de filtres pour les pages de listing : filtres de liste, interrupteurs oui/non, plages continues et intervalles prédéfinis. Les bornes d'une plage peuvent être des nombres, des montants ou des mesures avec unité. Le lien avec votre modèle de données est direct : une largeur stockée en nombre plus unité devient un curseur, une largeur stockée en texte devient au mieux une longue liste de cases à cocher non triée.
Les valeurs de facettes et les compteurs viennent de votre backend ou de votre moteur de recherche ; des composants comme la barre de filtres et le panneau de filtres latéral affichent ce que renvoie Orchestr. Pour ajouter une recherche sémantique et des filtres qui s'adaptent aux résultats, AI Search & Discovery est disponible en add-on. La base de vos facettes reste votre modèle d'attributs.
Les filtres comptent aussi pour le crawl : le guide de Google sur la navigation à facettes recommande d'exclure les URL de filtres du crawl si vous n'avez pas besoin de les indexer. Si vous voulez les indexer, gardez un ordre de paramètres cohérent et renvoyez un 404 pour les combinaisons vides. La fréquence à laquelle les clients commencent par un filtre plutôt que par la recherche est le sujet de notre analyse sur la recherche IA, la navigation par catégorie et les filtres à facettes.
Fiches techniques et tableaux comparatifs : pourquoi des identifiants communs comptent
Dans le modèle produit canonique de Laioutr, les spécifications sont des lignes ordonnées : un nom affiché, une valeur typée (texte, nombre, booléen, mesure ou montant) et, en option, une section comme "dimensions" ou "technique". Le tableau de spécifications formate chaque valeur selon la locale et regroupe les lignes par section. Un client en France voit "1,5 kg", un client aux États-Unis "1.5 kg", à partir des mêmes données.
Un tableau comparatif aligne ces lignes pour plusieurs produits côte à côte, ce qui ne fonctionne que si les lignes partagent les mêmes identifiants. Si un produit indique "Poids" et le suivant "Poids net (kg)", le tableau a des trous, et une vue "différences uniquement" finit par comparer des libellés au lieu de valeurs. Les noms de propriétés standardisés servent précisément à cela : aligner des lignes venant de connecteurs différents.
Une fois les lignes cohérentes, placer le tableau de spécifications sur une fiche produit relève de la mise en page et non d'un projet de données, et vos équipes éditoriales le font dans Studio, l'éditeur visuel de Laioutr. Une vue comparative de produits, si votre projet en construit une, lit les mêmes lignes.
Sélection de variantes : axes, disponibilité et images
Dans le modèle canonique, un produit contient ses groupes d'options (par exemple taille avec S, M, L et couleur avec rouge et bleu), et chaque variante porte ses options sélectionnées, son SKU, un GTIN optionnel, sa disponibilité et ses prix, prix unitaire compris.
Trois erreurs typiques apparaissent ici :
- Couleurs modélisées comme produits séparés. Le sélecteur ne peut pas les proposer, les clients naviguent donc d'une fiche produit à l'autre.
- Disponibilité par valeur uniquement. Griser "XL" fonctionne par valeur d'axe, mais "rouge en XL" est une combinaison qui exige un stock au niveau de la variante.
- Images rattachées au seul produit parent. Choisir le bleu change le prix, mais pas la photo.
Les trois se corrigent dans le modèle de données, pas dans le composant.
Schema.org et flux : la même structure, lue par des machines
Moteurs de recherche et moteurs de réponse IA lisent les mêmes faits que vos filtres. Schema.org permet à un Product de porter des propriétés supplémentaires sous forme de paires PropertyValue : propertyID accueille un code standard pour la caractéristique, c'est là qu'un identifiant ETIM ou ECLASS trouve sa place, et unitCode un code d'unité UN/CEFACT. Pour les variantes, Google documente un ProductGroup avec productGroupID, les attributs selon lesquels il varie et des variantes imbriquées.
Dans un frontend Laioutr, vous pouvez générer le JSON-LD avec le module Nuxt Schema.org à partir de l'entité qu'une section affiche, plutôt qu'à partir de champs SEO maintenus à part. Balisage et page visible partagent ainsi une source, voir SEO et GEO.
Les flux suivent les mêmes règles. Google Merchant Center attend le même identifiant de groupe d'articles pour toutes les variantes d'un groupe et des valeurs distinctes pour la couleur, la taille, la matière ou le motif. Pourquoi quarante canaux deviennent quarante vérités, c'est le sujet de notre article sur la cohérence des données produit entre canaux. Pour des exports par canal directement depuis la couche frontend, Distributr est disponible en add-on : zéro import, les données sont déjà là, une seule direction, vers l'extérieur. Ce n'est pas un PIM.
Un modèle de données unique pour tous les backends avec Orchestr
Les données produit vivent rarement dans un seul système : le PIM gère attributs et médias, l'ERP prix et stocks, un moteur de recherche les facettes. Orchestr projette ces sources sur un modèle canonique de produits, variantes, spécifications et filtres, si bien que les composants reçoivent la même forme quelle que soit l'origine d'un champ. Il regroupe plusieurs appels API séquentiels en une seule requête et utilise un cache à trois niveaux. Laioutr se connecte à 50+ backends via 300+ intégrations ; d'autres sources peuvent être raccordées via une intégration Orchestr. Plus sur l'architecture : Composabilité et orchestration.
Par où commencer :
- Auditez les 20 attributs qu'utilisent vos principaux filtres de catégorie : type, unité, liste de valeurs.
- Fixez les axes de variantes dans le PIM avant la prochaine release frontend.
- Associez les identifiants d'attributs à des noms communs pour que les lignes de comparaison s'alignent.
- Générez les données structurées à partir de l'entité affichée, puis vérifiez vos flux par rapport à elles.
FAQ
Avons-nous besoin d'ETIM ou d'ECLASS ?
Seulement si votre marché les attend, typiquement dans le négoce technique, l'électricité et le génie climatique, ou les achats industriels. Pour la mode ou les biens de consommation, un modèle d'attributs interne propre, avec valeurs typées et unités, suffit généralement.
Laioutr remplace-t-il notre PIM ?
Non. Le PIM reste le système de référence pour les données produit. Laioutr est la couche frontend : il lit les données via Orchestr, les affiche dans des composants et garde le storefront cohérent d'un backend à l'autre.
Qui gère les filtres et les fiches techniques, les développeurs ou le marketing ?
Les deux, avec une répartition claire. Les développeurs définissent une fois les composants et leurs liaisons de données. Les équipes produit et marketing les placent et les configurent dans Studio, sans ticket pour chaque page de catégorie.
Prochaines étapes
Vous voulez voir comment votre modèle d'attributs se comporte dans les filtres, les fiches techniques et la sélection de variantes ? Réservez une démo avec une catégorie d'exemple. Nous l'examinerons ensemble sur un Composable Headless Frontend.