Looker Studio vs Power BI : lequel de ces 2 outils de BI/dataviz choisir ?

Avant de commencer, voici une formation gratuite en rapport avec la question traitée dans cet article qui pourrait vous intéresser :

Formation sur Looker Studio (2023)

Allez, c’est parti ! 🤓

Looker Studio (ex Google Data Studio) et Power BI sont deux outils permettant (entre autres) de visualiser des données. Power BI étant un outil plus avancé que Looker Studio sur la partie transformation et modélisation des données, il est considéré comme un outil de Business Intelligence (BI).

Ces deux outils font partie du top 3 des outils les plus utilisés chez nos clients pour répondre à des besoins en data visualisation (avec Tableau Software).

Vous trouverez ci-dessous les principales questions que vous devez vous poser pour trancher entre Looker Studio et Power BI.

Votre entreprise évolue-t-elle dans l’écosystème Microsoft ou Google ?

Power BI appartenant à Microsoft et Looker Studio à Google, il est souvent plus judicieux de choisir un outil de data visualisation qui se situe dans votre écosystème actuel principal en raison de l’intégration et l’interopérabilité étroites entre les différents produits de chacun des fournisseurs.

Par exemple, Power BI étant développé par Microsoft, il est étroitement intégré avec d’autres produits Microsoft tel que Excel, Azure Synapse, SharePoint, Teams, etc. Vous pouvez ainsi facilement extraire des données de ces sources et les visualiser dans Power BI.

La connexion de Looker Studio avec une source Microsoft est souvent plus compliquée à mettre en place. Inversement, la connexion de Power BI avec une source Google comme Google Ads est également plus compliquée à mettre en place qu’avec Looker Studio.

Êtes-vous en mesure d’établir un traitement de données en amont sur un data warehouse ?

Très souvent dans les entreprises modernes en termes de “pratiques & stack data” les principales étapes pour réaliser un dashboard/reporting sont les suivantes :

• Étape 1 : Automatisation de l’ingestion des données brutes dans le data warehouse
• Étape 2 : Automatisation de la transformation (nettoyage, consolidation, création de nouvelles métriques et dimensions, etc) des données brutes dans le data warehouse
• Étape 3 : Création des métriques et dimensions ne pouvant pas être créées du côté du data warehouse en raison des éventuels problèmes d’agrégation/pondération
• Étape 4 : Création du dashboard/reporting
• Étape 5 : Partage du dashboard/reporting

Que signifie “en raison des éventuels problèmes d’agrégation/pondération” ?

Pour répondre, prenons comme métrique le taux de conversion (avec taux de conversion = nombre de conversions/nombre d’utilisateurs).

Imaginez que l’utilisateur d’un dashboard/reporting applique des filtres sur plusieurs dimensions affectant le taux de conversion affiché sur une visualisation, et que ce taux a été calculé en amont dans le data warehouse.

Compte tenu du fait que les données des tables analysées d’un data warehouse sont (en théorie) déjà agrégées pour des raisons de performances et de coûts, si le calcul du taux de conversion relatif au filtrage était réalisé (par l’outil de data visualisation) en faisant la moyenne des taux de conversion concernés, il y aurait un problème de pondération. En effet, la moyenne des taux de conversion agrégés relatifs au filtrage ≠ au taux de conversion sur données non agrégées relatif au filtrage.

On ne somme pas des fractions, on doit les recalculer !

En calculant le taux de conversion (nombre de conversions/nombre d’utilisateurs) de façon dynamique du côté de l’outil de visualisation, il est possible de garantir un taux de conversion toujours adapté aux filtres sélectionnés.

Pour garantir un taux de conversion toujours adapté aux filtres sélectionnés sans qu’il ne soit calculé de façon dynamique du côté de l’outil de visualisation, il faudrait le calculer pour toutes les combinaisons de filtre possibles, ce qui coûterait trop cher en stockage et en calcul.

Les principaux avantages d’établir un traitement de données en amont sur un data warehouse sont les suivants :

• Un seul langage de transformation à maîtriser, le plus souvent du SQL, universellement connu et largement utilisé, facilitant ainsi la montée en compétences des personnes en charge de la transformation (data analystes) et/ou le recrutement de ces personnes
• Une meilleure gouvernance des données au sein de l’entreprise
• Possibilité de distribuer les données transformées dans plusieurs outils (outil dashboard/reporting, CRM, régie publicitaire, outil SAV, ERP, etc)

Ainsi, si vous êtes en mesure d’établir un traitement de données en amont sur un data warehouse, Looker Studio est souvent suffisant.

