Databricks Mosaic AI : des agents IA qui maîtrisent véritablement la logique métier de SAP
- Databricks
- Databricks
- 9 min de lecture
Kenan Hodzic
Cet article explique pourquoi, dans l'environnement SAP, les agents IA échouent non pas en raison d'un problème d'accès aux données, mais d'un manque de sémantique – et comment Databricks Mosaic AI résout ce problème grâce à un contexte gouverné. L'accent est mis sur les Metric Views et Unity Catalog en tant que « contrat logique » pour les KPI et les accès, complétés par le raisonnement graphique (Neo4j Virtual Graph) pour les questions relatives aux flux de documents et aux hiérarchies. Résultat : moins d'improvisation sur les données brutes, plus de contrôle, de traçabilité et d'auditabilité – comme base d'une intelligence décisionnelle fiable.
Table des matières
1. Le problème : l'accès aux données ne signifie pas la maîtrise de la logique
1.1 De quoi s'agit-il ?
De nombreuses approches SAP-IA suivent un schéma d'une simplicité séduisante : un modèle linguistique de grande envergure (LLM) est connecté aux données SAP via OData, SQL ou des API, et génère des réponses à partir de celles-ci. Cela peut fonctionner pour des requêtes simples, mais ce modèle atteint ses limites dès que la logique métier SAP entre en jeu.
La logique financière et métier de SAP ne se limite pas à des tables isolées. Elle résulte de l'interaction entre les ledgers, les variantes d'exercice comptable, les règles de conversion, les flux de pièces, les hiérarchies, les définitions d'indicateurs et les autorisations. Un agent qui ne connaît pas cette logique peut fournir des réponses qui semblent correctes sur le plan formel, mais qui sont erronées sur le fond – ce qui, dans le contexte financier et de conformité, est plus dangereux que l'absence totale de réponse.
Ces agents – qui fonctionnent sur le plan technique, mais qui ne maîtrisent pas le niveau sémantique de SAP – sont désignés dans cet article sous le nom d’« agents naïfs ». Ce terme n’a aucune connotation péjorative, mais décrit précisément le cœur du problème : l’agent est naïf vis-à-vis de la logique métier, car il n’y a pas accès.
Un exemple permet d'illustrer le problème : un utilisateur demande la marge opérationnelle réelle d'une gamme de produits au cours du dernier trimestre. Un agent peu expérimenté accède directement à ACDOCA – le journal central dans SAP S/4HANA –, additionne les recettes et les coûts, puis fournit un résultat. Ce résultat est techniquement correct, mais erroné sur le fond. Il manque en effet à l'agent des informations essentielles :
- Quelle variante d'exercice fiscal s'applique à la société en question ?
- Quelle est la méthode de conversion des devises prescrite au sein du groupe ?
- Quelle hiérarchie des centres de profit ou des gammes de produits est valable sur le plan fonctionnel ?
- Quelles données l'utilisateur qui pose la question est-il autorisé à consulter ?
Le véritable risque ne réside pas ici dans un chiffre erroné isolé, mais dans le fait que la réponse semble convaincante sur le plan linguistique. Dans le domaine de la finance, de la conformité et du contrôle de gestion, une réponse formellement plausible mais techniquement erronée est bien plus dangereuse qu’une réponse manquant tout simplement.
On ne peut parler de véritable « Decision Intelligence » que lorsqu'un agent n'agit pas comme un simple traducteur SQL sur des tables brutes, mais utilise les règles métier définies au sein de l'entreprise comme référence absolue.
Les sections suivantes montrent où les agents naïfs échouent concrètement – et quels niveaux un agent doit maîtriser pour vraiment maîtriser la logique SAP.
1.2 Pourquoi les agents naïfs échouent
Les types d'erreurs typiques surviennent toujours lorsqu'un LLM traite directement du code SQL brut ou des données OData :
Les exercices comptables SAP coïncident rarement avec l'année civile. Un agent qui ne connaît pas la variante d'exercice comptable risque de délimiter les périodes de manière erronée.
Les indicateurs qui existent à différents niveaux de compression sont mélangés entre eux ou agrégés à un niveau qui n'est pas acceptable d'un point de vue économique.
Le flux des pièces, la logique d'annulation et de rapprochement font défaut ; l'agent additionne tout ce qu'il trouve.
Prévisionnel vs. réel, brut vs. net, le ratio SAC calculé vs. le champ brut : des concepts sémantiquement très différents, mais dont les noms se ressemblent souvent.
Société, périmètre de comptabilité analytique, hiérarchie des centres de profit : l'agent effectue une agrégation au-delà des limites organisationnelles qui ne doivent pas être franchies d'un point de vue comptable.
Les zéros non significatifs dans les numéros d'article, les modèles de préfixe, la gestion des barres obliques inversées dans les identifiants de membre, les conventions de dimensionnement : tout cela se passe en silence, sans message d'erreur.
Le cas le plus grave : l'agent consulte et divulgue des données que l'utilisateur qui en fait la demande ne devrait jamais voir, conformément au modèle d'autorisation SAP.
Ces erreurs ont toutes un point commun : elles surviennent parce que l'agent opère au niveau de la table, alors que la logique métier se situe à un niveau supérieur.
1.3 Les principaux niveaux pour les agents
Un agent naïf échoue donc non pas par manque de puissance de calcul, mais par manque de contexte : il ne sait pas ce que signifient les données. Pour comprendre ce qu'un agent devrait réellement maîtriser, il est utile de se référer à une taxonomie des niveaux pertinents :
niveau | Exemples | Là où réside la logique |
Sémantique des données de base | Comptes généraux, centres de coûts, articles | Vues CDS, modèles Datasphere |
Structures organisationnelles et hiérarchies | Société, arborescence des centres de profit | Tableaux hiérarchiques, modèles sémantiques |
Flux de documents / Chaînes de processus | De la commande à l'encaissement, de l'approvisionnement au paiement, de la saisie à la reporting | Enchaînement des documents, champs d'état |
logique de calcul | Écarts, indicateurs dérivés | Vues CDS, vues métriques, modèles analytiques |
Politique d'autorisation | Qui a le droit de voir quelle entité organisationnelle | Objets d'authentification SAP |
L'idée fondamentale est la suivante : cette logique existe déjà. Elle est codifiée dans les vues CDS, les modèles analytiques Datasphere et les vues métriques. Un agent n'a pas besoin de la réimplémenter : il doit s'y référer comme à une source fiable (vérité de référence) et ne doit pas la contourner.
2. La solution : Databricks Mosaic AI dans le contexte SAP
Databricks Mosaic AI est la couche d'IA et d'apprentissage automatique de la plateforme Databricks Data Intelligence. Alors que de nombreuses plateformes d'IA sont principalement axées sur l'entraînement de modèles ou sur de simples interfaces de chat, Mosaic AI offre une pile intégrée pour la création, l'évaluation et l'exploitation d'agents IA – directement sur le Lakehouse, là où les données sont déjà stockées. Cela rend Mosaic AI particulièrement pertinent dans l’environnement SAP : les agents IA ne fonctionnent pas sur une plateforme externe avec des données répliquées, mais sur la base de données gouvernée qui a de toute façon été mise en place dans le Lakehouse.
Mosaic AI se compose de plusieurs modules qui peuvent être combinés de manière ciblée pour répondre à des besoins spécifiques. Plutôt qu'une liste abstraite de fonctionnalités, chaque composant est directement adapté à un problème logique SAP concret.
Module Mosaic-AI | Problème SAP identifié |
Agent Bricks (générateur d'agents automatisé avec données synthétiques et tests de performance) | Une méthode rapide et éprouvée pour passer du concept de preuve de principe (PoC) à une précision prête pour la production, sans recourir à des essais manuels |
Cadre d'agents IA Mosaic | Orchestration, appel d'outils, mémoire |
Vues des métriques d'Unity Catalog | Une définition des indicateurs clés de performance (KPI) comme outil |
Recherche vectorielle + Récupération de graphes | Recherche basée sur des relations sémantiques plutôt que sur une simple recherche par mots-clés |
Tracing MLflow 3.0 | Possibilité de vérifier chaque décision prise par l'agent |
Passerelle IA | Gouvernance des modèles, maîtrise des coûts, sécurité |
MCP (Model Context Protocol) | Une connexion propre et standardisée des outils aux systèmes liés à SAP |
L'agent Bricks a été présenté lors du Data+AI Summit ; il génère automatiquement des données synthétiques et des benchmarks spécifiques à chaque domaine afin d'optimiser les agents en termes de coûts et de qualité, sans avoir recours à des essais manuels. Concrètement, pour SAP, cela signifie que les cas limites de la logique métier peuvent être systématiquement modélisés sous forme de cas de test avant la mise en production d'un agent.
Le guide Databricks d'Andreas & Yvonne
Vous voulez toutes les informations importantes en un coup d'œil ?
Téléchargez dès maintenant le guide gratuit de SAP Databricks !
3. Raisonnement sur les graphes : le niveau manquant
La plupart des erreurs décrites à la section 2 sont, par nature, des erreurs relationnelles. La logique métier dans SAP repose principalement sur les relations :
Compte GL → Centre de profit → Société
Fournisseur → Commande → Entrée de marchandises → Facture → Ligne de pièce → Pièce du grand livre
Centre de coûts → Matériel
Ce sont précisément ces relations qu’un graphe de connaissances représente – et sur lesquelles un agent doit pouvoir tirer des conclusions «à plusieurs niveaux de distance». Une question typique serait : «Quels centres de coûts en aval sont affectés par cette perturbation chez le fournisseur?» Une simple requête sur un tableau plat et une recherche vectorielle ne suffisent tout simplement pas pour cela.
Le problème jusqu'à présent : pour mettre en œuvre le raisonnement sur les graphes à partir des données SAP, il fallait jusqu'à présent copier ces données dans une base de données de graphes distincte. Cela crée un deuxième système d'enregistrement, fragmente la gouvernance et nécessite un pipeline dédié – ce qui constitue un inconvénient majeur compte tenu du volume et de la sensibilité des données SAP.
3.1 La nouveauté : Neo4j Virtual Graph
Disponible en préversion privée depuis mai 2026, pris en charge par Databricks dès le lancement. Virtual Graph permet d'exécuter des requêtes Cypher et des algorithmes de graphe directement sur les données déjà stockées dans Databricks, grâce à la technologie « zero-copy », sans aucun transfert de données.
L'architecture se compose de trois parties :
- Modèle de données généré par l'IA : le graphe est automatiquement dérivé du schéma de table existant ; les entités deviennent des nœuds, les clés étrangères (y compris celles qui ne sont pas déclarées, mais déduites) deviennent des relations, et les colonnes deviennent des propriétés. Le modèle reste modifiable et se synchronise avec les sources.
- Traducteur de requêtes : Cypher est traduit de manière déterministe en SQL optimisé, puis transmis au moteur Databricks sous forme de pushdown. « Déterministe » signifie : le même code SQL à chaque exécution, des performances et des coûts prévisibles – la traduction n'est pas pilotée par un modèle de langage (LLM).
- Couche de calcul sur les graphes : prend en charge les opérations spécifiques aux graphes (correspondance de motifs, traversées, algorithmes) que le langage SQL ne permet pas d'exprimer efficacement à lui seul.
Les données ne sortent jamais de leur périmètre de gouvernance. C'est là le point essentiel pour SAP : l'infrastructure sémantique devient une couche virtuelle superposée aux données déjà intégrées et gérées via BDC/Datasphere, et non un monde parallèle répliqué.
3.2 Quand utiliser un graphe virtuel, et quand un graphe natif ?
Virtual Graph et un graphe stocké en natif dans Neo4j ne sont pas interchangeables : ils répondent à des besoins différents :
- Virtual Graph convient lorsque la latence du warehouse (de quelques secondes à plusieurs minutes) est acceptable : GraphRAG via les données de base/de référence, l'enrichissement par lots, l'exploration pilotée par les analystes, les workflows basés sur des agents à l'échelle de la seconde. Règle générale : des agents qui fonctionnent à la seconde près.
- Le graphe natif Neo4j (AuraDB) est adapté aux exigences de l'ordre de la milliseconde : prise de décision en temps réel, scoring en ligne, écritures ACID, graphes de mémoire et de connaissances mis à jour en continu. Règle générale : des agents qui agissent en quelques millisecondes.
Pour les agents SAP Analytics – reporting, analyse financière, raisonnement sur la chaîne d'approvisionnement –, la plupart des requêtes s'exécutent en quelques secondes. Virtual Graph constitue donc le choix naturel et conforme aux règles de gouvernance pour débuter, le graphe natif venant compléter les chemins où la latence est critique.
4. Architecture et conception d'outils
4.1 Schéma d'architecture
Comment la logique SAP est transmise aux agents :
Les principes directeurs de cette architecture :
- Le BDC comme solution propre. Les modèles sémantiques issus de Datasphere ne sont pas répliqués bruts dans le Lakehouse, mais y sont transférés de manière contrôlée via Delta Sharing.
- Metric Views en tant que contrat KPI. L'agent interroge des indicateurs prédéfinis, et non des agrégations personnalisées.
- Virtual Graph en tant que couche relationnelle. Raisonnement multi-sauts sur les flux de documents et les structures organisationnelles, sans copie des données gérées.
- Unity Catalog en tant que périmètre de gouvernance commun pour les tables, les vues de métriques et le graphe virtuel.
Ces principes définissent le cadre ; la section suivante montre comment ils se traduisent concrètement dans la conception de l'outil d'un agent.
4.2 Conception des outils : la véritable clé
S'il y a un point essentiel à retenir de cet article, c'est bien celui-ci : la question cruciale n'est pas de savoir quel LLM est utilisé ni comment la requête est formulée. La question cruciale est de savoir de quels outils dispose l'agent – et ce que ces outils recouvrent.
Le principe est simple, mais ses implications sont considérables : un agent naïf dispose d'un accès libre aux tables SQL. Techniquement, il est ainsi en mesure de répondre à n'importe quelle question – mais c'est lui qui décide comment agréger les données, quelles périodes il va couvrir et quelles hiérarchies il va ignorer. La logique réside dans le modèle, et non dans l'architecture. C'est là que réside le problème.
Un agent à gouvernance sémantique, en revanche, ne dispose pas d'un langage SQL libre. Il dispose d'un ensemble d'outils sélectionnés avec soin, dans lesquels la logique métier est déjà intégrée :
- Outils de vue métrique – requêtes paramétrées pour des indicateurs définis. Une vue métrique n’est pas une interface de requête libre, mais un indicateur de performance clé (KPI) formellement défini : quels champs sont pris en compte, quelle logique d’agrégation s’applique, quel niveau organisationnel est prévu. L’agent choisit l’indicateur qu’ il interroge – et dans quel contexte (société, période, devise). Il ne décide jamais de la manière dont l’indicateur est calculé. Cette décision est prise au niveau de la couche gouvernée et est immuable.
- Outils de graphe (via Virtual Graph) – Requêtes sur les relations et les chemins : « Suivre le flux des documents », « Trouver tous les centres de coûts en aval de ce groupe de centres de profit », « Quels fournisseurs sont rattachés à cette société ? ». Ces questions ne peuvent pas être résolues correctement avec le SQL seul – elles nécessitent un raisonnement multi-sauts via des relations. Les outils graphiques encapsulent des modèles Cypher qui sont traduits de manière déterministe en SQL. L’agent appelle l’outil ; ce qui se passe en arrière-plan reste contrôlé et reproductible.
- Outils de recherche – recherche sémantique dans la documentation d'entreprise, les définitions d'indicateurs, les descriptions de processus et les documents de politique. Ces outils garantissent que l'agent ne se contente pas de traiter des chiffres, mais qu'il tient également compte du contexte sémantique. « Quelle est la politique du groupe en matière de conversion des devises dans le rapport trimestriel ? » est une question à laquelle aucun SQL ne peut répondre – mais un outil de recherche basé sur la documentation archivée de manière gouvernée le peut très bien.
L'interaction entre ces trois types d'outils constitue le véritable modèle de conception. Un outil de visualisation des indicateurs fournit l'indicateur. Un outil graphique fournit la relation organisationnelle dans le contexte de laquelle l'indicateur doit être interprété. Un outil de recherche fournit la règle selon laquelle les exceptions doivent être traitées. L’agent orchestre – il combine, déduit, formule – mais il n’invente pas de logique qui n’existe pas dans la couche gouvernée.
C'est là toute la différence entre « savoir extraire des données SAP » et « maîtriser la logique SAP » : la logique est intégrée et régie par les outils – elle n'est pas laissée à l'improvisation du modélisateur.
5. Exploitation : évaluation, gouvernance et sécurité
5.1 Évaluation et confiance
En matière de chiffres financiers, «plutôt correct» ne vaut rien. C'est pourquoi une évaluation structurée s'impose – et c'est exactement ce qu'offre Agent Bricks
Dimension | Signification |
Exactitude | La réponse est-elle correcte d'un point de vue technique ? |
Latence | L'agent répond-il dans un délai raisonnable ? |
Exécution | Utilise-t-on les bons outils ? |
Adhésion | L'agent respecte-t-il les contraintes définies ? |
Pertinence | La réponse est-elle pertinente par rapport à la question ? |
Sécurité | Les autorisations et les consignes de sécurité sont-elles respectées ? |
En y ajoutant des juges LLM et des ensembles de tests synthétiques couvrant spécifiquement les cas limites de SAP (limites d'exercice fiscal, conversion monétaire, annulations), on obtient une boucle d'évaluation sans laquelle aucune mise en production ne peut être envisagée.
Le deuxième pilier est constitué par le traçage MLflow 3.0: chaque décision prise par l'agent – quel outil, quel paramètre, quel résultat – est traçable et vérifiable. Dans le contexte SAP, où l'audit et la conformité ne sont pas des options, il ne s'agit pas d'un simple atout, mais d'une condition sine qua non.
5.2 Gouvernance et sécurité
Le problème épineux qui reste à résoudre, pour l'appeler par son nom : la mise en correspondance des autorisations SAP avec la sécurité au niveau des lignes et des colonnes du catalogue Unity. L'utilisateur ne doit voir que ce que son schéma d'autorisations SAP lui permet de voir – et cela doit être transmis par l'agent, sans être contourné.
L'avantage de l'architecture décrite ici : comme Virtual Graph fonctionne en mode « zero-copy » sur les données gérées par Unity Catalog, le même périmètre de gouvernance s'applique aux requêtes relationnelles, aux vues métriques et au raisonnement sur les graphes. Il n'y a pas de deuxième ensemble de données nécessitant une sécurisation distincte. Cela réduit considérablement la surface d'attaque et la complexité de la gouvernance.
6. Évaluation et perspectives
6.1 Retour à la réalité
Un article de fond qui ne fixe pas de limites claires donne une impression de manque de sérieux. C'est pourquoi nous énonçons clairement les principales restrictions :
- Virtual Graph fournit une latence de type entrepôt. Les chemins en temps réel de l'ordre de la milliseconde nécessitent toujours une mémoire de graphe native.
- À la date de publication de cet article, Virtual Graph est en préversion privée. Les architectures de production doivent tenir compte du calendrier de maturation et de la feuille de route : davantage de sources, la mise en cache adaptative, ainsi que les requêtes composites via Aura et Virtual Graph ont été annoncées.
- Qualité sémantique. La qualité de l'agent dépend entièrement de celle des modèles Datasphere et des vues métriques sous-jacents. Aucune couche d'agent ne peut pallier une sémantique déficiente au niveau de l'infrastructure.
Quand on connaît les limites, on peut planifier de manière réaliste – et c'est précisément là que le modèle par étapes suivant s'avère utile.
6.2 Niveaux de maturité
L'architecture cible décrite ne doit pas nécessairement être mise en œuvre d'un seul coup – et c'est d'ailleurs rarement le cas dans la pratique. Il est plus judicieux de procéder par étapes, en commençant par une base clairement délimitée et prête à être déployée en production, puis en évoluant à partir de là. Le modèle par étapes suivant permet de déterminer où en est une entreprise aujourd'hui et quelle est la prochaine étape réaliste à franchir :
- Questions-réponses en lecture seule. L'agent répond aux questions via une vue métrique. Un indicateur, une source régie.
- Raisonnement relationnel. Ajout de Virtual Graph ; requêtes multi-sauts concernant le flux de documents et les structures organisationnelles.
- Multi-agents via des chaînes de processus. Architecture de supervision avec des spécialistes pour chaque processus.
- Intelligence décisionnelle basée sur des agents. Des agents qui ne se contentent pas de répondre, mais proposent des options d'action accompagnées d'une justification et d'une piste d'audit.
La plupart des entreprises utilisant SAP se situent aujourd’hui entre les niveaux 1 et 2. Il ne s’agit pas d’un retard, mais du bon point de départ. En mettant correctement en place le niveau 1, on pose les bases de la gouvernance sur lesquelles tous les niveaux suivants peuvent s’appuyer de manière solide. Le passage au niveau 4 n’est pas un bond en avant technique, mais le résultat d’une évolution cohérente de la sémantique et de l’architecture.
7. Conclusion
L'équipage a établi le contact. Non pas avec une forme de vie extraterrestre, mais avec sa propre entreprise. Pour la première fois, le système ne se contente pas de répondre à des signaux, il en comprend le sens. Le centre de contrôle pousse un soupir de soulagement. Il ne s'agit plus d'une simple consultation de données. C'est de l'intelligence décisionnelle.
Le fil conducteur de cet article : la logique métier existe déjà – dans la couche sémantique de SAP. Mosaic AI n'est pas l'endroit où l'on la recrée, mais celui où l'on la rend gouvernée, évaluable et accessible aux agents.
Neo4j Virtual Graph comble ici une lacune cruciale : il applique le raisonnement relationnel, qui est au cœur de la logique métier, en mode « zero-copy » aux données qui se trouvent déjà dans le Lakehouse géré.
Il s'agit d'une approche plus nuancée que celle des « agents IA pour SAP » – et de la suite logique de l'évolution de la Business Intelligence vers la Decision Intelligence.
Votre stratégie en matière de données est personnalisée – vos conseils devraient l'être également.
Le choix entre ces méthodes dépend de nombreux facteurs : votre environnement système existant, vos objectifs commerciaux et votre culture en matière de données. Il n'existe pas de réponse standard.
Discutons ensemble, sans engagement, de la solution qui vous convient le mieux.
N'hésitez pas à nous contacter pour un entretien individuel.
Sources
- Databricks, Agent Bricks (Data+AI Summit) : générateur d'agents automatisé avec données synthétiques et tests de performance.
- Neo4j, Présentation de Neo4j Virtual Graph : le raisonnement sur les graphes à partir des données dont vous disposez déjà (28 mai 2026) : https://neo4j.com/blog/graph-database/introducing-neo4j-virtual-graph-graph-reasoning-on-the-data-you-already-have/
- Composants du Mosaic AI Agent Framework : recherche vectorielle, traçabilité MLflow, gouvernance du catalogue Unity, intégration MCP
