Audit Power BI : la checklist que j'utilise sur les missions de reprise

Auditer un environnement Power BI hérité, ce n'est pas une revue de code. C'est un travail d'archéologie : il faut comprendre ce qui a été construit, pourquoi, et ce qui s'en est éloigné avec le temps. Voici la checklist que j'utilise sur mes missions de reprise. Elle n'est pas exhaustive, elle est pragmatique.

Périmètre & gouvernance

• Liste des workspaces actifs, propriétaires, statut.
• Conventions de nommage : datasets, rapports, mesures, tables.
• Politique d'accès et de partage : qui voit quoi, comment.
• Existence d'un workspace de développement / recette / production.
• Nombre de rapports orphelins ou non utilisés.

Datasets & modélisation

• Schéma : flocon, étoile, tables aplaties.
• Relations : cardinalités, bidirectionnelles, ambiguïtés de chemin.
• Tables techniques (date, mesures techniques) bien isolées.
• Colonnes calculées versus mesures : ce qui pourrait être déplacé.
• Tailles des tables, colonnes inutiles, types de données.
• Compression et taille du dataset en mémoire.

Mesures DAX

• Mesures les plus utilisées et leurs temps d'exécution.
• Patterns à risque : itérations imbriquées, FILTER mal posé.
• Variables (VAR) utilisées ou non.
• Mesures dupliquées, mesures orphelines, mesures non utilisées.
• Cohérence de nommage et de format.

Power Query (M)

• Repli sur la source (query folding) : quelles requêtes folde, lesquelles non.
• Étapes inutiles ou redondantes.
• Volumes chargés versus volumes nécessaires.
• Robustesse aux variations de données source (types, valeurs nulles).
• Sources sensibles : fichiers Excel locaux, API non versionnées.

Refresh & infrastructure

• Taux de succès des refresh sur les 30 / 90 derniers jours.
• Durées de refresh : moyennes et pics.
• Passerelles utilisées, redondance, comptes de service.
• Plages de refresh et impact sur les sources transactionnelles.
• Alertes en cas d'échec : qui est notifié, comment.

Sécurité & RLS

• Niveau de sécurité ligne (RLS) implémenté ou non.
• Cohérence avec les rôles métier.
• Tests de RLS documentés.
• Comptes à privilèges : qui, pourquoi, jusqu'à quand.

Ce qui doit déclencher une alerte

Trois signaux qui, dans mon expérience, sont presque toujours des signes que l'environnement nécessite une intervention rapide :

1. Aucun reverse engineering possiblesans interroger l'auteur initial. C'est une dépendance critique au prestataire.
2. Refresh qui échouent silencieusement. Personne ne regarde, et les rapports affichent des données obsolètes pendant des jours.
3. Écarts entre rapports censés afficher la même chose. Symptôme classique d'un modèle dupliqué ou de mesures redéfinies plusieurs fois.

L'audit n'est pas une fin en soi. C'est ce qui permet ensuite de décider, en connaissance de cause, ce qui peut être réparé, ce qui doit être refait, et ce qui peut rester en l'état tant que ça tourne.