Taxonomie vs ontologie : la différence, illustrée sur un catalogue produit

Une taxonomie range les choses dans une hiérarchie de catégories, où chaque niveau inférieur est plus étroit que celui du dessus : Électroménager de cuisine > Machines à café > Machines à espresso. Une ontologie décrit les types de choses d'un domaine, leurs propriétés et les relations typées entre elles, avec des règles sur lesquelles un ordinateur peut raisonner : un filtre à eau est un accessoire d'une machine à espresso précise, un détartrant est un consommable de cette machine, sa chaudière est en acier inoxydable.

Dans un catalogue produit, taxonomie vs ontologie se résume ainsi : la taxonomie dit où un produit se range, l'ontologie dit comment les produits sont liés. La plupart des boutiques ont d'abord besoin d'une taxonomie solide, puis d'attributs avec des listes de valeurs contrôlées, et seulement ensuite d'un petit ensemble de relations typées là où les acheteurs posent des questions qui concernent plusieurs produits, comme la compatibilité, les pièces détachées, les remplacements et les lots. La suite de ce guide montre les deux modèles sur un même catalogue, la couche intermédiaire, et le moment où chacun devient rentable.

Une taxonomie dans un catalogue produit : un arbre, un seul type de lien

Une taxonomie produit, c'est l'arbre de catégories dans lequel on navigue sur une boutique en ligne et que l'on mappe vers les canaux. Sa seule vraie relation est plus large / plus étroit : Machines à espresso est plus étroit que Machines à café. Le SKOS Primer du W3C décrit exactement cela pour les « thésaurus, taxonomies, schémas de classification » : des concepts reliés par broader et narrower, plus un lien associatif « related » facultatif qui ne porte aucun autre sens.

Les taxonomies publiques fonctionnent de la même façon à grande échelle. La taxonomie produit de Google, version 2021-09-21, compte 5 595 catégories, d'Apparel & Accessories jusqu'à des types de produits uniques (voir notre guide de la taxonomie produit Google). Chaque catégorie est un nœud d'un seul arbre, et chaque produit reçoit un chemin depuis la racine.

Les taxonomies coûtent peu à construire et s'expliquent facilement à un merchandiser. Leur limite apparaît dès que tu poses une question qui ne porte pas sur le rangement. « Quels filtres vont sur cette machine ? » n'a pas de réponse dans un arbre, parce qu'un filtre et une machine sont dans des branches différentes et que l'arbre n'a aucune arête entre eux.

Une ontologie dans un catalogue produit : classes, propriétés et relations typées

Une ontologie part des mêmes classes (Machine à espresso est un type de Machine à café) et ajoute ce qu'un arbre ne sait pas dire. L'OWL 2 Primer du W3C présente OWL comme « un langage pour exprimer des ontologies » et en liste les briques : classes et sous-classes, propriétés d'objet qui relient une chose à une autre, propriétés inverses, restrictions de domaine et de portée, et limites de cardinalité.

Appliquée au catalogue espresso fictif, une ontologie contient des affirmations comme celles-ci :

• Filtre à eau WF-2 est un accessoire de la machine à espresso EM-200
• Détartrant 500 ml est un consommable pour EM-200 et EM-300
• Porte-filtre 58 mm est une pièce détachée pour EM-200
• EM-300 remplace EM-200
• EM-200 est en acier inoxydable, une valeur issue d'une liste de matériaux, pas du texte libre
• Chaque machine à espresso a exactement une pression de pompe en bar (une règle de cardinalité)

Chaque affirmation a un type sur lequel un logiciel peut agir. Comme « accessoire de » est défini une seule fois, la boutique peut afficher les accessoires sur la page de la machine, signaler un filtre qui n'est lié à aucune machine et répondre à la question à laquelle l'arbre ne pouvait pas répondre. Définir « remplace » comme une relation orientée permet à la boutique d'envoyer un visiteur de l'EM-200 arrêtée vers l'EM-300, mais pas l'inverse.

Taxonomie vs ontologie, côte à côte

La taxonomiste Heather Hedden fait une remarque utile dans sa comparaison des deux : les taxonomies servent surtout à l'indexation et à la recherche par sujet, alors que les ontologies servent à la recherche, à la comparaison et aux requêtes en plusieurs étapes sur les données. Les deux reposent sur des standards du W3C, SKOS pour les taxonomies et OWL pour les ontologies, donc elles se combinent au lieu de se concurrencer.

