Actualisation des données dans Power BI : planifiée et incrémentielle

Au début d’un projet, actualiser un rapport est instantané : quelques milliers de lignes se rechargent en un clin d’œil. Puis les données s’accumulent — des années d’historique, des millions de transactions — et le rafraîchissement quotidien se met à durer dix, vingt, trente minutes, à consommer de la mémoire et parfois à échouer sur une limite de temps. Pourtant, l’historique d’il y a trois ans ne change jamais : pourquoi le recharger chaque nuit ? L’actualisation incrémentielle répond exactement à ce gaspillage, en ne rechargeant que ce qui a bougé. Ce tutoriel part de l’actualisation planifiée simple pour aller jusqu’à l’incrémentielle, étape par étape.

Ce tutoriel s’inscrit dans une série sur Power BI et Microsoft Fabric ; le guide de référence Power BI et Microsoft Fabric en donne la vue d’ensemble. Il prolonge naturellement la mise en place de la passerelle de données et suppose une bonne maîtrise de Power Query et du query folding.

Prérequis

• Un rapport publié dans le service Power BI, avec un modèle relié à une source qui supporte le query folding (base SQL, par exemple).
• Une table volumineuse comportant une colonne de date ou de date/heure.
• Niveau : intermédiaire à avancé. Les notions de paramètres Power Query et de query folding sont indispensables.
• Temps estimé : 70 à 90 minutes.

Étape 1 — Mettre en place l’actualisation planifiée

Avant l’incrémentiel, posons la brique de base : faire en sorte que le rapport se rafraîchisse seul à heure fixe. Dans le service Power BI, ouvrez les Paramètres du modèle sémantique, puis déroulez Actualisation planifiée. Activez-la, choisissez la fréquence et les créneaux horaires, et indiquez une adresse pour recevoir les alertes en cas d’échec.

Si la source est interne, ce rafraîchissement passera par la passerelle configurée auparavant. Le signal de bon fonctionnement se lit dans l’historique d’actualisation : chaque exécution réussie y apparaît horodatée. Cette planification suffit tant que les volumes restent modestes. Mais dès que la table grossit, l’actualisation complète montre ses limites — et c’est là que l’incrémentiel devient nécessaire.

Étape 2 — Comprendre la limite de l’actualisation complète

Par défaut, chaque actualisation recharge l’intégralité des données, y compris l’historique ancien qui, par nature, ne bouge plus. Sur une table de plusieurs millions de lignes, cela signifie retélécharger et recompresser des années de données figées à chaque rafraîchissement. Le coût est triple : durée excessive, consommation mémoire élevée, et risque d’atteindre les limites de temps imposées par la plateforme.

Ces limites sont concrètes : pour un modèle servi par une licence Pro, une actualisation doit se terminer en environ deux heures ; en capacité, la marge monte à environ cinq heures. Dépasser ce plafond fait échouer le rafraîchissement. L’actualisation incrémentielle résout ce problème en distinguant deux zones : un historique archivé qu’on ne retouche plus, et une fenêtre récente, seule réellement rechargée. On obtient des rafraîchissements bien plus rapides et bien plus fiables.

Étape 3 — Créer les paramètres RangeStart et RangeEnd

L’incrémentiel repose sur deux paramètres aux noms imposés, que Power BI reconnaît spécifiquement. Leur orthographe et leur casse sont strictes : ils doivent s’appeler exactement RangeStart et RangeEnd, et être de type date/heure. C’est par eux que Power BI saura quelle tranche de données rafraîchir.

Dans l’éditeur Power Query, allez dans Gérer les paramètres > Nouveau paramètre. Créez RangeStart de type Date/Heure, avec une valeur courante quelconque (par exemple le 1er janvier de l’année en cours), puis créez de même RangeEnd. Ces valeurs de test ne servent qu’à la conception ; en production, c’est le service qui les pilotera automatiquement pour chaque partition. Une erreur de nom ou de type ici, et l’option d’incrémentiel restera grisée plus tard : vérifiez bien l’orthographe exacte.

Étape 4 — Filtrer la table avec les paramètres

