Dette technique des rapports dans Power BI : pourquoi un rapport devient ingérable (et comment le reprendre)

Au début, tout fonctionnait. Le rapport est sorti en deux jours et la direction était ravie. Six mois plus tard, ajouter une colonne prend une demi-journée, chaque correction en casse une autre, et plus personne n'ose ouvrir le fichier. Ce n'est ni un bug ni une fatalité : c'est de la dette technique.

Cet article s'adresse à deux lecteurs : celui qui doit reprendre un rapport construit par quelqu'un d'autre, et le responsable BI qui doit expliquer à sa direction pourquoi il faut « refaire ce qui marche ». Vous y trouverez une définition claire, les 7 formes de dette les plus fréquentes dans les rapports dans Power BI, une méthode d'audit et une grille pour décider quoi rembourser en premier.

En bref

• La dette technique, c'est un raccourci pris aujourd'hui qui coûtera plus cher demain.
• Elle se cache dans la préparation des données, le modèle, les mesures, la mise en page et la diffusion.
• On ne la rembourse pas d'un coup : on l'inventorie, on la priorise, puis on la rembourse au fil des évolutions.

La dette technique, c'est quoi ? Définition appliquée aux rapports Power BI

La métaphore vient de Ward Cunningham, en 1992. Un raccourci pris pour livrer plus vite, faute de temps ou de compétences, fonctionne comme un emprunt : on encaisse un gain immédiat, puis on paie des intérêts. Ces intérêts, ce sont le temps perdu à chaque évolution, les erreurs qui se glissent dans les chiffres et la difficulté à faire évoluer le système. Ils courent tant qu'on n'a pas « remboursé le capital », c'est-à-dire refait les choses proprement.

Martin Fowler a proposé une grille de lecture utile, qui croise deux questions : la dette a-t-elle été contractée volontairement, et l'a-t-elle été de manière réfléchie ?

Deux nuances essentielles :

• Une dette assumée n'est pas une faute. Livrer vite une première version pour valider un besoin est souvent le bon choix, à condition que la dette soit consciente et notée quelque part.
• Du code simplement mauvais n'est pas forcément de la dette. Le terme prend tout son sens quand il y a un coût de remboursement identifiable et des intérêts qui courent. Une formule mal indentée dans une page que personne n'ouvre ne coûte rien. La même formule recopiée dans quinze fichiers coûte cher à chaque changement de règle métier.

Les symptômes : quand un rapport Power BI vous fait payer des intérêts

