Fait partie de notre série Performance & Scalability
Lire le guide completChoisir le mauvais niveau de capacité Power BI est l’une des erreurs d’analyse les plus coûteuses qu’une organisation puisse commettre. Le sous-dimensionnement crée une limitation, des requêtes lentes et des échecs d'actualisation pendant les périodes de pointe. Le surdimensionnement permet de payer pour un calcul qui reste inactif la majeure partie de la journée. Pour obtenir une capacité adéquate, il faut comprendre comment Power BI utilise les ressources de calcul, ce que demande réellement votre charge de travail et comment les options SKU correspondent à ces demandes.
Ce guide couvre la planification des capacités de Power BI Premium et Microsoft Fabric, de la compréhension du modèle de calcul à la surveillance de l'utilisation actuelle, en passant par le dimensionnement de nouveaux déploiements et la gestion des coûts avec la mise à l'échelle automatique.
Points clés à retenir
- La capacité Power BI Premium est mesurée en cœurs virtuels (v-cores) qui régissent la mémoire et le débit de calcul
- Microsoft Fabric utilise les unités de capacité (CU) comme unité de facturation fondamentale, remplaçant les niveaux SKU
- Les charges de travail en arrière-plan (actualisation de l'ensemble de données) et les charges de travail interactives (exécution de requêtes) se disputent les ressources de capacité
- L'application Capacity Metrics est l'outil de surveillance essentiel pour comprendre l'utilisation des ressources
- Le lissage du processeur sur 24 heures signifie que les rafales sont moyennées — les courtes périodes de pointe ne déclenchent pas immédiatement la limitation
- Autoscale (Premium Gen2) ajoute automatiquement le calcul pendant les périodes de pointe et le supprime lorsque la demande diminue
- La consommation de mémoire des ensembles de données est la cause la plus courante de sous-performance de capacité
- Une bonne planification des capacités nécessite une mesure de base avant le dimensionnement
Modèle de capacité Power BI Premium
Power BI Premium fournit des ressources de calcul dédiées, isolées de l'infrastructure partagée utilisée par les espaces de travail Pro. Cette isolation offre des performances cohérentes, indépendamment de ce que font les autres locataires Power BI.
Le modèle de ressources : La capacité premium est mesurée en cœurs virtuels (v-cores). Chaque v-core fournit une quantité spécifique de mémoire et de calcul CPU. La relation entre les v-cores et les capacités détermine les charges de travail que la capacité peut gérer simultanément.
| UGS | Noyaux V | RAM | Débit de connexion DirectQuery/Live |
|---|---|---|---|
| P1 | 8 v-cœurs | 25 Go | 30 requêtes/seconde |
| P2 | 16 cœurs V | 50 Go | 60 requêtes/seconde |
| P3 | 32 cœurs V | 100 Go | 120 requêtes/seconde |
| P4 | 64 cœurs V | 200 Go | 240 requêtes/seconde |
| P5 | 128 cœurs V | 400 Go | 480 requêtes/seconde |
Microsoft Fabric remplace le modèle P-SKU par des unités de capacité Fabric (CU). Le tissu F64 est à peu près équivalent à P1, F128 à P2, etc. Le modèle Fabric permet un dimensionnement plus granulaire et une facturation au fur et à mesure (pause/reprise), ce qui est souvent plus rentable que l'abonnement mensuel des P-SKU.
| UGS de tissu | UC | P-SKU équivalent | Estimation mensuelle |
|---|---|---|---|
| F2 | 2 UC | — (petit développement/test) | ~262$ |
| F4 | 4 UC | — | ~524$ |
| F8 | 8 UC | — | ~1 047 $ |
| F16 | 16 UC | — | ~2 095 $ |
| F32 | 32 UC | — | ~4 189 $ |
| F64 | 64 UC | P1 | ~8 378 $ |
| F128 | 128 UC | P2 | ~16 756 $ |
| F256 | 256 UC | P3 | ~33 512 $ |
(Les prix sont approximatifs en USD ; les prix réels varient selon la région et les accords négociés.)
Catégories de charge de travail
La capacité de Power BI gère deux catégories de charges de travail, et elles sont en concurrence pour les mêmes ressources de calcul :
Charges de travail en arrière-plan exécutées sans interaction de l'utilisateur :
- Actualisation de l'ensemble de données (actualisations du mode d'importation)
- Actualisation du flux de données
- Charges de travail IA (formation de modèles, inférence)
- Rendu de rapport paginé déclenché par les abonnements
- Opérations d'exportation
Les charges de travail interactives répondent aux interactions des utilisateurs :
- Exécution de requêtes (l'utilisateur ouvre une page de rapport)
- Requêtes de connexion DirectQuery/Live
- Actualisation des vignettes du tableau de bord
- Exportation de rapport déclenchée par un utilisateur
- Questions et réponses en langage naturel
Lorsque les deux types de charge de travail sont en concurrence pour les mêmes v-cores, la capacité doit disposer de ressources suffisantes pour gérer les pics de chevauchement. Une capacité capable d'exécuter 20 actualisations simultanées d'ensembles de données pendant la nuit ouvrable tout en traitant 200 requêtes utilisateur simultanées pendant la journée ouvrable devra peut-être être dimensionnée pour les deux pics.
L'application de métriques de capacité
L'application Microsoft Fabric Capacité Metrics (anciennement application Power BI Premium Capacité Metrics) est l'outil essentiel pour la surveillance et la planification de la capacité. Installez-le depuis AppSource et connectez-le à votre capacité.
Ce que cela montre :
Utilisation du processeur et de la mémoire par type de charge de travail. Le graphique d'utilisation montre la consommation du processeur au fil du temps, avec des séries distinctes pour les charges de travail interactives et en arrière-plan. La ligne lissée montre la moyenne lissée sur 24 heures (ce que Power BI utilise pour les décisions de limitation).
Événements de limitation : lorsque le processeur lissé sur 24 heures dépasse 100 % des ressources de capacité, Power BI commence à limiter les charges de travail en arrière-plan (retardant les actualisations). Lorsqu’il dépasse considérablement le seuil de lissage, les charges de travail interactives sont également limitées. L'application de métriques affiche les événements de limitation avec leur durée et leur gravité.
Mémoire des ensembles de données : la cascade de mémoire indique quels ensembles de données sont chargés en mémoire, la quantité de mémoire qu'ils consomment et quand ils sont expulsés. Un ensemble de données qui est constamment expulsé et rechargé (nombre élevé d'« expulsions ») est trop volumineux pour la mémoire disponible, ce qui entraîne des retards lorsque les utilisateurs attendent que l'ensemble de données se recharge à chaque requête.
Principaux ensembles de données et rapports par consommation de ressources : l'application de métriques identifie les ensembles de données et les rapports qui consomment le plus de ressources : ce sont les candidats à l'optimisation avant la mise à l'échelle.
Mesures clés à surveiller :
| Métrique | Sain | Avertissement | Critique |
|---|---|---|---|
| Utilisation du processeur (lissée sur 24 h) | < 70 % | 70 à 90 % | > 90% |
| Utilisation de la mémoire | < 80 % | 80 à 90 % | > 90% |
| Expulsions d’ensembles de données (quotidiennement) | < 10 | 10-50 | > 50 ensembles de données fréquents |
| Attente de requête interactive | < 1 s en moyenne | 1 à 3 s en moyenne | > 3s moyenne |
| Taux de réussite de l'actualisation | > 98% | 95 à 98 % | <95% |
Dimensionner un nouveau déploiement
Lors du dimensionnement d’un déploiement Power BI Premium pour la première fois (sans données de métriques existantes), le processus d’estimation utilise ces entrées :
Étape 1 : Compter les utilisateurs et les modèles d'utilisation
- Combien d'utilisateurs au total accéderont aux rapports Power BI ?
- Quel est le nombre maximal d'utilisateurs simultanés ? (généralement 10 à 20 % du total des utilisateurs)
- Quelles sont les heures de pointe d'utilisation ? (Généralement de 9h à 11h et de 14h à 16h, heures de bureau)
Étape 2 : Estimer les besoins en mémoire de l'ensemble de données
- Additionnez la taille non compressée de tous les ensembles de données qui seront actifs simultanément
- Appliquez un taux de compression VertiPaq moyen de 5:1 pour estimer la taille en mémoire
- Ajoutez 20 % de frais généraux pour les opérations de requête
- Exigence totale de mémoire pour l'ensemble de données = la contrainte de dimensionnement dominante pour la plupart des implémentations
Étape 3 : Estimer la charge de travail d'actualisation
- Combien d'ensembles de données doivent être actualisés simultanément en période de pointe ?
- Quelle est la durée de rafraîchissement prévue pour chacun ?
- Consommation maximale des ressources d'actualisation = (nombre d'actualisations simultanées × mémoire moyenne par actualisation de l'ensemble de données)
Étape 4 : Ajouter le débit de DirectQuery/Live Connection
- Combien d'utilisateurs utiliseront les rapports avec DirectQuery ?
- Quel est le pic de requêtes attendu par seconde ?
- Comparez avec les limites de débit des SKU (P1 gère 30 requêtes DQ/seconde)
Exemple de calcul de taille :
Organisation avec 500 utilisateurs Power BI :
- 50 utilisateurs simultanés en pointe (10 % du total)
- 15 ensembles de données actifs, en moyenne 4 Go non compressés → ~ 0,8 Go chacun en mémoire = 12 Go de mémoire totale pour l'ensemble de données
- 10 ensembles de données sont actualisés simultanément pendant la nuit, chacun consommant 2 Go pendant l'actualisation = 20 Go de mémoire d'actualisation
- 20 pages de rapport DirectQuery au maximum = ~ 5 requêtes/seconde
Analyse : 32 Go de mémoire maximale (ensembles de données de 12 Go + actualisations de 20 Go) + surcharge = nécessite P1 (25 Go) peut être serré → envisagez P2 (50 Go). Le débit de DirectQuery se situe dans la limite de 30 qps de P1, la mémoire détermine donc la décision de dimensionnement.
En commençant par P1 et en surveillant avec l'application Metrics pendant 30 jours, vous découvrirez si P2 est nécessaire.
Configuration de la mise à l'échelle automatique
Power BI Premium Gen2 (et Fabric) prend en charge la mise à l'échelle automatique : en ajoutant automatiquement des ressources de calcul lorsque la demande dépasse la capacité provisionnée, puis en les supprimant lorsque la demande diminue.
Autoscale pour Premium (P-SKU) : Configurez dans le portail d’administration Power BI → Paramètres de capacité → Capacité Premium → Mise à l’échelle automatique. Définissez le nombre maximum de v-cores supplémentaires pouvant être ajoutés (1 à 71 pour P1). Lorsque l'utilisation de la capacité approche des limites, la mise à l'échelle automatique ajoute des v-cores par incréments.
Facturation à mise à l'échelle automatique : les v-cores supplémentaires sont facturés à l'heure au tarif par v-core. Un P1 qui ajoute 8 v-cores pendant 2 heures pendant une période de pointe paie 16 v-core-heures.
Autoscale pour le tissu : Les capacités de la structure peuvent être suspendues et reprises (ce qui est rentable pour le développement/test) et disposent d'un calcul extensible qui évolue dans les limites des CU achetées. Fabric prend également en charge les réservations (dépenses engagées pour des remises importantes) ainsi que la tarification à l'utilisation.
Quand utiliser la mise à l'échelle automatique :
- Vous avez des pics quotidiens prévisibles (par exemple, les rapports financiers de fin de mois génèrent 3 fois la charge normale)
- Vous ne souhaitez pas provisionner en permanence une capacité de pointe qui n'est nécessaire qu'occasionnellement
- Vous voulez une prévisibilité des coûts avec une soupape de sécurité pour les augmentations inattendues de la demande
Quand NE PAS utiliser la mise à l'échelle automatique :
- Utilisation élevée et soutenue (vous êtes constamment à pleine capacité) - mettez plutôt à niveau le niveau de base
- Charges de rendu de rapport uniques très importantes : la mise à l'échelle automatique peut ne pas réagir assez rapidement
- Des contraintes budgétaires strictes où toute facturation variable est inacceptable
Optimisation de la capacité avant la mise à l'échelle
Avant de passer à une plus grande capacité, optimisez les charges de travail existantes. La plupart des problèmes de performances peuvent être résolus sans dépenser plus d’argent.
Optimisation de l'ensemble de données :
- Exécutez VertiPaq Analyzer de DAX Studio pour identifier les grandes tables et colonnes qui peuvent être supprimées ou résumées
- Vérifiez les colonnes inutilisées et les mesures consommant de la mémoire sans être référencées dans aucun rapport
- Optimiser les types de données (utilisez Integer au lieu de Text pour les clés de date, Boolean au lieu de chaîne pour les indicateurs)
- Appliquer une actualisation incrémentielle pour réduire la durée de l'actualisation et la consommation de mémoire pendant les cycles d'actualisation
Optimisation du rapport :
- Réduisez le nombre de visuels par page de rapport : chaque visuel génère au moins une requête DAX au chargement
- Remplacez les visuels de faible valeur par des cartes ou des KPI qui génèrent des requêtes plus simples
- Évitez les relations bidirectionnelles et les DAX complexes qui génèrent plusieurs requêtes de moteur de stockage
- Utilisez les paramètres de champ au lieu de nombreuses colonnes calculées similaires
Optimisation du calendrier d'actualisation :
- Décaler les temps d'actualisation pour éviter l'actualisation simultanée de plusieurs ensembles de données volumineux
- Planifiez des ensembles de données de moindre priorité pendant les heures creuses
- Utilisez l'actualisation incrémentielle pour raccourcir la fenêtre d'actualisation pour les grands ensembles de données
- Suspendre ou désactiver les actualisations pour les ensembles de données rarement utilisés
Architecture multi-capacités
Les grandes organisations utilisent parfois plusieurs capacités pour isoler les charges de travail, séparer les centres de coûts ou assurer une redondance géographique.
Modèles multi-capacités courants :
- Isolement des niveaux : Production sur P2, Développement/Test sur F8. Empêche les actualisations des développeurs de consommer la capacité de production.
- Isolement de la charge de travail : Finance sur un P1, RH sur un autre P1. Empêche les charges de travail des départements de s’influencer mutuellement.
- Répartition géographique : utilisateurs américains sur la capacité de l'Est des États-Unis, utilisateurs de l'UE sur la capacité de l'Europe de l'Ouest. Réduit la latence pour les populations d’utilisateurs régionaux.
- Séparation des centres de coûts : chaque unité commerciale dispose de sa propre capacité, permettant une refacturation précise des coûts.
Considérations relatives aux capacités croisées : les ensembles de données et les rapports doivent être publiés dans des espaces de travail affectés à des capacités spécifiques. Un rapport ne peut utiliser des ensembles de données que dans la même capacité (ou les importer à partir d'une capacité différente, ce qui a des implications en termes de performances). Planifiez les attributions d'espace de travail à capacité avant la publication pour éviter les modèles d'accès aux données entre capacités.
Questions fréquemment posées
Quel est le niveau de capacité minimum de Power BI pour une utilisation en entreprise ?
Power BI Premium P1 (ou Fabric F64) est le niveau minimum qui prend en charge l'ensemble complet des fonctionnalités de l'entreprise : rapports paginés, pipelines de déploiement, accès aux points de terminaison XMLA, informations sur l'IA, entités calculées de flux de données et tailles de modèle jusqu'à 400 Go. Pour les petites organisations ou les implémentations départementales, Power BI Premium par utilisateur (PPU) à 20 $/utilisateur/mois fournit la plupart des fonctionnalités sans nécessiter d'engagement de capacité. Pour le développement et les tests, Fabric F2 ou F4 est suffisant.
Comment le lissage du processeur sur 24 heures affecte-t-il la planification de la capacité ?
Power BI utilise un algorithme de lissage du processeur sur 24 heures pour déterminer si une capacité est surchargée. De courtes rafales de consommation élevée de processeur (une actualisation importante se terminant en 30 minutes) ne provoquent pas immédiatement de limitation : la rafale est calculée en moyenne sur une fenêtre de 24 heures. Cela signifie que vous pouvez gérer des charges de travail en rafale modérées sans avoir à dimensionner en fonction des pics. Cependant, un processeur élevé et soutenu (plus de 3 heures de charge de travail intensive) poussera la moyenne lissée au-dessus du seuil de limitation. Taille adaptée à votre pic soutenu, pas à votre maximum momentané.
Microsoft Fabric est-il meilleur que Power BI Premium pour les nouveaux déploiements ?
Pour les nouveaux déploiements d'entreprise en 2026, Fabric est généralement la voie recommandée. Il offre les mêmes fonctionnalités Power BI que Premium, plus des charges de travail supplémentaires (ingénierie des données, science des données, entrepôt de données, analyses en temps réel), une facturation plus flexible (pause/reprise, réservations) et un modèle de gouvernance unifié. Les organisations qui utilisent déjà des P-SKU Premium avec des contrats à long terme peuvent trouver que rester sur Premium jusqu'au renouvellement est financièrement judicieux. Tout le contenu Power BI Premium est compatible avec Fabric.
Comment réduire les coûts de capacité sans dégrader l'expérience utilisateur ?
Les leviers de réduction des coûts ayant le plus grand impact sont : (1) optimiser les ensembles de données pour réduire l'empreinte mémoire avant de les dimensionner, (2) échelonner les calendriers d'actualisation pour éviter une concurrence simultanée en matière de ressources, (3) utiliser Fabric avec pause/reprise pour les capacités de développement (payer uniquement pendant les heures de bureau), (4) activer la mise à l'échelle automatique de la capacité de production plutôt que de provisionner en permanence les pics, et (5) auditer les espaces de travail pour les rapports et les ensembles de données inutilisés qui consomment des ressources d'actualisation sans utilisateurs actifs.
Quels outils de surveillance Microsoft fournit-il pour l'état de la capacité ?
L'outil principal est l'application Microsoft Fabric Capacité Metrics (disponible sur AppSource). Il fournit des mesures sur l'utilisation du processeur, l'utilisation de la mémoire, les événements de limitation, l'activité des ensembles de données et les performances des requêtes. Pour des diagnostics plus approfondis, le point de terminaison XMLA (accessible via SSMS ou Tabular Editor) permet d'interroger les DMV (Dynamic Management Views) pour obtenir des données de performances de requête en temps réel. L’API Power BI REST fournit un accès programmatique aux métriques de capacité pour les tableaux de bord de surveillance personnalisés.
Prochaines étapes
La planification des capacités est une activité continue et non une décision ponctuelle. Commencez par le bon niveau, surveillez activement avec l'application Capacity Metrics, optimisez les charges de travail avant de les mettre à l'échelle et planifiez la croissance. Les organisations qui tirent le meilleur parti de Power BI Premium traitent la gestion de la capacité comme une discipline d’ingénierie des performances.
Les services d'optimisation des performances Power BI d'ECOSIRE incluent l'évaluation de la capacité, l'analyse de la charge de travail et des recommandations de dimensionnement. Contactez-nous pour auditer votre utilisation actuelle de la capacité et identifier la voie la plus rentable pour améliorer les performances.
Rédigé par
ECOSIRE TeamTechnical Writing
The ECOSIRE technical writing team covers Odoo ERP, Shopify eCommerce, AI agents, Power BI analytics, GoHighLevel automation, and enterprise software best practices. Our guides help businesses make informed technology decisions.
ECOSIRE
Débloquez les décisions basées sur les données
Tableaux de bord Power BI personnalisés, modélisation des données et solutions d'analyse intégrées.
Articles connexes
Microsoft Fabric vs Power BI : quelle est la différence et de quoi avez-vous réellement besoin en 2026 ?
Microsoft Fabric vs Power BI expliqué aux décideurs : leurs relations, ce qui a changé avec les F-SKU, quand la licence Pro est suffisante et les scénarios de coûts 2026.
Consultant Power BI vs équipe interne : coût, rapidité et quand embaucher de l'aide (2026)
Devriez-vous embaucher un consultant Power BI ou créer en interne ? Comparaison des coûts 2026, compromis en matière de rapidité et de qualité, modèles hybrides et signaux d'alarme lors de l'embauche d'une entreprise.
Power BI Embedded : coûts, dimensionnement des capacités et quand il vaut la peine de créer vos propres tableaux de bord
Répartition des coûts de Power BI Embedded pour les éditeurs de logiciels indépendants et les équipes SaaS en 2026 : tarification A-SKU et F-SKU, dimensionnement de la capacité en fonction de la charge utilisateur et calculs de création/achat avec des scénarios.
Plus de Performance & Scalability
Optimisation de la vitesse Shopify : une liste de contrôle technique qui fait réellement évoluer les éléments essentiels du Web (2026)
Une liste de contrôle de vitesse Shopify testée sur le terrain pour 2026 : ce qui améliore réellement LCP, INP et CLS sur les magasins réels, ce qui fait perdre du temps et comment auditer les applications et les thèmes.
Liste de contrôle d'audit technique SEO 2026 : 47 contrôles que nous effectuons sur chaque site client
La liste de contrôle d'audit technique SEO en 47 points que nous exécutons sur chaque site client en 2026 : exploration, indexation, canoniques, hreflang, Core Web Vitals et journaux.
Odoo 19 RH : Matrice de compétences, Plans de carrière, Cycles de performance
Mise à niveau Odoo 19 RH : matrice de compétences natives, planification de parcours professionnel, cycles d'évaluation de performances, grille de 9 cases, planification de succession, intégration SIRH.
Benchmarks de performances Odoo 19 : numéros de réglage PostgreSQL 17
Benchmarks de performances Odoo 19 dans le monde réel : vitesse du client Web, débit ORM, paramètres de réglage PG17, regroupement de connexions, nombre de travailleurs, seuils de mise à l'échelle.
Optimisation des coûts OpenClaw et efficacité des jetons à grande échelle
Optimisation du coût des jetons OpenClaw : mise en cache des invites, routage des modèles, mise en cache des réponses, API par lots et garde-fous de coûts par locataire pour les agents de production.
Actualisation incrémentielle de Power BI pour les tables de plus de 10 millions de lignes
Playbook d'actualisation incrémentielle Power BI pour plus de 10 millions de tables de lignes : conception de partitions, RangeStart/RangeEnd, stratégies d'actualisation, repliement des requêtes et hybrides DirectQuery.