Les paramètres ne servent à rien tant qu’ils ne filtrent pas réellement la table. On applique donc sur la colonne de date un filtre borné par RangeStart et RangeEnd. L’idiome consacré, qui évite tout chevauchement de bornes, est « supérieur ou égal au début, strictement inférieur à la fin » :

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

Ce filtre restreint la table à la fenêtre comprise entre les deux paramètres. La borne de fin strictement inférieure (< et non <=) garantit qu’une même journée ne tombe jamais dans deux partitions à la fois. Après application, l’aperçu ne montre que les lignes de la plage de test : c’est normal et attendu. Le point crucial, vérifié à l’étape 6, est que ce filtre doit se « replier » vers la source pour que l’incrémentiel soit efficace.

Étape 5 — Définir la stratégie d’actualisation incrémentielle

Vient maintenant le cœur du dispositif : déclarer à Power BI comment découper le temps. De retour dans la vue principale, faites un clic droit sur la table concernée et choisissez Actualisation incrémentielle. Une boîte de dialogue propose deux durées à régler.

La première, archiver les données commençant avant, définit la profondeur d’historique conservée — par exemple cinq ans. La seconde, actualiser les données commençant avant, définit la fenêtre récente réellement rechargée à chaque exécution — par exemple les dix derniers jours. Concrètement, avec ces réglages, Power BI garde cinq ans d’historique mais ne rafraîchit que les dix derniers jours à chaque actualisation. Tout le reste, figé, n’est jamais retouché. Activez l’option, validez, et la stratégie est en place côté conception. Choisissez la fenêtre récente assez large pour couvrir les corrections tardives habituelles de vos données, sans excès qui annulerait le gain.

Étape 6 — Vérifier que le filtre se replie sur la source

C’est l’étape qu’il ne faut surtout pas sauter, car elle conditionne tout le bénéfice. Si le filtre de date ne se replie pas en requête native sur la source, Power BI téléchargera l’intégralité des données avant de filtrer en local — exactement ce qu’on cherchait à éviter. L’incrémentiel deviendrait alors plus lent qu’une actualisation classique.

Dans l’éditeur Power Query, faites un clic droit sur l’étape de filtre et vérifiez que Afficher la requête native est disponible : sa présence prouve que le filtre se traduit en SQL exécuté côté serveur. Si l’option est absente, remontez la chaîne d’étapes : une transformation non foldable placée avant le filtre casse le pliage. Réorganisez alors la requête pour que le filtre de date intervienne le plus tôt possible, sur des étapes qui se replient. Ce contrôle est la garantie que chaque partition ne demandera à la base que ses propres lignes.

Étape 7 — Publier et observer le partitionnement

Une fois la stratégie définie, c’est la publication qui la rend opérationnelle. Publiez le rapport dans le service. Lors du tout premier rafraîchissement, Power BI exécute une opération plus longue que d’habitude : il découpe la table en partitions (par mois ou par jour selon vos réglages) et charge l’historique complet une dernière fois. C’est un investissement initial unique.

Les rafraîchissements suivants, eux, ne touchent que les partitions de la fenêtre récente : ils deviennent spectaculairement plus rapides. Vous pouvez confirmer ce comportement en observant l’historique d’actualisation, où la durée chute nettement après la première exécution. C’est le signal que l’incrémentiel fonctionne : la plateforme ne recharge plus que le strict nécessaire, et les limites de durée cessent d’être un risque.

Étape 8 — Aller plus loin : détecter les changements et le temps réel

Deux options avancées affinent encore le dispositif. La première, détecter les changements de données, demande à Power BI de ne rafraîchir une partition récente que si une colonne témoin (un horodatage de dernière modification) a effectivement changé. On évite ainsi de recharger des journées qui n’ont reçu aucune écriture, économisant davantage de ressources.

