Prix SAP Business Data Cloud : le mécanisme, à défaut du tarif
À jour au 2026-08-14
SAP ne publie pas de tarif pour Business Data Cloud, et toute page qui en annonce un annonce une estimation de marché déguisée en grille tarifaire. Ce que SAP publie, c'est le mécanisme — et c'est là que se joue la facture. La plateforme se dimensionne et se facture en unités de capacité, une mesure groupée de calcul, de mémoire, de quota de stockage et de débit. Le plus petit tenant démarre à 128 unités, contre 64 pour un tenant Datasphere autonome. La question à laquelle on peut répondre honnêtement n'est donc pas « combien ça coûte », mais « qu'est-ce qui fait monter le chiffre ».
Ce qui est public, ce qui ne l'est pas
Est public : l'unité de compte et sa composition, le plancher du tenant, les types de charge qui puisent dans le même pool, et la surface de suivi qui rapporte la consommation après la mise en production. C'est suffisant pour construire un dimensionnement défendable devant une direction financière.
N'est pas public : le prix d'une unité de capacité, le prix d'entrée d'un tenant, la courbe de remise, le tarif de dépassement au-delà du quota de stockage, et la refacturation de la capacité Databricks intégrée. Rien de tout cela ne se déduit du mécanisme, et tout montant qui circule sur Business Data Cloud est l'estimation de quelqu'un, tirée d'un petit nombre d'affaires et citée sans le profil de charge qui l'a produite.
Cela change la rédaction d'une proposition. Annoncer un chiffre unique sans le détail des charges prépare la pire conversation, un an plus tard : un client qui n'a jamais vu la construction suppose qu'on lui a survendu.
Ce qu'achète une unité de capacité
Une unité regroupe environ l'équivalent d'un vCPU de calcul HANA Cloud et à peu près quatre gigaoctets de mémoire HANA Cloud, plus un quota de stockage avant facturation du dépassement et une part de débit de flux.
Comme l'unité est groupée, elle ne s'échange pas de la même façon selon la charge : un modèle de planification gourmand en mémoire ne consomme pas comme un flux de réplication lourd aux besoins mémoire modestes. Conséquence pratique : sur de l'analytique en mémoire, c'est la mémoire qui contraint, pas le nombre de cœurs. Un dimensionnement calé sur les vCPU chiffre la mauvaise variable.
Le plancher de 128 unités dépasse celui d'un tenant Datasphere autonome pour une raison précise : un tenant Business Data Cloud porte simultanément réplication, analytique en direct, planification, agent conversationnel et graphe de connaissances — un mélange plus large que ce qu'exécute une couche sémantique seule.
Les six charges qui se disputent le même pool
Les requêtes SAP Analytics Cloud en direct montent le plus fort aux heures ouvrées. Les flux de réplication tirent une charge continue et prévisible. L'évaluation des modèles analytiques consomme au moment de la requête et croît avec les utilisateurs simultanés. Les requêtes d'ancrage de l'agent sont peu coûteuses à l'unité mais se multiplient avec les utilisateurs actifs. Le parcours du graphe de connaissances est modéré et peu fréquent. Le démarrage des grappes Databricks se facture chez Databricks tout en pesant sur le pool.
La ligne que la plupart des dimensionnements oublient se cache dans la quatrième : des agents inactifs qui interrogent leur disponibilité consomment, selon le corpus, cinq à dix pour cent de la capacité du tenant, sans aucune conversation en cours.
Dernier piège, qui ressemble à un manque de capacité sans en être un : le parallélisme de réplication est réglé par défaut à huit fils par flux, et multiplié par des dizaines de flux simultanés il sature le quota d'entrées-sorties alors que le calcul a encore de la marge.
Dimensionner à la moyenne ou au pic
Traitement nocturne uniquement, personne devant un écran pendant la pointe. Le dimensionnement à la moyenne se défend : la file d'attente ne coûte à personne.
Utilisateurs en séance aux heures ouvrées — clôture mensuelle, cycle de planification, tableau de bord de direction. Dimensionnez au pic, avec une marge. Quand la pointe dépasse la capacité, le tenant met en file plutôt que de rejeter, ce qui est pire qu'une erreur nette : cela ressemble à une plateforme lente.
Un ordre de grandeur pour situer le plancher : un profil de rang 1 se situe autour de 130 à 240 unités en régime permanent et de 280 à 360 en pointe. Le tenant d'entrée en vaut 128, soit environ un tiers à une moitié de ce qu'exige une vraie pointe de rang 1. Annoncer le plancher comme suffisant n'est pas un petit optimisme, c'est une crise de capacité avec une date.
Les coûts absents de la ligne de capacité
La fédération d'abord. Interroger en direct un entrepôt Snowflake, un lac Iceberg ou un espace de travail Databricks externe consomme du calcul chez la plateforme source, facturé par elle. Une architecture très fédérée peut paraître économique dans le modèle SAP et coûter cher sur l'autre facture, sans que la conversation sur les unités de capacité ne le montre.
La même asymétrie joue dans l'autre sens : chaque requête d'un consommateur Databricks sur un produit de données partagé consomme du calcul côté lecteur. Supprimer un pipeline économise de l'effort d'ingénierie, pas du fonctionnement.
Enfin la main-d'œuvre : provisionner les données sources en produits de données gouvernés est le chemin critique de la plupart des implémentations, surtout sur un existant chargé d'années de champs spécifiques. C'est un coût de projet, et il appartient au même dossier d'investissement.
Ce qu'il faut exiger par écrit
Le bloc de capacité proposé et le détail des charges qui le produit : lequel des six consommateurs a été retenu, à quel volume. Un devis sans sa construction ne se réargumente pas quand la charge évolue.
La surface de suivi et de refacturation : la consommation se rapporte par espace sur une fenêtre glissante de trente jours, ce qui permet d'attribuer le coût à l'entité qui l'a généré.
Ce qui se passe au plafond — mise en file, bridage ou débordement élastique, et à quelles conditions commerciales. Le débordement élastique a été annoncé comme une orientation plutôt que comme un mécanisme arrêté : traitez sa disponibilité comme une question, pas comme une hypothèse de chiffrage.
Et la part éventuellement refacturée depuis une plateforme partenaire, qui ne se comporte pas comme la capacité SAP et peut relever d'un contrat distinct.
Ce que nous ne pouvons pas affirmer
Nous n'affichons aucun prix pour Business Data Cloud, parce que SAP n'en publie aucun : ni tarif à l'unité de capacité, ni prix d'entrée, ni courbe de remise, ni tarif de dépassement, ni refacturation de la part Databricks. Les montants qui circulent sont des estimations tirées d'affaires isolées, et les reprendre ici leur donnerait l'autorité d'un tarif qu'ils n'ont pas.
Questions fréquentes
Existe-t-il une grille tarifaire publique pour SAP Business Data Cloud ?
Non. SAP publie le modèle d'unités de capacité et le plancher du tenant, pas un tarif. Tout montant précis que vous trouverez est une estimation de marché issue d'un petit nombre d'affaires, presque toujours citée sans le profil de charge qui l'a produite — donc inutilisable pour dimensionner votre propre tenant.
Quel est le plus petit tenant possible ?
128 unités de capacité, soit le double du plancher de 64 unités d'un tenant Datasphere autonome. Ce plancher plus large reflète le mélange de charges qu'un tenant Business Data Cloud porte en même temps : réplication, analytique en direct, planification, ancrage de l'agent et parcours du graphe de connaissances sur un pool unique.
La capacité inclut-elle le lakehouse Databricks ?
Dans le modèle intégré, le lakehouse est préprovisionné et facturé par SAP : le client ne porte pas de contrat Databricks distinct pour cette capacité. En revanche SAP ne publie pas le tarif de refacturation, donc on ne peut pas déduire du modèle ce que cette part coûte face à un contrat direct.
Pourquoi mon devis dépasse-t-il largement le plancher de 128 unités ?
Parce que le plancher n'est pas un dimensionnement de rang 1. Les profils du corpus situent une charge de rang 1 autour de 130 à 240 unités en régime permanent et de 280 à 360 en pointe, et l'interrogation à vide de l'agent consomme à elle seule cinq à dix pour cent du pool.
Sur quoi cette page s'appuie
- BDC Capacity Units (C012)
- SAP Business Data Cloud (BDC) (C009)
- BDC Connect (C015)