Taxonomie vs Ontologie
Une différence de nature, pas de degré

Le chiffre qui change tout

Il y a un mois, j'ai déployé une infrastructure sémantique complète pour les éditions localement transcendantes, ma maison d'édition spécialisée dans les textes philosophiques obscurs ou improbables. PostgreSQL pour les données structurées, Neo4j pour le graphe de connaissances, Schema.org pour le marquage, entrées Wikidata pour chaque auteur et problème philosophique traité.

Résultat : +60% de ventes de livres en un mois.

Pas de changement de prix. Pas de campagne marketing. Simplement une meilleure découvrabilité : les moteurs de recherche et les LLMs comprennent enfin ce dont ces livres traitent et pourquoi ils sont pertinents. Mes rééditions de Whitehead ou de François Evellin peuvent maintenant être mentionnées dans les conversations sur le problème de l'espace (l'espace est-il un contenant ou une relation ? est-il continu ou granulaire ?).

Ce cas illustre une distinction que beaucoup d'entreprises technologiques négligent : la différence entre taxonomie et ontologie n'est pas une question de complexité, mais de nature. Et cette différence a un impact direct sur votre chiffre d'affaires.

I. La confusion courante (et coûteuse)

Ce que croient les founders et les CTOs

Quand un client me dit "on a besoin d'une taxonomie", voici ce qu'il pense généralement :

• Taxonomie = simple, rapide, "juste des catégories"
• Ontologie = compliqué, académique, "pour les data scientists"

Cette vision repose sur une idée séduisante mais fausse : qu'une ontologie serait simplement une "taxonomie complexe" ou "multi-dimensionnelle". On entend souvent : "Une taxonomie, c'est 1D (une hiérarchie), une ontologie c'est nD (un graphe)."

Problème : Cette vision d'ingénieur rate la distinction fondamentale. Il ne s'agit pas de dimensions, mais de fonction. Une taxonomie et une ontologie ne font pas la même chose, même quand elles organisent les mêmes entités.

Ce que cela coûte en pratique

Prenons un exemple concret. Vous construisez une base de données pour un SaaS B2B. Vous créez une table companies avec un champ industry :

CREATE TABLE companies (
  id SERIAL PRIMARY KEY,
  name VARCHAR(255),
  industry VARCHAR(100)  -- "Software", "EdTech", "FinTech"...
);

C'est une taxonomie. Vous rangez les entreprises dans des catégories. Ça marche... jusqu'au jour où vous devez répondre à des questions comme :

• "Quelles entreprises ont été fondées par des anciens de Y Combinator ?"
• "Quels SaaS utilisent Stripe ET sont basés au Canada ?"
• "Comment les entreprises EdTech se connectent-elles à Moneris ?"

Votre taxonomie ne peut pas répondre. Pas parce qu'elle est trop simple, mais parce que ce n'est pas son rôle. Une taxonomie classe. Elle ne spécifie pas les relations possibles.

II. Ce qu'est vraiment une taxonomie

Fonction : classer et ranger

Une taxonomie répond à la question : "Où mettre cet individu ?"

C'est une structure de classification, typiquement arborescente :

Règne Animal
  └─ Embranchement Chordata
      └─ Classe Mammalia
          └─ Ordre Carnivora
              └─ Famille Canidae
                  └─ Genre Canis
                      └─ Espèce Canis lupus familiaris (chien domestique)

Ou dans le monde tech :

Software
  └─ Application Software
      └─ Business Software
          └─ Education Software
              └─ Student Management System
                  └─ Tuiopay

La fonction d'une taxonomie est d'assigner. Elle dit : "Tuiopay est un Student Management System, qui est un Education Software, qui est un Business Software..."

Ce qu'une taxonomie ne dit pas

Voici la limite cruciale : une taxonomie ne dit rien sur le statut ontologique des catégories elles-mêmes.

La classe "Chien" existe-t-elle réellement, ou n'existe-t-il que des chiens individuels ? C'est le débat philosophique classique entre nominalistes (seuls les individus existent, les classes sont des noms pratiques) et réalistes (les universaux ont une existence réelle).

Pour une taxonomie, cette question n'a pas de réponse. Une taxonomie est un outil épistémologique : elle organise notre connaissance. Elle ne prend pas position sur la métaphysique.

III. Ce qu'est vraiment une ontologie

Fonction : spécifier ce qui peut exister et comment

Une ontologie répond à une question différente : "Quels types d'entités existent et quelles sont leurs affordances relationnelles ?"

Le terme "affordances relationnelles" est crucial. Il signifie : quelles relations ce type d'entité peut-il avoir ?

