Snowflake SAP : grille de décision pour DSI avant de signer un zero-copy

Business Data Cloud, Datasphere, Databricks, ETL classique : choisir sans se fier au benchmark du vendeur.

SAP et Snowflake ont annoncé leur partenariat zero-copy le 4 novembre 2025, lors de SAP TechEd. Depuis, les DSI ne tirent pas tous la même conclusion. La raison n'a rien de technique : la décision se joue sur le cycle de vie du contrat, la gouvernance des identités et la facture consolidée à cinq ans.

Le discours marketing présente l'offre comme la fin des ETL SAP, la suite logique de SAP Datasphere, et le bon choix pour toute organisation. Trois affirmations qui méritent chacune d'être creusées avant d'engager un comité d'architecture. Ce qui suit vise à poser les questions que les deux commerciaux attendent le moins.

Business Data Cloud : ce qui change vraiment par rapport à Datasphere

SAP a annoncé snowflake sap business data cloud en février 2025, d'abord avec Databricks ; l'ouverture à Snowflake date de novembre 2025. Le produit prolonge Datasphere en y ajoutant une couche de partage de données ouverte, construite autour de connecteurs natifs avec plusieurs plateformes analytiques (dont Snowflake, Databricks et Google BigQuery). Ce partenariat vient après ceux de Databricks et de Google Cloud, avec un composant spécifique baptisé BDC Connect.

La bascule est moins anodine qu'elle en a l'air. Datasphere restait un produit SAP de bout en bout : les données exposées dans un entrepôt SAP, interrogeables par SAP Analytics Cloud, administrées par les équipes BTP. Avec snowflake sap bdc connect, la plateforme analytique sort de l'orbite SAP. Les données S/4HANA restent dans le système opérationnel, mais leur métadonnée sémantique (modèles, hiérarchies, mesures calculées) est publiée vers un espace Snowflake accessible au reste du système d'information data.

Pour un DSI qui dispose déjà d'une plateforme Snowflake mature et qui cherche à connecter S/4HANA proprement, le sap snowflake connector livré par BDC est une amélioration nette par rapport aux options historiques (SLT, extraction via BW bridge, réplication par agent tiers). Pour un DSI qui construit une plateforme data analytique à partir de zéro, sans Snowflake ni Datasphere en production, le choix est plus ouvert : la question n'est plus "faut-il remplacer Datasphere ?" mais "quelle plateforme data cloud choisir pour les dix ans qui viennent, en sachant que SAP ouvre désormais ses données à plusieurs".

Zero-copy : comment ça marche sous le capot

Le principe du snowflake sap zero copy tient en une phrase : les données SAP ne sont pas copiées physiquement dans Snowflake, elles sont lues sur place depuis un stockage Iceberg partagé, administré par SAP mais interrogeable par Snowflake via un catalogue externe. Côté Snowflake, la documentation décrit une base liée à un catalogue (catalog-linked database), montée par un connecteur zero-copy de type SAP_BDC, qui expose les produits de données SAP en lecture seule. Le format de stockage sous-jacent n'est pas détaillé publiquement.

La séparation annoncée entre système source et plateforme analytique est réelle. Elle n'est pas absolue.

Plusieurs traversées techniques persistent et peuvent court-circuiter l'isolation que promet le schéma d'architecture.

Cinq traversées reviennent. La première touche les identités : les utilisateurs Snowflake qui lisent les données SAP doivent être mappés à des rôles SAP pour le filtrage par ligne, et une mauvaise synchronisation du référentiel ouvre une porte sur les données RH ou financières. La deuxième tient aux métadonnées : une évolution du modèle S/4HANA (ajout de colonne, changement de type) se propage au catalogue Iceberg et casse les requêtes Snowflake qui ne tolèrent pas le nouveau schéma, d'où l'intérêt de lire noir sur blanc la clause de versionnement du catalogue.

La troisième est moins visible : BDC Connect expose les tables, pas la logique ABAP qui calcule certains indicateurs côté SAP. Une requête Snowflake qui recalcule un chiffre d'affaires sans cette logique donnera un résultat différent de la transaction SAP, et l'écart ne se voit qu'à la clôture. Même prudence pour les montées de version S/4HANA 2023 vers 2024 ou 2025 : leur fenêtre doit être coordonnée avec les lectures Snowflake en cours, car le catalogue partagé n'est pas transactionnel au sens SAP. Reste le sujet des licences ODP : SAP encadre l'usage de ses interfaces par des outils tiers, et le juridique doit relire les conditions applicables à tout flux parallèle avant son déploiement.

