Fiche concept

BDC Connect for Databricks

À jour au 2026-09-27

Édité par Cédric Mary, éditeur et directeur de la publication — 27 ans d'écosystème SAP. Comment ces pages sont produites, et où intervient l'automatisation.

Qu'est-ce que BDC Connect for Databricks ?

BDC Connect for Databricks est le pont à copie zéro qui permet à SAP Business Data Cloud et à un Lakehouse Databricks de lire mutuellement leurs données gouvernées sans qu'aucun des deux côtés ne copie, n'exporte, ni ne réplique la moindre ligne. Pour tout architecte qui met en balance un patrimoine analytique fortement orienté Databricks et la couche sémantique propre de SAP, cela change la question : ce n'est plus « quelle plateforme l'emporte », mais « comment les deux plateformes partagent-elles une seule vérité gouvernée ».

Ce que c'est et pourquoi cela compte

Historiquement, connecter des données SAP à un Lakehouse Databricks — ou l'inverse — supposait de construire et de maintenir un pipeline d'extraction-transformation-chargement : un job batch, une zone de transit, une seconde copie des données susceptible de dériver par rapport à la source, et qui exigeait ses propres contrôles d'accès, sa propre surveillance, sa propre reprise sur incident. BDC Connect for Databricks supprime entièrement ce pipeline en s'appuyant sur le protocole ouvert Delta Sharing — le même mécanisme que Databricks utilise déjà pour partager des tables Delta Lake au-delà des frontières organisationnelles — combiné à la propre couche de gouvernance des data products de SAP à l'intérieur de BDC. Le résultat n'est pas un connecteur au sens traditionnel ; c'est un contrat de gouvernance partagé, posé sur deux plans de stockage distincts qui n'échangent en réalité jamais de données entre eux.

Comment ça fonctionne

D'un côté, BDC expose ses data products gouvernés — les vues enrichies de couche sémantique construites sur Datasphere ou BW/4HANA — sous forme de points de terminaison Delta Share. Le Unity Catalog de Databricks, le métastore de la plateforme, enregistre ce partage à l'aide d'une URL de partage et d'un jeton porteur limité en portée, et dès lors un notebook Databricks peut interroger directement le data product SAP avec du Spark SQL standard, les lectures allant directement du stockage géré par BDC au cluster de calcul Databricks. Le sens inverse fonctionne de la même manière : une table Delta gérée par Databricks peut être enregistrée comme data product externe à l'intérieur de BDC, puis consommée depuis une story SAP Analytics Cloud ou une Analytical Application BDC via une connexion live, les données restant en permanence dans le stockage cloud géré par Databricks. La gouvernance accompagne chaque lecture dans les deux sens — un data product porte un propriétaire, un engagement de fraîcheur, une classification de sensibilité, et une liste d'abonnés, et les règles de masquage au niveau colonne définies côté SAP s'appliquent même lorsque la donnée est interrogée depuis le côté Databricks.

Quand l'utiliser, et l'arbitrage

L'alternative traditionnelle — la réplication batch vers une couche de transit, que ce soit via un outillage ETL classique ou via les Replication Flows propres de SAP — reste le bon choix lorsque le système consommateur a besoin de données transformées, remodelées, ou fortement agrégées avant usage, ou lorsque les deux plateformes ne savent pas toutes deux parler le protocole Delta Sharing. BDC Connect for Databricks l'emporte clairement lorsque le besoin est un accès en lecture à des données gouvernées et à jour, sans transformation nécessaire, et lorsque la source et le consommateur évoluent déjà tous deux dans des écosystèmes prenant nativement en charge Delta Sharing — car cela élimine la maintenance de pipeline, supprime totalement le décalage de réplication, et évite le coût de double stockage lié au maintien de deux copies. Le prix à payer est un verrouillage architectural sur le protocole Delta Sharing et sur Unity Catalog comme métastore de gouvernance côté Databricks ; une organisation qui n'est pas déjà investie dans Databricks gagne peu à choisir cette voie plutôt qu'une pile purement SAP, et une organisation avec de forts besoins de transformation aura de toute façon besoin d'un pipeline quelque part, simplement en aval de la lecture à copie zéro plutôt qu'en amont. Il vaut aussi la peine de comparer avec BDC Connect for Snowflake ou pour Microsoft Fabric, qui appliquent la même idée de contrat de gouvernance à d'autres plateformes lakehouse — le bon choix suit le lieu où se trouve déjà réellement le patrimoine de calcul de l'organisation, pas une préférence de plateforme dans l'absolu.

Pièges et anti-patterns

Certaines équipes traitent BDC Connect comme un substitut à la discipline de modélisation des données, en supposant qu'aucune donnée ne bougeant, aucun travail de gouvernance n'est nécessaire côté Databricks — en pratique, les permissions Unity Catalog doivent toujours être activement maintenues, et un data product BDC doté d'une métadonnée de lignage faible se traduira par une table tout aussi faiblement gouvernée côté Databricks. Une autre erreur fréquente consiste à sous-estimer le cycle de vie des jetons et de l'enregistrement du partage : les jetons porteurs à portée OAuth expirent et doivent être renouvelés, et un partage qui cesse silencieusement de se rafraîchir produit une péremption silencieuse qui, au premier regard, ressemble à une connexion parfaitement vivante. Un troisième piège consiste à croire que copie zéro signifie coût zéro — chaque requête contre une table Delta partagée consomme toujours du calcul côté lecteur, et une charge analytique lourde contre un data product exposé par BDC peut générer des coûts de calcul Databricks bien réels, qui n'avaient pas été budgétés lorsque l'élimination du pipeline avait été présentée comme une pure économie.

