Trois dashboards montrent trois versions des « ventes ». Un utilise la date de commande, l’autre la facture, le troisième retire les retours. Power BI rend la construction et le partage plus rapides. Le modèle sémantique doit encore choisir grain, relations et mesures.

Power Query extrait et transforme. Le modèle tabulaire compresse les colonnes et relie faits aux dimensions. DAX calcule dans le contexte de filtre. Le service rafraîchit puis applique les droits. Une erreur à n’importe quelle étape peut produire un visuel propre et un chiffre faux.

Une mesure qu’on peut vérifier

Je définirais :

1. grain : une ligne de facture;
2. date : date comptable;
3. montant : hors taxes, devise convertie au taux du jour;
4. retours : avoirs comptabilisés dans la période;
5. exclusions : transactions internes;
6. formule : VentesNettes = Factures - Avoirs;
7. propriétaire : contrôle financier.

Le modèle utilise une dimension Date reliée au champ voulu. Une relation plusieurs-à-plusieurs non maîtrisée peut multiplier les montants. Je compare nombre de lignes, clés distinctes et total avant/après chaque fusion. Un mois témoin est rapproché du grand livre.

Les mesures certifiées vivent dans un jeu partagé. Les analystes peuvent créer leurs explorations autour sans recopier la définition. Chaque rapport affiche source, dernier rafraîchissement et version de mesure.

La publication devient une opération

Une passerelle relie les sources locales au service. Son compte, certificat, réseau et capacité sont surveillés. Un rafraîchissement partiel ne remplace pas la version saine : on charge, valide, puis publie. Les erreurs et rejets sont visibles.

La sécurité au niveau des lignes filtre par région ou rôle, mais doit être testée avec des utilisateurs représentatifs. Masquer une page n’empêche pas l’accès au modèle. Les exports créent des copies; les données sensibles demandent restrictions et audit.

Le libre-service peut saturer la source si cent modèles extraient la même table. Des jeux réutilisables, des horaires et une capacité mesurée réduisent le conflit. On suit durée, échecs, fraîcheur et requêtes lentes.

Tester la sécurité comme une matrice

Je créerais des comptes de test pour vendeur, directeur régional, finance et administrateur. Un script interroge le modèle avec chacun et vérifie les régions visibles, les totaux et les exports permis. Le test inclut un utilisateur sans région et un membre de deux groupes. Après chaque changement de relation ou rôle, le pipeline rejoue la matrice. Les journaux montrent l’identité effective et le filtre appliqué sans exposer les lignes. Cette méthode attrape une relation bidirectionnelle qui contourne la règle ou un groupe mal synchronisé. La sécurité au niveau des lignes devient ainsi une propriété testée du modèle, pas un cadenas affiché dans l’interface.

Je créerais un catalogue de dix mesures officielles avec définition, DAX, source, rapprochement et propriétaire. Puis j’autoriserais largement l’exploration. L’autonomie fonctionne mieux lorsqu’un analyste peut inventer une question sans réinventer le sens des colonnes de base.