SAP Joule et le problème des vendeurs itinérants

Königsberg et le voyageur de commerce

Le problème du vendeur itinérant (Travelling Salesman Problem, TSP) est une version généralisée du problème du pont de Königsberg. Dans tous les cas, il s'agit de trouver un chemin optimal (arêtes) à travers des lieux existants (nœuds), sachant que, par nature, il doit s'agir du chemin le plus court et qu'aucun lieu ne doit être visité plusieurs fois. Malheureusement, il n'existe pas de solution pour Königsberg.

La ville de Königsberg en Prusse est traversée dans son périmètre par la rivière Pregel ainsi que par deux îles. Les deux moitiés de la ville étaient reliées aux îles par trois ponts chacune, qui étaient reliées entre elles par un autre pont (soit sept ponts au total). La question à laquelle il fallait répondre était de savoir s'il existait une possibilité de traverser exactement une fois les sept ponts et, si tel était le cas, s'il était également possible de construire un chemin circulaire permettant de revenir au point de départ. Le mathématicien Leonhard Euler a prouvé en 1736 que la réalisation d'un tel chemin n'était pas possible à Königsberg, car un nombre impair de ponts (arêtes) menait à chacune des quatre zones riveraines ou îles (nœuds).

On suppose qu'il existe au maximum deux rives (nœuds) avec un nombre impair de ponts (arêtes) connectés. Il est possible que ces deux rives représentent le point de départ ou d'arrivée. Les autres sections de rive doivent être équipées d'un nombre pair de ponts afin de permettre un nouveau passage sur le nouveau chemin. Le problème des ponts n'est pas un problème géométrique classique, car la position exacte des ponts n'est pas importante, mais seulement la liaison des îles par les ponts. Le problème en question doit donc être classé comme problème topologique. Euler a réussi à résoudre ce problème en utilisant des méthodes qui relèvent actuellement de la théorie des graphes.

SAP Hana et le moteur graphique

Le groupe de logiciels SAP de Walldorf met actuellement en scène son intelligence artificielle comme remède miracle pour l'ERP moderne, mais un examen plus approfondi des plateformes techniques telles que SAP Hana et SAP BTP révèle une interaction très complexe d'anciens concepts et de nouvelles promesses de salut autour de la plateforme de base de données Hana. Dans la salle des machines de cette architecture, outre le traitement SQL classique, le SAP Graph Engine fait son travail depuis un certain temps.

Bien que la théorie des graphes soit une branche bien établie de l'informatique, le moteur graphique Hana a plutôt mené une existence de niche dans le passé et n'a guère pu présenter de cas d'application pratiques notables dans l'ensemble des clients existants de SAP. Cela change maintenant radicalement avec l'essor de SAP Business AI, car SAP réanime cette technique pour résoudre un problème fondamental de l'intelligence artificielle générative : L'hallucination dangereuse des modèles linguistiques qui manquent tout simplement d'une compréhension profonde des bases de données ERP très complexes qui se sont développées au fil du temps.

SAP Knowledge Graph et SAP Business AI

Le Knowledge Graph de SAP, profondément enraciné dans l'architecture Hana, se positionne désormais comme une révolution informatique et un lien sémantique entre la Business AI Platform et les applications ERP proprement dites. D'un point de vue technique, ce graphe de connaissances modélise les relations explicites entre les données commerciales, les métadonnées et les objets commerciaux - tels que les clients, les commandes et les factures - et utilise pour cela ce que l'on appelle des ontologies, qui définissent un traitement standardisé d'informations hétérogènes dans un modèle formel et reproduisent le contexte commercial inhérent.

Vecteurs versus graphes

Contrairement aux bases de données vectorielles, qui sont principalement basées sur des recherches mathématiques de similarité et dont les relations restent souvent implicites, le Knowledge Graph fournit des relations transparentes et interprétables, ce qui est indispensable pour une IA fiable et explicable dans un environnement critique pour l'entreprise. En intégrant des langages de requête de graphes comme OpenCypher ou la syntaxe RDF SPARQL, SAP permet en outre une logique de requête hybride performante, dans laquelle les données SQL relationnelles traditionnelles peuvent être combinées de manière transparente avec les structures de graphes sémantiques, sans que les données ne doivent être migrées ou dupliquées à grands frais.

Le Knowledge Graph est mis en scène par SAP comme le lien sémantique entre la nouvelle Business AI Platform et les applications SAP proprement dites de la soi-disant Autonomous Suite. Pour le client SAP critique, il est tout d'abord essentiel de comprendre que ce graphe de connaissances doit permettre à l'intelligence artificielle et aux agents autonomes d'IA de lire et de consulter de manière structurée les données ERP hautement complexes, historiques et souvent fragmentées. Selon la théorie technique qui sous-tend ce concept, le Knowledge Graph modélise explicitement les relations entre les données, les métadonnées et les objets commerciaux et constitue ainsi une couche de contexte sémantique indispensable. Sans cette connaissance contextuelle profonde et structurée, les modèles linguistiques et les agents d'IA pourraient certes analyser des données tabulaires nues, mais ne pourraient jamais comprendre la logique et les relations critiques pour l'entreprise qui se cachent derrière, ce qui conduirait inévitablement à des hallucinations d'IA dangereuses et inacceptables dans le quotidien des entreprises.

Pari risqué de l'IA sur l'avenir de l'ERP

Mais si l'on observe la construction informatique architecturale à travers le prisme critique d'un décideur informatique, le récit de SAP se révèle être un pari risqué sur l'avenir. Le groupe d'utilisateurs SAP germanophones (DSAG), et notamment son président Thomas Henzler, met le doigt sur la plaie et rappelle que, par le passé, il était souvent extrêmement difficile pour l'assistant IA Joule de répondre correctement à des questions spécifiques en raison de la complexité massive des bases de données SAP.

Certes, selon SAP, le Knowledge Graph devrait à l'avenir réduire drastiquement la modélisation manuelle des données et fournir aux modèles d'IA le contexte commercial dont ils ont un besoin urgent pour ce que l'on appelle le grounding, mais la réalité opérationnelle est actuellement encore tout autre. Des analyses indépendantes montrent que le Knowledge Graph de SAP n'est pas encore entièrement disponible dans le Business Data Cloud (BDC) tant vanté, mais qu'il a été annoncé pour le deuxième semestre 2026. Jusqu'à cette date, les agents IA autonomes tant vantés agissent en fait à l'aveuglette sur le plan sémantique, car il leur manque précisément la couche contextuelle essentielle qui doit empêcher de manière fiable les hallucinations dans la suite SAP Autonomous. De plus, la modélisation sans erreur de telles structures de graphes nécessite un immense savoir-faire technique et une qualité de données irréprochable, car un graphe de connaissances basé sur des données de base incohérentes ne fera qu'accélérer les erreurs de décision logiques de l'IA au lieu de les empêcher. Pour les clients existants de SAP, cette constatation signifie sans équivoque que la vision technique ERP d'une architecture d'IA basée sur des graphes sur SAP Hana est certes brillante sur le plan académique et logique sur le plan architectural, mais qu'elle doit encore prouver dans le dur quotidien informatique qu'elle est plus qu'une simple promesse nuageuse de plus sur la voie de l'entreprise autonome.