Série : Automatiser Power BI avec Claude AI — Épisode 2/12 Temps de lecture : 10 min Public cible : BI Engineers, Data Analysts, Responsables Data, DSI
TL;DR : Power BI est 4 à 12 fois plus lent que Looker Studio à développer, principalement à cause de son architecture fichier binaire (.pbix), de la répétitivité des tâches manuelles (30-40 % du temps), et de l’absence de CI/CD natif (je en dis pas que Looker Studio dispose de ce système car c’est un outilde BI en ligne ce qui est différent). Le format PBIP/PBIR introduit par Microsoft en 2023 décompose les rapports en fichiers JSON lisibles — rendant possible l’automatisation par LLM. Sur le projet client, cette approche a produit une vélocité x2,5 à x3 mesurée.
Quel constat a tout déclenché ?
Un dashboard Looker Studio livré en 2 heures. Le même périmètre en Power BI : estimation réaliste de 2 jours. Ce ratio de 1 à 8-12 sur la vélocité de livraison a déclenché notre expérimentation.
Début 2026, notre équipe chez Unnest reçoit un brief pour un grand groupe industriel international.
La demande : un dashboard de suivi de projets d’infrastructure. KPIs travaux, achats, conformité juridique. Données en temps réel depuis Microsoft Dataverse. Stack imposée : Power BI.
Pourquoi Power BI est-il structurellement plus lent à développer ?
Avant de chercher une solution, il faut comprendre le problème. Power BI est plus verbeux que ses concurrents pour quatre raisons structurelles.
1. L’architecture fichier .pbix est une boîte noire
Un fichier .pbix traditionnel est un fichier binaire compressé. Impossible de le lire, de le modifier manuellement, de le versionner correctement dans Git, ni de l’inspecter sans ouvrir Power BI Desktop. C’est une boîte noire.
Chaque modification — même mineure — implique d’ouvrir l’interface graphique, de naviguer dans des menus, de sauvegarder. Pas de scripting, pas d’automatisation, pas de diff Git lisible.
2. La répétitivité des tâches représente 30 à 40 % du temps
Un dashboard Power BI bien fait, c’est souvent 5 à 10 pages. Chaque page partage une structure commune : même header, même sidebar de navigation, mêmes boutons, même thème visuel.
En pratique, cette structure est copiée-collée manuellement d’une page à l’autre. Puis ajustée. Puis réajustée quand le design évolue. C’est du travail mécanique, sans valeur ajoutée, qui représente facilement 30 à 40 % du temps de développement.
3. La complexité DAX multiplie le temps de développement
DAX (Data Analysis Expressions) est un langage puissant. Trop puissant parfois. Pour des KPIs simples en apparence — “montant total des contrats en cours” — on peut se retrouver à écrire 20 lignes de DAX avec des CALCULATE, FILTER, ALL, USERELATIONSHIP.
Chaque mesure doit être testée, déboguée, documentée. Sur un projet avec 27 mesures comme celui-ci, c’est une semaine de travail à plein temps.
4. L’absence de CI/CD natif impose une recette manuelle
Power BI n’a pas de pipeline de tests natif. Pas de linter DAX standard. Pas de détection automatique de régressions entre versions. Chaque livraison implique une recette manuelle.
Un PV de recette complet — 40 critères de vérification — représente une journée entière d’un BI Engineer.
Comment le format PBIP/PBIR change-t-il la donne ?
En 2023, Microsoft a introduit le format Power BI Projects (PBIP). Au lieu d’un fichier binaire unique, le rapport est décomposé en une arborescence de fichiers texte lisibles. C’est le format PBIR (Power BI Report) — et c’est la pièce manquante qui rend l’automatisation possible.
plain textApp-Infra-Report/ definition/ pages/ Overview/ page.json visuals/ visual_001/ visual.json visual_002/ visual.json Achats/ ... bookmarks/ report.json .gitignore
Chaque visuel est un fichier JSON. Chaque page est un dossier. Les bookmarks, les thèmes, les paramètres de rapport — tout est accessible, lisible, modifiable avec un éditeur de texte.
Pour la première fois, il devient possible de scripter des opérations sur un rapport Power BI sans ouvrir l’interface graphique.
Qu’est-ce qu’un LLM peut faire sur des fichiers PBIR ?
Si les fichiers sont lisibles et modifiables, est-ce qu’un LLM peut les lire, les comprendre, et les écrire à notre place ? On a testé avec Claude Code. La réponse est oui — avec des nuances importantes.
Ce que Claude fait bien sur PBIR :
- Lire et comprendre la structure d’une page existante
- Dupliquer cette structure vers une nouvelle page en adaptant les IDs
- Renommer les références croisées (bookmarks, navigation, filtres)
- Générer des mesures DAX à partir d’une description fonctionnelle
- Identifier des incohérences structurelles (IDs en double, références cassées)
Ce que Claude fait moins bien :
- Inventer une structure de données sans contexte (il hallucine parfois les noms de colonnes)
- Gérer des interdépendances très imbriquées (ex. : bookmarks complexes)
- Produire du DAX optimal sans itération (première version fonctionnelle, rarement optimale)
Cette distinction est importante. Claude est un collaborateur qui accélère le travail d’un BI Engineer expérimenté — pas un remplaçant.
Quel était le contexte du projet client ?
Client : un grand groupe industriel international — Direction Infrastructures
Périmètre MVP :
- Page Vue d’ensemble (KPIs consolidés)
- Page Projets (suivi avancement travaux)
- Page Planning (Gantt simplifié)
- Page Achats (contrats, AO, économies)
- Page Conformité (juridique, assurances)
- Pages secondaires : Litiges, Glossaire, Organisation
Données : Microsoft Dataverse (temps réel, 13 tables)
Utilisateurs : Admin, Direction Infra, Responsables Infra Central/Local, Visiteurs CODIR/COMEX
Contrainte : Livraison MVP en 5 jours ouvrés
5 jours pour 7 pages, 27 mesures DAX, un système de navigation complet, et une intégration Dataverse.
Sans automatisation, c’est serré.
Avec Claude Code, c’est faisable.
Comment fonctionne le workflow augmenté ?
On n’a pas remplacé le processus BI par de l’IA. On a inséré Claude à chaque étape pour éliminer le travail mécanique et accélérer le travail cognitif.
plain text1. BRIEF MÉTIER | 2. MAQUETTE REACT (Claude Desktop) — Prototype interactif avant d'ouvrir Power BI | 3. SPEC TECHNIQUE (Claude Desktop) — Plan/Ship/Analyze, critères Gherkin, atlas KPIs | 4. BUILD PBIR (Claude Code) — Duplication pages, génération DAX, navigation | 5. RECETTE AUTOMATISÉE (Claude Chrome) — PV de recette généré, anomalies détectées | 6. LIVRAISON
Chaque étape fait l’objet d’un article dans cette série. Mais avant d’aller plus loin dans le “comment”, il fallait poser le “pourquoi”.
Quels gains concrets l’automatisation produit-elle ?
La vraie question n’est pas “est-ce que l’IA peut faire du Power BI ?”. Elle est : est-ce que l’IA peut réduire la friction suffisamment pour changer l’économie d’un projet BI ?
Nos mesures sur ce projet donnent des premiers éléments de réponse :
Tâche | Temps manuel | Temps avec Claude | Gain |
Maquette interactive | 3 jours | 1/2 journée | -70 % |
Spec technique | 3 jours | 1 jour | -65 % |
Duplication d’une page | 45 min | 3 min | -85 % |
Génération DAX (page complète) | 2h | 30 min review | -75 % |
PV de recette | 1 jour | 40 min | -80 % |
Ces chiffres ne sont pas des promesses marketing. Ce sont des mesures réelles sur un projet réel, avec des contraintes réelles.
Ils ne veulent pas dire que Claude “fait tout”. Ils veulent dire que Claude élimine le travail mécanique — et que l’humain se concentre sur ce qui a de la valeur : la compréhension métier, la validation utilisateur, la relation client.
FAQ — Power BI, productivité et automatisation
Pourquoi Power BI est-il plus lent à développer que d’autres outils de BI ?
Power BI utilise un fichier binaire .pbix inexploitable par script, impose la répétition manuelle des éléments communs entre pages (30-40 % du temps), nécessite du DAX complexe pour des KPIs simples, et n’offre pas de CI/CD natif.
Qu’est-ce que le format PBIP/PBIR ?
PBIP (Power BI Projects) est un format introduit par Microsoft en 2023 qui décompose un rapport Power BI en fichiers JSON lisibles. PBIR (Power BI Report) est le format interne de ces fichiers. Chaque visuel, page et bookmark devient un fichier texte modifiable et versionnable dans Git.
Claude Code peut-il remplacer un développeur Power BI ?
Non. Claude accélère le travail mécanique (duplication, génération DAX de base, détection d’anomalies) mais nécessite la supervision d’un BI Engineer expérimenté. La première version DAX est fonctionnelle, rarement optimale.
Faut-il des compétences en programmation pour utiliser cette approche ?
Une connaissance de base de la structure JSON et du format PBIR est nécessaire. Ce dossier fournit les templates de prompts et les scripts Python d’exploration pour démarrer.
Vous avez des questions sur ce workflow ? Vous travaillez sur un projet Power BI avec des contraintes similaires ? Contactez-nous ou retrouvez-moi sur LinkedIn.