Tout projet data ou IA commence par la même promesse : « on a déjà les données ». C'est vrai. Elles sont dans le PLM, l'ERP, le MES, Snowflake, SharePoint, et dans quelques fichiers Excel que personne n'ose supprimer.
Et pourtant, trois mois plus tard, le projet bute toujours sur les mêmes questions. Qu'appelle-t-on une « pièce » ? Une référence de conception, un article acheté, ou un composant monté sur une ligne ? Qui est le « fournisseur » : le site qui forge ou la société qui facture ?
Les données existent en abondance ; il reste à s'accorder sur ce qu'elles veulent dire.
C'est exactement le rôle d'une ontologie. Cet article répond à une question qu'on nous pose à chaque démarrage de projet : à quoi sert-il de créer une ontologie, et pourquoi commencer par là ?
Ce qu'est une ontologie
Une ontologie est la description explicite des concepts d'un métier, des relations qui les unissent et des règles qui les gouvernent. Une pièce est fournie par un fournisseur. Elle est faite d'un matériau. Ce matériau est fondu dans un pays. Chaque affirmation de ce type devient un lien manipulable dans le graphe.
Concrètement, une ontologie contient quatre briques.
Une ontologie se distingue d'un schéma de base de données, qui décrit la façon dont les données sont stockées pour une application donnée : elle décrit ce que ces données signifient pour le métier, indépendamment de toute application. Elle va aussi plus loin qu'un glossaire, puisqu'elle relie les concepts entre eux et permet de raisonner dessus.
Une fois l'ontologie posée, les données des différents systèmes viennent s'y accrocher. Le résultat est un graphe de connaissance : vos faits, reliés selon le sens que votre métier leur donne.
Cinq utilités d'une ontologie
Un langage commun entre les métiers
La première valeur d'une ontologie apparaît avant même qu'on ait chargé la moindre donnée. Pour la construire, l'ingénierie, les achats, la fabrication et la qualité doivent se mettre d'accord sur leurs concepts. Et c'est souvent la première fois qu'ils le font explicitement.
Cet exercice fait remonter les malentendus qui coûtent cher. Deux équipes qui utilisent le même mot pour deux choses différentes. Une règle connue d'un seul expert. Une relation que tout le monde suppose, mais qu'aucun système ne porte.
L'ontologie laisse à chaque métier son vocabulaire : elle documente les équivalences (synonymes, variantes locales) et fixe une définition de référence, ce qui permet au graphe de reconnaître un même objet sous ses différents noms.
Les réunions de réconciliation diminuent, et un nouvel arrivant comprend le métier en lisant le modèle plutôt qu'en interrogeant les anciens.
Relier les systèmes sans les remplacer
Les projets de « plateforme unique » promettent de tout centraliser. Ils finissent souvent en migration de plusieurs années, avec un nouveau silo à la clé. Une ontologie prend le chemin inverse : elle laisse les données là où elles sont et décrit comment elles se relient.
Chaque source garde son rôle. Le PLM reste maître de la conception, l'ERP des achats, le MES de la fabrication. L'ontologie dit simplement que l'article de l'ERP et la référence du PLM sont deux facettes du même objet. Elle pose les ponts qui manquent entre des systèmes construits chacun pour son propre usage.
C'est aussi ce qui rend la démarche progressive. On connecte une première source, on répond à une première question, puis on ajoute la suivante. Chaque source branchée enrichit le même graphe au lieu de créer un nouveau projet.
La couche sémantique se pose au-dessus de l'existant, sans toucher aux systèmes de référence ni à leurs propriétaires.
Rendre l'IA fiable, et vérifiable
C'est aujourd'hui la raison la plus pressante. Un LLM branché directement sur des tables d'entreprise devine le sens des colonnes à partir de leurs noms. Sur des schémas industriels, avec leurs codes et leurs abréviations, il se trompe souvent, et avec aplomb.
Les chiffres le confirment. Dans un benchmark publié en 2023, GPT-4 interrogeant directement une base SQL d'entreprise obtenait 16,7 % de réponses justes. Les mêmes questions posées sur une représentation en graphe de connaissance, guidée par une ontologie, atteignaient 54,2 %, soit trois fois plus [1]. Dans une étude de suivi, l'ontologie servait aussi à détecter et corriger les requêtes incohérentes du LLM, ce qui portait la précision à 72,55 % [2].
L'ontologie joue deux rôles pour l'IA.
L'ontologie apporte aussi un bénéfice décisif dans l'industrie : la preuve. Quand la réponse vient d'un parcours dans le graphe, ce parcours devient visible : les pièces, les fournisseurs et les documents qui y mènent. Chaque réponse devient ainsi justifiable et auditable, et l'expert métier peut la contester point par point.
L'IA passe du statut de démo impressionnante à celui d'outil sur lequel on peut prendre une décision.
Répondre aux questions que personne n'a prévues
Un tableau de bord répond très bien à la question pour laquelle il a été construit. Le jour où les achats, la qualité ou un programme arrivent avec une question posée sous un autre angle, il se tait. Il faut alors lancer un nouveau développement, qui fige un point de vue de plus.
Une ontologie range des faits et leurs liens, et l'angle d'analyse se choisit au moment de poser la question. « Quelles pièces sont exposées si ce fournisseur tombe ? », « Quels véhicules sont touchés par cette évolution réglementaire ? » : les deux questions parcourent le même graphe, dans deux directions différentes.
L'ontologie permet aussi de modéliser ce qui manque : un certificat matière absent devient un objet du graphe, qu'on peut compter, filtrer et prioriser. Le graphe sait exactement où sont les trous, et lesquels combler en premier.
On passe d'une BI qui répond à N questions planifiées à un graphe qui répond aux questions qu'on n'a pas encore posées.
Un actif qui grandit avec le métier
Dans la plupart des entreprises, la connaissance métier vit dans deux endroits fragiles : la tête des experts et des fichiers qui vieillissent. Quand l'expert part, la règle part avec lui. Quand le fichier n'est plus maintenu, il devient un risque.
L'ontologie capitalise cette connaissance dans un format explicite, versionné et partagé. Elle évolue : quand une question révèle un concept ou une relation manquante, on l'ajoute sans casser l'existant. Le métier fait avancer sa propre représentation au rythme de ses questions.
Elle reste aussi la propriété du client. Une ontologie bien construite est exportable et constitue un actif de l'entreprise, indépendant de l'outil qui l'a produite.
Chaque question posée, chaque source connectée, chaque trou comblé enrichit le même modèle. Un rapport de consultant vieillit dans un tiroir ; une ontologie prend de la valeur à chaque usage.
Snowflake, Foundry : toutes les « ontologies » ne se valent pas
Le mot est à la mode, et les grandes plateformes de données l'ont toutes adopté. Mais derrière le même mot se cachent des choses très différentes. Deux exemples reviennent dans presque toutes nos conversations.
Snowflake et ses vues sémantiques. Snowflake propose des « semantic views » : des objets qui décrivent, au-dessus des tables, des faits, des dimensions, des métriques, des synonymes et des chemins de jointure [3]. Elles alimentent Cortex Analyst, l'assistant qui traduit une question en SQL. C'est utile, et c'est un vrai progrès pour la BI conversationnelle. Leur portée reste toutefois celle d'une couche sémantique : centrées sur les tables et les agrégats (« quel est le chiffre d'affaires par région ? »), elles traitent les relations comme des jointures et se limitent aux données présentes dans Snowflake.
Palantir Foundry et son Ontology. Foundry va beaucoup plus loin. Son Ontology décrit des types d'objets, des types de liens entre eux, et des types d'actions qui modifient ces objets de façon contrôlée [4]. C'est une vraie ontologie opérationnelle, et l'une des plus abouties du marché. Sa limite est ailleurs : elle vit à l'intérieur de Foundry. Elle s'appuie sur les données intégrées dans la plateforme, se construit avec ses outils et ses équipes, et ne se transporte pas ailleurs. Le modèle de votre métier devient un actif de la plateforme autant que le vôtre.
La question à poser porte donc sur trois points : que modélise cette ontologie, sur quelles données, et à qui appartient-elle ?
| SnowflakeVues sémantiques | Palantir FoundryOntology | GraphicientGraphForge | |
|---|---|---|---|
| Ce qui est modélisé | Métriques, dimensions, jointures | Objets, liens, actions | Concepts, relations, interfaces, règles, synonymes |
| Questions servies | Agrégats et indicateurs (text-to-SQL) | Applications opérationnelles | Questions transverses multi-niveaux, avec sous-graphe justificatif |
| Périmètre des données | Données dans Snowflake | Données intégrées dans Foundry | Sources existantes du client, dont Snowflake |
| Qui construit | Équipes data | Équipes Foundry et data | Experts métier, en no-code |
| Portabilité | Liée à Snowflake | Liée à Foundry | Exportable à tout moment, propriété du client |
Ces approches ne s'excluent pas. Chez nos clients, Graphicient lit les données de Snowflake et en respecte la gouvernance. Une vue sémantique reste très efficace pour calculer un indicateur ; l'ontologie sert à relier ce qu'aucune plateforme ne voit seule.
Pourquoi l'ontologie d'une plateforme ne suffit pas
Ces outils sont de qualité, et leur limite tient à leur point de départ : une ontologie de plateforme décrit les données de cette plateforme. Tant que le métier tient dans un seul outil, l'écart reste mince ; dans l'industrie, le métier s'étend toujours sur plusieurs systèmes.
- 01Ce qui n'est pas dans la plateforme n'existe pas.Une vue sémantique Snowflake ne voit que les tables Snowflake. L'Ontology Foundry ne voit que ce qui a été intégré dans Foundry. Or la connaissance industrielle est éclatée : nomenclature dans le PLM, gammes dans le MES, contrats dans l'ERP, exigences dans des documents, règles dans des fichiers Excel. Pour que l'ontologie de la plateforme couvre le métier, il faut d'abord tout y déplacer. On se retrouve alors face à un projet de migration.
- 02Une ontologie par plateforme, c'est un silo de plus.Un grand industriel exploite plusieurs plateformes de données. Si chacune porte sa propre « ontologie », on recrée au niveau du sens la fragmentation qu'on voulait résoudre au niveau des données. La « pièce » de Snowflake, celle de Foundry et celle du PLM redeviennent trois objets différents, qu'il faut à nouveau réconcilier.
- 03Elles répondent aux questions prévues.Une vue sémantique est excellente pour une métrique définie à l'avance : un chiffre par région, par mois, par famille. Dès qu'une question traverse plusieurs niveaux, de la pièce au matériau, du matériau au pays de fonte, du pays au programme, le modèle s'arrête. Le LLM retombe alors sur les tables brutes et doit deviner les jointures. C'est exactement là que la précision s'effondre [1].
- 04Elles donnent un résultat, pas un raisonnement.Le text-to-SQL renvoie un nombre. Il ne montre pas le chemin qui y mène, ni les objets intermédiaires, ni ce qui manque en route. Pour un expert qui doit valider une décision, ou un auditeur qui doit la vérifier, un chiffre sans chemin ne suffit pas. Dans un graphe, la réponse est le chemin.
- 05Elles ne modélisent ni l'absence ni la règle.Un certificat manquant, une qualification expirée, une règle de conformité entre deux concepts : une couche sémantique orientée métriques n'a pas de place pour ces objets. Ce sont pourtant eux qui font la valeur d'une analyse de risque ou d'un audit de conformité.
- 06Le modèle appartient à la plateforme.Il est construit avec ses outils, dans son format, souvent par ses équipes ou des spécialistes formés à elle. Changer de plateforme, c'est reconstruire. Et la connaissance du métier reste entre les mains de ceux qui maîtrisent l'outil.
En résumé : l'ontologie d'une plateforme rend cette plateforme plus intelligente. Une ontologie métier rend l'entreprise plus intelligente, quelles que soient les plateformes qu'elle utilise aujourd'hui et celles qu'elle choisira demain.
Les objections qu'on entend, et ce qu'on y répond
Comment démarrer une ontologie sur un projet
La règle d'or : commencer par une question, pas par le modèle exhaustif. Une ontologie qui veut tout décrire dès le premier jour ne répond à rien avant six mois.
- 1Choisir une question qui fait mal.« Si ce composant devient non conforme, quels véhicules sont touchés ? » Une question à laquelle on répond aujourd'hui en plusieurs jours, à la main.
- 2Lister les concepts qu'elle traverse.Souvent cinq à dix : pièce, fournisseur, matériau, exigence, véhicule, document.
- 3Nommer les relations et les règles.Avec les experts métier, pas à leur place. C'est là que se règlent les malentendus.
- 4Brancher les sources existantes.Sans migration : on relie les colonnes des systèmes aux concepts de l'ontologie.
- 5Poser la question, puis la suivante.Chaque nouvelle question révèle un concept ou un lien à ajouter. L'ontologie grandit par l'usage.
En pratique, une première ontologie utile se construit en quelques jours, pas en quelques mois.
Ce que Graphicient apporte
Graphicient a construit sa plateforme autour d'une conviction : l'ontologie doit appartenir aux métiers.
Conclusion
Créer une ontologie permet de régler une fois pour toutes la question que tous les projets data et IA finissent par se poser : de quoi parle-t-on exactement ?
À partir de là, le reste suit. Les métiers partagent un langage. Les systèmes se relient sans migration. L'IA répond juste, et montre pourquoi. Et chaque nouvelle question enrichit un actif qui appartient à l'entreprise.
Notre mission : donner aux équipes métier l'autonomie de structurer et d'exploiter leur propre connaissance, sans dépendre d'une équipe data à chaque question.
Venez avec une question métier, vous repartirez avec votre première ontologie.Contactez-nous →Sources
- [1]Sequeda, Allemang, Jacob — A Benchmark to Understand the Role of Knowledge Graphs on Large Language Model's Accuracy for Question Answering on Enterprise SQL Databases (data.world, novembre 2023). GPT-4 en zero-shot : 16,7 % de précision sur SQL direct, 54,2 % sur la représentation en graphe de connaissance. arxiv.org/abs/2311.07509
- [2]Allemang, Sequeda — Increasing the LLM Accuracy for Question Answering: Ontologies to the Rescue! (mai 2024). L'ontologie sert à détecter et réparer les requêtes erronées ; précision portée à 72,55 %. arxiv.org/abs/2405.11706
- [3]Snowflake Documentation — YAML specification for semantic views : objets de schéma définissant des concepts métier (tables logiques, faits, dimensions, métriques) au-dessus des tables Snowflake, utilisés par Cortex Analyst. docs.snowflake.com
- [4]Palantir Documentation — Ontology architecture : l'Ontology Foundry comme couche opérationnelle définissant types d'objets, types de liens et types d'actions, au-dessus des actifs intégrés à la plateforme. palantir.com/docs