Ingénierie de graphes de connaissances et d'ontologies de domaine

Votre IA ne peut pas raisonner sur ce qu'elle ignore

La recherche vectorielle trouve des éléments qui semblent similaires. Les graphes de connaissances trouvent des éléments qui sont vrais. Cette distinction fait toute la différence entre un système d'IA qui devine et un système qui raisonne.

Les benchmarks cliniques le rendent concret : les LLM ancrés dans des graphes de connaissances structurés par ontologie ont réduit les taux d'hallucination de 63 % à 1,7 %, tandis que la recherche purement vectorielle plafonne autour de 70 % de précision sur les tâches de connaissance complexes, contre plus de 85 % pour les approches hybrides combinant vecteurs et graphes (voir nos recherches sur l'IA ancrée dans le domaine de la santé).

La plupart des équipes qui tentent de créer des graphes de connaissances aboutissent à tout autre chose : un graphe de propriétés étiquetées dans Neo4j sans sémantique formelle, sans capacité d'inférence et sans suivi de la provenance. C'est une base de données, pas un graphe de connaissances. Cela fonctionne jusqu'à ce que vous ayez besoin de répondre à des questions que les concepteurs du schéma n'avaient pas anticipées, de retracer une sortie d'IA jusqu'à ses faits sources, ou de faire évoluer votre modèle de domaine sans casser chaque consommateur en aval.

Notre approche consiste à construire la vraie chose : des ontologies formelles avec inférence, une infrastructure de graphe de production avec provenance au niveau du triplet, et des cadres de maintenance conçus pour maintenir les connaissances à jour lorsque votre domaine évolue inévitablement.

Graphe de propriétés, magasin de triplets RDF, ou les deux : choisir la bonne architecture

Le débat Neo4j contre RDF consomme plus de cycles d'ingénierie qu'il ne le devrait, généralement parce que la décision est prise avant que les exigences ne soient comprises.

L'avantage du RDF, c'est le raisonnement automatisé : déclarez que tout médicament (Drug) interagissant avec un inhibiteur de la MAO est contre-indiqué pour les patients sous ISRS, et le moteur d'inférence déduit chaque contre-indication spécifique sans énumération manuelle.

Notre approche privilégie les systèmes hybrides où l'ontologie formelle réside dans un magasin RDF pour le raisonnement et la conformité, tandis qu'un graphe de propriétés gère les requêtes de parcours, avec une couche de synchronisation qui les maintient cohérents. Ajoutez des plongements vectoriels (TransE, CompGCN ou réseaux de neurones sur graphes) pour la similarité sémantique, et vous obtenez un système de recherche qui gère les correspondances exactes, l'inférence logique et la similarité floue dans un seul pipeline.

Ingénierie ontologique : la partie que tout le monde sous-estime

Acheter une base de données graphe est facile. Construire l'ontologie qui la rend utile, c'est là que les projets s'enlisent. Une ontologie de domaine est une spécification formelle de ce qui existe dans votre domaine, de la façon dont les choses sont liées et des contraintes qui régissent ces relations.

