Fiche concept

Capacity Units BDC

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

Les agents Joule inactifs consomment 5 à 10 % du budget CU total d'un tenant rien qu'en vérifiant leur disponibilité — la ligne la moins évidente d'un plan de capacité BDC, et le plancher d'entrée à 128 CU couvre rarement une vraie charge Tier-1.

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

Pourquoi c'est important

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 : 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.
Surcoût de polling Joule à l'inactivité : 5-10 % du pool quel que soit l'usage.
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.
BDC Capacity Units n'est maîtrisé que lorsqu'il change une décision d'acheteur nommée.
Commencer par le contrat sémantique et le modèle de contrôle avant de démontrer l'outil.

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 polling overhead: Agents Joule à l'état inactif consommant 5 à 10 % du pool de CU total, indépendamment du trafic conversationnel.
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 ?

Pourquoi cela compte

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