Le tableau montre aussi la forme du travail. Une taxonomie est terminée quand chaque produit a sa place. Une ontologie n'est jamais terminée, et ce n'est pas un problème tant que chaque type de relation que tu ajoutes répond à une vraie question.

Attributs et vocabulaires contrôlés : la couche entre les deux

La plupart des catalogues qui pensent avoir besoin d'une ontologie ont en réalité d'abord besoin de cette couche intermédiaire. Elle a deux parties.

• Des attributs par classe de produit. Une machine à espresso a une pression de pompe, un type de chaudière, un volume de réservoir et une puissance. Un moulin a un type de meules et un diamètre de meules. L'ensemble des attributs par classe (souvent appelé famille de produits ou jeu d'attributs) est déjà une petite ontologie : il dit quel type de chose a quelles propriétés.
• Des vocabulaires contrôlés pour les valeurs d'attributs. Le matériau est l'une des valeurs acier inoxydable, aluminium, plastique ou laiton, et non « inox », « RVS » et « stainless » côte à côte. C'est une liste contrôlée qui rend une valeur filtrable, traduisible et comparable d'un fournisseur à l'autre.

Notre guide des données de référence explique comment gouverner ces listes de valeurs, et le guide de modélisation des attributs explique quels attributs appartiennent à quelle classe. Une fois les deux en place, les relations typées entre produits ne sont plus qu'un petit pas, parce que les choses que tu relies sont déjà bien définies.

Où intervient un knowledge graph

Les trois termes sont souvent employés comme s'ils étaient interchangeables. Ce sont des couches :

• Taxonomie : la hiérarchie des catégories.
• Ontologie : le schéma, c'est-à-dire les classes, les propriétés, les types de relations et les règles.
• Knowledge graph (graphe de connaissances) : l'ontologie remplie d'instances réelles, donc les vraies fiches EM-200, WF-2 et détartrant et les liens entre elles.

Un catalogue produit avec des liens typés est un petit knowledge graph, même si personne ne l'appelle ainsi. Notre entrée de dictionnaire sur le knowledge graph produit va plus loin sur les bases de données orientées graphe et les langages de requête ; pour la plupart des catalogues, les relations peuvent vivre dans le PIM à côté des produits.

Quel modèle pour ton catalogue : les signaux à repérer

Choisis le modèle en fonction des questions que les acheteurs et les canaux posent à tes données :

• Une taxonomie suffit quand les produits sont surtout autonomes (basiques textiles, déco, livres) et que les tâches principales sont la navigation et le mapping des catégories vers les canaux.
• Ajoute des attributs et des vocabulaires contrôlés quand les acheteurs filtrent et comparent sur les caractéristiques, ou quand tu vends sur des marketplaces qui exigent des valeurs structurées par catégorie.
• Ajoute des relations typées quand une part significative des questions concerne plusieurs produits : « est-ce que ça va dessus », « qu'est-ce qui remplace ceci », « de quoi ai-je besoin avec ». Les pièces détachées, les consommables, les outils avec accessoires, l'électronique avec chargeurs et étuis, et les catalogues B2B avec produits successeurs sont dans ce cas.
• Envisage une base de données orientée graphe dédiée seulement quand les relations sont le produit lui-même, par exemple un catalogue de pièces où une pièce va sur des milliers de modèles et de configurations de machines, et que les tables de liens du PIM ne suffisent plus.

Ajouter des relations typées à un catalogue existant en cinq étapes

Tu n'as pas besoin de modéliser tout le domaine avant que la première relation rapporte. Pars des questions, pas du schéma :

1. Rassemble les questions qui touchent plusieurs produits. Lis un mois de tickets du service client, de questions-réponses produit et de recherches sur le site, et isole les questions qui impliquent deux produits : compatible avec, remplace, nécessite, recharge. Dans un catalogue de matériel à café, ce sont en général la compatibilité, les pièces détachées et les consommables.
2. Choisis deux ou trois types de relations et définis chacun en une phrase. « Accessoire de : un produit optionnel qui ne fonctionne qu'avec le produit cible. » Note le sens de la relation et les classes de produits autorisées de chaque côté, pour qu'un détartrant ne puisse jamais devenir par erreur un accessoire d'un moulin.
3. Amorce les liens avec les données que tu as déjà. Les fichiers fournisseurs contiennent souvent des listes de compatibilité, et les anciennes descriptions disent souvent « compatible EM-200 ». Transforme-les une fois en liens, puis retire la phrase de la description.
4. Ajoute un contrôle de complétude. Chaque produit de la catégorie Filtres à eau doit avoir au moins un lien accessoire de ; chaque machine arrêtée doit avoir un lien remplace qui pointe vers elle. Un produit qui échoue au contrôle est un trou dans les données, pas une question de style.
5. Publie les relations là où elles sont lues. Le bloc accessoires de la page produit, l'export BMEcat ou l'export vers un canal, et les données structurées de la page. Une relation qui ne vit que dans le back-office ne répond à la question de personne.

