Installez l’application Microsoft Fabric Capacity Metrics : c’est elle qui vous donne, en deux vues consécutives, la visibilité nécessaire pour surveiller la capacité Power BI. Ouvrez d’abord la page Health, puis basculez sur Compute pour détecter un éventuel throttling avant qu’il n’affecte vos utilisateurs.
Cette application, disponible gratuitement sur AppSource, reste la référence officielle pour l’analyse de données Power BI liée à la consommation de capacité. Elle agrège deux fenêtres temporelles distinctes qui structurent toute votre démarche de suivi de performance Power BI :
- 14 jours glissants pour la page Compute, qui trace l’évolution des Capacity Units consommées.
- 30 jours glissants pour la page Storage, qui suit le stockage facturable par espace de travail.
Conseil de pro : avant toute installation, vérifiez que vous disposez bien du rôle administrateur de capacité. Sans ce droit, le rapport de capacité Power BI restera partiellement vide, même une fois l’application connectée.
Points clés
La surveillance efficace d’une capacité Power BI repose sur l’installation du Metrics app, la lecture croisée des pages Health, Compute et Storage, et une couche d’alerting externe car l’application n’en fournit pas nativement.
| Point | Détails |
|---|---|
| Outil de référence | Installez l’application Microsoft Fabric Capacity Metrics depuis AppSource pour centraliser la surveillance. |
| Fenêtres temporelles | Consultez 14 jours de données sur Compute et 30 jours sur Storage pour repérer les tendances. |
| Suspension de capacité | Attendez-vous à un pic de facturation lissée au redémarrage, pas à une vraie anomalie. |
| Alerting externe requis | Combinez Fabric capacity overview events, Log Analytics et Power Automate, le Metrics app seul ne notifie rien. |
| Accompagnement Biworks | Biworks installe, configure les alertes et forme vos équipes à la certification PL-300 pour piloter la capacité en autonomie. |
Table des matières
- Étapes rapides pour installer et exécuter l’application Métriques de capacité
- Que surveiller dans les pages Health, Compute, Storage et Timepoint ?
- Comment interpréter les CU, le throttling et la mise à l’échelle automatique ?
- Surveiller une capacité suspendue sans se faire piéger par les faux positifs
- Quelles actions réduisent concrètement la consommation de capacité ?
- Comment compléter le Metrics app avec des alertes et des automatisations ?
- Comment Biworks accompagne l’implémentation et la formation Power BI
- Ce que la plupart des administrateurs négligent dans leur surveillance de capacité
- Faites auditer votre capacité Power BI par des experts Microsoft
- Sources
- Questions fréquentes
Étapes rapides pour installer et exécuter l’application Métriques de capacité
L’installation se fait en quelques minutes, mais deux ou trois détails de paramétrage font souvent trébucher les équipes IT pressées. Voici la marche à suivre pour une implémentation de Power BI sans accroc côté monitoring.
- Ouvrez AppSource ou, depuis Power BI, allez dans Applications > Obtenir des applications, puis recherchez « Métriques de capacité Microsoft Fabric ».
- Installez l’application et laissez-la se connecter automatiquement à votre tenant.
- Renseignez les paramètres demandés lors de la première connexion :
UTC_offset(le décalage horaire de votre organisation),RegionNameetDefaultCapacityIDouCapacityIDselon la version. - Authentifiez-vous via OAuth2, avec un compte disposant des droits d’administrateur de capacité.
- Lancez la première actualisation du jeu de données sémantique sous-jacent : elle peut prendre plusieurs minutes selon le volume d’activité de votre capacité Microsoft Fabric.
Cette procédure d’installation, décrite en détail dans la documentation officielle du Metrics app, exige ces trois paramètres précis pour que le rapport se connecte à la bonne capacité et affiche les bons fuseaux horaires.
Conseil de pro : si les visuels restent vides après la première actualisation, vérifiez d’abord la valeur de CapacityID avant de suspecter un problème de droits. C’est l’erreur de configuration la plus fréquente.
Que surveiller dans les pages Health, Compute, Storage et Timepoint ?
Chaque page du Metrics app répond à une question opérationnelle différente. Les confondre fait perdre un temps précieux quand une alerte tombe un lundi matin.
La page Health ouvre le diagnostic. Elle regroupe trois indicateurs centraux, le temps d’attente d’actualisation, le temps d’attente de requête et un score de planification de capacité, qui orientent immédiatement vers la bonne investigation, comme le souligne la présentation du Health center intégré au Metrics app.
La page Compute affiche les tendances sur 14 jours sous forme de graphiques en ruban et de matrices d’opérations. C’est ici que vous repérez les opérations les plus gourmandes en Capacity Units, triées par type : requêtes DAX, actualisations, dataflows.
La page Storage suit le stockage facturable par espace de travail sur une fenêtre de 30 jours, données supprimées mais encore récupérables comprises.
La page Timepoint permet un drill à la granularité de 30 secondes.
Quand un pic de consommation apparaît sur la courbe Compute, seule la vue Timepoint permet de remonter jusqu’à l’opération exacte qui l’a déclenchée, requête, actualisation ou tâche Spark, plutôt que de deviner à partir d’une moyenne journalière.
C’est cette granularité, combinée à la catégorisation fine des opérations (Spark, Dataflows Gen2, fonctions IA), que la documentation Microsoft sur l’application Métriques met en avant pour diagnostiquer un throttling ou une mise à l’échelle automatique mal comprise.
Comment interpréter les CU, le throttling et la mise à l’échelle automatique ?
Une Capacity Unit (CU) mesure la puissance de calcul consommée sur une fenêtre glissante, agrégée par intervalles de 30 secondes puis lissée pour donner les courbes que vous voyez dans Compute. Plus votre tenant héberge de workloads actifs (Power BI, Spark, entrepôts SQL), plus cette consommation grimpe simultanément sur le même socle de capacité.
Le throttling apparaît quand la demande dépasse durablement la capacité disponible. Trois signaux doivent vous alerter :
- Une file d’attente qui s’allonge sur les opérations interactives plutôt que sur les tâches d’arrière-plan.
- Un temps de réponse au 95e centile qui se dégrade sur plusieurs jours consécutifs, pas seulement sur un pic isolé.
- Un taux d’utilisation soutenu proche de la saturation sur la fenêtre de 14 jours, sans redescente nocturne.
La documentation d’optimisation des capacités distingue les opérations interactives des opérations en arrière-plan, un throttling apparaît surtout en cas de forte concurrence entre les deux, et recommande d’envisager un scale-out ou l’autoscale plutôt qu’une simple optimisation ponctuelle une fois ce seuil franchi.
L’autoscale, justement, complique parfois la lecture : il absorbe temporairement les pics en ajoutant des CU à la volée, ce qui masque le symptôme sans en traiter la cause. Si votre facture augmente sans que la courbe Compute ne montre de throttling visible, l’autoscale travaille probablement en coulisses. Il faut alors comparer la fréquence des déclenchements d’autoscale à l’historique des opérations pour savoir si le problème est structurel ou ponctuel.
Surveiller une capacité suspendue sans se faire piéger par les faux positifs
Suspendre une capacité Fabric la nuit ou le week-end fait économiser des coûts, mais génère un artefact que beaucoup d’administrateurs interprètent à tort comme un incident. Lors de la reprise, l’utilisation lissée accumulée pendant la pause est convertie et facturée d’un coup, ce qui crée un pic visible sur les courbes, un phénomène de report de charge documenté dans le guide de surveillance d’une capacité en pause.
- Consultez la table des événements système et filtrez sur les états « Suspendu » et « Actif » pour dater précisément la reprise.
- Basculez la visualisation en échelle logarithmique : elle atténue l’effet visuel du pic de reprise et rend les vraies anomalies plus lisibles.
- Ne configurez jamais une alerte de seuil brut juste après une fenêtre de suspension planifiée, elle se déclenchera à tort presque à chaque fois.
Conseil de pro : si vous suspendez systématiquement la capacité en dehors des heures ouvrées, décalez vos analyses post-incident d’au moins 30 minutes après la reprise. Le temps que le report de charge se résorbe.
Quelles actions réduisent concrètement la consommation de capacité ?
L’optimisation des ressources BI ne se limite pas à surveiller, elle passe par des interventions techniques précises sur vos modèles et vos actualisations.
- Revoir le modèle de données : privilégiez un schéma en étoile, supprimez les colonnes inutilisées et surveillez la cardinalité des colonnes à forte volumétrie, qui pèsent lourd en mémoire.
- Auditer les mesures DAX : repérez les mesures coûteuses avec un outil comme Best Practice Analyzer, et simplifiez les itérateurs imbriqués qui multiplient les scans de table.
- Optimiser les actualisations : activez l’actualisation incrémentielle sur les grandes tables, vérifiez que le query folding fonctionne réellement côté source, et étalez vos plannings d’actualisation pour lisser la charge plutôt que de tout déclencher à la même heure.
- Archiver les rapports inactifs : un nombre significatif de rapports d’un tenant n’ont plus d’usage réel après quelques mois, d’après un guide opérationnel sur la surveillance Power BI, et chacun continue pourtant de consommer des cycles d’actualisation.
Ces bonnes pratiques sont détaillées dans notre guide sur l’optimisation des usages Microsoft Fabric, avec des exemples concrets par type de charge.
Comment compléter le Metrics app avec des alertes et des automatisations ?
L’application Metrics a une limite connue : elle n’envoie aucune alerte native. Pour être proactif plutôt que réactif, il faut construire une couche de surveillance autour d’elle.
- Utilisez les Fabric capacity overview events pour recevoir des notifications sur les changements d’état de capacité.
- Corrélez les identifiants d’opération du Metrics app avec
queryinsights.exec_requests_historypour retrouver le texte exact de la requête et l’utilisateur à l’origine d’une charge anormale, une pratique décrite dans la documentation d’optimisation Fabric. - Interrogez les DMV comme
sys.dm_exec_requestspour un diagnostic en temps réel sur les entrepôts SQL rattachés à la capacité. - Construisez un flux Power Automate branché sur l’API REST Power BI pour créer automatiquement un ticket dès qu’un indicateur de performance Power BI franchit un seuil défini.
Conseil de pro : ne branchez jamais une alerte automatisée directement sur le taux d’utilisation brut sans exclure les fenêtres de suspension planifiée. Vous passeriez votre première semaine à désactiver de fausses alertes.
Comment Biworks accompagne l’implémentation et la formation Power BI
Biworks est partenaire Microsoft et organisme de formation certifié Qualiopi, avec un parcours menant à la certification PL-300. Concrètement, cela se traduit par :
- L’installation et le paramétrage complet de l’application Métriques de capacité sur votre tenant.
- La mise en place d’alertes et d’automatisations adaptées à vos seuils métier.
- Des audits d’optimisation de capacité pour cibler modèles, DAX et plannings d’actualisation.
- Des formations Power BI et Fabric éligibles au CPF pour autonomiser vos équipes IT.
Ce que la plupart des administrateurs négligent dans leur surveillance de capacité
La plupart des équipes IT installent le Metrics app, regardent la courbe Compute une fois par semaine, et considèrent le travail fait. C’est là l’angle mort : une capacité Power BI ne se pilote pas comme un serveur qu’on surveille de loin, elle réagit à des comportements utilisateurs changeants, des nouveaux rapports publiés sans revue, des actualisations empilées aux mêmes heures.
La conviction que je défends après avoir observé de nombreux tenants Fabric : le vrai levier n’est pas l’outil de surveillance, c’est la discipline de revue pilotée par des indicateurs clés qu’on met autour. Un Health center consulté une fois par mois ne sert à rien. Un plan d’audit trimestriel des mesures DAX coûteuses, couplé à un archivage systématique des rapports inactifs, change réellement la trajectoire de consommation. Trop d’organisations investissent dans le monitoring et négligent l’action corrective qui doit suivre. Priorisez d’abord la page Health et les trois KPI qu’elle expose, puis construisez vos automatisations d’alerte seulement une fois que vous savez précisément quel seuil déclenche une vraie intervention plutôt qu’une notification ignorée.
Faites auditer votre capacité Power BI par des experts Microsoft
Vous venez de voir tout ce qu’une surveillance rigoureuse exige, installation, paramétrage, lecture croisée des pages, alerting externe. Biworks est l’alternative concrète à l’apprentissage en solitaire : au lieu de passer des semaines à décoder les courbes du Metrics app par essai erreur, vous bénéficiez d’un consultant qui a déjà résolu ces situations de throttling et de faux positifs post-suspension sur d’autres tenants Fabric.
Notre équipe de consulting en Business Intelligence prend en charge l’installation du Metrics app, la configuration des alertes Power Automate et l’audit d’optimisation de vos modèles et actualisations. Pour les équipes qui veulent monter en compétence en interne, notre formation Power BI certifiante PL-300, éligible au CPF, couvre justement ces mécaniques de capacité et d’optimisation. Demandez un audit de votre capacité actuelle pour identifier vos premières marges d’économie.
Sources
- Microsoft Fabric Capacity Metrics app – metrics-app
Questions fréquentes
Quels sont les inconvénients de Power BI côté capacité ?
Le principal inconvénient tient à la complexité de diagnostic : le Metrics app n’alerte pas nativement, et le throttling reste parfois invisible tant que l’autoscale absorbe les pics en coulisses.
Quelles certifications existent pour administrer Power BI ?
La certification de référence est PL-300, qui valide les compétences de préparation de données, de modélisation et d’analyse dans Power BI. Biworks propose une formation Qualiopi de 3 jours éligible au CPF pour la préparer.
Pourquoi utiliser Power BI plutôt qu’Excel pour ce type de suivi ?
Power BI gère nativement des volumes de données bien plus importants qu’Excel et actualise automatiquement les tableaux de bord de surveillance, alors qu’Excel demande des manipulations manuelles répétées à chaque analyse de capacité.
Est-ce que Power BI est difficile à administrer côté capacité ?
La prise en main du Metrics app reste accessible, mais interpréter correctement le throttling, l’autoscale et les faux positifs de suspension demande une vraie montée en compétence technique, souvent accélérée par une formation structurée.
Le Metrics app peut-il remplacer un outil d’alerting complet ?
Non, il n’envoie aucune notification automatique. Il faut le compléter avec Fabric capacity overview events, Log Analytics ou un flux Power Automate pour couvrir ce besoin.