Fiche concept

Capacity Units BDC

À 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 Capacity Units BDC ?

Le plancher d'entrée à 128 CU couvre rarement une vraie charge Tier-1 : six types de charge se partagent un seul pool d'unités de capacité, il faut donc dimensionner un tenant BDC sur son pic, pas sur sa moyenne.

De quoi il s'agit

Les Capacity Units sont l'unité de facturation et de dimensionnement de SAP Business Data Cloud — une mesure regroupée de calcul, de mémoire, d'allocation de stockage et d'opérations d'entrée-sortie par seconde des flux de données, vendue par blocs dimensionnés au niveau du tenant plutôt que facturée ressource par ressource. Une capacity unit achète environ l'équivalent d'un vCPU de calcul HANA Cloud, environ quatre gigaoctets de mémoire HANA Cloud, une allocation de stockage modeste avant que la tarification de dépassement ne s'applique, et une tranche de débit de flux de données. Le plus petit tenant Business Data Cloud démarre à 128 capacity units, sensiblement plus que le plancher de 64 unités d'un tenant Datasphere autonome, ce qui reflète l'éventail plus large de charges — réplication, analytique en direct, planification, Joule, Knowledge Graph — qu'un tenant Business Data Cloud est censé porter simultanément. Pour un consultant qui dimensionne une mission, la maîtrise des capacity units est ce qui sépare une proposition au montant mensuel prévisible de ce que redoute tout interlocuteur financier : une facture qui s'emballe, découverte après la mise en production.

Pourquoi c'est important

Selon les estimations de dimensionnement d'Analytics Legends (2026, pas un chiffre SAP), un pattern Tier-1 se dimensionne à 130-240 CU en régime établi et 280-360 CU au pic — plus du double du plancher tenant à 128 CU, donc présenter ce plancher comme suffisant prépare une crise de capacité en cours de projet.
La mémoire (~4 Go par CU) est le principal poste de coût pour l'analytique in-memory, pas le calcul — une discussion de dimensionnement centrée sur le nombre de vCPU chiffre la mauvaise variable.
Six types de charges distincts (requêtes SAC live, flux de réplication, évaluation des Analytic Models, grounding Joule, parcours du Knowledge Graph, démarrage de clusters Databricks) se disputent un seul pool CU partagé, donc un pic sur l'un affame les autres.

Points clés

1 CU = 1 vCPU + 4 GB HANA + stockage + IOPS.
Minimum tenant BDC : 128 CU (entrée €100-180k/an FY26).
Dimensionnement Tier-1 (estimation Analytics Legends, 2026) : 130-240 en régime stable, 280-360 en pic ; provisionner au pic + marge de 20 %.
Six types de charge : replication · requêtes AM · SAC Live · Joule · Knowledge Graph · côté Databricks.
La charge de grounding Joule croît avec le nombre d'utilisateurs actifs — la dimensionner sur l'usage mesuré dans le tenant, pas sur une règle empirique publiée.
Dimensionner sur la moyenne = anti-pattern (le pic double la moyenne).
Refacturation : consommation par Space sur 30 jours glissants issue du Tenant Monitor.
Le bursting élastique de CU est en preview Q2 2026, cible GA H2 2026.

Termes employés sur cette page

Capacity Unit (CU): Primitive de facturation de BDC : ~1 vCPU + 4 Go HANA Cloud + stockage + IOPS combinés.
Tenant CU pool: Total de CU contractualisées, partagé entre toutes les charges de travail d'un même tenant BDC.
Sizing at peak: Provisionnement défensif à la charge de pointe mesurée + 20 % de marge. Par défaut ; dimensionner à la moyenne est un anti-pattern.
Joule grounding load: Calcul consommé par les agents Joule pour ancrer leurs réponses dans les données du tenant ; il se multiplie avec le nombre d'utilisateurs actifs. SAP ne publie aucun chiffre fixe de consommation à vide.
Per-Space chargeback: Schéma d'allocation utilisant la consommation glissante sur 30 j par Space du Tenant Monitor pour répartir les coûts entre LoBs.
Tenant Monitor: Tableau de bord BDC intégré affichant la consommation de CU, la charge de requêtes et la santé de la réplication par Space.
Elastic CU bursting: Preview au T2 2026 / GA visée au S2 2026 — dépassement temporaire des CU contractualisées à un taux de burst de 1,3 à 1,5×, facturé trimestriellement.
Surge billing: Facturation appliquée lorsque le tenant dépasse son quota de stockage ou d'IOPS. Le parallélisme de réplication en est la cause la plus fréquente.

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 →

Les guides qui répondent avec cette page

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

Capacity Units BDC

Qu'est-ce que Capacity Units BDC ?

De quoi il s'agit

Pourquoi c'est important

Points clés

Termes employés sur cette page

Sources

Concepts liés

Modules d'académie associés

Études approfondies

Guides SAP analytics & TJM

Les guides qui répondent avec cette page