On parle de dette technique dans trois situations : au moment du choix (« on livre en codant en dur, mais on sait qu'on crée de la dette »), lors d'un audit ou d'une reprise de projet et, le plus souvent, quand les symptômes apparaissent. Les voici, tels que nous les rencontrons chez nos clients :

• Chaque évolution prend plus de temps que la précédente. Ajouter un indicateur qui demandait une heure en demande maintenant une journée.
• Une modification en casse une autre. Vous renommez une colonne, et trois pages affichent des croix rouges.
• Plus personne n'ose toucher à certaines parties. « Cette formule, on ne sait pas ce qu'elle fait, mais on n'y touche pas. »
• Les chiffres divergent d'un rapport à l'autre. Le chiffre d'affaires du tableau de bord commercial n'est jamais celui du rapport financier.
• Le fichier grossit et ralentit. L'ouverture prend plusieurs minutes, le rafraîchissement planifié échoue une fois sur deux.
• La documentation est absente ou obsolète, et le développeur qui a tout construit a quitté l'entreprise. Personne ne sait plus pourquoi telle requête filtre telle année.

La dette se révèle rarement en temps réel. Elle apparaît au moment où le volume grossit, où une règle métier change, ou quand quelqu'un d'autre reprend le projet.

Vidéo MYPE : Pourquoi vos rapports sont lents (et comment éviter de perdre du temps en réunion)

Dette n°1 : connecter les sources de données avec des chemins en dur

C'est la dette la plus banale : C:\Users\Julie\Desktop\Ventes_2025.xlsx. Tout fonctionne sur le poste de Julie… jusqu'à ce qu'elle change d'ordinateur, que le fichier migre sur SharePoint ou que le rapport soit publié et doive s'actualiser sans elle.

Les intérêts : une actualisation qui échoue dès que le fichier bouge, et une chasse au chemin dans chaque étape le jour où il faut migrer.

Le remboursement : pour toutes les sources de données, centraliser les chemins, les noms de serveur et les noms de base dans des paramètres. Il n'y a plus qu'un seul endroit à modifier, et vous pouvez basculer d'un environnement de test à la production en changeant une valeur.

Profitez-en pour nommer chaque étape et chaque table de façon explicite (Fact_Ventes, Dim_Client). L'absence de conventions de nommage est une dette discrète, qui coûte cher le jour de la reprise. Même logique pour les en-têtes : un fichier source dont une colonne change de nom casse toute la chaîne lors des mises à jour voir notre article une colonne renommée dans le fichier source.

Vidéo MYPE : créer un paramètre pour centraliser vos chemins

Dette n°2 : des colonnes calculées DAX au lieu de transformations Power Query

Concaténer un nom et un prénom, extraire l'année d'une date, regrouper des libellés : tout cela peut se faire en colonne calculée, directement dans le modèle. C'est rapide, ça marche… et c'est souvent une dette.

Les intérêts : une colonne calculée est stockée dans le modèle et recalculée à chaque actualisation, sans profiter des optimisations de la source. Sur quelques milliers de lignes, c'est invisible. Sur dix millions, le fichier grossit et les performances se dégradent. Surtout, la logique s'éparpille : une partie du nettoyage en amont, une partie dans le modèle, et personne ne sait plus où chercher.

Le remboursement : appliquer la règle « préparer en amont, calculer en aval ». Les transformations de structure (nettoyage, découpage, regroupements) vont dans l'éditeur Power Query, voire directement dans la source. Le langage DAX sert aux calculs qui dépendent des sélections de l'utilisateur. C'est ce que résume la maxime de Roche : transformer les données aussi en amont que possible, et aussi en aval que nécessaire.

👉 Pour aller plus loin : mesures ou colonnes calculées, que choisir ?

Vidéo MYPE : créer ses colonnes au bon endroit, dans l'éditeur

Dans notre livre (p. 95) : l'infographie « Concepts à ne pas confondre, épisode XI », qui répartit les rôles entre préparation et calcul.

Dette n°3 : une table plate dans le jeu de données au lieu d'un schéma en étoile

Exporter une extraction du logiciel métier, la charger telle quelle en mode Import et construire tous les graphiques dessus : c'est la façon la plus rapide d'obtenir un premier rapport. C'est aussi la dette la plus coûteuse à rembourser plus tard.

Les intérêts : impossible d'analyser deux tables de faits avec un même segment (budget et réalisé, ventes et stocks). Des valeurs répétées sur des millions de lignes alourdissent le fichier. Et les formules deviennent de plus en plus tordues pour contourner la structure.

Le remboursement : séparer les faits, c'est-à-dire ce qu'on mesure, des dimensions, c'est-à-dire les axes d'analyse (clients, produits, dates). On les relie ensuite dans un modèle de données en étoile. C'est le chantier le plus lourd du jeu de données, mais c'est lui qui débloque tous les autres.

👉 Pour aller plus loin : trop de tables dans la vue Modèle ?

Vidéos MYPE : les différentes relations entre les tables dans la vue Modèle et créer une table de dimension dynamique

Dans notre livre (p. 91) : « Table de faits vs table de dimension ».

Dette n°4 : des mesures DAX dupliquées, mal nommées, illisibles

CA, CA 2, CA (copie), CA_final_v3… Chaque nouveau besoin donne lieu à une nouvelle formule, souvent copiée-collée depuis la précédente puis légèrement modifiée.

Les intérêts : quand la règle de calcul du chiffre d'affaires change (une remise à exclure, un nouveau statut de commande), il faut retrouver et corriger chaque copie. Celle qu'on oublie produit un chiffre faux, que personne ne remarque avant le comité de direction.

Le remboursement :

• une table dédiée aux mesures, avec des noms explicites ;
• des mesures de base (Total Ventes) réutilisées par les mesures dérivées, plutôt que des formules recopiées ;
• des variables et une indentation propre, pour qu'une formule de 40 lignes reste lisible ;
• des groupes de calcul quand vous déclinez la même logique (cumul annuel, N-1, variation) sur des dizaines de mesures ;
• des mesures explicites plutôt que des agrégations implicites glissées dans les champs.

👉 Pour aller plus loin : les bonnes pratiques pour écrire vos mesures

Vidéos MYPE : les groupes de calcul et indenter une mesure pour la rendre lisible

Dans notre livre (p. 131) : « Les bonnes pratiques des mesures ».

Dette n°5 : les jeux de données recopiés dans chaque rapport

Chaque nouveau besoin donne lieu à un nouveau fichier, ouvert dans Power BI Desktop avec sa propre copie des données, des relations et des mesures. Au bout d'un an, on compte douze modèles qui chargent les mêmes tables… et douze définitions de la marge. Les jeux de données (aujourd'hui appelés modèles sémantiques) se sont multipliés sans que personne ne l'ait décidé.

