Power BI Embedded : ajouter des analyses à votre application

Chaque application SaaS a finalement besoin d'analyses. Les utilisateurs veulent des tableaux de bord montrant leurs modèles d'utilisation, leurs mesures de performances et leurs résultats commerciaux. Créer une couche d'analyse personnalisée à partir de zéro - bibliothèques de graphiques, pipelines de données, mise en cache, fonctionnalités d'exportation, interactions d'exploration - nécessite 6 à 12 mois d'efforts d'ingénierie et de maintenance continue. Power BI Embedded offre une alternative : des fonctionnalités d'analyse de niveau entreprise intégrées directement dans votre application, soutenues par l'infrastructure de Microsoft.

Power BI Embedded ne consiste pas simplement à « mettre une iframe sur une page ». Il s'agit d'une plate-forme complète permettant de proposer des expériences d'analyse interactives, sécurisées et multi-locataires au sein de l'interface utilisateur de votre propre application. Vos clients interagissent avec des analyses qui semblent natives de votre produit pendant que vous exploitez le moteur de visualisation mature de Power BI, la couche de calcul DAX et l'infrastructure de connectivité des données.

Ce guide couvre l'architecture, les modèles d'authentification, la sécurité mutualisée, la planification de la capacité, l'intégration du SDK et les considérations tarifaires pour l'intégration de Power BI dans votre application. Si vous prévoyez une implémentation d’analyse intégrée, explorez nos services d’analyse intégrée Power BI pour obtenir des conseils sur l’architecture et une assistance au développement.

Points clés à retenir

• Power BI Embedded prend en charge deux scénarios : « intégration pour vos clients » (l'application possède les données) et « intégration pour votre organisation » (l'utilisateur possède les données)
• L'authentification du principal de service est recommandée pour les applications SaaS multi-locataires ; les comptes d'utilisateurs principaux sont plus simples mais créent des points de défaillance uniques
• La sécurité au niveau des lignes (RLS) est le principal mécanisme permettant de garantir l'isolation des données des locataires dans les ensembles de données partagés.
• Les SKU Fabric F offrent la capacité la plus rentable pour les scénarios intégrés, à partir de F2 pour le développement
• Le SDK JavaScript permet un contrôle programmatique approfondi : application de filtres, capture d'événements, contrôle de la navigation et personnalisation des thèmes
• Le dimensionnement de la capacité dépend des utilisateurs simultanés, de la complexité des requêtes et du volume de données, et pas seulement du nombre total d'utilisateurs.
• Les thèmes personnalisés et le chrome caché donnent aux rapports intégrés un aspect natif à votre application

---

Scénarios d'intégration : clients contre organisation

