Votre catalogue produit ressemble probablement à ceci : des tables SQL avec quelques centaines de colonnes, des jointures dans tous les sens, des champs JSON mal définis pour « les attributs qu'on n'a pas su où mettre », et une équipe data qui passe ses lundis matin à expliquer pourquoi la requête d'hier ne retourne plus les mêmes résultats qu'avant-hier. Ce n'est pas un problème de compétence, c'est un problème de paradigme.
Le problème que personne ne veut admettre
Le modèle relationnel a été conçu pour représenter des entités stables avec des attributs prévisibles. Un produit physique n'est pas cela. Un produit est un objet dont la nature change selon le contexte où on l'observe : une perceuse est un outil pour un bricoleur, un bien de consommation durable pour un comptable, un objet pouvant causer des blessures pour un assureur, et un assemblage de composants pour un ingénieur SAV. Ces quatre lectures sont toutes vraies, toutes légitimes, et toutes structurellement différentes.
Le SQL, dans son schéma étoile ou flocon, vous force à en choisir une. Le graphe de connaissance vous permet de les tenir toutes simultanément.
Ce que le SQL fait bien, et ce qu'il ne peut pas faire
Il serait malhonnête de dépeindre SQL comme un outil dépassé. Pour des requêtes analytiques sur des données stables et bien typées, c'est encore ce qu'il y a de plus robuste : personne ne va modéliser ses agrégats de ventes dans un graphe. Mais les limites du modèle relationnel sont structurelles, pas conjoncturelles. Elles apparaissent dès que vos données répondent à l'une de ces trois caractéristiques.
L'architecture en trois couches d'un graphe de connaissance
Couche 1 : les entités et leurs types
Chaque concept du domaine devient un nœud typé. Un produit est différent d'une variante, d'un composant, d'une catégorie ou d'une marque. Ces types sont définis dans l'ontologie et héritent de propriétés selon leur position dans la hiérarchie de classes.
:Perceuse rdfs:subClassOf :OutilElectrique . :OutilElectrique rdfs:subClassOf :Produit . :Produit rdfs:subClassOf :EntiteCommerciale .
Ce qui signifie que toutes les règles applicables à une entité commerciale s'appliquent automatiquement à une perceuse, sans qu'on ait besoin de le répéter.
Couche 2 : les relations sémantiques
Les arêtes du graphe ne sont pas de simples liens. Ce sont des propriétés nommées et typées qui portent une signification précise : estCompatibleAvec (symétrique), estVarianteDe (fonctionnelle, avec domaine et co-domaine), necessiteAccessoire (avec une propriété obligatoire vrai ou faux), remplace (transitive dans certains contextes).
La différence avec une table de jointure ? Ces relations peuvent être exploitées par un moteur d'inférence. Si A est compatible avec B et B avec C, on peut définir une règle qui infère automatiquement la compatibilité de A avec C, ou au contraire contraindre la non-transitivité si le domaine métier l'exige.
Couche 3 : les règles et l'inférence
C'est la couche qui transforme un graphe en connaissance plutôt qu'en simple donnée. Deux langages complémentaires y opèrent, et il importe de ne pas les confondre : ils n'agissent pas au même niveau.
OWL modélise ce que les choses sont et ce qu'on peut en inférer. Déclarer qu'une perceuse nécessite un marquage CE suffit pour que le raisonneur propage cette contrainte à toutes les instances, sans saisie manuelle.
# OWL : toute Perceuse nécessite un MarquageCE :Perceuse rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :necessiteDocument ; owl:someValuesFrom :MarquageCE ] .
SHACL ne déduit rien : il valide. Il vérifie que les données respectent des contraintes définies et produit un rapport de violation le cas échéant. C'est le bon outil pour encoder une règle métier comme « tout produit de la classe matériaux de construction doit avoir une fiche FDES ».
# SHACL : tout matériau de construction doit avoir une fiche FDES
:FicheFDESContrainte a sh:NodeShape ;
sh:targetClass :MateriauxDeConstruction ;
sh:property [
sh:path :ficheEnvironnementale ;
sh:minCount 1 ;
sh:message "Fiche FDES obligatoire pour ce produit."
] .
En une phrase : OWL structure la connaissance, SHACL en garantit la qualité. Les deux sont complémentaires mais n'opèrent pas sur la même couche, et ne sont pas interchangeables. Ces règles ne sont pas de la logique applicative enfouie dans votre backend : elles vivent dans le graphe, sont versionnables, auditables, et s'appliquent indépendamment de l'application qui interroge les données.
Un exemple concret : le catalogue d'un distributeur B2B
Un distributeur distribue 400 000 références issues de 300 fournisseurs, dans 12 pays aux assortiments partiellement différents, avec des contraintes réglementaires hétérogènes et une équipe merchandising qui regroupe les produits selon des logiques différentes selon les canaux : site e-commerce, catalogue PDF, EDI fournisseurs, ERP interne.
En SQL, ce scénario génère invariablement
- +Une table produits de 60 à 120 colonnes selon l'ancienneté du système
- +Des tables de surcharge pour les attributs non prévus à l'origine
- +Des vues matérialisées pour l'e-commerce, d'autres pour l'EDI
- +Des scripts de transformation ad hoc pour chaque pays
- +Une documentation toujours en retard d'une version
En graphe, la même réalité se modélise ainsi
# Un produit et sa hiérarchie :REF-42891 a :Perceuse ; :libelle "Perceuse à percussion 800W SDS-Plus"@fr ; :appartientACategorie :CategoriePercage ; :estVarianteDe :ModelePrincipal-DWD524 . # Une relation avec son contexte :REF-42891 :estDisponibleSur :MarcheFrance ; :avecPrix "129.90"^^xsd:decimal ; :avecDevise :EUR ; :depuisDate "2024-01-01"^^xsd:date .
Dans Graphicient, les équipes métier n'écrivent pas de SPARQL. Le module IA Chatbot leur permet d'interroger ces mêmes données en langage naturel, dans un contexte métier précis, en s'appuyant sur le graphe pour encadrer le LLM. « Quels produits de notre gamme outillage sont compatibles avec la batterie 18V de la marque X ? » devient une question posée en français, dont la réponse est vérifiée, justifiable et auditable.
Ce que le graphe révèle et que le SQL ne verra jamais
Le facteur qui rebat les cartes : les LLM
Il y a une raison plus récente, et plus décisive, de prendre ce sujet au sérieux : l'interface principale d'accès aux données d'entreprise est en train de devenir le langage naturel. On demande à un modèle « quels produits compatibles avec la référence X sont disponibles en Belgique à moins de 150 € ? » et on attend une réponse juste.
Or un LLM lâché en text-to-SQL sur un schéma relationnel d'entreprise doit deviner le sens de noms de colonnes et de tables cryptiques, sans la moindre sémantique pour le guider. Un graphe, à l'inverse, porte le sens explicitement : les nœuds sont typés, les relations sont nommées dans le vocabulaire métier, les contraintes sont lisibles. C'est exactement le terrain dont un modèle a besoin pour ancrer ses réponses.
Le benchmark de référence publié par l'équipe de data.world chiffre l'écart : un GPT-4 interrogé en zero-shot directement sur des bases SQL d'entreprise tombe juste dans environ 16 % des cas ; les mêmes questions posées sur une représentation en graphe de ces mêmes bases font grimper la justesse à environ 54 %. Un facteur trois, sur la seule base du modèle de données.
Le rôle du schéma change de nature. Sa mission n'est plus seulement de stocker la donnée, mais de l'expliquer à la machine qui la lit. Et expliquer le sens d'une donnée, c'est précisément ce qu'une colonne SQL ne sait pas faire.
Les objections courantes, et les réponses honnêtes
« C'est trop complexe pour nos équipes »
Partiellement vrai. L'ontologie demande une phase de modélisation sérieuse en amont, et SPARQL a une courbe d'apprentissage. Mais la complexité existe aussi dans le SQL : elle est simplement distribuée autrement, dans les ETL, les scripts de transformation, la documentation informelle et les têtes de trois personnes qui ont quitté l'entreprise. La différence est que dans un graphe, la complexité est explicite et centralisée ; dans un schéma relationnel hérité, elle est implicite et dispersée.
« Les performances ne suivront pas »
Les bases de données graphe modernes (Neo4j, ArcadeDB, Neptune, Stardog, Oxigraph, MarkLogic) sont conçues pour traverser des millions d'arêtes en temps réel. Pour les requêtes analytiques lourdes, une architecture hybride reste possible : le graphe pour la sémantique et les relations, un entrepôt colonne pour l'agrégation. La vraie question n'est pas « le graphe est-il plus rapide que SQL » (sur des requêtes analytiques simples, SQL gagne toujours), mais « quel outil est le plus adapté à la nature de mes données ». Pour des données de connaissance produit, la réponse est rarement SQL.
« Nos fournisseurs ne parlent pas RDF »
Personne ne vous demande d'exposer du Turtle à vos fournisseurs. Le graphe est une couche interne ; les interfaces avec l'extérieur (EDI, CSV, API REST) restent dans leurs formats natifs. Le travail de correspondance entre le format brut du fournisseur et l'ontologie interne fait partie de la valeur ajoutée de votre couche sémantique.
Les données produit sont intrinsèquement relationnelles, hiérarchiques, contextuelles et évolutives, et aucun de ces quatre adjectifs n'est le point fort du modèle tabulaire. SQL restera pertinent pour les transactions, les agrégations et les exports. Mais pour structurer la sémantique d'un catalogue, ce que chaque produit est, ce à quoi il se rapporte et ce qu'on peut en inférer, le graphe traite le problème à sa racine plutôt que de le contourner à coups de colonnes JSON et de scripts d'ETL. La question n'est plus « pourquoi adopter un graphe de connaissance produit », mais « par quelle partie du problème commencer ».
Sources
- Neo4j, Graph Database vs. Relational Database: Key Differences (2025).
- InterSystems (2025) sur le coût exponentiel des récursions SQL au-delà de quatre niveaux.
- N. Figay (2025) sur la distinction entre OWL et SHACL.
- Oxford Semantic Technologies (2024) sur les rapports de validation SHACL.
- Yakovets, Godfrey & Gryz (2013) sur l'évaluation des chemins de propriétés SPARQL en SQL récursif.
- Vidal et al. (2025) sur les graphes de connaissance d'entreprise comme couche sémantique.