Aller au contenu
Réserver un Audit IA
Retour aux publications
Transformation métiers

Copilot dans Power BI : la qualité vient du modèle, pas du prompt

Copilot dans Power BI écrit du DAX et génère des rapports, mais sa qualité dépend entièrement de la propreté du modèle sémantique. Ce qu'il faut préparer avant.

6 min
Couverture : dans Power BI, la qualite de Copilot vient du modele semantique, pas du prompt.

Copilot dans Power BI écrit du DAX, génère des pages de rapport et répond à des questions en langage naturel sur vos données. Sa qualité ne dépend presque pas de la formulation de la demande : elle dépend de la propreté du modèle sémantique. Un modèle dont les tables s'appellent Table1 et les colonnes Col_3 produira des réponses médiocres quelle que soit la précision du prompt.

C'est la même leçon que dans Excel, où le format tableau conditionne tout — mais avec un effet amplifié, parce qu'un modèle Power BI porte des relations, des mesures et des hiérarchies que l'assistant doit interpréter.

Ce qu'il faut pour y accéder

  • Une capacité Fabric ou Power BI Premium (SKU F2 ou supérieur, ou P1 et au-delà). Contrairement aux autres applications, ce n'est pas une licence par utilisateur : c'est une capacité au niveau de l'organisation.
  • Copilot activé au niveau du tenant par l'administrateur Fabric.
  • Un modèle sémantique publié, dans un espace de travail rattaché à cette capacité.

C'est le déploiement le plus lourd de la famille Copilot, et celui qui se décide au niveau de la plateforme de données, pas du poste de travail.

Pourquoi le modèle décide de tout

L'assistant ne voit pas vos données comme un humain regarde un rapport. Il lit les noms, les descriptions, les relations et les mesures déclarées. Ce sont ses seuls indices sur ce que représentent les chiffres.

Ce que porte le modèleCe que l'assistant en fait
Tables et colonnes nommées en langage métierComprend la question posée en langage métier
Descriptions renseignées sur les mesuresChoisit la bonne mesure au lieu d'en inventer une
Relations correctement définiesCroise les tables sans se tromper de sens
Hiérarchies déclarées (année › trimestre › mois)Agrège au bon niveau
Mesures redondantes ou ambiguësChoisit au hasard, sans le signaler

La dernière ligne est celle qui coûte cher. Un modèle contenant trois mesures de chiffre d'affaires légèrement différentes produira des réponses qui varient d'une question à l'autre, sans qu'aucune erreur ne soit visible.

Lorsque le rapport doit être rapproché d’explications documentaires, l’architecture hybride de recherche documentaire et de requêtes SQL aide à séparer les valeurs calculées des interprétations générées.

Le travail préparatoire est donc de la modélisation, pas du prompt engineering : renommer en langage métier, documenter les mesures, supprimer les doublons, masquer les colonnes techniques.

Les trois usages qui rendent service

Écrire une mesure DAX à partir d'une description. « Le chiffre d'affaires des douze derniers mois glissants » produit la formule. Le gain est réel pour qui connaît le métier sans maîtriser la syntaxe DAX — c'est-à-dire la majorité des analystes fonctionnels.

Générer une première page de rapport. Un point de départ visuel sur un modèle qu'on découvre. À reprendre entièrement, mais plus rapide que la page blanche.

Interroger un rapport en langage naturel. Pour un lecteur qui n'a pas construit le rapport, c'est le seul moyen d'aller au-delà de ce que les visuels affichent.

Avant de transformer cette réponse en livrable externe, utilisez le cadrage des contrôles d’un reporting réglementaire automatisé pour préciser les validations attendues.

Ce qu'il ne faut pas lui demander

Un chiffre destiné à sortir du rapport. Un DAX généré se relit ligne à ligne avant d'alimenter quoi que ce soit d'officiel. Une mesure fausse produit un graphique parfaitement crédible.

Pour un usage financier, la préparation d’un reporting IA avec contrôles et piste d’audit permet d’examiner ce qui doit être vérifié et conservé avant diffusion.

Une interprétation métier. « Pourquoi les ventes ont-elles baissé » n'est pas une question de modèle. Il décrira la baisse ; il n'en connaît pas la cause, et il ne dira pas qu'il l'ignore.

Un travail sur un modèle que personne n'a nettoyé. C'est l'erreur qui produit le plus de déceptions, et elle se corrige en amont — dans le modèle, pas dans la demande.

Le travail de modélisation qui conditionne Copilot dans Power BI fait l'objet d'un module dédié dans une formation Copilot pour les analystes.

La même règle vaut dans Excel, où Copilot dépend de tableaux bien structurés. Pour cadrer un déploiement complet, voir Microsoft Copilot en entreprise.

Questions fréquentes

Faut-il une licence Copilot par utilisateur pour Power BI ? Non. Contrairement à Word ou Excel, Copilot dans Power BI dépend d'une capacité Fabric ou Power BI Premium (F2 ou supérieur, P1 ou supérieur) et doit être activé au niveau du tenant. La décision est d'infrastructure, pas de poste.

Pourquoi les réponses de Copilot sur mon rapport sont-elles incohérentes ? Dans la quasi-totalité des cas, le modèle sémantique est en cause : mesures ambiguës ou dupliquées, colonnes non décrites, relations mal orientées, noms techniques. L'assistant choisit alors sans indiquer qu'il a choisi.

Le DAX généré est-il fiable ? Il est syntaxiquement correct la plupart du temps, et sémantiquement correct seulement si le modèle est explicite. Toute mesure destinée à un usage officiel se relit — une erreur de DAX produit un chiffre plausible, jamais une erreur visible.

Copilot peut-il créer un modèle sémantique de zéro ? Non, et c'est cohérent avec sa logique : il travaille à partir d'un modèle, il ne le conçoit pas. La modélisation reste un travail humain, et c'est précisément l'investissement qui détermine la qualité de tout ce que l'assistant produira ensuite.

Sources

Charlène BasteiroPlanifier un échange30 min avec CharlèneDirectrice des opérations
Charlène Basteiro

Votre projet IA avec Charlène

30 minutes · Directrice des opérations Noolya