Un rapport doit être classé comme inutilisé après vérification croisée de ses consultations, de son mode de diffusion, de son actualisation et de sa dépendance à une décision métier. Dans Power BI, les métriques intégrées couvrent 90 jours seulement. Pour un arbitrage de purge ou de migration, il faut donc compléter ce signal par les journaux d’audit et une validation des propriétaires.
En bref
- Un rapport sans vue sur 90 jours n’est pas automatiquement supprimable, car son usage peut être trimestriel, annuel ou réalisé hors du service Power BI.
- Les métriques d’utilisation Power BI sont utiles pour une première Identification, mais elles excluent plusieurs scénarios d’incorporation et peuvent différer des journaux d’audit.
- Un rapport rarement ouvert mais alimentant une diffusion réglementaire, un export planifié ou une décision financière doit rester dans le périmètre de contrôle.
- La décision doit porter sur trois issues distinctes : conserver, reconstruire ou retirer du parc documentaire et technique.
Ce contenu s’adresse aux responsables de Business Intelligence qui doivent auditer un parc de Rapports BI avant une migration, une réduction de dette technique ou une revue de licences. Il traite l’usage des rapports, pas la protection des données personnelles ni les clauses contractuelles de conservation, qui relèvent respectivement de votre DPO et de votre direction juridique.
Quels Rapports BI peuvent être considérés comme jamais consultés ?
Un rapport jamais consulté n’est pas seulement un objet affichant zéro ouverture dans un écran de supervision. C’est un objet dont l’usage réel ne peut pas être démontré sur une période adaptée à sa finalité. Un tableau de bord commercial quotidien, non ouvert depuis trente jours, mérite une analyse immédiate. Un état de clôture ouvert chaque trimestre demande un historique plus long.
Le seuil de 90 jours correspond au périmètre standard du rapport de métriques d’utilisation Power BI. Microsoft indique que ce rapport prédéfini présente les données de consultation des 90 derniers jours et qu’il est mis à jour quotidiennement. Cette limite est décrite dans la documentation officielle sur les métriques d’utilisation Power BI, consultée le 18 mars 2026. Elle suffit pour repérer les objets silencieux, pas pour décider seule de leur suppression.
La première distinction porte sur le type de silence. Un rapport peut être absent des métriques parce que personne ne l’ouvre. Il peut aussi être consulté dans un scénario que l’outil ne compte pas. Microsoft précise que les métriques ne suivent pas les rapports incorporés avec le flux où l’utilisateur ou l’application possède ses informations d’identification, ni les contenus publiés sur le web. Un portail interne intégrant un rapport peut donc rester fréquenté alors que le rapport d’usage affiche zéro vue.
Le silence technique ne prouve pas l’inutilité métier
Les Rapports inutilisés se répartissent souvent en quatre familles. La première regroupe les doublons : même indicateur, même périmètre, mais un ancien lien ou une ancienne mise en page. La deuxième contient les objets conçus pour un projet arrêté. La troisième rassemble les états périodiques, parfois ouverts une seule fois par an. La dernière famille est plus risquée : des rapports encore liés à des exports, à une application ou à un abonnement, sans que leurs propriétaires en connaissent la dépendance.
La consultation des rapports doit donc être rapprochée de leur fréquence métier attendue. Un rapport de suivi de production peut être considéré comme inactif après 60 jours sans ouverture si son propriétaire confirme une utilisation quotidienne attendue. Pour un rapport de bilan annuel, une absence de vue sur 90 jours ne démontre rien. Il faut examiner au moins quinze mois, afin de couvrir une campagne complète et sa période de préparation.
Le tableau suivant permet de classer les objets avant toute décision. Les seuils proposés sont des règles de tri pour lancer l’enquête. Ils ne remplacent pas l’accord du métier ni l’examen des flux aval.
| Type de rapport | Fenêtre d’observation | Signal de faible usage | Vérification avant retrait |
|---|---|---|---|
| Tableau de bord opérationnel | 90 jours | Aucune vue et aucun visiteur unique | Contrôler les abonnements, liens d’application et exportations |
| Rapport mensuel | 6 mois | Aucune ouverture sur deux cycles de diffusion | Valider auprès du propriétaire métier et de la finance |
| État trimestriel | 15 mois | Aucune ouverture sur quatre échéances | Vérifier les archives, les exports et les procédures de clôture |
| Rapport annuel ou réglementaire | 24 mois | Absence de preuve d’usage sur deux exercices | Faire valider la conservation par les fonctions compétentes |
Ce tableau est construit pour l’audit d’un parc décisionnel. Il ne prétend pas fixer une durée légale de conservation. Cette question sort du périmètre de la Gestion des données décisionnelles et doit être portée par les responsables compétents.
Un rapport classé silencieux doit rester visible dans l’inventaire avec son identifiant technique, son espace de travail, son modèle sémantique, son propriétaire et sa date de dernière preuve d’usage. La suppression immédiate efface souvent l’information qui aurait permis de comprendre une règle de gestion enfouie. L’étape suivante consiste donc à mesurer l’usage avec les bons compteurs.
Comment mesurer la consultation des rapports dans Power BI ?
Power BI fournit un rapport de métriques d’utilisation directement depuis l’espace de travail qui contient le contenu à examiner. L’utilisateur disposant des droits requis ouvre les options du rapport puis sélectionne l’affichage des métriques d’utilisation. Le service génère le rapport lors du premier accès. Microsoft précise que l’accès aux données nécessite une licence Fabric ou Power BI Premium par utilisateur pour consulter les métriques, tandis que la collecte couvre l’utilisation de tous les utilisateurs, quelle que soit leur licence.
Cette donnée a été relevée le 18 mars 2026 dans la documentation Microsoft Learn consacrée aux rapports de métriques d’utilisation. L’administrateur Fabric peut activer ou désactiver cette fonction et peut masquer les données nominatives. Lorsque cette fonction est désactivée au niveau du locataire, l’absence de métriques ne prouve donc aucune absence de consultation.
Les quatre compteurs à extraire pour l’analyse des rapports
Le nombre total de vues est le premier compteur, mais il ne doit jamais être lu seul. Une seule personne peut recharger plusieurs fois la même page sans que cela établisse une diffusion large. Le nombre de visiteurs uniques apporte une indication plus solide sur l’audience réelle. Le rapprochement entre les deux permet de distinguer un rapport de pilotage régulièrement utilisé par un petit groupe d’un objet ouvert une fois par curiosité.
Le segment par page de rapport est particulièrement utile. Une page peu consultée dans un rapport très ouvert n’est pas forcément à supprimer. Elle peut être la seule page mobilisée pendant une réunion mensuelle. À l’inverse, une page jamais ouverte pendant plusieurs cycles de gestion mérite d’être soumise au propriétaire, surtout lorsqu’elle alourdit le modèle ou maintient des mesures devenues sans objet.
Le segment par plateforme aide aussi à repérer une mauvaise hypothèse de conception. Si un tableau de bord est principalement consulté sur mobile, une page conçue pour un écran large peut être abandonnée à cause de sa lisibilité. La cause n’est pas l’indicateur, mais sa restitution. Dans ce cas, retirer le rapport serait une mauvaise décision ; il faut d’abord revoir sa présentation et confirmer le besoin.
La copie modifiable du rapport d’utilisation constitue un moyen de passer d’une analyse isolée à un Suivi des rapports sur l’ensemble d’un espace de travail. Microsoft indique qu’une copie peut être enregistrée puis modifiée, et que le modèle sémantique sous-jacent contient les métriques de tous les rapports ou tableaux de bord de l’espace concerné. Une fois le filtre ReportGuid retiré, l’équipe peut comparer tous les contenus publiés au même endroit.
- Exporter l’inventaire des rapports, des tableaux de bord, des modèles sémantiques et des espaces de travail.
- Créer ou enregistrer une copie du rapport de métriques pour chaque espace de travail contrôlé.
- Supprimer le filtre limitant l’analyse au seul rapport depuis lequel les métriques ont été ouvertes.
- Classer les objets selon les vues, les visiteurs uniques, les pages ouvertes et la fréquence métier attendue.
- Transmettre la liste des candidats au retrait à un propriétaire métier nommé, avec une date limite de réponse.
Cette méthode évite le tri à l’intuition. Elle ne compense pas les limites de la mesure. Microsoft signale notamment que des connexions instables, des bloqueurs de contenu ou des événements côté client peuvent entraîner un sous-comptage. Les changements de page peuvent également gonfler certaines mesures sans générer une nouvelle demande au service.
Il faut donc garder les métriques d’usage dans leur rôle : elles servent à orienter l’enquête. Les journaux d’audit et les dépendances techniques servent à confirmer ou à infirmer le constat.
Pourquoi les métriques d’utilisation ne suffisent-elles pas à identifier les rapports inutilisés ?
Un rapport de métriques mesure un comportement de consultation côté client. Les journaux d’audit recensent des activités observées par le service. Cette différence de collecte explique que les chiffres ne coïncident pas toujours. Microsoft l’écrit explicitement : les API et les journaux utilisent des données du service Power BI, tandis que les métriques d’utilisation sont collectées côté client.
Pour l’Identification des Rapports inutilisés, le journal d’audit doit être traité comme la source de confirmation pour les événements disponibles. Il permet de vérifier qu’un rapport a été ouvert, modifié, partagé ou supprimé dans une période donnée. Il ne restitue pas tous les détails de navigation proposés par les métriques. Microsoft précise notamment que les vues de pages de rapport ne sont pas présentes dans les journaux d’audit.
Les cas où zéro vue est un faux négatif
Les rapports intégrés dans une application interne forment le premier cas limite. L’utilisateur peut consommer l’information sans ouvrir powerbi.com, selon le mode d’intégration retenu. Les métriques standard ne couvrent pas tous ces scénarios. Il faut demander au propriétaire de l’application comment il contrôle l’accès, puis rechercher les traces au niveau de l’application ou du service.
Les rapports distribués par abonnement demandent une vérification distincte. Un destinataire peut lire un export PDF ou Excel joint à un message sans ouvrir le rapport source. Ce comportement peut prouver une utilité du contenu, mais il peut aussi révéler que le rapport interactif ne répond plus aux habitudes de travail. La réponse ne consiste pas toujours à conserver la publication telle quelle. Elle peut être de remplacer le rapport par un état paginé si le besoin est strictement documentaire.
La question devient concrète lors d’une sortie de BusinessObjects. Un Web Intelligence ouvert rarement, mais exporté chaque mois, ne doit pas être évalué avec les mêmes métriques qu’un tableau de bord interactif. Le rapprochement entre l’ancien rapport et son équivalent cible est détaillé dans cette analyse de la reprise d’un Webi vers un rapport paginé Power BI. Les objets à conserver doivent être classés selon leur mode réel de consommation, pas selon leur apparence technique.
Les dépendances de données constituent un autre piège. Un rapport peut ne recevoir aucune visite tout en utilisant un modèle sémantique partagé avec des rapports actifs. Supprimer son modèle parce que le rapport est silencieux peut casser plusieurs Tableaux de bord. L’inventaire doit donc séparer le rapport de présentation, le modèle sémantique, la passerelle, l’actualisation et les flux de préparation.
Dans un environnement BusinessObjects 4.3, le raisonnement est comparable mais les sources changent. Les traces de consultation, les planifications, les instances et les dépendances d’univers doivent être rassemblées avant de qualifier un document. Un rapport Webi peut embarquer une condition ou une logique peu visible dans son interface. La revue des règles de gestion dans les univers BusinessObjects permet de vérifier ce qui resterait à reconstruire si le document était finalement retenu.
Le protocole de contrôle doit également repérer les rapports en erreur. Un objet non ouvert peut avoir été abandonné, mais il peut aussi avoir cessé de fonctionner après une modification de source ou une perte de droit. Dans le second cas, l’absence d’usage est une conséquence d’incident. La décision demande alors au métier s’il souhaite rétablir, remplacer ou retirer l’objet.
La meilleure preuve d’inutilité n’est jamais un compteur isolé. C’est l’accord entre une absence de consultation, l’absence de diffusion, l’absence de dépendance et la validation écrite d’un responsable métier.
Comment classer les Rapports BI avant une purge ou une migration ?
Un parc ne doit pas être séparé entre « à migrer » et « à supprimer » dès le premier atelier. Cette opposition pousse à conserver trop d’objets par prudence. Une troisième voie est nécessaire : la reconstruction ciblée. Elle s’applique lorsqu’un rapport répond encore à un besoin réel mais que sa présentation, ses requêtes ou son modèle sémantique ne justifient pas une reprise à l’identique.
La matrice de décision peut comporter quatre statuts. Le premier, actif et à reprendre, concerne les rapports régulièrement consultés avec des règles de gestion confirmées. Le deuxième, utile mais à reconstruire, concerne les contenus à faible usage dont la finalité reste confirmée. Le troisième, à archiver, concerne les éléments qui doivent rester consultables sans être maintenus dans le socle courant. Le quatrième, à retirer, concerne les objets sans propriétaire, sans usage démontré et sans dépendance technique.
Un calcul de charge pour éviter de migrer un inventaire brut
Voici un exemple chiffré destiné à dimensionner une première revue. Il ne s’agit pas d’un tarif ni d’une promesse de durée. Le périmètre compte 240 Rapports BI : 120 rapports simples, 72 rapports intermédiaires et 48 rapports complexes. Les hypothèses de tri retiennent respectivement 1 heure, 3 heures et 6 heures pour examiner l’usage, les dépendances, le propriétaire et la décision de classement.
Le calcul donne 120 heures pour les rapports simples, 216 heures pour les intermédiaires et 288 heures pour les complexes. La phase de qualification représente donc 624 heures. Ce total exclut la recette, la formation, la reprise des droits, la correction des sources et la reconstruction des rapports retenus. Il est fondé sur les hypothèses affichées dans ce paragraphe ; il doit être recalculé à partir de votre structure réelle.
Si l’analyse conclut que 45 % des objets sont à retirer ou à archiver, 108 rapports sortent du périmètre de reprise. Le projet ne gagne pas mécaniquement 45 % de charge, car les modèles, les règles partagées et les flux ETL restent parfois nécessaires. En revanche, l’équipe cesse de financer la transposition de 108 interfaces sans usage démontré. C’est un arbitrage plus défendable qu’une reprise intégrale décidée sur la seule taille de l’inventaire.
Sur un parc inférieur à cent rapports dont une part notable est silencieuse et dont les règles de gestion sont accessibles, la reconstruction des objets utiles est souvent préférable à la copie des anciens écrans. L’arbitrage change au-delà de plusieurs centaines de rapports contenant des logiques peu documentées. Dans ce cas, un retrait trop large peut coûter plus cher en recette et en reconstitution des règles que la reprise contrôlée d’un sous-ensemble.
La charge de migration doit ensuite être traitée séparément de l’analyse d’usage. Les hypothèses, les objets sources et les exclusions sont détaillés dans ce chiffrage de la migration de BusinessObjects vers Power BI. Mélanger les deux travaux dans une seule estimation rend le budget illisible : l’audit sert à réduire le périmètre, la migration sert à reconstruire ou reprendre ce qui a été validé.
La classification doit être signée par un responsable de domaine et versionnée. Sans cette trace, un rapport retiré revient fréquemment dans le périmètre à quinze jours d’une bascule, parce qu’un utilisateur retrouve un ancien export ou une procédure non documentée.
Comment organiser un suivi des rapports après leur identification ?
L’Optimisation BI ne consiste pas à lancer une purge unique. Un parc décisionnel recommence à accumuler des objets dès que les créations, les copies et les changements de périmètre ne sont plus suivis. Le contrôle doit donc devenir une routine de gouvernance légère, avec un inventaire fiable et une échéance attribuée à chaque propriétaire.
La fréquence dépend de la volatilité du parc. Un espace de travail alimenté par des projets ponctuels demande une revue mensuelle des nouveautés et des rapports sans propriétaire. Un domaine financier stable peut être revu après chaque cycle de clôture, avec une revue annuelle plus complète. L’objectif est de détecter l’abandon avant que les règles métier, les contacts et les sources ne disparaissent.
Un registre de décision plutôt qu’une liste de suppression
Le registre de Suivi des rapports doit inclure le nom fonctionnel, l’identifiant technique, l’espace de travail, le modèle sémantique, le propriétaire métier, le propriétaire technique, la dernière consultation prouvée, le mode de diffusion, le statut de décision et la date de prochaine revue. Les colonnes de décision doivent préciser si le rapport est conservé, reconstruit, archivé ou retiré.
Un statut temporaire est utile lorsque le métier ne répond pas. Il évite de figer l’objet dans le parc actif. Après une période définie par votre gouvernance interne, le rapport passe en archive technique avec un accès restreint, sans actualisation coûteuse si son usage ne le justifie plus. Cette action exige toutefois de vérifier les dépendances et les obligations applicables ; elle ne doit pas être appliquée par automatisme.
La désactivation d’une actualisation est un signal intéressant, mais pas une preuve autonome. Microsoft indique que les métriques sont actualisées quotidiennement, tandis que les actualisations du modèle et du rapport relèvent d’une mécanique différente. Un rapport peut être peu consulté et rester nécessaire à un export planifié. Le registre doit donc distinguer l’ouverture interactive, la diffusion planifiée et l’actualisation du jeu de données.
Le contrôle post-migration mérite un traitement particulier. Un rapport reconstruit ne doit pas être déclaré équivalent à son prédécesseur par principe. Il faut comparer un échantillon de périodes, documenter les écarts, identifier leur origine et faire accepter une tolérance par les responsables métier. Un filtre de statut posé dans un univers, une date de référence différente ou un traitement d’annulation modifié suffisent à créer un écart significatif.
Un protocole de recette structuré est disponible dans ce protocole de migration BI et de réconciliation. Il doit être appliqué aux rapports conservés ou reconstruits, tandis que les objets retirés restent traçables dans le registre. La Gestion des données devient alors contrôlable : chaque absence de reprise correspond à une décision documentée, non à un oubli.
Avant la prochaine revue, extrayez les métriques des espaces de travail sur lesquels votre équipe publie, notez leur période de couverture et rapprochez-les des abonnements, des exports et des journaux disponibles. C’est ce rapprochement qui transforme une liste de rapports silencieux en décision de périmètre.
Un rapport sans consultation depuis 90 jours doit-il être supprimé ?
Non. Les métriques Power BI couvrent 90 jours et ne suivent pas tous les scénarios d’incorporation. Vérifiez la fréquence métier, les abonnements, les exports, les dépendances techniques et l’accord du propriétaire avant toute suppression.
Pourquoi les journaux d’audit et les métriques d’utilisation affichent-ils des chiffres différents ?
Les journaux d’audit reposent sur des données du service Power BI, tandis que les métriques sont collectées côté client. Des blocages réseau, certaines formes d’intégration ou les changements de page peuvent créer des écarts entre les deux sources.
Quels objets faut-il contrôler en plus des rapports ?
Contrôlez les modèles sémantiques, les flux de données, les actualisations, les passerelles, les abonnements, les applications Power BI et les exports planifiés. Un rapport peu consulté peut dépendre d’un composant partagé avec du contenu actif.
Peut-on utiliser les métriques d’utilisation dans Mon espace de travail ?
Non. Microsoft indique que le rapport de métriques d’utilisation n’est pas pris en charge pour Mon espace de travail. Pour un audit fiable, les contenus concernés doivent être publiés dans des espaces de travail gouvernés.
Le dossier complet Recette & réconciliation : prouver que les nouveaux chiffres valent les anciens
