Table sans relation dans Power BI Desktop : le guide du modèle sémantique

Power BI : quelle table peut rester sans relation dans le modèle sémantique (et laquelle supprimer) ?

Vous ouvrez la vue Modèle de Power BI Desktop et quelques tables flottent à l’écart, sans aucun trait vers le reste du schéma. Deux réflexes reviennent souvent : les relier à tout prix, ou les effacer. Les deux peuvent être des erreurs. Certaines sont faites pour rester isolées, d’autres n’auraient jamais dû être chargées, et d’autres encore manquent cruellement d’une relation.

Cet article vous donne la règle pour trancher, les 6 cas où une table vit très bien dans Power BI sans relation, les étapes intermédiaires à ne pas importer du tout, et ce qu’il faut absolument relier.

En bref

• Une relation sert à propager une sélection d’un endroit du schéma vers un autre. S’il n’y a rien à propager, pas besoin de relation.
• Mesures, paramètres, segments déconnectés, groupes de calcul et informations techniques restent volontairement isolés.
• Les étapes intermédiaires ne doivent pas être isolées : elles ne doivent pas être chargées du tout.

Pourquoi relier des tables : filtrer les données d’une table à l’autre

Une relation ne sert qu’à une chose : propager un filtre, c’est-à-dire filtrer les données d’un côté du schéma à partir d’une sélection faite de l’autre. Quand vous cliquez sur « France » dans un segment, la relation entre la dimension Pays et les ventes transmet cette sélection : le moteur ne garde que les lignes concernées, puis calcule vos mesures.

Devant une table isolée, posez-vous donc une seule question : ses colonnes doivent-elles restreindre ce qu’affiche une autre partie du schéma ?

• Oui : il lui faut une relation (ou, à défaut, une relation virtuelle écrite dans une mesure).
• Non : elle peut rester seule. C’est même souvent le signe d’un schéma bien construit.
• Elle ne sert à rien dans le rapport : elle n’a rien à faire dans le schéma.

Vidéo MYPE : les différentes relations dans la vue Modèle

Table de mesures, paramètres, segments : 6 cas sans relation dans Power BI

1. La table de mesures

Créer une table vide (via « Entrer des données », avec un seul champ que l’on masque ensuite) pour y ranger toutes vos mesures est une bonne pratique. Elle ne contient rien à filtrer : une mesure s’évalue dans le contexte du visuel, quel que soit l’endroit où elle est rangée. Aucune relation n’est donc nécessaire.

Vidéo MYPE : regrouper vos mesures au même endroit

2. Les paramètres de plage numérique (« what-if »)

Un paramètre de plage numérique génère une liste de valeurs (par exemple de 0 % à 20 % par pas de 1 %) et un segment sous forme de curseur. Une mesure lit la valeur choisie avec SELECTEDVALUE et l’injecte dans le calcul : hausse de prix, inflation, augmentation de salaire. Relier cette liste aux ventes n’aurait aucun sens : « 5 % » n’est pas un attribut d’une vente.

👉 Pour aller plus loin : créer un simulateur de salaire

Vidéo MYPE : utiliser les paramètres de scénario

3. Les paramètres de champs

Même principe pour les paramètres de champs : la liste générée contient des champs ou des mesures (Pays, Produit, Commercial), et l’axe du graphique change selon la sélection de l’utilisateur. Cette fonctionnalité est gérée par Power BI lui-même, sans aucune relation.

👉 Pour aller plus loin : utiliser les paramètres de champs

Vidéo MYPE : tutoriel sur les paramètres de champs

Dans notre livre (p. 111) : « Les différents types de paramètres ».

4. Les tables de segments « déconnectés »

Choix de la devise, de l’unité d’affichage (k€ ou M€), du nombre d’éléments d’un Top N, d’un seuil d’alerte… Vous saisissez quelques lignes, vous en faites un segment, et une mesure réagit au choix avec SELECTEDVALUE et SWITCH. Là encore, rien n’est à restreindre : c’est la mesure qui lit la sélection.

Cas particulier : si vous voulez que ce segment agisse réellement sur les ventes sans relation physique, la fonction TREATAS crée une relation virtuelle à l’intérieur de la mesure.