Reprenons l'exemple Tuiopay, mais cette fois avec une perspective ontologique :

CLASSE : Software
  Affordances relationnelles :
    - PEUT avoir : developer (type: Organization)
    - PEUT avoir : inception_date (type: Date)  
    - PEUT avoir : users (type: Person, cardinalité: multiple)
    - PEUT avoir : owner (type: Organization)
    - PEUT avoir : country (type: Country)
    - PEUT avoir : industry_focus (type: Industry)
    - PEUT utiliser : payment_processor (type: Software)

La différence :

• Taxonomie : "Tuiopay est un logiciel"
• Ontologie : "Un logiciel peut avoir un développeur, des utilisateurs, une date de création, un propriétaire..."

L'ontologie ne se contente pas de classer. Elle spécifie le champ des possibles pour chaque type d'entité.

Implications pour l'architecture de données

Quand vous créez une base de données, vous faites des choix ontologiques, que vous le sachiez ou non.

PostgreSQL (relationnel) :

CREATE TABLE software (
  id SERIAL PRIMARY KEY,
  name VARCHAR(255),
  inception_date DATE,
  developer_id INTEGER REFERENCES organizations(id),
  owner_id INTEGER REFERENCES organizations(id)
);

CREATE TABLE software_users (
  software_id INTEGER REFERENCES software(id),
  user_id INTEGER REFERENCES persons(id)
);

Ce schéma encode des choix ontologiques :

• Un software doit avoir un name (NOT NULL implicite)
• Un software peut avoir un developer (NULL autorisé)
• Un software peut avoir plusieurs users (table de jonction)

Neo4j (graphe) :

(s:Software {name: "Tuiopay", inception: date("2017-01-01")})
  -[:DEVELOPED_BY]->(o:Organization {name: "TUIO"})
  -[:OWNED_BY]->(o)
  -[:HAS_USER]->(p1:Person)
  -[:HAS_USER]->(p2:Person)
  -[:USES_PROCESSOR]->(stripe:Software {name: "Stripe"})

Ici, l'ontologie est encore plus explicite : les types de relations sont nommés (DEVELOPED_BY, OWNED_BY, HAS_USER). Chaque relation a une sémantique.

Wikidata (graphe + ontologie explicite) :

Q136649061 (Tuiopay)
  - P31 (instance of) → Q7397 (software)
  - P178 (developer) → Q136649061 (TUIO organization)
  - P571 (inception) → 2017
  - P17 (country) → Q16 (Canada)

Chaque propriété (P-code) est elle-même une entité avec des contraintes : P178 ne peut relier qu'un Software à une Organization. C'est l'ontologie qui définit ces règles.

IV. Le cas des problèmes philosophiques : l'espace permanent des questions

La tech crée de nouveaux types, mais les problèmes philosophiques sont permanents

En technologie, on crée effectivement constamment de nouvelles classes : "Smartphone" (post-2007), "SaaS", "Enrollment Management Software"... Ce sont de nouvelles solutions à des problèmes métiers.

Mais les problèmes philosophiques fonctionnent différemment.

Les problèmes : ce qui est commun à toutes les traditions

Pour les éditions localement transcendantes, j'ai été confronté à une difficulté ontologique fondamentale : les problèmes philosophiques sont permanents et universels. Ce sont les solutions qui varient.

Le catalogue contient des livres traitant de :

• Le problème de l'espace
• Le problème de l'immanence et de la transcendance
• Le problème de l'Un et du Multiple
• Le problème de la conscience

L'insight crucial : Un problème philosophique n'est pas une "question qu'un philosophe se pose". C'est ce qui est commun à tous les philosophes et à toutes les traditions, indépendamment de leurs réponses.

Exemples :

• Problème de l'espace : Question permanente depuis les Grecs
  • Aristote : Lieu naturel
  • Newton : Espace absolu
  • Leibniz : Relations entre corps
  • Kant : Forme a priori de la sensibilité
  • Einstein : Espace-temps courbé
  • Whitehead : Événements et relations (An Enquiry Concerning the Principles of Natural Knowledge)
• Problème de l'immanence : Comment Dieu/l'Absolu se rapporte-t-il au monde ?
  • Plotin : Émanation de l'Un
  • Spinoza : Deus sive Natura
  • Hegel : Esprit se réalisant dans l'histoire
  • Deleuze : Plan d'immanence

La clé : Chaque philosophe propose une solution (ou un système de solutions) à ces problèmes permanents. Certains philosophes ignorent délibérément certains problèmes (Badiou et la conscience, par exemple).

L'espace des problèmes comme méta-espace

