Fiche concept

BDC Connect for Databricks

À jour au 2026-07-24T14:00:00Z

Édité par Cédric-Olivier Mâry, é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 (GA le 2025-10-06) est un pont bidirectionnel véritablement zero-copy via Delta Sharing — une table Delta Databricks devient un Data Product BDC interrogeable et inversement, sans pipeline ETL ni donnée quittant sa source autoritaire.

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 cela fonctionne

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 n'est maîtrisé que lorsqu'il change une décision d'achat nommée.
Commencer par le contrat sémantique et le modèle de contrôle avant de démontrer l'outil.
Utiliser les signaux SAP, analystes, études, KG et actualités actuels comme preuves, pas comme décoration.
Séparer les faits vérifiés des tendances directionnelles et des hypothèses modélisées.
Définir le propriétaire, la métrique, le seuil, le circuit de support et le plan de retour arrière avant de passer à l'échelle.
Pour les cas d'usage non-IA, définir quand même la qualité, l'adoption et la propriété opérationnelle.
Laisser un actif opérationnel réutilisable : mémo, checklist, tableau de contrôle et journal d'exceptions.
Une réponse premium est courte, explicite sur les arbitrages, et défendable en comité de pilotage.

Termes employés sur cette page

Decision owner: La personne responsable qui accepte l'arbitrage et finance l'action suivante.
Semantic contract: La définition partagée des termes métier, indicateurs, entités et règles d'accès utilisée par les outils et les équipes.
Control plane: La couche qui applique les politiques, les accès, la traçabilité, la supervision et l'escalade sur l'ensemble du modèle opérationnel.
Evidence grade: Un label qui distingue le fait vérifié, le signal directionnel, l'hypothèse modélisée et l'observation de terrain.
Adoption metric: Le comportement mesurable prouvant que le concept a modifié le travail réel après la mise en production.
Reusable IP: Un artefact, une checklist ou un modèle réutilisable d'un client à l'autre sans copier de données propres au client.
Decision owner: La personne responsable qui accepte l'arbitrage et finance l'action suivante.
Semantic contract: La définition partagée des termes métier, indicateurs, entités et règles d'accès utilisée par les outils et les équipes.

Sources

Fiche complète réservée aux abonnés. Ce que la fiche complète ajoute : le cadre de décision complet · la comparaison SAP · Snowflake · Databricks · Fabric · les pièges courants et leur correctif · l'aide-mémoire · les schémas d'architecture · les blocs de code · les chiffres à citer.

Ouvrir dans l'application →