L'angle Joule, septembre 2026

BDC Connect for Databricks est un pont de données, pas un pont de modèles — c'est la première précision à apporter quand un client demande son lien avec Joule ou SAP AI Core. Le connecteur déplace des lignes gouvernées entre Datasphere/BW4HANA et des tables Delta Databricks ; il ne route aucun appel d'inférence, et le generative AI hub de SAP n'appelle pas un modèle hébergé sur Databricks à travers lui. Ce qu'il permet, c'est le schéma de fédération que la revue de cette plateforme sur le Databricks Mosaic AI Agent Framework (C173) décrit : un agent Joule reste l'orchestrateur conscient du processus auquel un utilisateur métier parle réellement, et fait appel à un agent Mosaic AI comme outil spécialiste quand le raisonnement a réellement besoin de tables Delta, d'un modèle ML enregistré, ou d'un index Vector Search qui vit nativement sur Databricks. Ce connecteur est la plomberie qui permet à cet outil spécialiste de lire des actuals SAP — par exemple des données de grand livre S/4 — sans étape d'export, les Data Access Controls de SAP continuant à gouverner quelles lignes le lecteur côté Databricks peut voir.

Le sens inverse compte tout autant pour les travaux d'IA : quand un modèle entraîné sur Databricks (un score de demand-sensing, une prédiction de churn) doit atteindre une conversation Joule ou une story SAP Analytics Cloud, le bon schéma consiste à publier la sortie du modèle comme table Delta et à l'enregistrer comme data product externe BDC dans le sens Databricks→BDC, pas à réentraîner un modèle équivalent dans SAP AI Core. Les modèles de fondation tabulaires propres à SAP (SAP-RPT-1.5, et TabPFN-3.5-Plus depuis sa GA du 2026-09-15 dans AI Core) résolvent un problème différent — la prédiction en contexte sur données structurées sans étape d'entraînement — et ne justifient pas de dupliquer un modèle Mosaic AI qui fonctionne déjà.

Un angle mort de gouvernance à signaler à un client qui bâtit sur la SAP Business AI Platform (qui depuis Sapphire, le 12/05/2026, unifie BTP, BDC et Business AI dans un environnement gouverné unique) : un data product d'origine Databricks exposé via ce connecteur n'apparaît pas automatiquement comme un nœud que le SAP Knowledge Graph peut exploiter dans son raisonnement. Quelqu'un doit le modéliser comme une véritable entité Datasphere avant qu'un agent Joule puisse fonder une réponse dessus avec la même confiance que sur une donnée SAP native — traiter cette étape de modélisation comme un livrable, pas comme une hypothèse acquise, lors du cadrage d'une architecture où un agent Joule appelle un agent Mosaic.

Pourquoi c'est important

L'exemple de requête SQL directe est une preuve concrète que l'intégration est réellement zero-copy, pas un argument marketing — les lectures vont directement du stockage géré BDC au cluster compute Databricks.
L'enregistrement par bearer token OAuth 2.0 scopé par tenant BDC est le mécanisme de sécurité réel — un détail à vérifier contre le modèle IAM du client avant tout cadrage.
La gouvernance (propriétaire, SLA de fraîcheur, classification) s'applique à chaque Data Product publié dans les deux sens — c'est un marketplace gouverné, pas un simple tuyau de données brutes.

Points clés

BDC Connect for Databricks est un pont bidirectionnel zéro copie bâti sur le protocole ouvert Delta Sharing — une table Delta devient un Data Product BDC interrogeable, et inversement.
Pas de pipeline ETL ni de copie intermédiaire : la donnée reste dans son magasin de référence, donc aucune seconde copie à sécuriser, surveiller ou réconcilier.
Cela déplace la question d'architecture de « quelle plateforme gagne » vers « comment les deux partagent une seule vérité gouvernée ».
Le contrôle d'accès est appliqué du côté qui partage — modéliser les permissions du data product avant de l'exposer, pas après.
Atteint la disponibilité générale le 2025-10-06, premier canal de production bidirectionnel zéro copie entre BDC et un Lakehouse Databricks.
L'enregistrement du share côté Databricks utilise un jeton porteur OAuth 2.0 cadré par tenant BDC — le faire tourner selon un calendrier, pas comme une configuration ponctuelle.
C'est un pont de données, pas un pont de modèles : il ne route aucun appel d'inférence du generative AI hub vers Databricks ni l'inverse — les sorties de modèles ne traversent la frontière que sous forme de tables Delta publiées ou de data products BDC.
Il exige que l'espace de travail Databricks consommateur tourne sur Unity Catalog ; un espace encore sur le Hive metastore classique ne peut pas consommer un Delta Share tant qu'il n'a pas migré.

Sources

Ouvrir dans l'application →

Les guides qui répondent avec cette page

Ces guides citent cette page parmi les sources sur lesquelles leur réponse s'appuie.

Architecte Databricks SAP freelance : la couture SAP