La seconde concerne les besoins de fraîcheur extrême. En combinant l’archive historique avec une partition de données en direct, on obtient une table hybride : l’historique est importé pour la vitesse, tandis que les données les plus récentes sont interrogées en direct sur la source. L’utilisateur voit alors à la fois la profondeur de l’historique et la fraîcheur de l’instant. Ces options se règlent dans la même boîte de dialogue d’actualisation incrémentielle ; réservez-les aux cas qui le justifient réellement, car elles ajoutent de la complexité.

Étape 9 — Surveiller et respecter les limites

Un dispositif incrémentiel bien réglé reste à surveiller dans le temps. La fenêtre récente, par définition petite, doit rester compatible avec les plafonds de durée de votre licence — environ deux heures en Pro, environ cinq heures en capacité. Tant que vous ne rafraîchissez qu’une fenêtre étroite, vous êtes très loin de ces limites, mais une fenêtre mal dimensionnée peut les rapprocher.

Prenez l’habitude de consulter périodiquement l’historique d’actualisation pour repérer toute dérive de durée, signe qu’un volume a changé d’échelle ou qu’un pliage s’est cassé après une modification de la requête. Mettez aussi en place les alertes par e-mail sur échec, afin d’être prévenu sans surveiller manuellement. Un incrémentiel surveillé est un incrémentiel qui tient ses promesses sur la durée, là où un dispositif posé puis oublié finit par se dégrader silencieusement.

Déclencher une actualisation à la demande

L’actualisation planifiée couvre le rythme régulier, mais certains événements appellent un rafraîchissement immédiat : une clôture comptable terminée plus tôt que prévu, une correction de données urgente, la fin d’un import nocturne. Power BI offre plusieurs façons de déclencher une actualisation hors planning, qu’il est utile de connaître pour ne pas attendre le prochain créneau.

Le moyen le plus simple est le bouton Actualiser maintenant, accessible depuis le modèle sémantique dans le service : il relance immédiatement le même mécanisme que la planification, incrémentiel compris. Pour les besoins automatisés, le service expose une API REST qui permet de déclencher une actualisation depuis un script ou un outil d’orchestration, par exemple à la toute fin d’un traitement de chargement de données. Les organisations qui disposent d’une capacité peuvent aller plus loin grâce au point de terminaison XMLA, qui autorise un rafraîchissement ciblé partition par partition, sans recharger toute la fenêtre récente. Ce chaînage « la donnée arrive, puis le rapport se rafraîchit » garantit que les utilisateurs voient toujours l’information la plus fraîche dès qu’elle est disponible, sans dépendre d’un horaire fixe. C’est le degré de maturité vers lequel tendent les déploiements sérieux, une fois la planification de base maîtrisée.

Erreurs fréquentes

Tutoriels liés

• Importer et nettoyer avec Power Query — comprendre le query folding, indispensable ici.
• Connecter Power BI à SQL Server via la passerelle — le canal des actualisations sur source interne.
• Publier et partager dans le service — où se planifient les rafraîchissements.

Références

• Documentation « Configurer l’actualisation incrémentielle pour les modèles sémantiques Power BI » (Microsoft Learn).
• Guide « Actualisation incrémentielle et données en temps réel » et « Tables hybrides ».
• Documentation sur le query folding dans Power Query.

Questions fréquentes

L’actualisation incrémentielle exige-t-elle une licence Premium ?
Non. Elle fonctionne aussi avec une licence Pro. La principale différence tient aux plafonds de durée : environ deux heures en Pro, environ cinq heures en capacité.

Pourquoi mes paramètres doivent-ils s’appeler exactement RangeStart et RangeEnd ?
Ce sont des noms réservés que Power BI reconnaît pour piloter le partitionnement. Toute autre orthographe, ou une mauvaise casse, empêche l’activation de l’incrémentiel.

Que se passe-t-il si mon filtre ne se replie pas ?
Power BI télécharge toutes les données puis filtre localement, ce qui annule le bénéfice. Le repli du filtre vers la source est la condition d’efficacité de tout le dispositif.

Puis-je utiliser l’incrémentiel sur un fichier Excel ou CSV ?
En pratique, non de façon efficace : ces sources ne supportent pas le query folding. L’incrémentiel donne sa pleine valeur sur des bases relationnelles capables de filtrer côté serveur.