👉 Pour aller plus loin : la fonction TOPN

Vidéo MYPE : les fonctions SWITCH et SELECTEDVALUE

5. Les groupes de calcul

Un groupe de calcul apparaît dans le schéma avec un seul champ (par exemple Période : MTD, QTD, YTD). Il modifie le calcul de vos mesures existantes en DAX ; il ne restreint aucune ligne. Pas de relation, donc.

Vidéo MYPE : les groupes de calcul

Dans notre livre (p. 177) : « Groupe de calcul », le tutoriel pas à pas.

6. La table de correspondance de la RLS dynamique

Pour une RLS dynamique, on crée une liste de correspondance « adresse e-mail ↔ périmètre » (région, agence, portefeuille client). Elle est le plus souvent laissée déconnectée : le rôle de sécurité contient une seule règle DAX qui lit cette liste avec USERPRINCIPALNAME() et ne garde, dans la dimension Région, que les périmètres autorisés pour la personne connectée. Résultat : un seul rôle au lieu d’un par région, et un nouveau collaborateur se gère en ajoutant une ligne, sans relation à créer ni fichier à republier. La relier à la dimension fonctionne aussi, mais la version déconnectée évite les relations bidirectionnelles.

👉 Pour aller plus loin : qu’est-ce que la RLS dynamique et comment l’utiliser ?

Vidéo MYPE : mettre en place la RLS dynamique

7. Le calendrier déconnecté pour une analyse glissante

Cas classique : l’utilisateur choisit une date dans un segment, et les visuels affichent les 12 derniers mois par rapport à cette date. Si ce segment s’appuyait sur le calendrier relié aux ventes, il ne garderait que ce seul jour… et le graphique n’afficherait qu’un point. La solution : une copie du calendrier, sans relation, qui sert uniquement de segment. Une mesure récupère la date choisie avec SELECTEDVALUE, puis calcule sur la fenêtre des 12 mois précédents (par exemple avec DATESINPERIOD), pendant que le calendrier relié continue d’alimenter l’axe du graphique.

Vidéo MYPE : visualiser les 12 derniers mois en sélectionnant une seule date

8. Les tables techniques : date d’actualisation et documentation

Une ligne unique qui stocke la date et l’heure de la dernière actualisation (DateTime.LocalNow() dans l’éditeur) pour l’afficher dans une carte. Une liste des mesures et de leur définition, qui sert de documentation aux lecteurs. Des libellés pour des titres dynamiques. Rien de tout cela n’a vocation à restreindre quoi que ce soit, ni besoin d’une colonne calculée ou d’une relation pour jouer son rôle.

Les requêtes qui ne doivent même pas arriver dans le fichier pbix

Deuxième famille, à ne surtout pas confondre avec la première : ce qui est isolé parce que cela n’aurait jamais dû être chargé dans le fichier .pbix. Dans Power Query, beaucoup de requêtes ne sont que des étapes intermédiaires :

• les exports mensuels d’une boutique Shopify (un CSV de commandes par mois, avec les en-têtes sur la première ligne) : la combinaison de plusieurs fichiers produit un résultat final, mais les requêtes d’exemple et la fonction générées automatiquement n’ont rien à faire dans le schéma ;
• une table de correspondance déjà fusionnée dans les ventes ;
• deux sources ajoutées l’une à l’autre (ventes 2025 et ventes 2026) : seul le résultat de l’ajout compte ;
• les requêtes de référence qui servent de contrôle (lignes en erreur, doublons) ;
• les paramètres de connexion et les fonctions personnalisées.

La bonne réponse n’est pas de les effacer, puisque le résultat final en dépend, mais de décocher « Activer le chargement » (clic droit sur la requête). Les tables Power Query concernées restent dans l’éditeur avec toutes leurs étapes appliquées, mais leur contenu n’est plus visible dans la vue Modèle ni dans le volet Données du rapport. Si ces mêmes étapes servent à plusieurs rapports, déplacez-les dans un flux de données partagé.