La snowflake sap integration s'évalue sur la qualité de ces joints, pas sur la couleur du schéma d'architecture.

Comparatif des quatre voies de sortie SAP

Les options qu'une direction informatique compare aujourd'hui relèvent de logiques très différentes, et la comparaison brute sur le prix n'a aucun sens : les périmètres diffèrent. Deux questions séparent vraiment les quatre voies : les données sont-elles copiées, et à qui appartient la gouvernance ensuite ?

Le zero-copy via snowflake sap bdc ne copie pas physiquement les données et garde le catalogue SAP comme référence ; en contrepartie, la portabilité reste moyenne puisqu'elle dépend de ce catalogue, et l'offre est récente. SAP Datasphere natif offre la gouvernance la plus continue, de bout en bout dans le périmètre SAP, avec une réplication interne par moments et une portabilité faible. SAP Databricks via BDC ne copie pas non plus, mais passe par Unity Catalog, ce qui donne une bonne portabilité au prix d'une gouvernance SAP moins serrée ; la copie réapparaît dès qu'on passe par SLT. L'ETL classique vers Synapse ou BigQuery est la plus mûre et la plus portable, mais elle copie massivement et laisse à l'équipe la charge de reconstruire la gouvernance.

Le snowflake connector sap livré via BDC se distingue surtout par la préservation de la sémantique métier SAP dans Snowflake : les objets analytiques S/4HANA conservent leurs mesures, hiérarchies et règles d'autorisation. Un ETL classique vers BigQuery force à recoder cette sémantique dans le data warehouse cloud cible, ce qui multiplie les écarts entre reportings SAP et tableaux de bord analytiques. Contrairement à ce que laisse entendre le consensus, cette préservation n'est pas toujours un cadeau : elle lie durablement la gouvernance analytique à la roadmap SAP.

Lire la facture à cinq ans

La facturation d'une pile BDC + Snowflake complète combine quatre lignes : licence BDC côté SAP, licence BTP pour l'orchestration, consommation calcul Snowflake, consommation stockage Iceberg. Les trois premières apparaissent dans le devis commercial. La quatrième se révèle en production, souvent plusieurs mois après la mise en service.

Le piège classique, c'est la lecture du coût d'entrée seul. Un contrat signé aujourd'hui engage une architecture et un fournisseur pour plusieurs années, et toute économie à l'entrée peut créer une dépendance qu'aucune équipe future ne pourra dénouer sans redémarrer de zéro. Le même mécanisme s'observe dans toute négociation qui mêle rente perpétuelle et investissement initial favorable : le prix réel est celui de la sortie, pas celui de l'entrée.

Côté Snowflake, la facture de calcul dépend des patterns d'usage réels : requêtes concurrentes, taille des warehouses, cache utilisé. Les lectures zero-copy sur Iceberg ne sont pas gratuites ; chaque requête mobilise du compute Snowflake même si la donnée reste physiquement chez SAP. Un business case construit sur l'hypothèse zero-copy = coût nul sera démenti dès le troisième mois. Les patterns à surveiller de près : requêtes ad hoc des analystes métier, rafraîchissement de tableaux de bord haute fréquence, croisements avec d'autres sources dans Snowflake.

Dernier point souvent négligé. Sur la gouvernance, snowflake sap hana et les objets S/4HANA exposés via BDC restent soumis aux règles d'autorisation SAP. Cela peut jouer dans les deux sens : on ne duplique pas la matrice de sécurité, mais toute évolution d'autorisation doit être poussée depuis SAP, ce qui crée une dépendance opérationnelle à l'équipe BTP. Une DSI dont la file de tickets BTP se compte en semaines verra vite le problème.

Lire l'architecture à l'échelle de l'organisation

Une architecture de type BDC Connect ne se lit pas en absolu. Le même schéma marche très bien chez l'un et devient un gouffre chez le voisin, pour des raisons qui tiennent autant à la taille qu'à la maturité des équipes data internes.

