L’un des angles morts les plus fréquemment sous-estimés de Power BI concerne la conservation des données d’usage. Que ce soit :
- l’historique d’activité (Activity Log),
- l’historique de rafraîchissement des jeux de données
- ou l’historique des accès et permissions,
Power BI applique nativement des durées de rétention limitées, de 30 à 90 jours selon les journaux et rapports concernés.
Cette contrainte, rarement mise en avant lors de l’adoption initiale de l’outil, devient un problème structurel dès que l’organisation cherche à professionnaliser sa gouvernance BI.
Les données d’usage disponibles nativement
Power BI met à disposition, au niveau de chaque rapport, un rapport de métriques d’usage. Selon la version de ce rapport et la métrique consultée, il couvre une fenêtre glissante de 30 ou de 90 jours. Au-delà de cette fenêtre, les données correspondantes ne sont plus consultables : il n’est donc pas possible, nativement, de suivre l’usage d’un rapport sur une année complète. De même, le journal d’activité de Power BI, accessible via l’API Admin, ne remonte que 30 jours d’historique.
Les conséquences concrètes pour les équipes BI
Impossible d’analyser une tendance annuelle
Un rapport peut sembler peu utilisé sur les 30 derniers jours simplement parce qu’il est consulté trimestriellement par la direction financière lors de la clôture. Sans historique à long terme, impossible de distinguer un rapport réellement obsolète d’un rapport à faible fréquence mais à forte valeur métier. Ce point est détaillé dans notre article sur l’analyse d’usage.
Impossible de reconstituer un incident ou de prouver un contrôle d’accès
Si un incident de sécurité ou une fuite de données suspectée est détecté quatre mois après les faits (ce qui n’est pas rare), les journaux natifs ne permettent plus de reconstituer qui a modifié les permissions ou exporté des données à l’époque des faits. La même limite s’applique aux audits de conformité : dans les secteurs réglementés (finance, santé, assurance), les auditeurs demandent régulièrement des preuves de contrôle d’accès sur une période de six à douze mois, que l’organisation ne peut pas produire pour ses rapports Power BI sans historisation externe.
Impossible de mesurer l’adoption de la BI dans le temps
Pour justifier un investissement en formation, en licences ou en nouvelles capacités Fabric, une direction IT doit pouvoir montrer l’évolution de l’adoption de la Business Intelligence sur plusieurs exercices comptables : une donnée qui n’existe simplement pas au-delà de la fenêtre de rétention native.
Les solutions palliatives natives et leurs limites
Microsoft propose d’exporter les journaux d’activité via l’API Power BI Admin (endpoint getActivityEvents) ou de les envoyer vers un espace de travail Azure Log Analytics via l’intégration native disponible dans les paramètres tenant. Cette approche fonctionne techniquement, mais elle exige un projet d’ingénierie à part entière :
- Développement d’un script planifié pour extraire les journaux avant expiration (l’extraction doit être quotidienne, sans interruption, sous peine de trou définitif dans l’historique).
- Mise en place d’un espace de stockage externe (Data Lake, base de données, Log Analytics) avec gestion du cycle de vie.
- Construction de rapports de restitution exploitables par les équipes non techniques.
- Maintenance dans la durée : gestion des évolutions d’API, surveillance des échecs d’extraction, alertes en cas d’interruption.
C’est un projet dimensionné pour une équipe de data engineering, rarement une priorité pour des équipes BI déjà pleinement sollicitées par la production de rapports métier.
Vers une historisation automatisée et actionnable
La bonne pratique consiste à capter l’historique en continu, dès le premier jour de déploiement de Power BI dans l’organisation, plutôt que de tenter de le reconstituer après coup, ce qui est techniquement impossible une fois la fenêtre de rétention Microsoft dépassée. Un historique exploitable doit permettre de croiser plusieurs dimensions simultanément : qui a consulté quoi, quand, avec quelle fréquence, et comment cet usage évolue dans le temps, sans nécessiter une compétence technique pour interroger les données brutes.
Questions fréquentes
Quelle est la durée de rétention exacte des journaux Power BI ?
Elle varie selon le type de journal : dans Power BI, le journal d’activité accessible via l’API Admin couvre 30 jours glissants, et les rapports de métriques d’usage 30 ou 90 jours selon leur version. Ces durées sont définies par Microsoft et peuvent évoluer ; il est recommandé de vérifier la documentation officielle à jour plutôt que de se fier à une valeur figée.
Peut-on récupérer un historique déjà expiré ?
Non. Une fois la fenêtre de rétention dépassée, les données d’activité correspondantes ne sont plus accessibles via les API Microsoft, quelle que soit la méthode employée. C’est pourquoi la mise en place d’une collecte continue le plus tôt possible est essentielle.
L’historisation externe pose-t-elle un risque de sécurité supplémentaire ?
Toute donnée exportée hors de Power BI Service doit être sécurisée selon les mêmes standards que la donnée source (chiffrement, contrôle d’accès, conformité). C’est un point à valider avec l’équipe sécurité lors du choix d’une solution d’historisation, qu’elle soit développée en interne ou fournie par un éditeur tiers.
Cette limite d’historique est l’un des sept signaux de perte de gouvernance détaillés dans notre article «Gouvernance Power BI : les 7 signes que votre environnement vous échappe».
Voir aussi «Analyse d’usage Power BI» pour comprendre comment exploiter un historique long terme.
