Base de données relationnelle ou sémantique ?
« On a déjà une base de données. Pourquoi aurait-on besoin d’une ontologie en plus ? » La question revient dans presque tous les avant-projets. Et elle est légitime. Les bases de données relationnelles fonctionnent bien depuis 50 ans, les équipes savent les utiliser, les outils sont matures.
Sauf que depuis 2022, quelque chose a changé. L’IA générative a créé un nouveau besoin que les SGBDR n’ont pas été conçus pour adresser : connecter une IA à des connaissances qui signifient quelque chose, pas juste des données brutes, mais des concepts, des relations, des règles, du contexte sémantique. Et c’est précisément là que l’IA symbolique, sous forme de knowledge graphs et d’ontologies OWL, prend toute sa valeur.
Ce n’est pas une question de mode. C’est une question d’architecture. Voici comment démêler le vrai du faux.
La base de données relationnelle : excellente pour ce qu’elle fait, limitée pour ce qu’on lui demande de faire
Commençons par ne pas jeter le bébé avec l’eau du bain. Une base de données relationnelle (PostgreSQL, MySQL, Oracle, SQL Server…) est un outil remarquablement efficace pour ce qu’elle a été conçue à faire : stocker des données structurées en tables, garantir leur intégrité transactionnelle (ACID), et répondre à des requêtes agrégatives sur de grands volumes.
Elle excelle pour gérer les commandes d’un e-commerce, la comptabilité d’une entreprise, les inscriptions d’une plateforme, ou les mesures d’un capteur IoT. Ces données sont régulières, prévisibles, et le schéma change rarement.
Le problème surgit quand on demande à cette même architecture de gérer des connaissances hétérogènes, des relations complexes entre entités, ou des règles métier qui doivent s’inférer plutôt que simplement se consulter. Et plus encore quand on veut brancher un LLM dessus pour poser des questions en langage naturel.
« Une base relationnelle stocke des réponses. Un knowledge graph stocke des significations. Ce n’est pas la même chose. »
Qu’est-ce qu’un knowledge graph ?
Un knowledge graph (graphe de connaissances) est une représentation des connaissances sous forme d’un réseau d’entités reliées entre elles par des relations nommées. On le formalise en RDF (Resource Description Framework) sous forme de triplets : sujet → prédicat → objet.
Exemple concret :
- Aspirine → appartient à → Classe des anti-douleurs
- Aspirine → a pour principe actif → Acide acétylsalicylique
- Acide acétylsalicylique → est contre-indiqué avec → Anticoagulants oraux
Dans une base relationnelle, chaque relation implique une table de jointure explicite. Dans un knowledge graph, la relation peut avoir ses propres propriétés, ses propres règles, et se propager par inférence à travers d’autres relations.
L’ontologie OWL : le knowledge graph avec un cerveau logique
Une ontologie exprimée en OWL (Web Ontology Language) va plus loin encore : elle ajoute au graphe une couche de raisonnement logique. En OWL, on peut définir non seulement ce qui est (les faits), mais ce qui doit être (les contraintes) et ce qu’on peut en déduire (les inférences).
Si l’ontologie définit qu’un « médicament à base de substance active X » hérite automatiquement de toutes les contre-indications de cette substance, alors tout nouveau médicament ajouté à la base bénéficiera de cette règle sans qu’il faille la recoder. C’est ce que les SGBDR ne peuvent pas faire nativement.
Comparaison détaillée : base relationnelle, NoSQL, et knowledge graph
| Dimension | Base relationnelle (SQL) | Base NoSQL / documentaire | Knowledge graph / Ontologie OWL |
|---|---|---|---|
| Structure des données | Tables et colonnes, schéma rigide | Documents JSON/BSON, schéma flexible | Entités et relations, graphe flexible & évolutif |
| Modélisation des relations | Jointures entre tables, complexe pour les relations profondes | Emboîtement de documents, peu adapté aux relations many-to-many | Relations de première classe, navigables à n niveaux nativement |
| Raisonnement / inférence | Non, logique métier dans le code applicatif | Non | Oui, moteur de raisonnement OWL intégré |
| Interopérabilité | Partielle, via ETL, APIs propriétaires | Partielle | Native, standards W3C (RDF, OWL, SPARQL), linked data |
| Évolution du schéma | Coûteuse, migrations lourdes | Flexible | Flexible, ajout de classes et propriétés sans migration |
| Requêtes sémantiques | Non, SQL pur | Non | Oui, SPARQL 1.1 avec requêtes sur le sens, pas juste la forme |
| Intégration LLM / IA générative | Difficile, via NL2SQL, résultats variables | Moyen | Optimal, architecture GraphRAG native, contexte sémantique riche |
| Transactions (ACID) | Excellente | Variable | Moins prioritaire, optimisée pour la lecture sémantique |
| Performance sur grands volumes | Excellente (données tabulaires) | Excellente | Bonne, optimisée pour la profondeur, pas la volumétrie brute |
| Maturité écosystème | Très mature, près de 50 ans d’outillage | Mature | En croissance, Stardog, GraphDB, Jena, Neptune, Wikidata |
Quand choisir quoi ? Un guide de décision pratique.
Restez avec votre SGBDR si…
- Vos données sont très structurées et homogènes
- Vous avez besoin de transactions ACID haute fréquence
- Le schéma est stable depuis des années
- Vos requêtes sont essentiellement agrégatives (SUM, COUNT, GROUP BY)
- Pas besoin d’IA sur ces données à court terme
Passez à un knowledge graph si…
- Vos données viennent de sources hétérogènes à unifier
- Vous avez des relations complexes multi-niveaux à naviguer
- Vous voulez brancher un LLM sur vos connaissances métier
- Vous avez des règles métier à inférer automatiquement
- Vous construisez un système RAG ou un assistant IA d’entreprise
Secteurs particulièrement concernés
- Santé et pharma (médicaments, pathologies, interactions)
- Juridique et conformité réglementaire
- Industrie (nomenclatures, gammes de fabrication)
- Mode et retail (taxonomies produits complexes)
- Administration et institutions publiques
Architecture hybride recommandée
- SGBDR pour les transactions et les données opérationnelles
- Knowledge graph pour la couche sémantique et IA
- Synchronisation via connecteurs RDF ou API standard
- LLM accède au graphe via GraphRAG, pas directement au SQL
Exemple concret : VetiVoc, une ontologie pour le monde de la mode
Imaginez un retailer international qui doit gérer ses produits dans 15 langues, avec des attributs qui varient selon les marchés, les saisons et les réglementations locales. Une base relationnelle classique va produire des tables de jointures labyrinthiques, des colonnes nullables en cascade, et des requêtes qui deviennent ingérables dès qu’on cherche « tous les produits en laine mérinos qui appartiennent à la catégorie pull et dont le pays de fabrication est certifié éthique ».
VetiVoc, l’ontologie modulaire développée par Cogsonomy pour les domaines de la Mode, du Textile et de l’Habillement, répond exactement à ce besoin. Avec près de 2 000 concepts et termes associés, elle permet de modéliser les vêtements dans leur complexité sémantique réelle (matières, coupes, origines, certifications, usages) de façon interopérable et extensible.
Plus concrètement : si on ajoute demain une nouvelle certification éthique dans l’ontologie, tous les produits concernés héritent automatiquement de ce nouveau statut. Sans recoder. Sans migration. Sans mettre à jour 15 tables différentes.
Le vrai enjeu : pas la technologie, mais la méthode.
La question « knowledge graph ou base de données ? » est en réalité une question déguisée : êtes-vous prêt à modéliser vos connaissances, pas seulement à stocker vos données ? Car c’est là que réside la vraie difficulté. Pas dans la technologie. Les outils comme Protégé, GraphDB, Stardog ou Apache Jena sont matures et documentés. La vraie difficulté est dans l’ingénierie des connaissances : identifier ce que votre organisation sait vraiment, structurer ce savoir sous forme formelle, aligner les experts métier et les équipes technique sur un modèle commun.
C’est un travail qui demande une méthode, une expérience des domaines métier, et une maîtrise du formalisme OWL. Et c’est précisément pour ça que la demande explose actuellement auprès des organisations qui veulent déployer de l’IA sur leurs données internes avec des garanties sérieuses de fiabilité.
Aide à la décision rapide
→ Oui : GraphRAG + ontologie OWL est l’architecture cible.
→ Architecture hybride : SGBDR pour l’opérationnel, KG pour la couche sémantique IA.
Vous voulez savoir si un knowledge graph est fait pour votre projet ?
Nos formations couvrent la modélisation des connaissances, OWL, SPARQL et l’intégration avec l’IA générative — avec des cas concrets issus de projets réels.
FAQ
Une base relationnelle stocke des données sous forme de tables avec un schéma rigide, optimisée pour les transactions. Un knowledge graph stocke des entités et des relations en triplets RDF, avec un schéma flexible et une capacité native de raisonnement logique. L’un est fait pour les données structurées répétitives ; l’autre pour les connaissances complexes et hétérogènes.
Dans la quasi-totalité des cas, non — et ce n’est d’ailleurs pas l’objectif. Les SGBDR restent supérieurs pour les transactions, la volumétrie massive de données structurées et les requêtes agrégatives. Le knowledge graph prend la main sur la modélisation sémantique, les relations complexes et l’intégration IA. L’architecture hybride — SGBDR + KG — est la norme en production.
Neo4j est une base de données graphe orientée propriétés (Property Graph). Elle permet de naviguer des relations de façon très efficace, mais sans couche d’ontologie OWL, il n’y a pas de raisonnement logique ni d’interopérabilité sémantique standard W3C (RDF/OWL/SPARQL). Un knowledge graph au sens sémantique est adossé à une ontologie formelle et utilise les standards du web sémantique.
Le coût dépend principalement de la complexité du domaine et de l’état actuel des connaissances métier. Un KG de domaine restreint (quelques centaines de concepts) peut se construire en quelques semaines. Un référentiel institutionnel large (comme les 14 000 concepts de l’ontologie médicament ANSM) est un projet de plusieurs mois. L’investissement principal est dans l’ingénierie des connaissances, pas dans la technologie
SPARQL a une courbe d’apprentissage un peu plus abrupte que SQL pour les débutants — principalement parce qu’il demande de penser en termes de graphe et de triplets plutôt que de tables. Mais pour quelqu’un déjà à l’aise avec SQL et la modélisation de données, la transition prend généralement quelques jours à quelques semaines. Les formations Cogsonomy couvrent SPARQL de zéro, avec des exercices pratiques sur des cas réels.