Intégrez pour vos clients (l'application possède des données)

Le scénario « l'application possède des données » est le principal cas d'utilisation des applications SaaS. Votre application s'authentifie auprès de Power BI à l'aide d'un principal de service ou d'un compte d'utilisateur principal, génère un jeton d'intégration et diffuse le rapport intégré à vos utilisateurs finaux. Vos clients n’interagissent jamais directement avec Power BI et n’ont pas besoin de licences Power BI.

Flux architectural :

1. Votre client se connecte à votre application en utilisant votre système d'authentification.
2. Le backend de votre application appelle l’API REST Power BI pour générer un jeton d’intégration, limité au rapport, à l’ensemble de données et au rôle RLS spécifiques de ce client.
3. Le backend renvoie le jeton d'intégration et l'URL d'intégration au frontend.
4. L'interface initialise le SDK JavaScript Power BI avec le jeton d'intégration et restitue le rapport dans un élément de conteneur désigné.
5. Le jeton d'intégration expire après une période configurable (1 heure par défaut) et votre application l'actualise de manière transparente.

Caractéristiques clés :

• Les clients n'ont pas besoin de licences Power BI Pro ou Premium par utilisateur
• Tous les coûts de capacité sont supportés par vous (le fournisseur d'applications) via les SKU Fabric/Embedded
• Vous avez un contrôle total sur ce que les utilisateurs voient via RLS et le filtrage programmatique
• L'authentification se fait entièrement dans le système d'authentification de votre application
• Les jetons intégrés fournissent un accès limité et limité dans le temps à des artefacts spécifiques

Il s'agit du modèle utilisé par les éditeurs de logiciels indépendants, les plates-formes SaaS et les portails internes, dans lequel le consommateur d'analyses ne devrait pas savoir ou se soucier du fait que Power BI est la technologie sous-jacente.

Intégrer pour votre organisation (l'utilisateur possède les données)

Le scénario « l'utilisateur possède les données » permet d'intégrer du contenu Power BI dans des applications internes où les utilisateurs disposent déjà de licences Power BI (Pro ou PPU). L’expérience intégrée utilise l’identité et les autorisations Power BI de l’utilisateur.

Flux architectural :

1. L'utilisateur s'authentifie auprès d'Azure AD via votre application.
2. Votre application acquiert un jeton d'accès au nom de l'utilisateur à l'aide du flux OAuth 2.0 pour le compte de.
3. L'application appelle l'API Power BI REST avec le jeton de l'utilisateur pour obtenir la configuration intégrée.
4. Le rapport s'affiche avec toutes les autorisations Power BI de l'utilisateur.

Caractéristiques clés :

• Chaque utilisateur doit disposer d'une licence Power BI Pro ou Premium par utilisateur
• Les utilisateurs voient le contenu en fonction de leurs propres autorisations Power BI et attributions RLS
• Aucune capacité Fabric/Embedded supplémentaire n'est requise (utilise l'allocation de licence Pro/PPU de l'utilisateur)
• Moins de contrôle pour le développeur d'applications, plus d'autonomie pour l'utilisateur
• Architecture plus simple mais coût de licence par utilisateur plus élevé

Ce modèle est généralement utilisé pour les portails intranet, les intégrations SharePoint et les applications internes où les utilisateurs disposent déjà de licences Power BI et doivent conserver leurs autorisations d'accès existantes.

Choisir entre les scénarios

Pour la plupart des applications SaaS ciblant des clients externes, « l'application possède des données » est le bon choix. Le reste de ce guide se concentre principalement sur ce scénario.

---

Authentification : principal du service vs utilisateur principal

Authentification du principal du service

Un principal de service est une identité d’application Azure AD à laquelle Power BI fait confiance pour accéder aux ressources par programme. Il s’agit de la méthode d’authentification recommandée pour les applications embarquées de production.

Exigences de configuration :

1. Enregistrez une application dans Azure AD.
2. Créez un secret client ou un certificat pour l'application.
3. Créez un groupe de sécurité Azure AD et ajoutez-y le principal du service.
4. Dans le portail d'administration Power BI, activez l'accès du principal de service pour le groupe de sécurité sous Paramètres du locataire > Paramètres du développeur.
5. Accordez au principal du service l'accès aux espaces de travail Power BI spécifiques contenant votre contenu incorporé.

Avantages :

• Aucune dépendance vis-à-vis d'un compte utilisateur spécifique (élimine le point de défaillance unique)
• Les secrets et certificats clients peuvent être alternés sans interruption de service
• Les principaux de service peuvent être étendus à des espaces de travail spécifiques (moindre privilège)
• Fonctionne avec les identités managées Azure AD dans les applications hébergées par Azure
• Prend en charge l'authentification basée sur un certificat pour une sécurité accrue

Limites :

• Impossible d'accéder à "Mon espace de travail" (espaces de travail personnels)
• Impossible d'appeler certaines API d'administration
• Nécessite Azure AD Premium pour certaines fonctionnalités avancées
• La configuration initiale est plus complexe que celle de l'utilisateur principal

Authentification de l'utilisateur principal

Un utilisateur principal est un compte utilisateur Azure AD standard avec une licence Power BI Pro ou PPU que votre application utilise pour s'authentifier auprès de Power BI. L'application se connecte en tant qu'utilisateur pour générer des jetons d'intégration.

Avantages :

• Configuration initiale plus simple (créer un utilisateur, attribuer une licence, accorder l'accès à l'espace de travail)
• Peut accéder à toutes les fonctionnalités de Power BI, y compris les API d'administration
• Aucune inscription d'application Azure AD requise

Inconvénients :

• Point de défaillance unique : si le compte utilisateur est verrouillé, le mot de passe expire ou l'authentification MFA est déclenchée, votre application perd l'accès aux analyses. - Impossible d'utiliser des stratégies d'accès conditionnel qui nécessitent une connexion interactive
• La rotation des mots de passe nécessite des mises à jour de l'application
• Viole les meilleures pratiques de sécurité consistant à ne pas utiliser de comptes humains pour les processus machine
• Coût de la licence pour le compte utilisateur

Recommandation : Utilisez l'authentification du principal de service pour tous les déploiements de production. Les comptes d'utilisateurs principaux sont acceptables pour les environnements de validation de principe et de développement où la simplicité compte plus que la fiabilité.

Génération et gestion de jetons

Quelle que soit la méthode d’authentification, votre application génère des jetons intégrés via l’API REST Power BI. Le jeton encapsule les autorisations pour la session intégrée.

Considérations relatives aux jetons intégrés :

• Durée de vie du jeton : La valeur par défaut est de 1 heure, configurable jusqu'à 24 heures. Des durées de vie plus courtes sont plus sécurisées mais nécessitent des actualisations plus fréquentes.
• Portée du jeton : chaque jeton est limité à des rapports, des ensembles de données et des espaces de travail spécifiques. Générez la portée la plus étroite possible.
• Identité RLS : Lors de l'utilisation de la sécurité au niveau des lignes, l'identité RLS (nom d'utilisateur et rôles) est intégrée dans le jeton. C’est ainsi que vous assurez l’isolement des locataires.
• Actualisation du jeton : Votre interface doit surveiller l'expiration du jeton et demander un nouveau jeton avant son expiration. Le SDK JavaScript fournit des événements à cet effet.

Exemple de flux de génération de jetons :

POST https://api.powerbi.com/v1.0/myorg/GenerateToken
{
    "datasets": [{"id": "dataset-guid"}],
    "reports": [{"id": "report-guid"}],
    "identities": [{
        "username": "[email protected]",
        "roles": ["TenantRole"],
        "datasets": ["dataset-guid"]
    }]
}

La réponse contient un jeton intégré et un horodatage d'expiration. Votre backend met en cache ce jeton (en respectant l'expiration) et le sert aux requêtes frontend authentifiées.

---

Sécurité au niveau des lignes multi-locataires

Pourquoi RLS est essentiel pour l'embarqué

Dans une application SaaS mutualisée, les données de plusieurs clients résident souvent dans le même jeu de données Power BI. Sans sécurité au niveau des lignes, un jeton d'intégration accorde l'accès à toutes les données de l'ensemble de données. RLS garantit que chaque client ne voit que ses propres données, même si l'ensemble de données sous-jacent est partagé.

RLS n’est pas facultatif pour les scénarios intégrés multi-locataires. Un échec dans l’isolation des locataires est une violation de données. Concevez RLS comme un contrôle de sécurité fondamental, et non comme une réflexion après coup.

RLS statique

RLS statique définit des règles de filtrage fixes à l'aide d'expressions DAX dans Power BI Desktop. Chaque rôle dispose d'un ensemble de filtres de table qui limitent les lignes visibles.

Exemple :

Un "TenantRole" avec ce filtre sur la table Customers :

[TenantId] = USERNAME()

Lors de la génération d'un jeton d'intégration, votre application définit la valeur USERNAME() sur l'identifiant du locataire actuel. Le filtre DAX restreint toutes les requêtes aux lignes auxquelles TenantId correspond.

Le RLS statique est simple et efficace pour une isolation simple des locataires. Cela fonctionne bien quand :

• L'isolation des locataires est basée sur une seule colonne (TenantId) qui se propage à travers les relations
• Tous les locataires voient la même structure de rapport, juste filtrée selon leurs données
• Le nombre de rôles RLS est faible et stable

### RLS dynamique

Dynamic RLS utilise des expressions DAX qui sont évaluées au moment de la requête en fonction de l'identité de l'utilisateur. Cela permet des scénarios de sécurité plus complexes sans créer de rôles distincts pour chaque locataire.

Modèles RLS dynamiques courants :

Modèle USERPRINCIPALNAME() :

[Email] = USERPRINCIPALNAME()

Le jeton d'intégration définit le nom d'utilisateur de l'identité effective sur l'adresse e-mail de l'utilisateur. Le filtre correspond à une colonne E-mail dans une table de mappage de sécurité.

Modèle de table de sécurité : Créez une table de sécurité dédiée mappant les utilisateurs aux données auxquelles ils peuvent accéder :

Appliquez des filtres RLS qui joignent cette table de sécurité à vos tables de faits via des relations. Ce modèle prend en charge les autorisations au niveau de l'utilisateur au sein d'un locataire, et pas seulement l'isolation au niveau du locataire.

Tests et validation RLS

Tests préalables au déploiement :

1. Dans Power BI Desktop, utilisez « Afficher sous » pour tester chaque rôle RLS avec des exemples de noms d'utilisateur.
2. Vérifiez que le filtrage croisé entre les tables respecte les limites RLS.
3. Testez les cas extrêmes : utilisateurs sans lignes correspondantes (devraient voir des rapports vides, pas des erreurs), utilisateurs avec plusieurs rôles et valeurs nulles dans les colonnes de filtre.
4. Vérifiez que les mesures DAX utilisant ALL() ou REMOVEFILTERS() ne contournent pas RLS (elles ne devraient pas, mais vérifiez).

Validation de production :

• Automatisez les tests RLS dans le cadre de votre pipeline de déploiement
• Générez des jetons intégrés pour tester les identités des locataires et vérifier que les résultats de la requête correspondent aux données attendues
• Surveiller les tentatives de contournement RLS dans les métriques de capacité (modèles de requêtes inhabituels, volumes de données inattendus)
• Effectuer des revues de sécurité trimestrielles des configurations RLS

---

## Dimensionnement de la capacité et SKU de tissu

Comprendre la capacité

Power BI Embedded nécessite une capacité dédiée : des ressources de calcul réservées à vos charges de travail intégrées. La capacité est mesurée en unités de capacité (CU), qui déterminent la puissance de traitement disponible pour le rendu des rapports, l'exécution de requêtes et l'actualisation des ensembles de données.

La capacité n’est pas par utilisateur. Il s’agit d’un pool de calcul partagé dans lequel s’appuient toutes vos sessions intégrées. Cela signifie que les tarifs évoluent en fonction de la concurrence et de la complexité des requêtes, et non en fonction du nombre total d'utilisateurs.

Options SKU du tissu F

Les SKU Microsoft Fabric F constituent le modèle de tarification actuel pour la capacité Power BI Embedded. Ils ont remplacé les anciens SKU A par un modèle plus flexible et capable de mettre en pause.

Remarques importantes :

- Les utilisateurs simultanés ne signifient pas le nombre total d'utilisateurs. Cela signifie que les utilisateurs interrogent activement au même moment. Un ratio typique est de 5 à 10 % du total des utilisateurs simultanés à un moment donné.

• Ce sont des chiffres indicatifs approximatifs. La capacité réelle dépend fortement de la complexité des requêtes, de la taille du modèle et du nombre de visualisations par rapport.
• Les SKU F peuvent être mis en pause lorsqu'ils ne sont pas utilisés (contrairement aux anciens SKU P), ce qui est précieux pour le développement et les charges de travail saisonnières.
• F64 et supérieur incluent les fonctionnalités Power BI Premium (rapports paginés, IA, pipelines de déploiement) sans frais de licence supplémentaires.

Méthodologie de dimensionnement des capacités

Étape 1 : Estimez les utilisateurs simultanés.

Utilisateurs simultanés = Nombre total d'utilisateurs x Taux de concurrence maximal

Pour les tableaux de bord d'analyse SaaS accessibles pendant les heures de bureau : taux de simultanéité de 5 à 10 %. Pour les tableaux de bord opérationnels vérifiés fréquemment tout au long de la journée : taux de concurrence de 15 à 25 %. Pour les tableaux de bord événementiels (surveillance en temps réel, alertes) : taux de concurrence de 30 à 50 %.

Étape 2 : Évaluez la complexité des requêtes.

Rapports simples (5 à 10 visuels, agrégations de base, tableau de faits uniques) : 1x référence. Rapports moyens (10 à 20 visuels, intelligence temporelle, plusieurs tableaux de faits) : 2 à 3 x référence. Rapports complexes (plus de 20 visuels, DAX complexe, grands ensembles de données, requêtes multi-sources) : base de référence 4 à 6x.

Étape 3 : Calculez la capacité requise.

Commencez par le SKU qui correspond à votre estimation d’utilisateurs simultanés dans le tableau ci-dessus. Multipliez par votre facteur de complexité. Si le résultat dépasse la capacité de requêtes simultanées du SKU, passez au niveau suivant.

Étape 4 : Validez avec des tests de charge.

Le dimensionnement théorique est un point de départ. Avant le lancement de la production, effectuez des tests de charge avec des volumes de données, des modèles de requête et des niveaux de simultanéité réalistes. Microsoft fournit à cet effet un outil de test de charge de capacité Power BI Embedded.

Étape 5 : Planifier la croissance.

Ajoutez 30 à 50 % de marge au-dessus de votre pic actuel pour accueillir la croissance au cours des 6 à 12 prochains mois. Les SKU F peuvent être mis à niveau sans temps d'arrêt, afin que vous puissiez les dimensionner progressivement.

Stratégies d'optimisation des coûts

• Suspendre les capacités de développement en dehors des heures de travail. SKU F facturés à la seconde lorsqu’ils sont actifs, gratuits en cas de pause. L'automatisation de la pause/reprise avec Azure Automation ou Logic Apps peut réduire les coûts de développement de 60 à 70 %.

• Optimiser les modèles avant de faire évoluer la capacité. Un modèle bien optimisé sur F8 surpasse souvent un modèle mal optimisé sur F32. Investissez dans l’optimisation du modèle avant de lancer le calcul sur des problèmes de performances.

• Utilisez des tables d'agrégation pour les grands ensembles de données. La pré-agrégation des données à des granularités communes (quotidienne, hebdomadaire, mensuelle) réduit le traitement des requêtes de 80 à 90 % pour les visuels de niveau résumé tout en préservant la capacité d'exploration des détails.

• Implémentez la mise en cache au niveau du rapport via l'API REST Power BI. Pour les tableaux de bord avec des mises à jour de données peu fréquentes, les résultats mis en cache réduisent la consommation de capacité par session utilisateur.

• Envisagez des capacités distinctes pour différentes charges de travail. Isoler les opérations d'actualisation des requêtes interactives empêche les pics d'actualisation de dégrader l'expérience utilisateur. Ceci est particulièrement important si vous disposez de grands ensembles de données qui sont actualisés pendant les heures de bureau.

---

Intégration du SDK JavaScript

Intégration de base

Le SDK JavaScript Power BI (powerbi-client) fournit l’interface de programmation permettant d’intégrer et de contrôler le contenu Power BI dans votre application Web.

Installation :

npm install powerbi-client

Flux d'intégration de base :

import * as pbi from 'powerbi-client';

const powerbi = new pbi.service.Service(
    pbi.factories.hpmFactory,
    pbi.factories.wpmpFactory,
    pbi.factories.routerFactory
);

const embedConfig = {
    type: 'report',
    id: reportId,
    embedUrl: embedUrl,
    accessToken: embedToken,
    tokenType: pbi.models.TokenType.Embed,
    settings: {
        panes: {
            filters: { visible: false },
            pageNavigation: { visible: true }
        },
        background: pbi.models.BackgroundType.Transparent,
        layoutType: pbi.models.LayoutType.Custom,
        customLayout: {
            displayOption: pbi.models.DisplayOption.FitToWidth
        }
    }
};

const reportContainer = document.getElementById('report-container');
const report = powerbi.embed(reportContainer, embedConfig);

Contrôle programmatique

Le SDK expose un contrôle programmatique étendu sur le rapport intégré :

Application de filtres :

const filter = {
    $schema: "http://powerbi.com/product/schema#basic",
    target: {
        table: "Sales",
        column: "Region"
    },
    operator: "In",
    values: ["North", "South"],
    filterType: pbi.models.FilterType.BasicFilter
};

await report.setFilters([filter]);

Capturer des événements :

report.on('loaded', function() {
    console.log('Report loaded successfully');
});

report.on('dataSelected', function(event) {
    const data = event.detail;
    // Handle user selection — navigate to detail page, update other UI, etc.
});

report.on('pageChanged', function(event) {
    const pageName = event.detail.newPage.displayName;
    // Track page navigation in your analytics
});

Actualisation du jeton :

report.on('tokenExpired', async function() {
    const newToken = await fetchNewEmbedToken();
    await report.setAccessToken(newToken);
});

Contrôle de navigation :

// Navigate to a specific page
const pages = await report.getPages();
const targetPage = pages.find(p => p.displayName === 'Revenue Analysis');
await targetPage.setActive();

// Set a specific slicer value
const visuals = await targetPage.getVisuals();
const slicer = visuals.find(v => v.type === 'slicer');
await slicer.setSlicerState({
    filters: [{
        $schema: "http://powerbi.com/product/schema#basic",
        target: { table: "Date", column: "Year" },
        operator: "In",
        values: [2026],
        filterType: pbi.models.FilterType.BasicFilter
    }]
});

Rendu progressif pour les performances

Pour les rapports complexes comportant de nombreux éléments visuels, le rendu progressif améliore les performances perçues en affichant d'abord le contenu au-dessus de la ligne de flottaison :

const embedConfig = {
    // ... standard config
    settings: {
        // ... other settings
        commands: [{
            visualRendered: {
                phase: 1,
                visualNames: ['revenue-kpi', 'trend-chart', 'summary-table']
            }
        }]
    }
};

report.on('visualRendered', function(event) {
    if (event.detail.phase === 1) {
        // Hide loading spinner, show report
        document.getElementById('loading').style.display = 'none';
    }
});

---

Thèmes personnalisés et image de marque

Pourquoi les thèmes personnalisés sont importants

Les visuels Power BI par défaut utilisent la palette de couleurs et le style de Microsoft. Dans un contexte embarqué, cela crée une incohérence visuelle avec votre application. Les thèmes personnalisés alignent les analyses intégrées sur le système de conception de votre produit, ce qui rend l'expérience native plutôt que boulonnée.

Structure JSON du thème

Les thèmes Power BI sont définis sous forme de fichiers JSON avec un contrôle sur les couleurs, les polices, les valeurs visuelles par défaut et le style des éléments :

{
    "name": "MyApp Theme",
    "dataColors": [
        "#2563EB", "#7C3AED", "#059669", "#D97706",
        "#DC2626", "#0891B2", "#4F46E5", "#65A30D"
    ],
    "background": "#FFFFFF",
    "foreground": "#1E293B",
    "tableAccent": "#2563EB",
    "textClasses": {
        "callout": {
            "fontSize": 28,
            "fontFace": "Inter, sans-serif",
            "color": "#0F172A"
        },
        "title": {
            "fontSize": 14,
            "fontFace": "Inter, sans-serif",
            "color": "#1E293B"
        },
        "header": {
            "fontSize": 12,
            "fontFace": "Inter, sans-serif",
            "color": "#475569"
        },
        "label": {
            "fontSize": 11,
            "fontFace": "Inter, sans-serif",
            "color": "#64748B"
        }
    },
    "visualStyles": {
        "*": {
            "*": {
                "border": [{
                    "color": {"solid": {"color": "#E2E8F0"}},
                    "radius": 8
                }],
                "background": [{
                    "color": {"solid": {"color": "#FFFFFF"}},
                    "transparency": 0
                }]
            }
        }
    }
}

Application de thèmes par programmation

Les thèmes peuvent être appliqués au moment de l'intégration ou commutés dynamiquement (utile pour la prise en charge du mode sombre) :

// Apply theme at embed time
const embedConfig = {
    // ... standard config
    theme: { themeJson: customThemeJson }
};

// Switch theme dynamically (e.g., light/dark mode toggle)
await report.applyTheme({ themeJson: darkThemeJson });

Masquage de Power BI Chrome

Pour une apparence entièrement native, masquez les éléments d’interface utilisateur intégrés de Power BI et remplacez-les par vos propres contrôles d’application :

const settings = {
    panes: {
        filters: { visible: false },      // Hide filter pane
        pageNavigation: { visible: false } // Hide page tabs
    },
    bars: {
        actionBar: { visible: false },     // Hide action bar
        statusBar: { visible: false }      // Hide status bar
    },
    background: pbi.models.BackgroundType.Transparent,
    visualRenderedEvents: true
};

Créez ensuite des contrôles personnalisés de navigation, de filtrage et d'exportation dans le cadre d'interface utilisateur de votre application. Utilisez le SDK JavaScript pour appliquer des filtres par programmation, modifier des pages et déclencher des exportations lorsque les utilisateurs interagissent avec vos contrôles personnalisés.

Cette approche nécessite davantage d'efforts de développement mais produit une expérience transparente dans laquelle les utilisateurs ne peuvent pas faire la distinction entre les fonctionnalités natives de votre application et le contenu Power BI intégré.

---

Optimisation des performances pour l'embarqué

Performances frontales

• Chargement paresseux du SDK. Le SDK JavaScript Power BI fait environ 300 Ko. Chargez-le de manière asynchrone et uniquement lorsque l'utilisateur accède à une page d'analyse.
• Préchargez les jetons intégrés. Générez des jetons intégrés avant que l'utilisateur ne demande le rapport. Si votre application sait que l'utilisateur consultera probablement des analyses (basées sur des modèles de navigation), préchargez le jeton pendant les transitions de page.
• Utilisez l'intégration d'amorçage. Le SDK prend en charge un modèle d'amorçage qui initialise l'iframe avant que le jeton d'intégration ne soit disponible, réduisant ainsi le temps de chargement perçu de 200 à 500 ms.

// Bootstrap first (fast — creates iframe immediately)
const report = powerbi.bootstrap(container, { type: 'report' });

// Load later when token is available
const embedConfig = { /* full config */ };
report.load(embedConfig);

• Implémenter la mise en cache des rapports. Une fois un rapport chargé, l'iframe le conserve en mémoire. Si l'utilisateur s'éloigne et revient, réutilisez l'iframe existante au lieu de la réintégrer. Cela élimine entièrement le temps de chargement pour les visites répétées au sein de la même session.

Performances du back-end

• Cache les jetons intégrés. Les jetons intégrés sont valables pour toute leur durée de vie (1 heure par défaut). Mettez-les en cache dans Redis ou en mémoire et réutilisez-les dans toutes les demandes pour la même combinaison rapport/identité.
• Génération de jetons par lots. Si le tableau de bord d'un utilisateur contient plusieurs rapports intégrés, générez tous les jetons intégrés dans un seul appel d'API à l'aide de la fonctionnalité multi-ressources du point de terminaison GenerateToken.
• Surveiller les limites de débit de l'API. L'API REST Power BI a des limites de débit par principal de service. Surveillez 429 réponses et mettez en œuvre un recul exponentiel. Pour les applications à grande échelle, répartissez la charge sur plusieurs principaux de service.

Conception de rapports pour les applications embarquées

Les rapports conçus pour une consommation intégrée doivent donner la priorité aux performances plutôt qu'à la complexité visuelle :

• Limiter les visuels à 8-12 par page (chaque visuel génère une requête distincte)
• Utilisez le mode Importation au lieu de DirectQuery lorsque cela est possible (10 à 100 fois plus rapide)
• Pré-agréger les données à la granularité appropriée
• Évitez les mesures DAX complexes sur les pages de destination (enregistrez-les pour les détails d'exploration)
• Utilisez des signets pour les vues précalculées au lieu des calculs dynamiques
• Testez les temps de chargement des rapports à votre niveau de concurrence attendu, pas seulement pour un seul utilisateur

Pour les organisations mettant en œuvre des analyses intégrées, ECOSIRE fournit des services de conseil et de développement en architecture pour garantir des performances optimales dès le premier jour.

---

Considérations de sécurité pour les applications embarquées

Sécurité des jetons

Les jetons intégrés accordent l’accès au contenu Power BI. Traitez-les comme des informations d'identification sensibles :

• N'exposez jamais les jetons intégrés dans le code source ou les paramètres d'URL côté client.
• Générez des jetons côté serveur et fournissez-les via des points de terminaison API authentifiés
• Utilisez la durée de vie du jeton la plus courte (par défaut, 1 heure est raisonnable pour la plupart des applications)
• Implémenter une logique d'actualisation des jetons plutôt que de générer des jetons de longue durée
• Surveiller les modèles de génération de jetons pour détecter les anomalies (volume inhabituel, ID de rapport inattendus)

Validation de l'isolement des locataires

Pour les applications multi-locataires, validez en permanence l’isolation des locataires :

• Tests automatisés qui génèrent des jetons intégrés pour le locataire A et vérifient que les données du locataire B ne sont pas accessibles
• Journalisation des requêtes pour détecter les tentatives d'accès aux données entre locataires
• Audits de configuration RLS réguliers (les rôles RLS peuvent être modifiés dans Power BI Desktop et accidentellement affaiblis)
• Alerte sur les erreurs de filtre RLS (qui peuvent indiquer une mauvaise configuration)

Sécurité du réseau

• Restreindre l'accès de l'API REST Power BI aux plages IP connues à l'aide de l'accès conditionnel Azure AD
• Utiliser des points de terminaison privés pour les connexions de passerelle aux sources de données sur site
• Activer la journalisation d'audit dans le portail d'administration Power BI pour suivre tous les appels d'API et intégrer la génération de jetons
• Implémentez les en-têtes de politique de sécurité du contenu pour restreindre l'intégration d'iframe au domaine de votre application

---

##FAQ

Combien coûte Power BI Embedded pour une application SaaS comptant 10 000 utilisateurs ?

Le coût dépend des utilisateurs simultanés et non du nombre total d'utilisateurs. Si 5 % de vos 10 000 utilisateurs sont simultanés au pic (500 utilisateurs simultanés), vous aurez besoin d'une capacité d'environ F32 à environ 8 200 $ par mois (paiement à l'utilisation). Avec une réservation (engagement d'un an), cela tombe à environ 5 500 $ par mois. Votre coût réel peut être supérieur ou inférieur en fonction de la complexité du rapport, de la taille de l'ensemble de données et des modèles d'utilisation. Commencez par F8 pour un pilote, un test de charge avec une concurrence réaliste et une mise à l'échelle basée sur des mesures réelles.

Puis-je utiliser Power BI Embedded sans Azure ?

Power BI Embedded nécessite Azure AD pour l’authentification et la capacité Fabric/Embedded provisionnée via Azure. Votre application elle-même peut être hébergée n'importe où (AWS, GCP, sur site), mais les ressources Power BI doivent être dans Azure. Le principal du service ou le compte utilisateur principal doit être dans Azure AD et la capacité doit être une ressource Azure. Pour les organisations sans empreinte Azure existante, la configuration ajoute environ 2 à 4 heures de travail de configuration Azure et une gestion Azure continue minimale au-delà de la capacité elle-même.

Quelle est la différence entre les SKU Power BI Embedded A, les SKU EM et les SKU Fabric F ?

Les SKU A étaient la capacité Power BI Embedded d’origine, provisionnée via Azure. Les SKU EM constituaient une option de licence pour l'intégration interne avec Office 365. Les deux ont été remplacés par les SKU Fabric F, qui fournissent un modèle de capacité unifié pour toutes les charges de travail Power BI et Fabric. Les SKU F offrent une facturation à la seconde, une capacité de pause/reprise et une structure tarifaire plus simple. Pour les nouvelles implémentations, utilisez exclusivement les SKU F. Les clients SKU A existants doivent planifier la migration vers les SKU F pour bénéficier de meilleurs prix et de meilleures fonctionnalités.

Les utilisateurs peuvent-ils exporter des données à partir de rapports intégrés ?

Oui, mais vous contrôlez cela via les paramètres d'intégration. Le SDK JavaScript vous permet d'activer ou de désactiver les fonctionnalités d'exportation (Exporter vers Excel, PDF, PowerPoint) par rapport. Vous pouvez également implémenter une fonctionnalité d'exportation personnalisée via l'API Export, qui vous donne plus de contrôle sur le format, les filtres appliqués et la journalisation d'audit. Pour les données sensibles, désactivez l'exportation intégrée et fournissez votre propre mécanisme d'exportation qui applique des contrôles d'autorisation et un filigrane supplémentaires.

Comment gérer le développement de rapports dans un scénario intégré ?

Le développement de rapports suit le flux de travail Power BI standard : créez des rapports dans Power BI Desktop, publiez dans un espace de travail de développement, testez avec des exemples de jetons intégrés, passez en production via des pipelines de déploiement. La principale différence est que les rapports intégrés nécessitent des tests supplémentaires pour le comportement RLS, les performances en cas de concurrence, une mise en page réactive sur toutes les tailles d'écran et une interaction avec l'interface utilisateur de votre application. Établissez un pipeline CI/CD qui inclut une validation RLS automatisée et des tests de régression des performances dans le cadre de chaque déploiement de rapport.