Les intérêts : douze actualisations qui sollicitent la même source, des chiffres qui divergent, et chaque correction à répercuter douze fois.

Le remboursement : publier un modèle sémantique de référence dans un espace partagé, puis y connecter les rapports au lieu de dupliquer le modèle. Quand plusieurs modèles ont besoin des mêmes tables préparées, un flux de données permet de mutualiser la préparation en amont. Le principe vaut aussi pour les entreprises qui hébergent leurs rapports sur site avec Report Server.

👉 Pour aller plus loin : modèles sémantiques, flux de données et datamarts dans le service en ligne

Vidéo MYPE : qu'est-ce qu'un dataflow et comment l'utiliser

Dans notre livre (p. 99) : « Modèle sémantique vs flux de données ».

Dette n°6 : une mise en forme conditionnelle et des segments à configurer page par page

La dette ne se cache pas que dans le modèle. Côté rapport, elle prend la forme de réglages faits à la main, un par un :

• des couleurs saisies une à une au lieu d'un thème aux couleurs de l'entreprise ;
• un format conditionnel (rouge sous zéro, vert au-dessus) codé en dur dans chaque tableau, au lieu d'être porté par une mesure de couleur réutilisable ;
• des bornes minimum et maximum de graphiques fixées manuellement, qui deviennent fausses dès que les volumes changent ;
• une image d'arrière-plan avec les titres de pages incrustés, à refaire dans un logiciel de dessin à chaque changement de libellé ;
• un filtre de page qui diffère d'une page à l'autre, sans que personne ne pense à le vérifier.

Les intérêts : un changement de charte graphique ou de seuil métier devient un chantier de plusieurs jours, car il faut configurer à nouveau chaque visualisation.

Le remboursement : un thème JSON, des mesures de couleur centralisées pour la mise en forme, des sélections synchronisées entre les pages et des réglages d'affichage pilotés par les données plutôt que saisis à la main.

👉 Pour aller plus loin : appliquer une charte graphique cohérente

Vidéo MYPE : colorer vos valeurs automatiquement en une minute

Dette n°7 : afficher ses chiffres dans PowerPoint par copier-coller

Dernière forme de dette, souvent oubliée : la diffusion. Chaque début de mois, quelqu'un exporte des captures, les colle dans un support PowerPoint, réécrit les commentaires… et recommence le mois suivant.

Les intérêts : une demi-journée par mois pour afficher les chiffres du mois, des chiffres figés dès leur envoi et des versions qui circulent par mail.

Le remboursement : des abonnements automatiques, une application par audience, des pages intégrées de façon dynamique dans les diapositives. Et quand l'actualisation doit déclencher une action (prévenir une équipe dans Teams, par exemple), la Power Platform prend le relais.

👉 Pour aller plus loin : les interactions possibles avec vos diapositives et mettre en place un abonnement

Vidéos MYPE : exports figés, dynamiques et diaporamas et rafraîchir vos modèles avec Power Automate

Auditer un rapport Power BI : faire l'inventaire de la dette

Avant de rembourser, il faut savoir ce qu'on doit. Lors d'une reprise de projet, nous procédons en trois passes.

1. Le modèle. Ouvrez la vue Modèle : une table géante au centre, des relations bidirectionnelles partout, des tables isolées ? Comptez les colonnes calculées et les mesures, cherchez les doublons. Le Best Practice Analyzer de Tabular Editor, un outil externe gratuit, passe le modèle au crible de dizaines de règles publiées par Microsoft (colonnes inutilisées, relations douteuses, formules à risque) et produit une liste à prioriser.

2. La préparation. Pour chaque source : chemin en dur ou paramètre ? Étapes nommées, ou « Personnalisé3 » ? Les requêtes intermédiaires sont-elles désactivées au chargement ?

