Les bugs que l’IA a trouvés dans Power BI (et que l’humain aurait manqués)

Série : Automatiser Power BI avec Claude AI — Épisode 10/12 Temps de lecture : 10 min Public cible : BI Engineers, Data Quality, Project Managers

TL;DR : 8 anomalies détectées par Claude avant la mise en production du projet client, dont 2 critiques : un écart de plusieurs dizaines de MEUR entre deux pages du même dashboard (mesures DAX avec filtres différents) et 3 cartes Conformité affichant toutes la même valeur (même binding DAX copié-collé). Les 6 autres : fake data en production, type mismatch texte/décimal, colonne calculée au lieu de mesure, filtre hardcodé, MAX() inutile, logique HTML dupliquée.

Pourquoi les anomalies invisibles sont-elles les plus dangereuses ?

Il existe deux types d’anomalies dans un dashboard Power BI. Le premier type est visible : erreur affichée, bouton cassé, page qui ne charge pas. Le second type est invisible : les chiffres s’affichent, mais ils sont faux. Le dashboard a l’air de fonctionner parfaitement. Mais il ment. Le second type est de loin le plus dangereux.

Anomalie critique #1 : comment un écart de plusieurs dizaines de MEUR passe-t-il inaperçu ?

Symptôme détecté par Claude Chrome lors du PV de recette :

plain text
Page Vue d'ensemble → Scorecard Achats : XX contrats | YYY MEUR
Page Achats → Scorecard Achats : XX' contrats | YYY' MEUR

Écart : plusieurs dizaines de contrats | plusieurs dizaines de MEUR
Source de données : identique (table Contrats)

Plusieurs dizaines de millions d’euros d’écart entre deux pages du même dashboard, sur la même source de données.

Diagnostic :

Deux mesures DAX différentes pour “Montant Contractualisé” :

plain text
-- Mesure A (Vue d'ensemble) — INCORRECTE
[Vue ensemble] Montant Contractualisé =
SUM(Contrats[Montant_Contractualise])
-- Inclut TOUS les contrats, y compris "En attente" et "Annulé"

-- Mesure B (Page Achats) — CORRECTE
[Achats] Montant Contractualisé =
CALCULATE(
    SUM(Contrats[Montant_Contractualise]),
    Contrats[Statut] = "Signé"
)
-- Inclut uniquement les contrats signés

Ce qui aurait pu se passer : Le dashboard est livré. En COMEX, la Direction pose une question sur l’écart. Personne ne peut répondre. La crédibilité du projet est détruite.

C’est exactement le type de doublon sémantique que le dictionnaire KPI et l’atlas des mesures DAX sont conçus pour prévenir.

Anomalie critique #2 : 3 cartes Conformité qui affichent toutes la même valeur

Trois cartes distinctes, trois KPIs différents, même valeur affichée.

Les trois cartes pointaient vers la même mesure DAX : [Conformité] Contrats Actifs. Le développeur avait copié-collé le visuel sans adapter le binding.

Visuellement correct. Logiquement faux.

Quelles sont les 6 autres anomalies détectées ?

Problème #3 : Fake data en production

Mesure “Coût Réel” utilisée sur 4 visuels. La colonne Projets[Cout_Reel] n’existe pas dans Dataverse. Valeur retournée : BLANK() sur tous les visuels. La mesure avait été générée par Claude lors d’une itération de test avec un nom de colonne inventé.

Problème #4 : Type mismatch texte/décimal

plain text
[Projets] Avancement Moyen = AVERAGE(Projets[Taux_Avancement])
-- Projets[Taux_Avancement] est stocké en TEXTE ("75%"), pas en décimal
-- Résultat : BLANK() au lieu de 0,75

Problème #5 : Colonne calculée au lieu d’une mesure

plain text
Projets[Jours Retard] = DATEDIFF(Projets[Date_Fin_Prevue], TODAY(), DAY)
-- Recalculée quotidiennement au refresh, pas à chaque interaction
-- Ne répond pas aux filtres. Devrait être une mesure.

Problème #6 : Filtre hardcodé

plain text
[Achats] Contrats France =
CALCULATE(COUNTROWS(Contrats), Contrats[Pays] = "France")
-- Hardcodé. Si le client ajoute des pays, la mesure ne se met pas à jour.

Problème #7 : MAX() inutile sur valeur unique

plain text
[Projets] Nom Projet = CALCULATE(MAX(Projets[Nom]), ...)
-- MAX() sur un texte unique n'a pas de sens
-- Devrait être : SELECTEDVALUE(Projets[Nom])

Problème #8 : Logique HTML dupliquée

Même bloc de nettoyage HTML dans 3 mesures différentes. Devrait être dans une seule mesure réutilisable.

Quel prompt utiliser pour un quality check DAX complet ?

plain text
Tu es un expert DAX Power BI. Voici toutes les mesures DAX du rapport :
[Liste complète des mesures avec leurs définitions]

Effectue un quality check complet. Vérifie :

1. TYPE MISMATCH : les colonnes utilisées ont-elles le bon type ?
2. RÉFÉRENCES INVALIDES : les colonnes/tables existent-elles dans le schéma ?
3. MESURES DUPLIQUÉES : deux mesures calculent-elles la même chose ?
4. COLONNES CALCULÉES MAL UTILISÉES : des patterns qui devraient être des mesures ?
5. FILTRES HARDCODÉS : des valeurs en dur qui devraient être des paramètres ?
6. LOGIQUE DUPLIQUÉE : des blocs de code répétés ?
7. MAX() INUTILES : des MAX/MIN sur des valeurs uniques ?

Pour chaque problème : identifie la mesure, explique le problème, propose une correction.

Que révèlent ces bugs sur le développement Power BI ?

Ces 8 problèmes ne sont pas spécifiques à ce client. Ce sont les bugs les plus courants dans n’importe quel projet Power BI. Le pattern général est toujours le même :

Un développeur crée une mesure rapidement

Il la teste sur les données disponibles, elle “fonctionne”

Personne ne fait de review systématique

Le bug arrive en production

Claude peut faire une review systématique de toutes les mesures DAX en quelques minutes. Pas parce qu’il comprend le métier mieux qu’un humain — mais parce qu’il lit tous les fichiers sans inattention, sans fatigue, sans “je vérifierai plus tard”.

FAQ — Détection d’anomalies Power BI avec l’IA

Claude peut-il détecter des erreurs de données, pas seulement de code DAX ? Non directement. Claude analyse le code DAX et la structure PBIR, pas les données brutes. Mais en comparant les valeurs affichées entre pages (comme l’écart de plusieurs dizaines de MEUR), il détecte des incohérences que seule une vérification croisée peut révéler.

Combien de temps prend un quality check DAX par Claude ? Environ 10 minutes pour un rapport de 27 mesures. C’est le temps de formater le prompt et de lire les résultats. Claude analyse les mesures en quelques secondes.

Ces 8 types de bugs sont-ils spécifiques à l’utilisation de l’IA ? Non. Le problème #3 (fake data) est lié à Claude qui a inventé un nom de colonne. Les 7 autres sont des bugs classiques du développement Power BI manuel. L’IA les détecte, elle n’en est pas la cause principale.

Comment prévenir les doublons sémantiques de mesures DAX ? L’atlas des mesures DAX est la meilleure prévention : une mesure, un nom, une définition, avant d’écrire une ligne de code.