Réussir cela exige deux types d'expertise qui coexistent rarement : une connaissance approfondie du domaine (ce qu'un spécialiste de la réglementation pharmaceutique sait des classifications de substances IDMP) et des compétences en représentation formelle des connaissances (comment exprimer ce savoir en OWL 2 DL sans créer de goulets d'étranglement pour le raisonnement), détaillées dans notre livre blanc sur l'IA neuro-symbolique dans un domaine clinique réglementé.

Commencez par les questions de compétence

Notre processus d'ingénierie ontologique commence par les questions de compétence : les requêtes spécifiques auxquelles le graphe de connaissances doit être capable de répondre. Non pas des exigences vagues comme « prendre en charge l'analyse de la sécurité des médicaments », mais des exigences précises comme « à partir de la liste des médicaments d'un patient et d'une nouvelle prescription, identifier toutes les contre-indications transitives via les interactions des voies métaboliques en moins de 200 millisecondes ». Ces questions de compétence guident chaque décision de modélisation et deviennent la suite de tests de régression pour l'évolution de l'ontologie.

Choisir le bon formalisme

Nous choisissons le formalisme adapté à la tâche :

• OWL 2 DL — domaines nécessitant un raisonnement complet en logique de description (pharmaceutique, juridique, réglementaire).
• OWL 2 EL — grandes ontologies où la classification traitable est importante (SNOMED CT compte plus de 350 000 concepts et fonctionne parfaitement en EL).
• SKOS — taxonomies et vocabulaires contrôlés où vous avez besoin de hiérarchie et d'étiquettes mais pas d'inférence logique.
• SHACL — contraintes pour les règles de validation des données qui accompagnent l'ontologie.

La plupart des systèmes de production utilisent plusieurs formalismes en combinaison, et savoir lequel appliquer et où constitue une part importante de ce qu'apporte une mission.

Résolution d'entités : le multiplicateur de budget par 3 que personne n'anticipe

Avant qu'un graphe de connaissances puisse raisonner sur vos données, celles-ci doivent être propres, dédupliquées et reliées. La résolution d'entités — déterminer que « JPMorgan Chase », « JP Morgan », « JPMC » et « J.P. Morgan Chase & Co. » désignent la même entité — semble simple mais s'avère réellement difficile à l'échelle de l'entreprise.

La difficulté se multiplie avec des sources hétérogènes. Fusionner les connaissances de 10 à 15 systèmes sources différents implique de gérer des schémas conflictuels, des conventions d'identifiants différentes, une qualité de données variable et des incohérences temporelles (un système indique que l'entreprise a été acquise au T3, un autre au T4). Les équipes sous-estiment régulièrement le coût de la résolution d'entités d'un facteur de 3 à 5 fois.

Nous concevons des pipelines de résolution d'entités qui combinent la correspondance à base de règles, des modèles de similarité appris et une vérification humaine dans la boucle pour les cas limites. Le pipeline est architecturé pour produire un graphe d'entités canonique avec des liens de provenance remontant à chaque enregistrement source, afin que vous puissiez toujours retracer pourquoi deux enregistrements ont été fusionnés ou maintenus séparés.

Cette chaîne de provenance devient essentielle pour la traçabilité réglementaire dans le cadre de dispositifs comme le règlement européen sur l'IA (EU AI Act), où les articles 12 et 13 exigent que vous démontriez la traçabilité des données alimentant les systèmes d'IA à haut risque.