Attention à la différence entre ces deux options : décocher « Inclure dans l’actualisation » fige le contenu (utile pour un fichier Excel d’historique qui ne bouge plus), mais il reste chargé. Désactiver le chargement, au contraire, retire le résultat du schéma sans rien perdre dans l’éditeur.

👉 Pour aller plus loin : un classeur par mois, faut-il les charger un par un ? et corriger des dizaines de valeurs grâce à une correspondance

Vidéos MYPE : combiner les classeurs d’un dossier en un clic et les différentes fusions (jointures)

Dans notre livre (p. 189) : « Les 3 avantages de désactiver le chargement ».

Les tables qui, elles, doivent être reliées : faits, dimensions et table de dates

À l’inverse, certaines tables isolées signalent un vrai problème :

• Une dimension sans relation (clients, produits, régions) : vos segments n’ont aucun effet, et la même valeur se répète sur chaque ligne de vos visuels.
• Deux tables de faits à comparer (ventes et budget) : elles ne se relient pas entre elles, mais chacune doit être reliée aux dimensions communes.
• La table de dates : sans relation vers la colonne de date de vos faits, aucune fonction d’intelligence temporelle ne fonctionne. Si vos ventes portent plusieurs dates (commande, livraison), créez une relation active et des relations inactives, activées dans les mesures avec USERELATIONSHIP.

Même logique en mode composite, quand des données importées côtoient des données interrogées en requête directe sur une base SQL : les relations restent nécessaires, même si certaines deviennent « limitées ».

👉 Pour aller plus loin : la même valeur se répète dans mon visuel, même période sur 2 tables en même temps et mes infos clients sont éparpillées

Vidéos MYPE : réutiliser le calendrier en 2 secondes et gérer plusieurs dates avec USERELATIONSHIP

Dans notre livre (p. 123) : « 3 bonnes raisons d’utiliser un calendrier ».

Ranger les tables sans relation : nommage, format et masquage

Isolé ne veut pas dire en désordre. Quelques conventions suffisent pour que n’importe qui comprenne le rôle de chaque élément :

• préfixez-les (_Mesures, Param_Devise, zz_Info) pour les repérer d’un coup d’œil ;
• dans la vue Modèle, regroupez-les dans une disposition à part ;
• masquez les champs techniques et ne laissez apparents que ceux utiles aux segments ;
• définissez dès la création le format des champs et des mesures (pourcentage pour un taux, devise pour un montant) ;
• renseignez leur rôle dans la description de chacun ; Tabular Editor permet de le faire en masse.

Les avantages d’un modèle sans tables inutiles

Les avantages se voient vite, dans Power BI Desktop comme une fois le rapport publié :

• De meilleures performances : moins de volume chargé, une actualisation plus rapide et moins d’interrogations de la source, surtout quand le pliage de requêtes (query folding) ne s’applique pas.
• Un volet Données lisible : les personnes qui créent leurs propres visuels à partir du modèle sémantique trouvent tout de suite le bon champ Pays, au lieu de trois.
• Une maintenance plus simple : pour modifier une règle ou mettre à jour une source, vous savez où intervenir.
• Moins d’erreurs de visualisation : plus de risque de glisser dans un graphique un champ venant d’une étape intermédiaire.

Avant de publier, un dernier passage dans la vue Modèle suffit à améliorer la lisibilité. Dans le service Power BI, le contenu publié (l’ancien jeu de données) est aussi celui que réutilisent les rapports d’autres équipes : chaque élément inutile y est multiplié d’autant, comme dans les modèles qui en dérivent.

Checklist : relier, laisser isolée ou ne pas charger ?

Aller plus loin avec nos formations Power BI

Ces choix de modélisation se travaillent mieux sur vos propres données que dans l’abstrait. Nos formations Power BIvous apprennent à construire un schéma propre, de l’import des sources à la publication, et préparent aussi à la certification PL-300.

Pour garder ces bonnes pratiques sous la main, toutes les infographies citées viennent de notre livre « Microsoft Power BI en images ». Et si votre vue Modèle ressemble à un plat de spaghettis, lisez aussi trop de tables dans la vue Modèle et notre article sur la dette technique des rapports.