À l’inverse, si vous n’êtes pas en mesure d’établir un traitement de données en amont sur un data warehouse, Power BI propose une couche de transformation et de modélisation beaucoup plus performante que Looker Studio. Ainsi, en utilisant les langages M (de Power Query) et DAX, il est possible de transformer et modéliser les données directement sur Power BI sans transformer les données en amont dans un data warehouse avec un outil comme dbt entre l’ingestion et la diffusion des données, Power BI s’occupe de tout.

Voici plusieurs actions de transformation et modélisation que vous pouvez réaliser sur power BI :

• Nettoyer des données (transformation avec le langage M de Power Query)
• Fusionner des colonnes (transformation avec le langage M de Power Query)
• Supprimer des colonnes (transformation avec le langage M de Power Query)
• Fusionner des tables (transformation avec le langage M de Power Query)
• Changer le type des données (transformation avec le langage M de Power Query)
• Créer des relations entre différentes tables (modélisation)
• Créer des hiérarchies entre plusieurs dimensions (modélisation, exemple “pays>régions>villes”)
• Créer des colonnes calculées, des mesures et des tables personnalisées (modélisation avec le langage DAX)

Power BI confère donc plus d’autonomie aux utilisateurs finaux sur la transformation et la modélisation des données que Looker Studio. Cependant, la courbe d’apprentissage des langages M de Power Query et DAX est plus raide que celle de l’apprentissage du langage SQL (plus standard).

Avez-vous de gros besoins en termes de mise en page, de choix dans les graphiques, et de création de métriques dynamiques ?

En termes de mise en page, Looker Studio confère plus de flexibilité que Power BI.

Concernant le choix dans les graphiques, Power BI propose un éventail de visualisations plus large que Looker Studio (dont beaucoup sont issues de la communauté).

Pour ce qui est de la création des métriques dynamiques, Power BI permet de faire des calculs dynamiques plus avancés et confère plus de flexibilité que Looker Studio. Il n’y a qu’à voir la taille de la documentation du langage DAX pour s’en rendre compte. Power BI propose une banque de fonctions prédéfinies plus conséquente que Looker Studio.

D’un autre côté, Looker Studio propose plusieurs fonctionnalisés natives non présentes nativement sur Power BI (comme c’est le cas avec les périodes de comparaison par exemple). Ainsi, plusieurs fonctionnalités natives de Looker Studio nécessitent des lignes de DAX sur Power BI et demandent donc plus de temps.

Ici, pour savoir ce qui est le plus adapté pour vous entre Power BI et Looker Studio, nous vous conseillons de définir plusieurs cas d’usage courants, propres à vos besoins, sur ces 3 aspects, à savoir :

• Vos besoins en termes de mise en page
• Vos besoins en termes de choix de graphique
• Vos besoins en termes de création de métriques dynamiques

Puis, dans un second temps, que vous les testiez sur les deux outils afin de pouvoir les évaluer selon 2 critères, à savoir :

• La faisabilité
• Le niveau de complexité

Avez-vous besoin de dahshboards/reportings mobile responsive ?

Sur Looker Studio, il n’est pas possible de créer de reportings/dashboards responsive (en tout cas pas de reportings/dashboards avec une expérience utilisateur acceptable). Power BI est bien plus performant sur ce point-là.

Avez-vous besoin de mettre en place un système d’alerte ?

Si nous prenons les principaux éléments de la chaîne de valeur des “applications data”, à savoir :

• Dashboards/reportings/ descriptifs
• Systèmes d’alerte
• Dashboards/reportings prédictifs
• Dashboards/reportings prescriptifs

Les systèmes d’alerte se situent en 2ème place, c’est un enjeu important pour beaucoup d’entreprises. Looker Studio ne permet pas de mettre en place un système d’alerte, mais Power BI le permet assez facilement. À savoir, Looker Studio Pro le permet ! 🙂

Quel est votre budget ?

Looker Studio est gratuit tandis que Power BI devient payant si vous souhaitez partager les reportings/dashboards créés.

En effet :

• Power BI Desktop est une version gratuite de Power BI destinée à la création de rapports et de visualisations sur un ordinateur local. Cette version peut être téléchargée et utilisée gratuitement
• Power BI Pro est une version payante de Power BI qui offre des fonctionnalités avancées de collaboration et de partage des rapports (9,40€ par utilisateur et par mois)
• Power BI Premium est une version qui confère plus de fonctionnalités et de capacités que Power BI Pro (18,70€ par utilisateur et par mois)

Voici la page officielle des prix : https://powerbi.microsoft.com/fr-fr/pricing/

La licence la plus souvent utilisée chez nos clients est Power BI Pro. Cependant, dans certains cas, pour des raisons de capacité principalement (taille de la mémoire du modèle, fréquence d’actualisation, etc) la licence Power BI Premium est nécessaire.

Comme vous pouvez le voir, la réponse n’est pas tranchée et dépend vraiment de votre contexte et de vos besoins.