3. Le rapport et sa diffusion. L'Analyseur de performances de PBI Desktop mesure le temps de calcul de chaque visuel : les visuels les plus lents ressortent immédiatement, et vous pouvez déboguer les pages concernées. Côté service Power BI (app.powerbi.com), vérifiez où le rapport est publié (« Mon espace de travail » est un signal d'alerte), comment il s'actualise et qui y accède. Sur un parc étendu, l'API d'administration permet même d'inventorier automatiquement tous les modèles et leurs sources.

Cet inventaire peut aujourd'hui être accéléré par l'IA : connecté à votre modèle via le MCP Server, un assistant peut lister les formules en double, documenter chaque calcul et repérer les incohérences de nommage. Nous détaillons les prompts à utiliser dans notre article sur le MCP Server.

Vidéos MYPE : utiliser Tabular Editor et et si l'IA générait vos rapports à votre place ?

Rembourser la dette : intérêts, coût et fréquence d'utilisation

Tout rembourser d'un coup est rarement possible. La bonne question : quelle dette coûte le plus d'intérêts par rapport à son coût de remboursement ?

Trois règles pour s'y tenir :

• Commencez par les remboursements rapides (paramètres, nommage, abonnements) : ils apportent des gains immédiats et sécurisent la suite.
• Remboursez en touchant. Chaque fois qu'une évolution vous amène sur une partie endettée, nettoyez-la au passage plutôt que de planifier une refonte totale.
• Pondérez par l'usage. Un rapport consulté chaque jour par 200 personnes mérite plus d'efforts qu'un rapport ouvert une fois par trimestre. Les statistiques d'utilisation du service vous le diront.

Une tentation fréquente consiste à passer en capacité Premium pour compenser un modèle trop lourd. C'est payer les intérêts avec une seconde carte de crédit : le fichier reste mal conçu, il coûte simplement plus cher à faire tourner. Mieux vaut optimiser le modèle d'abord, et dimensionner ensuite.

Faire accepter le chantier : parler de dette à votre direction

Le plus difficile est souvent de justifier, auprès des parties prenantes, du temps passé à « refaire ce qui marche ». La métaphore financière est votre meilleur argument, parce qu'elle parle à une direction :

• Chiffrez les intérêts. « Chaque nouveau KPI nous coûte deux jours au lieu d'une demi-journée » ; « nous passons quatre heures par mois à expliquer des écarts entre rapports ».
• Présentez le remboursement comme un investissement, avec un coût (X jours) et un retour (Y heures gagnées par mois).
• Rendez la dette visible. Un simple registre (dette, date, raison, coût estimé) suffit. Une dette notée est une dette pilotée ; une dette oubliée devient une mauvaise surprise.
• Rappelez le risque, pas seulement le coût. Un chiffre faux présenté en comité coûte bien plus que quelques jours de refonte.

Prévenir la dette dans vos prochains projets PBI

La meilleure dette reste celle qu'on contracte en connaissance de cause. Quelques réflexes suffisent à éviter l'essentiel :

• Partez des questions métier, pas des données disponibles : quels chiffres clés, pour qui, à quelle fréquence ? Gardez en tête l'utilisateur du rapport à chaque arbitrage.
• Ne reproduisez pas la logique d'un classeur Excel : un onglet par mois ou une colonne par année sont des dettes dès le premier jour.
• Construisez en étoile dès la première version, même petite.
• Paramétrez les sources et nommez tout dès le départ : tables, colonnes, mesures, pages.
• Un modèle partagé par domaine métier, plutôt qu'un modèle par rapport.
• Testez chaque fonctionnalité sur une copie avant publication, et versionnez vos fichiers (format PBIP, Git, pipelines de déploiement).
• Notez chaque dette volontaire dans le registre, avec la date à laquelle vous comptez la rembourser.

Prendre le temps de tester une évolution avant de la publier, c'est aussi protéger la confiance que les utilisateurs accordent à vos chiffres.

Conclusion : la dette n'est pas une faute, l'oublier en est une

Toute équipe BI contracte de la dette, et c'est normal : livrer vite une première version reste souvent le bon choix. Ce qui fait la différence entre des rapports Power BI qui vieillissent bien et des fichiers que plus personne n'ose ouvrir, c'est la conscience de cette dette et la discipline de la rembourser.

Vous reprenez un rapport et ne savez pas par où commencer ?

Pour faire monter vos équipes en compétence sur la modélisation et les bonnes pratiques, découvrez nos formation Expert.

Et pour garder ces bonnes pratiques sous la main, toutes les infographies citées viennent de notre livre « Microsoft Power BI en images ».