Attends-toi à ce que le premier passage couvre les machines les plus vendues et leurs consommables, pas la longue traîne. C'est en général là que se trouvent les questions.

Pourquoi les relations typées comptent pour les moteurs de recherche et les agents d'achat AI

Un acheteur qui demande à un assistant AI « quel filtre à eau va sur mon EM-200 » a besoin d'une réponse issue des données, pas d'une description qui dit « compatible avec la plupart des modèles EM ». Une prose de ce genre ne donne rien qu'une machine puisse suivre. Une relation typée de WF-2 vers EM-200, si.

Le vocabulaire pour publier ces relations existe déjà. Le type Product de Schema.org propose isAccessoryOrSparePartFor, isConsumableFor, isSimilarTo et isRelatedTo, ainsi que material, category et isVariantOf. Chacune est une relation typée au sens de l'ontologie, et c'est pourquoi un catalogue avec des liens typés peut être publié sous une forme que les crawlers et les agents savent lire, alors qu'un catalogue qui n'a qu'un arbre de catégories ne le peut pas. Notre guide de la taxonomie schema.org explique comment les catégories et les types de produits se correspondent.

Aucun standard ne garantit qu'un assistant AI donné lise aujourd'hui une propriété donnée. La direction, elle, est claire : attributs structurés, valeurs contrôlées et relations explicites sont les parties d'un catalogue qu'une machine peut utiliser sans deviner.

Six façons dont les catalogues confondent taxonomie et ontologie

1. Des attributs déguisés en catégories. Une catégorie Machines à espresso rouges, c'est une valeur de filtre qui se fait passer pour un nœud. La couleur est un attribut ; l'arbre reste centré sur le type de produit.
2. Des collections marketing dans la taxonomie. Cadeaux à moins de 50 et Nouveautés sont des collections utiles, mais les mélanger à l'arbre de classification casse le mapping des catégories vers les canaux.
3. Des relations écrites dans le texte de description. « Compatible EM-200 et EM-300 » dans une description ne peut être ni filtré, ni contrôlé, ni exporté comme lien.
4. Un seul lien associé fourre-tout. Si les accessoires, les alternatives et les remplacements vont tous dans « related », la boutique ne peut pas les traiter différemment sur la page, et un crawler non plus.
5. Du texte libre là où il faut une liste. Trois orthographes d'un même matériau créent trois options de filtre et trois traductions.
6. Des relations sans direction. « Remplace » et « est remplacé par » sont deux affirmations différentes. Stocke la direction une fois et déduis l'inverse, au lieu de maintenir les deux à la main.

Catégories, familles et liens produit typés dans WISEPIM

WISEPIM couvre les trois couches au même endroit. L'arbre de catégories est la taxonomie, avec une catégorisation par AI précise à plus de 95 % et un mapping des catégories vers la taxonomie produit de Google. Les familles de produits portent le jeu d'attributs par classe, avec héritage des familles parentes et des classes ETIM facultatives. Les option sets (jeux d'options) sont les vocabulaires contrôlés : des listes partagées de valeurs autorisées pour les attributs à choix unique et à choix multiple, chacune avec une règle pour les valeurs inconnues à l'import (les ajouter, les ajouter en les signalant pour revue, ou les ignorer).

Les liens produit typés sont la couche ontologique. Dans l'éditeur produit, tu lies des produits comme ventes croisées (cross-sells), montées en gamme (upsells), produits associés, remplacements ou accessoires, et les éléments d'un lot portent une quantité. Les types ne survivent à l'export que là où le format leur réserve une place : l'export BMEcat de Feed Hub les écrit comme références d'article typées, les accessoires comme accessoires, les remplacements comme produits successeurs et les éléments de lot comme consists-of. Les connexions aux boutiques sont plus limitées : la connexion Lightspeed eCom n'envoie que les liens Related Products, comme produits associés Lightspeed, et les autres connexions de boutique n'envoient pas de liens produit. Si tu prépares tes données produit pour les assistants d'achat AI, notre page agentic commerce montre ce que WISEPIM publie pour eux.