Actualisation incrémentielle dans Power BI : gestion efficace de grands ensembles de données

Chaque implémentation de Power BI finit par se heurter au même mur : l'ensemble de données devient suffisamment volumineux pour que les actualisations complètes prennent trop de temps, consomment trop de ressources et dépassent les fenêtres de temps disponibles avant que les utilisateurs n'aient besoin des données.

Une table de transactions de 50 millions de lignes, entièrement actualisée toutes les 4 heures, ne prend pas seulement beaucoup de temps : elle gaspille des ressources en rechargeant des données qui n'ont pas changé. L'actualisation incrémentielle résout ce problème en chargeant uniquement les enregistrements nouveaux et modifiés, tout en conservant les données historiques qui ne changent pas. Si cela est fait correctement, un ensemble de données dont l'actualisation prenait auparavant 3 heures peut être mis à jour en moins de 10 minutes.

Ce guide couvre l'actualisation incrémentielle de Power BI, depuis les premiers principes jusqu'à la configuration avancée, y compris les erreurs courantes qui interrompent les implémentations et les meilleures pratiques qui les rendent fiables en production.

Points clés à retenir

• L'actualisation incrémentielle partitionne les ensembles de données par date, en chargeant uniquement les données récentes à chaque cycle d'actualisation
• Nécessite une colonne datetime sur la table de faits et deux paramètres Power Query (RangeStart, RangeEnd)
• Les données historiques sont conservées dans les anciennes partitions qui ne sont jamais réinterrogeées après le chargement initial
• Power BI Premium (ou Fabric) est requis pour une actualisation incrémentielle avec plus de 10 partitions
• L'option Détecter les modifications de données réduit encore le traitement en actualisant uniquement les partitions où les données ont été modifiées.
• Les tables hybrides (combinant l'importation et DirectQuery) permettent des données en temps réel ainsi que des partitions d'importation historiques
• Une configuration appropriée nécessite de comprendre le pliage de Power Query : les requêtes non pliables interrompent l'actualisation incrémentielle
• La surveillance de l'état des partitions via le point de terminaison XMLA et des outils tiers évite les pannes silencieuses

---

Comment fonctionne l'actualisation incrémentielle

Comprendre l’actualisation incrémentielle commence par comprendre comment Power BI partitionne les données.

Dans un modèle d'importation standard, l'intégralité de l'ensemble de données réside dans une seule partition. Chaque actualisation remplace complètement cette partition. Pour les petits ensembles de données, c'est très bien. Pour les grandes tables, cela crée les problèmes décrits ci-dessus.

L'actualisation incrémentielle divise la table de faits en plusieurs partitions, chacune couvrant une plage de dates spécifique :

• Partition 1 : 2020-01-01 au 2020-12-31 (historique, jamais actualisée)
• Partition 2 : 2021-01-01 au 2021-12-31 (historique, jamais rafraîchie)
• Partition 3 : 2022-01-01 au 2022-12-31 (historique, jamais rafraîchie)
• Partition 4 : 2023-01-01 au 2023-12-31 (historique, jamais rafraîchie)
• Partition 5 : 2024-01-01 au 2024-12-31 (rafraîchie mensuellement)
• Partition 6 : 2025-01-01 au 2025-03-31 (actualisée quotidiennement)
• Partition 7 : 2025-04-01 à actuel (rafraîchie toutes les heures ou à la demande)

À chaque actualisation planifiée, seules les partitions les plus récentes (5, 6 et 7 dans cet exemple) sont traitées. Les partitions historiques restent intactes depuis leur premier chargement. Cela signifie qu'un cycle d'actualisation ne traite qu'une fraction du total des données, ce qui réduit considérablement le temps, la mémoire et la charge du système source.

---

Prérequis et exigences

Avant de configurer l'actualisation incrémentielle, vérifiez que ces conditions préalables sont remplies :

Licence : l'actualisation incrémentielle est disponible dans Power BI Pro (avec des limitations) et Power BI Premium/Fabric (capacité complète). Avec Pro, vous pouvez configurer jusqu'à 10 périodes de rafraîchissement. Premium supprime cette limite et ajoute la fonctionnalité « détecter les modifications de données ».

Colonne Datetime : la table de faits doit avoir une colonne datetime (et non un entier clé de date – doit être un type datetime réel) que Power BI utilisera pour partitionner les données. Il s'agit généralement de la date de la transaction, de l'horodatage de l'événement ou de la colonne de création à.

Repliement de requête : la requête Power Query qui charge la table de faits doit prendre en charge le repliement de requêtes : la possibilité de traduire les étapes de transformation Power Query en une requête source (SQL, etc.) que le système source exécute. Si le repliement des requêtes s'interrompt, l'actualisation incrémentielle échoue silencieusement : elle charge toutes les données à chaque actualisation, ce qui va à l'encontre de l'objectif.

Prise en charge du système source : la source doit prendre en charge efficacement le filtrage par plage de dates. Une table source sans index sur la colonne datetime produira des actualisations lentes même avec une actualisation incrémentielle configurée, car chaque actualisation de partition effectuera une analyse complète de la table pour rechercher des enregistrements dans la plage de dates.

---

Configuration étape par étape

Étape 1 : Créez les paramètres Power Query requis

Dans Power BI Desktop, ouvrez l’éditeur Power Query. Accédez à Gérer les paramètres → Nouveau paramètre.

Créez deux paramètres exactement comme suit (les noms sont sensibles à la casse et doivent correspondre exactement) :

Ces paramètres doivent être de type Date/Heure et non Date. Ils seront remplacés par le moteur d'actualisation de Power BI au moment de l'exécution, mais ils ont besoin de valeurs par défaut valides pour le développement et les tests.

Étape 2 : Filtrez la table de faits à l'aide de ces paramètres

Dans l’éditeur Power Query, sélectionnez votre table de faits. Appliquez un filtre sur la colonne datetime en utilisant les paramètres :

= Table.SelectRows(Source, each [TransactionDate] >= RangeStart and [TransactionDate] < RangeEnd)

Cette étape de filtrage est critique : elle doit se replier sur la source de données. Pour vérifier le pliage, cliquez avec le bouton droit sur la dernière étape de la requête et vérifiez si « Afficher la requête native » est disponible. S'il est grisé, le pliage est rompu. Recherchez quelles étapes de transformation situées au-dessus brisent la chaîne de pliage.

Étape 3 : Vérifiez le pliage de la requête

Le repliement des requêtes est interrompu le plus souvent à cause de :

• Fonctions personnalisées qui ne peuvent pas être traduites en SQL
• Fusionner (joindre) deux requêtes dont l'une ou les deux ne se plient pas
• Certaines fonctions de transformation de texte (Text.Upper, Text.PadStart)
• Utilisation d'opérations de liste (List.Contains)
• Ajout d'une colonne d'index
• Certaines opérations de conversion de type

En cas d’échec du pliage, refactorisez la requête pour déplacer les opérations problématiques vers une étape ultérieure après le filtre de date – ou effectuez la transformation dans une vue de la base de données source plutôt que dans Power Query.

Étape 4 : Configurer la stratégie d'actualisation incrémentielle

Dans Power BI Desktop, cliquez avec le bouton droit sur la table de faits dans le volet Champs → Actualisation incrémentielle.

Les options de configuration :

• Stocker les lignes des N dernières années/mois/jours civils : Ceci définit la fenêtre historique totale conservée dans le modèle. Les données plus anciennes sont automatiquement supprimées du modèle (partitions supprimées).

• Actualiser uniquement les lignes au cours des N dernières années/mois/jours civils : ceci définit la fenêtre glissante qui est réactualisée à chaque cycle. Les données antérieures à cette fenêtre sont traitées comme historiques (immuables) et ne sont plus jamais actualisées.

• Détecter les modifications de données : (Premium uniquement) utilise une colonne datetime distincte (généralement une colonne « dernière modification ») pour détecter quelles partitions historiques ont modifié les données et retraite uniquement ces partitions.

Exemple de configuration pour une base de données transactionnelle avec 5 ans d'historique : - Stocker les lignes au cours des 5 dernières années

• Actualiser uniquement les lignes au cours des 3 derniers jours

Cela crée des partitions couvrant 5 années de données, mais seules les partitions des 3 derniers jours sont actualisées à chaque cycle.

Étape 5 : Publier et valider

Publiez le rapport sur le service Power BI. La première actualisation après la publication prendra plus de temps que les actualisations suivantes : elle charge toutes les données historiques et crée toutes les partitions pour la première fois. Ceci est attendu.

---

Configuration avancée : détecter les modifications de données

L'option « Détecter les modifications de données » dans Premium ajoute une autre couche d'efficacité. Il fonctionne en interrogeant une colonne désignée (généralement une colonne last_modified_date) pour déterminer si des enregistrements d'une partition historique ont été mis à jour. Seules les partitions dont les données ont réellement changé sont actualisées.

Sans détecter les changements de données : la fenêtre glissante de 3 jours est toujours actualisée, même si aucune donnée n'a changé au cours des 3 derniers jours.

Avec détection des modifications de données : le moteur d'actualisation vérifie si des enregistrements dans la fenêtre déroulante ont été modifiés avant de décider de traiter ou non chaque partition. Si les données du lundi ont été actualisées lundi soir et qu'aucun enregistrement n'a été modifié depuis, l'actualisation du mardi soir ignore la partition du lundi.

Ceci est particulièrement utile pour les scénarios dans lesquels :

• Les données sources sont écrites une seule fois et rarement mises à jour (événements immuables en ajout uniquement)
• La fenêtre glissante est grande (par exemple, 30 jours) mais la plupart des jours ne comportent aucun changement
• La capacité de requête du système source est limitée

La colonne de détection des modifications de données doit être indexée dans la base de données source : le moteur d'actualisation interroge cette colonne pour chaque partition à chaque cycle d'actualisation.

---

Tables hybrides : données en temps réel + historiques

Power BI Fabric/Premium introduit les tables hybrides : une puissante combinaison de mode d'importation (partitions historiques) et de mode DirectQuery (données actuelles). Cela permet des tableaux de bord qui affichent les données mises à jour à la minute en cours ainsi que les données d'importation historiques.

Dans une configuration de table hybride :

• Les partitions historiques (anciennes et plus anciennes) sont en mode importation : rapides, mises en cache et entièrement agrégées
• La partition actuelle est en mode DirectQuery — les requêtes sont exécutées en direct sur la base de données source

L'expérience utilisateur est transparente : les requêtes couvrent les deux modes de manière transparente. Une requête « ventes de cette semaine par rapport à la semaine dernière » extrait les données d'hier de la partition d'importation et les données d'aujourd'hui via DirectQuery, en les combinant en un seul résultat.

Considérations concernant les tables hybrides :

• Les performances de DirectQuery dépendent entièrement des performances de la base de données source : une base de données lente signifie des requêtes lentes en cours.
• La partition DirectQuery ne bénéficie pas des optimisations du mode import (pas de compression VertiPaq, pas de pré-agrégations)
• Nécessite un espace de travail Premium ou Fabric

---

Surveillance de l'état de l'actualisation incrémentielle

Les échecs d'actualisation incrémentielle sont souvent silencieux : le modèle s'affiche comme « actualisé avec succès » même si certaines partitions échouent ou reviennent à l'actualisation complète. La surveillance est essentielle à la fiabilité de la production.

Inspection des points de terminaison XMLA : Power BI Premium expose un point de terminaison XMLA auquel des outils tels que SQL Server Management Studio (SSMS), Tabular Editor ou Azure Analysis Services peuvent se connecter. À partir de là, vous pouvez interroger les métadonnées de la partition pour voir l'heure de la dernière actualisation de chaque partition et si des partitions sont dans un état d'erreur.

Éditeur tabulaire 2 (gratuit) : connectez-vous à l'espace de travail Premium via XMLA et inspectez la table des partitions dans le modèle. Chaque partition affiche son nom, sa plage de dates, l'horodatage de la dernière actualisation et son état. Il s'agit de l'outil le plus pratique pour diagnostiquer les problèmes d'actualisation incrémentielle.

Journal d'activité Power BI : le journal d'activité de l'administrateur enregistre les opérations d'actualisation, y compris les partitions traitées et les erreurs éventuelles. Disponible via l'API REST Power BI.

Modèles d'échec courants :

---

Vérification du pliage des requêtes en pratique

Le repliement des requêtes est la raison la plus courante pour laquelle l’actualisation incrémentielle ne parvient pas à fournir les gains de performances promis. Voici comment diagnostiquer et réparer les cassures de pliage courantes.

Test 1 : Afficher la requête native. Après avoir ajouté l’étape de filtre RangeStart/RangeEnd dans Power Query, cliquez avec le bouton droit sur l’étape. Si « View Native Query » est disponible et affiche une requête SQL avec une clause WHERE filtrant la plage de dates, le pliage fonctionne.

Test 2 : Vérifiez le SQL généré. La requête native doit contenir quelque chose comme :

WHERE [TransactionDate] >= @RangeStart AND [TransactionDate] < @RangeEnd

Si la clause WHERE est manquante, le pliage est interrompu et le filtre est appliqué dans le moteur de Power Query après le chargement de toutes les données de la source.

Restauration du pliage : si une transformation personnalisée a interrompu le pliage, déplacez-la après l'étape de filtrage de date ou effectuez la transformation dans une vue SQL de la base de données source et connectez Power BI à la vue au lieu de la table.

---

Questions fréquemment posées

L'actualisation incrémentielle fonctionne-t-elle avec toutes les sources de données ?

L'actualisation incrémentielle fonctionne avec n'importe quelle source de données prenant en charge le regroupement de requêtes et le filtrage de plages de dates, notamment SQL Server, Azure SQL, PostgreSQL, Snowflake, BigQuery, Azure Synapse et Databricks. Cela ne fonctionne pas bien avec les sources qui ne prennent pas en charge le regroupement de requêtes (fichiers Excel, CSV plat, certaines API REST) ​​— dans ces cas, une actualisation complète est toujours requise. Pour les sources non pliables, la solution de contournement recommandée est de transférer les données dans une base de données SQL avant la connexion à Power BI.

Quelle licence Power BI est requise pour l'actualisation incrémentielle ?

L’actualisation incrémentielle est disponible dans Power BI Pro (limitée à 10 périodes d’actualisation), Power BI Premium par capacité, Power BI Premium par utilisateur (PPU) et les capacités Microsoft Fabric. La fonctionnalité « Détecter les modifications de données » et les tables hybrides nécessitent Premium ou Fabric. Pour la plupart des implémentations d'entreprise comportant plus de 10 partitions historiques, Premium ou Fabric sont requis.

Comment l'actualisation incrémentielle gère-t-elle les données arrivant tardivement ?

Les données arrivant tardivement (les enregistrements arrivant après la date de leur transaction (par exemple, une transaction de décembre arrivant dans l'extrait de données de janvier)) sont traitées en définissant la fenêtre d'actualisation continue suffisamment large pour capturer les arrivées tardives. Si les données peuvent arriver avec jusqu'à 7 jours de retard, la définition de la fenêtre glissante sur 14 jours garantit que les arrivées tardives sont capturées lorsque la partition concernée est à nouveau actualisée. Alternativement, l'option de détection des modifications de données avec une colonne de dernière modification capture les arrivées tardives quel que soit le paramètre de fenêtre glissante.

L'actualisation incrémentielle peut-elle fonctionner sur les tables de dimensions, pas seulement sur les faits ?

L'actualisation incrémentielle est conçue pour les grandes tables de faits et nécessite une colonne de filtre datetime. La plupart des tables de dimensions (produits, clients, emplacements) n'ont pas de colonne de partition datetime appropriée et sont suffisamment petites pour qu'une actualisation complète soit appropriée. Pour les tables de dimension à évolution lente qui sont devenues volumineuses (tables client avec plus de 50 millions de lignes), une approche alternative consiste à utiliser des vues SQL dans la base de données source pour filtrer les enregistrements récemment modifiés et gérer la conservation de l'historique dans la couche de base de données plutôt que dans Power BI.

Comment puis-je voir quelles partitions existent dans mon modèle d'actualisation incrémentielle ?

Le moyen le plus simple consiste à connecter Tabular Editor (version gratuite 2) à votre espace de travail Power BI Premium via le point de terminaison XMLA. Sous Tables → [votre table] → Partitions, vous verrez toutes les partitions créées avec leurs plages de dates et les horodatages du dernier traitement. SQL Server Management Studio (SSMS) se connecte également via XMLA et affiche les détails de la partition dans l'Explorateur d'objets.

Que se passe-t-il si l'actualisation incrémentielle échoue en cours de route ?

Si une actualisation échoue à mi-chemin, Power BI réessaye les partitions défaillantes. Les partitions qui se sont terminées avec succès avant l'échec ne sont pas retraitées : seules les partitions ayant échoué sont réessayées. Ce comportement de nouvelle tentative signifie que l’actualisation incrémentielle est plus résiliente aux pannes transitoires du système source que l’actualisation complète. Si une partition échoue systématiquement, elle reste dans son dernier état chargé avec succès tandis que les nouvelles partitions continuent d'être actualisées normalement.

---

Prochaines étapes

L’actualisation incrémentielle est fondamentale pour toute implémentation de Power BI qui gère de grands ensembles de données transactionnelles. Bien faire les choses dès le départ – avec un pliage approprié des requêtes, des fenêtres glissantes appropriées et une surveillance – évite les problèmes de performances qui obligent à une réarchitecture coûteuse ultérieurement.

Les services d'optimisation des performances Power BI d'ECOSIRE incluent la conception et la mise en œuvre d'actualisations incrémentielles pour les ensembles de données d'entreprise à grande échelle. Contactez-nous pour évaluer votre architecture de rafraîchissement actuelle et identifier les opportunités d'optimisation.