Le grand compte avec SAP central et plateforme Snowflake mature est le cas le plus naturel : BDC Connect remplace les pipelines SLT historiques et simplifie la gouvernance. Le retour sur investissement se joue sur la réduction des latences d'intégration et la fin des doubles référentiels. Le snowflake sap analytics cloud coexiste avec les consommateurs Snowflake déjà en place, sans conflit de périmètre.

Pour une ETI qui utilise SAP sans data warehouse cloud, rien n'est joué. BDC Connect est une porte d'entrée sur Snowflake, mais Databricks propose une offre équivalente via le même BDC. L'arbitrage se fait sur la compétence interne et la direction prise par le reste du système d'information. Démarrer Snowflake uniquement pour SAP crée une dépendance forte sur un seul cas d'usage ; démarrer sur plusieurs sources simultanément dilue le risque. Le risque se mesure en comparant, sur le seul besoin SAP, la facture annuelle Snowflake à celle d'un Datasphere classique : si l'écart ne se referme pas dans le business case, le projet n'a pas sa place.

À l'autre bout, la PME SAP sur BW/4HANA avec peu de besoins analytiques transverses n'a sans doute pas besoin de snowflake sap business data cloud. Datasphere natif couvre les besoins d'une majorité des reportings métiers, pour un coût total inférieur à une pile Snowflake dédiée. Le vrai sujet pour cette taille d'organisation reste la bascule BW/4HANA, pas l'ouverture vers un data lake entreprise externe.

Le zero-copy apporte sa valeur la plus immédiate à l'organisation multi-ERP où SAP est minoritaire. BDC Connect permet alors d'intégrer SAP comme une source parmi d'autres dans un lakehouse existant, sans imposer la logique Datasphere au reste du système. C'est aussi le scénario où la négociation commerciale est la plus difficile pour SAP, ce qui laisse souvent une marge de manœuvre réelle sur les tarifs.

Preuves à exiger avant la signature

Un benchmark fourni par le vendeur a la valeur de la parole du vendeur. Les cycles de référencement produit, les conditions de test et les volumes de données utilisés sont choisis par celui qui cherche à vendre. La seule preuve technique qui compte pour un comité d'investissement est celle qu'un tiers neutre peut reproduire, ou qu'un pair du même secteur peut valider sur sa propre production.

On voit ce réflexe dans d'autres industries techniques depuis longtemps : avant d'acheter un équipement critique, on demande un essai croisé, mené par une équipe qui n'a pas d'intérêt dans la vente, sur des conditions proches de l'usage réel. Rien ne devrait empêcher d'appliquer la même règle à un contrat multi-millions d'architecture data.

Face à un commercial qui présente l'architecture zero-copy comme la seule option raisonnable, quelques questions calibrées font émerger les contraintes qu'il ne nomme pas spontanément. Comment êtes-vous censés livrer ce rythme de montée de version sans casser mes requêtes Snowflake en production ? Qu'est-ce qui, dans votre roadmap BDC des douze prochains mois, pourrait obliger vos clients à réécrire leurs intégrations ? Quel est votre objectif commercial trimestriel sur cette offre ? Ces questions ne négocient pas sur le prix affiché ; elles exposent les contraintes réelles de l'autre côté de la table.

Ce qui tranche, c'est le contrat, pas la stack

Le partenariat livre une avancée réelle sur l'intégration des données SAP vers les plateformes analytiques modernes. Le zero-copy résout proprement plusieurs problèmes qui traînaient depuis dix ans dans les projets BW et SLT. La décision d'adoption, pourtant, se joue rarement sur la technique : elle se joue sur la lecture du contrat à cinq ans, sur la cartographie des traversées de sécurité, et sur la capacité de l'organisation à ne pas enfermer son système d'information data dans un seul partenariat d'éditeur.

Avant toute signature, auditez les coûts cachés d'une pile BDC + Snowflake sur un cas d'usage réel. Demandez la liste nominative des clients en production. Exigez un chiffrage de sortie écrit. Validez que la roadmap SAP des dix-huit prochains mois n'impose pas une réécriture des intégrations. Et seulement après, débattez de zero-copy contre réplication, de Snowflake contre Databricks, de BDC contre Datasphere. Dans l'ordre inverse de ce que propose le pitch commercial.

FAQ : questions fréquentes

Six réponses tirées des questions que posent les directions informatiques en phase de choix.