Lorsqu’une entreprise a standardisé son informatique sur Microsoft 365, Azure et Entra ID, maintenir un outil de BI isolé comme Looker devient coûteux et source de friction : double authentification, silo de données, facturation séparée et montée en compétence dispersée. Centraliser l’analytique d’entreprise sur Power BI permet de réunir la BI au cœur de l’écosystème Microsoft, de réduire les coûts de licence et d’aligner les équipes sur un socle commun. La migration de Looker vers Power BI est un projet de convergence qui touche autant les données que la gouvernance.
Pourquoi centraliser sur Power BI ?
Looker (désormais intégré à Google Cloud) repose sur un langage de modélisation propriétaire, LookML, qui a fait sa force dans les organisations orientées data engineering. Power BI, lui, s’appuie sur DAX et Power Query, et s’intègre nativement à Excel, Teams, SharePoint et Azure Synapse. Pour une entreprise déjà engagée dans Microsoft, le bénéfice est multiple : une licence souvent déjà incluse dans les abonnements M365, une gouvernance unifiée via Entra ID, et une distribution des rapports directement dans les outils que les collaborateurs utilisent au quotidien.
La centralisation répond aussi à un enjeu de cohérence : des KPI définis une seule fois, un catalogue de rapports unique, et une équipe data qui ne maintient plus deux plateformes aux logiques différentes.
Les différences concrètes entre Looker et Power BI
| Dimension | Looker | Power BI |
|---|---|---|
| Modélisation | LookML (code, versionné dans Git) | Modèle tabulaire, DAX, Power Query |
| Langage de calcul | SQL généré depuis LookML | DAX (mesures), M (préparation) |
| Déploiement | Looker (Google Cloud) | Power BI Service, intégré M365 |
| Gouvernance | Projets Git, rôles et permissions | Workspaces, RLS, applications Power BI |
| Distribution | Embedded analytics, portail Looker | Teams, SharePoint, Power BI Embedded |
| Préparation | Derivés (PDTs) | Dataflows, Datamarts |
Les étapes précises de la migration
-
Inventaire des modèles LookML : recenser les explores, les vues, les dimensions et les mesures, qui concentrent l’essentiel de la logique métier.
-
Extraction de la sémantique métier : traduire chaque dimension et mesure LookML en une spécification claire (formule, granularité, filtres) indépendante de la syntaxe.
-
Conception du modèle Power BI : reconstruire le modèle de données dans Power BI (relations en étoile ou snowflake), en choisissant entre mode Import, DirectQuery ou composite selon les volumes.
-
Traduction des mesures en DAX : convertir les mesures LookML en formules DAX, en portant une attention particulière aux agrégations, aux calculs temporels et aux filtres de sécurité.
-
Mise en place de la sécurité : reproduire la row-level security et les permissions utilisateurs de Looker via les rôles RLS de Power BI.
-
Reconstruction des dashboards : recréer les looks et dashboards dans Power BI en respectant les standards visuels de l’entreprise.
-
Validation croisée : comparer chaque KPI entre Looker et Power BI sur des périodes de référence jusqu’à concordance exacte.
-
Déploiement et bascule : publier dans les workspaces, distribuer via Teams et les applications Power BI, puis désactiver Looker progressivement.
Les pièges à éviter et leurs parades
| Risque | Conséquence | Parade |
|---|---|---|
| Mesures LookML mal traduites en DAX | KPI divergents | Spécification écrite + tests numériques |
| Différences de contexte de calcul | Totaux ou ratios faux | Maîtriser le contexte de filtre DAX |
| Sécurité non reproduite | Fuite de données | Cartographier les permissions avant la bascule |
| Volumes trop lourds en Import | Rafraîchissements lents | Choisir DirectQuery ou partitions incrémentales |
| Gouvernance insuffisante | Prolifération de rapports | Workspaces structurés et rôles clairs |
Les bonnes pratiques d’une centralisation réussie
- Établir un référentiel des mesures (dictionnaire sémantique) avant de coder, pour aligner LookML et DAX.
- Valider la connectivité des sources (bases, entrepôts, API) vers Power BI dès l’audit initial.
- Adopter les best practices de modélisation Power BI : modèle en étoile, mesures uniques, tables de dates dédiées.
- Mettre en place un plan de migration par lots, en commençant par les tableaux de bord les plus utilisés.
- Maintenir une période de double lecture pour sécuriser la confiance des utilisateurs.
Embedded analytics et distribution des rapports
Looker est souvent utilisé pour de l’embedded analytics : des tableaux de bord intégrés à vos propres applications. Ce cas d’usage exige une attention particulière lors de la bascule vers Power BI :
- Power BI Embedded : la capacité Azure dédiée permet d’intégrer des rapports dans vos applications via l’API JavaScript et des jetons d’embarquement, en remplacement des embeds Looker. Il faut redéfinir le contrôle d’accès (jetons par utilisateur ou par organisation) pour préserver la sécurité.
- Distribution interne : les looks et dashboards partagés via le portail Looker se transforment en applications Power BI publiées dans des workspaces, puis diffusées via Teams, SharePoint ou le portail web.
- Actualisation des données : planifier les rafraîchissements (mode Import) ou utiliser DirectQuery pour des données temps réel, en reproduisant les PDTs (persistent derived tables) de Looker par des tables agrégées ou des dataflows.
- Alertes et abonnements : configurer les alertes de données et les abonnements par e-mail pour que les utilisateurs retrouvent leurs notifications habituelles sans interruption.
Traiter l’embarquement comme un chantier à part entière — et non comme un simple transfert de visuels — garantit que les applications consommatrices de données continuent de fonctionner sans couture après la migration.
DAX avancé : contextes de filtre et time intelligence
La traduction des mesures LookML en DAX est le cœur technique d’une migration Looker vers Power BI, et c’est là que se jouent la plupart des écarts de KPI. Deux notions de DAX concentrent les difficultés.
Le contexte de filtre détermine la valeur d’une mesure selon les filtres, lignes et colonnes actifs. Une mesure LookML qui calcule une part de marché ou un ratio doit être traduite en DAX en maîtrisant CALCULATE, qui modifie le contexte, et les fonctions d’itération (SUMX, AVERAGEX) qui évaluent une expression ligne par ligne. Une traduction trop littérale produit des totaux faux, même quand les valeurs individuelles semblent justes.
La time intelligence (DATEADD, SAMEPERIODLASTYEAR, DATESYTD, TOTALYTD) reproduit les comparaisons temporelles de LookML, mais exige une table de dates dédiée, marquée comme table de dates, sans laquelle ces fonctions échouent silencieusement. Les calculs de variation, de cumul annuel ou de moyenne mobile reposent tous sur ce prérequis.
La parade est méthodique : spécifier chaque mesure en langage métier (formule, granularité, filtres) avant de coder, puis valider numériquement chaque mesure sur des périodes de référence en comparant Looker et Power BI. Un dictionnaire de mesures partagé, des tests systématiques et une revue par les métiers transforment cette traduction en un socle fiable.
La conduite du changement
Le passage de LookML à DAX demande aux équipes de réapprendre à modéliser et à calculer. Performances Digital accompagne cette montée en compétence : formation à la modélisation Power BI et au DAX, ateliers pratiques sur vos propres données et transfert de connaissances pour que votre équipe devienne autonome sur la nouvelle plateforme analytique.
Centraliser votre analytique d’entreprise sur Power BI aligne votre BI avec votre écosystème Microsoft, réduit les coûts et simplifie la gouvernance. Performances Digital pilote la migration de Looker vers Power BI de bout en bout : inventaire LookML, traduction des mesures, modélisation, sécurité et formation. Demandez votre devis gratuit : nous auditerons vos modèles LookML et vos dashboards pour bâtir une trajectoire de convergence sûre et chiffrée.
