SAP Knowledge Graph : quand les relations deviennent des données

Une ontologie pour l'entreprise autonome

Les nœuds (nodes) représentent des entités métier réelles telles que les clients, les sites, les commandes ou les factures, tandis que les arêtes (edges) décrivent les relations explicites entre ces entités (par exemple : le client A passe la commande B). C'est sur cette structure que repose le modèle formel de représentation des connaissances (propriétés), appelé « ontologie ». Elle définit des concepts standardisés, des hiérarchies et des règles pour l'ensemble de l'entreprise.

D'un point de vue technique, ces connaissances sont généralement représentées via le Resource Description Framework (RDF) sous forme de triplets, qui suivent une structure grammaticale claire composée d'un sujet, d'un prédicat et d'un objet (par exemple : le fournisseur X fournit le produit Y). Contrairement à un simple tableau SQL, un tel graphe de connaissances est interprétable de manière logique tant par les humains que par les machines.

SAP HANA Cloud Vector Engine

À cet égard, il est essentiel de faire la distinction avec les bases de données vectorielles (telles que SAP Hana Cloud Vector Engine). Une base de données vectorielle transforme des données non structurées en vecteurs numériques multidimensionnels (embeddings). Cela peut donner lieu à des espaces comportant des centaines de dimensions – un jeu d’enfant pour l’ordinateur, mais inimaginable pour l’être humain : on s’arrête généralement à quatre dimensions – trois dimensions spatiales et la quatrième dimension pour le temps.

Dans les espaces multidimensionnels, les relations entre les points de données sont calculées de manière purement mathématique à partir de distances spatiales (telles que la similarité cosinus ou les distances euclidiennes). Cette approche est particulièrement adaptée à la recherche de similitudes dans des textes non structurés (Retrieval-Augmented Generation, RAG), mais reste une « boîte noire » mathématique pour l'utilisateur, car les relations calculées sont implicites et ne peuvent être expliquées de manière logique.

Un graphe de connaissances, en revanche, définit les relations de manière explicite, transparente et fondée sur des règles. Alors que les vecteurs reflètent l'association mathématique de l'IA, le graphe de connaissances incarne son ensemble de règles logiques et explicables.

Intégration native de Graph dans SAP Hana Cloud

Pendant longtemps, l’utilisation pratique des bases de données graphiques dans l’univers SAP s’est heurtée à une rupture de média particulièrement gênante. Quiconque souhaitait analyser des réseaux de relations complexes devait extraire laborieusement les données du système ERP et les transférer vers des systèmes tiers spécialisés tels que Neo4j. Avec la mise à jour stratégique de HANA au premier trimestre 2025, SAP a comblé cette lacune fonctionnelle. Depuis lors, la base de données en mémoire HANA Cloud offre une prise en charge native du stockage et de la recherche dans les graphes de connaissances.

La base de données s'appuie pour cela sur la syntaxe RDF bien établie et le langage de requête SPARQL. Le principal avantage architectural de cette approche „ multi-modèle “ réside dans la possibilité de combiner directement les données : les développeurs peuvent associer de manière transparente des données relationnelles SQL à des données de graphe dans une seule requête ou les relier via des jointures, sans qu'il soit nécessaire de répliquer les données.

SAP Knowledge Graph et SAP Virtual Data Models

Le SAP Knowledge Graph, qui se situe à un niveau supérieur, s'appuie sur ce moteur de base de données intégré. Il accède à l'ensemble des métadonnées du SAP Virtual Data Model (VDM) et crée une ontologie qui représente les relations métier inhérentes à S/4. Ce graphe sert de boussole à l’assistant IA Joule et aux agents autonomes. Lorsqu’un utilisateur demande à Joule en langage naturel : „ Montre-moi les commandes en retard “, l’IA n’a plus besoin de deviner les structures des tables. Le Knowledge Graph navigue à travers le réseau sémantique, identifie les API autorisées appropriées, définit les paramètres de filtrage adéquats et construit une requête précise. Le risque d’obtenir des résultats imprécis ou non pertinents est ainsi considérablement réduit par rapport aux approches reposant uniquement sur les modèles de langage (LLM).