Voici le tournant ontologique décisif :

L'espace des problèmes philosophiques est le méta-espace dans lequel les divers systèmes philosophiques sont des plongements.

Métaphore mathématique :

• Les problèmes = espace topologique général (dimensions permanentes)
• Les systèmes philosophiques (Spinoza, Kant, Hegel...) = sous-espaces, courbes, surfaces plongées dans cet espace
• Chaque système = une "trajectoire" à travers l'espace des problèmes

Conséquence pour la pensée : L'essentiel n'est pas de mémoriser les solutions doctrinales historiques, mais de saisir les problèmes et s'orienter dans les conversations.

Quand un chercheur en IA ou un étudiant interroge "qu'est-ce que l'espace ?", il ne cherche pas UNE réponse (Newton vs Einstein), il cherche à comprendre le problème et voir les différentes voies explorées.

Pourquoi un livre obscur devient pertinent

Cas concret : Whitehead et le problème de l'espace

Alfred North Whitehead, An Enquiry Concerning the Principles of Natural Knowledge (1919), est un livre technique et oublié. Pourtant :

• Problème traité : La nature de l'espace après la relativité d'Einstein
• Solution proposée : Espace comme structure d'événements et relations (philosophie du processus)
• Connexions :
  • Répond à Einstein (espace-temps n'est pas substance)
  • Dialogue avec Bergson (durée vs spatialité)
  • Préfigure les débats actuels en physique quantique (espace émergent)

Avant notre infrastructure sémantique : Ce livre était invisible. Un chercheur cherchant "philosophie de l'espace" trouvait Kant, peut-être Leibniz, rarement Whitehead.

Après (PostgreSQL + Neo4j + Wikidata) :

(book:Book {title: "Enquiry Concerning Natural Knowledge", author: "Whitehead"})
  -[:TREATS]->(problem:PhilosophicalProblem {name: "Nature of Space"})
  
(problem)-[:RELATED_TO]->(tradition:Tradition {name: "Process Philosophy"})
(problem)-[:CONNECTED_TO]->(problem2:Problem {name: "Space-Time Structure"})
(problem)-[:DISCUSSED_BY]->(einstein:Philosopher {name: "Albert Einstein"})
(problem)-[:DISCUSSED_BY]->(bergson:Philosopher {name: "Henri Bergson"})

Résultat : Quand un LLM ou un chercheur explore "philosophie de l'espace", il découvre Whitehead comme traitement alternatif d'un problème permanent, pas comme curiosité historique.

Modélisation ontologique : les problèmes comme entités réelles

Approche taxonomique (insuffisante) :

Philosophie
  └─ Métaphysique
      └─ Problème de l'espace

Cela range le problème dans une catégorie, mais ne montre pas ses connexions.

Approche ontologique (riche) :

CLASSE : Problème philosophique
  Affordances relationnelles :
    - EST traité_par : Philosophe* (multiple philosophes)
    - A des solutions_proposées : Système* 
    - EST lié_à : Problème* (autres problèmes connexes)
    - APPARAÎT dans : Tradition* (multiples traditions)
    - EST discuté_dans : Ouvrage*
    - UTILISE concepts : Concept*

INSTANCE : Problème de l'espace
  - traité_par : Aristote, Newton, Leibniz, Kant, Einstein, Whitehead, Bergson
  - solutions : [Espace absolu (Newton), Relations (Leibniz), Forme a priori (Kant), 
                 Espace-temps (Einstein), Structure d'événements (Whitehead)]
  - lié_à : [Problème du temps, Problème de la substance, Problème de la relativité]
  - traditions : [Philosophie naturelle, Idéalisme transcendantal, 
                  Philosophie du processus, Philosophie de la physique]

Pourquoi cette modélisation change tout :

1. Découvrabilité : LLMs comprennent que Whitehead répond au même problème qu'Einstein, même si les solutions diffèrent
2. Navigation : Un lecteur découvre les différentes voies explorées pour un même problème
3. Contextualisation : L'IA peut dire "Ce livre traite du problème X, voici d'autres approches : Y, Z"

Réalisme des problèmes : une question ontologique sérieuse

La question "les problèmes philosophiques existent-ils réellement ?" n'est pas triviale.

Position nominaliste (les problèmes sont des conventions) :

CREATE TABLE books (
  id SERIAL PRIMARY KEY,
  title VARCHAR(255),
  topics TEXT  -- Tags libres
);

Les problèmes n'existent que comme tags arbitraires.

Position réaliste (les problèmes ont une existence objective) :

(book:Book {title: "Enquiry"})
  -[:TREATS]->(problem:PhilosophicalProblem {name: "Space"})
  
(problem)-[:PERMANENT_SINCE]->(:Era {name: "Ancient Greece"})
(problem)-[:DISCUSSED_BY]->(whitehead:Philosopher)
(problem)-[:DISCUSSED_BY]->(kant:Philosopher)

Notre position : Les problèmes philosophiques ont une existence objective dans l'espace conceptuel de la philosophie. Ils ne sont pas des inventions arbitraires, mais des structures invariantes de la pensée humaine face au réel.

Pourquoi ? Parce que :

1. Permanence : Le problème de l'espace existe depuis 2500 ans, indépendamment des solutions proposées
2. Universalité : Toutes les traditions (grecque, indienne, chinoise, arabe) rencontrent ces mêmes problèmes
3. Résistance : Les problèmes résistent aux solutions (d'où leur permanence)

Ce n'est pas du "pragmatisme cynique" ("+60% ventes donc c'est vrai"). C'est une reconnaissance de structures réelles de la pensée. Les ventes augmentent parce que notre modélisation correspond à quelque chose de réel dans l'espace conceptuel.

V. Taxonomie vs Ontologie : ce que dit la recherche récente

Les ontologies améliorent les performances des LLMs

Heather Hedden, auteure de The Accidental Taxonomist (3ème édition, 2022), a récemment documenté cette observation clé :

"Les graphes de connaissances qui suivent une ontologie explicite permettent aux LLMs de mieux performer qu'un graphe non harmonisé, qui n'adhère pas à une ontologie claire."

En d'autres termes : les IA comprennent mieux le contenu structuré par une ontologie que par une simple taxonomie.

Pourquoi ? Parce qu'une ontologie fournit du contexte relationnel. Elle ne dit pas seulement "ce livre est dans la catégorie Philosophie", elle dit "ce livre traite du problème X, qui est connecté aux concepts Y et Z, traités par l'auteur A, dans la tradition B".

Barry Smith et Basic Formal Ontology (BFO)

Barry Smith, philosophe à SUNY Buffalo et créateur de Basic Formal Ontology (maintenant norme ISO 21838), a montré que les ontologies philosophiques rigoureuses ont des applications industrielles directes.

BFO est utilisé par :

• Le Département de la Défense américain (US DoD)
• Les National Institutes of Health (NIH)
• Plus de 100 projets de graphes de connaissances biomédicaux

L'insight de Smith : une ontologie bien conçue est un actif réutilisable à l'échelle d'une industrie. Vous ne créez pas une ontologie pour un seul projet, vous créez un framework conceptuel qui sert de fondation à toute une classe de problèmes.

Pour nous, créer l'ontologie des "problèmes philosophiques" n'est pas seulement utile pour un catalogue de livres. C'est une infrastructure sémantique qui peut servir :

• Aux bibliothèques universitaires (catalogage)
• Aux plateformes éducatives (recommandations)
• Aux LLMs (contextualisation philosophique)
• Aux chercheurs (découverte de textes connexes)

VI. Implications pratiques pour votre entreprise

Pour les Founders : l'ontologie comme avantage compétitif

Question simple : Vos concurrents peuvent-ils copier votre ontologie ?

Techniquement oui, juridiquement non (si vous la protégez). Mais surtout : une bonne ontologie demande de l'expertise métier que les concurrents n'ont pas.

Notre ontologie des problèmes philosophiques encode 40 ans d'expertise philosophique. Elle sait que "le problème de l'Un" chez Plotin n'est pas le même que "le problème de l'unité" chez Kant, même si les termes sont proches. Cette nuance fait toute la différence pour la découvrabilité.

ROI mesurable :

• +60% de ventes de livres (ÉLT, 1 mois)
• +40% de cycles de review réduits (Tuiopay, estimation)
• Amélioration du score Google Knowledge Graph (mesurable via Google Search Console)

Pour les CTOs : PostgreSQL, Neo4j ou les deux ?

La vraie question n'est pas "lequel choisir" mais "pour quoi faire ?"

PostgreSQL (taxonomie + données) :

• Bon pour : Transactions, intégrité référentielle, contraintes fortes
• cas d'usage : "Stocker les livres et leurs métadonnées"
• Limite : Relations complexes = JOINs multiples, schéma rigide

Neo4j (ontologie + graphe) :

• Bon pour : Relations complexes, découverte de patterns, requêtes exploratoires
• Cas d'usage : "Quels livres sont connectés par des problèmes similaires ?"
• Limite : Moins efficace pour les transactions classiques

Notre approche (duale) :

1. PostgreSQL = source de vérité pour les données transactionnelles (commandes, stocks, utilisateurs)
2. Neo4j = graphe de connaissances pour la discoverabilité (problèmes, auteurs, concepts, traditions)
3. Synchronisation = ETL nightly de PostgreSQL vers Neo4j
4. Exposition = API REST (PostgreSQL) + API GraphQL (Neo4j)

Cette architecture double coûte plus cher à maintenir, mais le ROI justifie l'investissement.

Pour les Data Scientists : taxonomies et ontologies ensemble

Une ontologie n'est pas un remplacement de taxonomie, c'est une couche au-dessus.

Architecture recommandée :

Couche 4: Ontologie (graphe de connaissances)
  ↓ Définit les relations possibles
Couche 3: Taxonomie (hiérarchies de concepts)
  ↓ Fournit le vocabulaire contrôlé
Couche 2: Schéma de données (PostgreSQL/Neo4j)
  ↓ Implémente les contraintes
Couche 1: Données brutes (instances)

Exemple concret (ÉLT) :

• Couche 1 : Livre "Éthique" de Spinoza (instance)
• Couche 2 : Table books avec champs title, author_id, problem_id
• Couche 3 : "Éthique" est dans la catégorie "Rationalisme > Métaphysique > XVIIe siècle"
• Couche 4 : "Éthique" -[:TREATS]-> "Problème de l'immanence" -[:RELATED_TO]-> "Concept : Dieu"

Les couches 3 et 4 travaillent ensemble. La taxonomie (couche 3) fournit la structure hiérarchique pour la navigation ("Browse par époque"). L'ontologie (couche 4) fournit les connexions sémantiques pour la découverte ("Readers also interested in...").

Conclusion : De la classification à la vérité

La distinction taxonomie/ontologie n'est pas académique. Elle a un impact direct sur :

• Votre chiffre d'affaires (discoverabilité)
• Votre architecture technique (choix de bases de données)
• Votre stratégie produit (quelles fonctionnalités activer)

Mais plus fondamentalement, elle révèle quelque chose sur la nature de la réalité elle-même.

Récapitulatif

	Taxonomie	Ontologie
Question	"Où ranger ?"	"Quelles relations possibles ?"
Fonction	Classer	Spécifier les affordances
Structure	Hiérarchie (arbre)	Graphe de relations typées
Exemple	"Tuiopay est un logiciel"	"Un logiciel PEUT AVOIR developer, users..."
Statut	Épistémologique (organisation)	Ontologique (types et relations)
Impact AI	Contexte limité	LLMs performent mieux
ROI	Améliore navigation	Améliore discoverabilité

La recommandation finale

Avant de demander "ai-je besoin d'une taxonomie ?", demandez-vous :

1. Ai-je besoin de RANGER des choses (navigation, catégories) ?
   → Taxonomie
2. Ai-je besoin de RELIER des choses (recommandations, découverte) ?
   → Ontologie
3. Les deux ?
   → Architecture duale (taxonomie + ontologie)

Pour la plupart des entreprises B2B SaaS modernes, la réponse est "les deux". Mais ne confondez pas les rôles : une taxonomie organise, une ontologie connecte.

Les +60% de croissance de ventes de livres philosophiques obscurs ne sont pas qu'un "hack de growth" : c'est la preuve que quand vous alignez votre infrastructure technique sur les structures réelles de la pensée, vous touchez quelque chose de vrai. Et ce qui est vrai finit toujours par fonctionner.

La sémantique n'est plus une affaire de théoriciens, c'est une infrastructure de vérité - et accessoirement, de revenus.

Références

Livres :

• Barry Smith, Robert Arp, Andrew Spear, Building Ontologies with Basic Formal Ontology, MIT Press, 2015
• Heather Hedden, The Accidental Taxonomist, 3ème édition, Information Today Inc., 2022

Articles :

• Amie Thomasson, "Some Ontology, Briefly", PRINCIPIA 28(3): 357–381, 2024
• Barry Smith, "Ontology", dans Luciano Floridi (ed.), The Blackwell Guide to the Philosophy of Computing and Information, Blackwell, 2003
• Heather Hedden, "Ontologies vs. Knowledge Graphs", blog Hedden Information Management, décembre 2024

Standards :

• ISO/IEC 21838 (Basic Formal Ontology), 2021
• W3C OWL (Web Ontology Language)
• Schema.org vocabulary

Cas d'étude :

• Éditions Localement Transcendantes : infrastructure sémantique pour textes philosophiques (+60% ventes, novembre 2025)
• Tuiopay : graphe de connaissances pour SaaS éducatif canadien (7 items Wikidata, 28 propriétés, novembre 2025)