Pourquoi les projets de graphes de connaissances échouent (et comment l'éviter)

Le schéma d'échec du secteur est bien documenté : 95 % des projets pilotes d'IA générative en entreprise échouent, et les projets de graphes de connaissances ont leurs propres modes d'échec spécifiques.

1. Le piège de la preuve de concept. Une petite preuve de concept réussit avec un jeu de données soigneusement sélectionné et un schéma simple, alors la direction donne le feu vert à la construction complète. L'équipe découvre ensuite que les données réelles sont 10 fois plus désordonnées, que l'ontologie a besoin de 50 fois plus de concepts, et que les schémas de requêtes qu'elle a optimisés ne couvrent que 30 % des cas d'usage réels. Notre approche cadre les missions autour d'échantillons de données de production et de charges de requêtes réelles dès le premier jour.
2. La sur-axiomatisation. Les ingénieurs en ontologie issus du milieu universitaire ajoutent chaque axiome et restriction possibles, et le moteur d'inférence ralentit, passant de secondes à des heures sur des bases de connaissances modestes. Nous profilons les performances du moteur d'inférence tôt et en continu, en appliquant le principe d'axiomatisation minimale : n'ajouter des contraintes que lorsqu'elles servent une question de compétence spécifique.
3. La dérive ontologique. Le graphe de connaissances est lancé, fonctionne bien, puis se dégrade lentement à mesure que le domaine évolue — SNOMED CT publie des mises à jour trimestrielles, les taxonomies réglementaires changent, de nouvelles catégories de produits émergent, et personne n'assume la maintenance. Une mission est cadrée pour produire des cadres de maintenance d'ontologie avec détection des changements, analyse d'impact et tests de régression, en validant chaque nouveau concept ou relation par rapport à l'ensemble de la suite de questions de compétence avant le déploiement.
4. L'absence de responsabilité au niveau de la direction. Les graphes de connaissances sont une infrastructure — ils permettent des capacités d'IA en aval mais ne produisent pas de fonctionnalités visibles à eux seuls. Sans un parrainage exécutif reliant la qualité du graphe aux résultats commerciaux (réduction des hallucinations, conformité plus rapide, meilleure détection des interactions médicamenteuses), le projet perd son financement la deuxième année. Nous aidons les équipes à construire l'argumentaire commercial avec des indicateurs concrets liés à leurs cas d'usage spécifiques.

Connecter les graphes de connaissances aux LLM, au RAG et à l'IA agentique

Le GraphRAG de Microsoft (et sa variante à coût réduit LazyGraphRAG, qui abaisse les coûts d'extraction à 0,1 % de leur valeur initiale) a démontré que la recherche structurée par graphe surpasse la recherche purement vectorielle sur les requêtes complexes à sauts multiples. Mais le GraphRAG en production est plus difficile que ne le suggèrent les articles : la détection de communautés crée des artefacts de recherche, les pipelines d'extraction nécessitent un réglage spécifique au domaine, et il n'existe aucun suivi de provenance intégré.

Nous concevons une recherche ancrée dans le graphe de connaissances où chaque fait récupéré porte son triplet source, son score de confiance et sa validité temporelle. Lorsque le LLM génère une affirmation, le système la vérifie par rapport au graphe et cite les triplets spécifiques qui la soutiennent ou la contredisent (voir une démonstration fonctionnelle de la vérification des citations par rapport au graphe). Avec le RAG vectoriel, « le modèle a trouvé un passage similaire » est la meilleure attribution que vous obtenez.

Les graphes de connaissances comme outils accessibles aux agents

Pour les architectures d'IA agentique, les graphes de connaissances servent de sources de connaissances accessibles en tant qu'outils. Neo4j a lancé une couche de connaissances pour les systèmes agentiques sur Google Cloud en avril 2026, et l'adoption du Model Context Protocol (MCP) s'accélère en tant que norme de connecteur entre les agents et les connaissances.

Notre approche consiste à construire des graphes de connaissances interrogeables par les agents dès le premier jour : points de terminaison SPARQL, API structurées ou interfaces compatibles MCP qui permettent aux agents d'IA d'accéder aux connaissances du domaine sous forme d'appel d'outil plutôt que d'injection de prompt, une approche détaillée dans nos recherches sur le pare-feu de responsabilité pour les agents d'IA en entreprise.

Ce que nous livrons

Chaque mission est cadrée en fonction de votre domaine, de votre paysage de données et de vos exigences en matière d'IA en aval. Les livrables comprennent :

• Une ontologie de domaine formelle (OWL, entièrement annotée) validée par des moteurs d'inférence automatisés.
• Le graphe de connaissances peuplé, avec des pipelines d'ingestion pour les sources structurées et non structurées.
• Des services de résolution d'entités avec provenance complète.
• Des définitions de contraintes SHACL pour la validation des données.
• Une suite de tests de questions de compétence (motifs SPARQL ou Cypher) servant de tests de régression pour l'évolution de l'ontologie.
• Des interfaces d'intégration pour le RAG, l'ancrage des LLM ou l'accès des outils d'IA agentique.
• Un cadre de maintenance d'ontologie avec détection des changements et déploiement versionné.

Nous livrons également une évaluation honnête des cas où une approche plus simple vous conviendrait tout aussi bien.