Aussi élégant que ce concept puisse paraître en théorie, la pratique met en évidence les obstacles et les risques que cette technologie présente pour les clients SAP existants : un graphe de connaissances opérationnel à l'échelle de l'entreprise n'est pas un produit « clé en main », mais le résultat d'un processus de modélisation extrêmement complexe. La création et la maintenance continue des ontologies et des structures de graphes exigent un savoir-faire sémantique approfondi et mobilisent des ressources informatiques considérables. Ceux qui pensent que le logiciel se charge de la structuration sémantique de manière entièrement automatique sous-estiment considérablement la complexité des processus personnalisés et des tables personnalisées qui se sont développées au fil du temps.

Qualité des données, unités de capacité et politique relative à l'API

Un graphe de connaissances ne peut pas remédier à une mauvaise qualité des données. Si la base de données du système ERP est incomplète, obsolète ou incohérente, même le graphe le plus intelligent ne fournira que des informations erronées, bien que parfaitement structurées. Les analyses complexes de graphes (telles que la recherche de chemins et de boucles) sur des ensembles de données transactionnelles massifs et hautement interconnectés sont très gourmandes en ressources de calcul. Les bases de données en mémoire atteignent rapidement leurs limites physiques lors de telles opérations, ce qui peut faire grimper sans pitié les coûts matériels des instances HANA Cloud.

D'un point de vue technique, le Knowledge Graph est extrêmement bien conçu, mais sur le plan commercial, il sert de « péage » stratégique à SAP. Pour tirer pleinement parti de la technologie des graphes, SAP contraint ses clients existants à intégrer l’écosystème restrictif du Business Data Cloud (SAP BDC) et de la Business Technology Platform (BTP ou BAIP, Business AI Platform). Par le biais de modèles de facturation basés sur la consommation (Capacity Units) et de directives API restrictives, SAP tente de conserver le contrôle absolu sur les contextes métier de ses clients existants et de bloquer systématiquement la fuite, sans licence, de ces précieuses métadonnées vers des plateformes d’IA tierces puissantes et plus abordables de tiers ou d’hyperscalers.

Des alternatives autonomes au-delà du monopole des ERP

Les clients existants de SAP ne doivent toutefois pas se résigner sans réagir face à cette mainmise monopolistique. Le marché des requêtes d'IA spécifiques aux bases de données et des couches sémantiques connaît un développement fulgurant et propose des alternatives puissantes et indépendantes des éditeurs :

Des outils tels que vanna.AI proposent des frameworks flexibles permettant de connecter directement des applications basées sur des modèles linguistiques à des bases de données SQL existantes (de Snowflake à Oracle en passant par PostgreSQL). Grâce à l’ajout de DDL, de documentation et d’exemples de requêtes historiques, le système apprend les relations sémantiques sans qu’il soit nécessaire d’acquérir une licence pour une infrastructure SAP coûteuse.

Le framework WrenAI démontre de manière impressionnante comment un modèle sémantique peut être construit directement à l'aide d'un éditeur graphique, dans lequel les tables sont définies comme des nœuds et les relations comme des arêtes. WrenAI convertit ce graphe de connaissances en un format standardisé qui évite les requêtes redondantes et ambiguës et génère des commandes SQL précises – sans passer par le SAP BTP Generative AI Hub ou Datasphere, ce qui représente un coût supplémentaire.

Des plateformes spécialisées dans les graphes, telles que Graphwise avec GraphDB, démontrent également comment mettre en place des systèmes de graphes de connaissances à l'échelle de l'entreprise, basés sur des normes ouvertes (RDF, OWL, SPARQL). Ces systèmes peuvent orchestrer des sources de données hétérogènes et être directement reliés à des modèles linguistiques modernes via des plugins intelligents (tels que le ChatGPT Retrieval Connector), tandis que la souveraineté sur les données sensibles reste entièrement sous le contrôle de l'entreprise.

Bilan personnel pour la communauté SAP

Le Knowledge Graph est sans aucun doute le paradigme techniquement le plus avancé pour l'avenir de l'IA d'entreprise, car il comble le fossé indispensable entre l'imprécision stochastique des modèles linguistiques et la précision déterministe des systèmes ERP de gestion d'entreprise. Cependant, en tant que client SAP existant et prudent, vous devriez dissocier la mise en œuvre de cette technologie de la doctrine commerciale de SAP en matière de plateformes. Tirez parti des capacités multimodales du Hana Cloud Graph Engine pour structurer clairement vos données. Mais refusez systématiquement d’enfermer l’intégralité de votre carte sémantique d’entreprise exclusivement dans le piège coûteux des licences SAP BTP. L’avenir appartient aux espaces de données ouverts et interopérables, dans lesquels l’entreprise conserve une souveraineté absolue sur son contexte métier et son intelligence artificielle.