Data Studio vs Power BI : ce que j’ai appris en changeant d’outil en cours de mission

J’ai passé des semaines à choisir entre deux outils de tableau de bord.

On ne m’avait jamais demandé un tableau de bord.

C’est la mission qui m’a le plus appris sur le pilotage d’un réseau, et elle m’a appris que la question « Google Data Studio ou Power BI ? » (celle à laquelle des centaines de comparatifs répondent en alignant des fiches techniques) arrive souvent trop tôt. Avant de choisir entre deux outils, encore faut-il être sûr que c’est bien de ce type d’outil qu’on a besoin.

Je forme sur Microsoft Power BI, je livre sur les deux. Ni Google ni Microsoft ne me paient. Voici 8 critères, un tableau à scanner en 30 secondes, un cas vécu, et un verdict tranché par situation.

Une précision de vocabulaire avant de commencer : en avril 2026, Google a renommé Looker Studio en Data Studio, le nom qu’il portait avant 2022. Même outil, mêmes rapports, rien à refaire de votre côté. Si vous cherchez encore « Looker Studio », c’est bien de lui qu’on parle ici. Google est revenu en arrière parce que le nom « Looker Studio » se confondait avec Looker, sa plateforme de BI d’entreprise, qui est un tout autre produit. On y revient plus bas.

Le tableau comparatif en 30 secondes

Critère	Google Data Studio	Microsoft Power BI
1. L’écosystème requis	Un compte Google suffit. Rien à faire ouvrir par la DSI.	Suppose une licence ouverte et un tenant qui autorise l’accès. Souvent hors de votre main.
2. Le cloisonnement par site	Pas de moteur natif. À construire en amont, dans la source.	RLS natif : filtre appliqué automatiquement selon l’utilisateur connecté. Mature.
3. Reproduire un tableau existant	Le tableau croisé groupe les en-têtes de colonnes, mais sur 2 niveaux maximum, avec un seul style pour tout l’en-tête.	Le visuel matrice empile plusieurs niveaux d’en-têtes. Mais pas de style différencié par niveau non plus.
4. Le ticket d’entrée	Gratuit, utilisateurs illimités. Pro : 9 $/utilisateur/mois, facturé par projet Google Cloud.	Free (solo, sans partage). Pro : 14 $/utilisateur/mois. PPU : 24 $. Capacité Fabric : plusieurs milliers de $/mois, mais lecteurs gratuits.
5. Le volume	100 000 lignes par connexion. 5 sources maximum par croisement.	Pro : modèle 1 Go, 8 actualisations/jour. PPU : 100 Go, 48/jour.
6. D’où viennent vos données	21 connecteurs natifs, tous Google. Le reste via des connecteurs partenaires payants (20 à 350 $/mois chacun).	Plus de 250 connecteurs natifs gratuits (SQL Server, Oracle, SAP, Excel…).
7. La résidence des données	Pro : résidence UE possible, fixée à la création de l’abonnement et non modifiable ensuite.	Région attribuée à la création du tenant. Changement possible via le support, mais destructif.
8. La diffusion aux managers	Un lien web. Rien à installer.	Passe par le compte Microsoft de l’entreprise. Premier accès plus lourd, fluide ensuite.

Tarifs relevés en juillet 2026, en dollars américains, par utilisateur et par mois, engagement annuel. Aucun des deux éditeurs ne publie de tarif public en euros : la conversion dépend de votre canal de facturation. Sources : pages officielles Google Cloud et Microsoft. Ces montants évoluent régulièrement, à revérifier avant toute décision d’achat.

Sur le critère 3, une précision qui vaut pour les deux : ni l’un ni l’autre ne sait mettre en forme conditionnellement le texte d’un en-tête, ni styler différemment chaque niveau de la hiérarchie. Et aucun des deux ne reproduit une page composée à la main : c’est l’objet de l’acte 2.

Acte 1 : la DSI décide avant vous

Le contexte. Un réseau de plusieurs centaines de magasins. Chaque semaine, un directeur régional reconstituait son reporting à la main, en copiant-collant des tableaux denses. Environ 20 % de son temps.

Sa demande tenait en une phrase : « qu’il se remplisse tout seul ».

On démarre en Power BI. Le prototype est construit, livré, hébergé sur l’espace SharePoint du groupe. Il fonctionne.

Puis le mur : pas de licence Power BI ouverte pour ce périmètre, et un tenant Microsoft fermé aux accès applicatifs tiers. Deux décisions prises ailleurs, bien avant nous, parfaitement légitimes du point de vue de la DSI. Aucun argument technique ne les fera bouger dans le calendrier d’un directeur régional.

Première leçon, et elle vaut pour vous : avant de comparer les fonctionnalités, demandez ce que votre SI vous autorise à brancher. Cette question vous fera gagner trois semaines.

Acte 2 : je livre, et la vraie demande arrive

On pivote : BigQuery pour consolider, Google Data Studio pour restituer. C’était même le choix évident : Google Data Studio était son seul accès Google. Le tableau de bord est automatisé, hébergé en France, il tourne pour quelques centimes par mois.

Je livre.

Et c’est là que la demande se complète :

Qu’il se remplisse tout seul. Mais je veux le rendu exactement identique au mien.

Exactement. Pas mieux. Identique.

Alors j’ai regardé son tableau. Vraiment regardé, cette fois.

Quatre blocs juxtaposés, chacun avec un nombre de sous-colonnes différent : le premier en chapeaute deux, le suivant trois, le dernier deux mais avec des libellés qui n’ont aucun rapport avec les autres. Des lignes qui n’ont rien à voir entre elles : un décompte, des pourcentages, des euros, des points, et des cases vides là où la donnée n’existe pas. Deux niveaux d’en-têtes, dans deux verts différents. Une police propriétaire.

Ce n’était pas un tableau croisé.

Et c’est tout le problème. Un outil de dataviz construit un tableau à partir de dimensions : il croise des lignes et des colonnes, donc tous les blocs portent les mêmes sous-colonnes et toutes les cellules ont le même type. Lui avait composé une page à la main, bloc par bloc, pendant des années. Rien là-dedans ne se déduit d’une dimension.

Soyons précis, parce que je me suis trompé sur ce point avant de vérifier : Google Data Studio sait grouper des en-têtes de colonnes. Son tableau croisé le fait nativement, sur deux niveaux. Power BI le fait aussi, avec son visuel matrice. Ce n’est pas là que ça bloque.

Ça bloque parce que ce tableau n’est structurellement pas un objet de BI. Aucun des deux outils ne le reproduira : ni Google Data Studio, ni Power BI, ni un troisième. Pas par faiblesse : par nature.

Deuxième leçon : avant de choisir un outil, regardez la structure de ce que vos équipes utilisent déjà. Pas le nom qu’elles lui donnent. Sa structure.

Acte 3 : ce qui a gagné n’est pas un outil de BI

Alors j’ai arrêté de chercher le bon outil de dataviz.

Le livrable final est un PowerPoint. Généré automatiquement depuis BigQuery, tous les lundis à 10 h, déposé là où le directeur régional regarde déjà : sa boîte mail. Pas de lien à retrouver, pas de favori à sauvegarder, aucun filtre à manipuler. Un rendu au pixel près de ce qu’il fabriquait à la main.

Il l’a validé en 24 heures. Un deuxième directeur régional est déjà branché.

Il ne demandait pas un meilleur tableau de bord. Il demandait le sien, sans les heures de copier-coller.

Ce n’était pas un tableau de bord. C’était un document. Alors j’ai livré un document.

Une précision honnête, parce que la nuance compte : Google Data Studio n’est pas mort dans cette histoire. Il reste au programme pour la consultation interactive : explorer, filtrer, creuser. Simplement, ce n’est pas ce dont on avait besoin le lundi matin. Deux besoins, deux livrables. C’est le raccourci « un outil pour tout » qui était faux.

Le critère que tout le monde saute : qui a le droit de voir quoi

Revenons au comparatif, parce qu’il reste utile, à condition de savoir qu’on a bien besoin d’un outil de BI.

Si vous pilotez un réseau, voici le critère qui décide, plus souvent que le prix. Vous avez quarante directeurs de magasin. Chacun doit voir son magasin, et seulement le sien. Vous, vous voyez tout. Le directeur régional voit sa région.

Power BI a un moteur pour ça, le RLS (row-level security, sécurité au niveau de la ligne) : vous déclarez qui voit quoi, et l’outil applique le filtre tout seul, à chaque requête, selon la personne connectée. C’est mature, c’est standard, c’est fait pour ça.

Google Data Studio n’a pas cet équivalent. Le cloisonnement existe, mais il se construit en amont, dans vos données : des vues pré-filtrées, des accès paramétrés. Chez Power BI la sécurité est dans l’outil ; chez Google Data Studio, elle est dans votre plomberie, donc c’est à vous de la prévoir. Ce n’est pas une impasse. C’est une charge de conception qu’il faut avoir vue avant de s’engager, pas trois semaines après.

Une précision utile : pour du cloisonnement vraiment étanche entre clients externes, Google ne pousse pas Data Studio mais Looker, son outil de BI d’entreprise, homonyme et pourtant tout autre chose, à tarif d’entreprise. On sort alors complètement de la logique du gratuit.

Le prix : gratuit ne veut pas dire sans coût

Sur le papier, le match est vite plié : Google Data Studio est gratuit, sans limite d’utilisateurs. Power BI Pro coûte 14 $ par personne et par mois.

Deux nuances. D’abord, un piège de facturation : Google Data Studio Pro se facture par projet Google Cloud, pas par organisation. Plusieurs projets (un par filiale, par exemple), et vous multipliez les abonnements sans l’avoir vu venir. Notez que Pro n’est pas obligatoire : la version gratuite couvre l’essentiel des besoins d’un réseau de PME.

Ensuite, un renversement côté Microsoft : à partir d’un certain niveau de licence par capacité, les lecteurs deviennent gratuits et illimités. Si vous avez trois personnes qui construisent les rapports et quarante qui les consultent, le calcul par utilisateur n’est plus le bon. Ces licences se comptent en milliers de dollars par mois, ordre de grandeur, à chiffrer au cas par cas, les grilles sont mouvantes et je ne veux pas vous donner un chiffre faux.

Mais voici le vrai message : le coût de l’outil n’est presque jamais le poste principal. Ce qui coûte, c’est la chaîne en amont : aller chercher les données, les consolider, les fiabiliser. Un Google Data Studio gratuit posé sur des données sales coûte plus cher qu’un Power BI payant posé sur un modèle propre. Le prix de la licence est la partie visible, et la moins chère. Dans ma mission, le livrable final tourne pour quelques centimes par mois. Tout le travail était ailleurs.

Le volume : le faux problème

Le plafond de Google Data Studio fait peur quand on le lit : 100 000 lignes par connexion.

Mettons-le en face du réel. Ce réseau de plusieurs centaines de magasins, suivi jour par jour et magasin par magasin, tient dans environ 11 000 lignes. Un neuvième du plafond.

Les limites de Google Data Studio ne sont pas votre problème. Elles le deviennent si vous voulez plusieurs années d’historique à la maille fine, ou si vous croisez beaucoup de sources : la limite des 5 sources par croisement arrive plus vite que celle des lignes. Mais pour piloter un réseau au quotidien, le volume est un faux débat. On refuse Google Data Studio pour de mauvaises raisons bien plus souvent qu’on ne bute sur ses limites.

Où vivent vos données

Les deux éditeurs sont américains, donc soumis au CLOUD Act. Aucun des deux n’est « plus RGPD » que l’autre, et méfiez-vous de qui vous dira le contraire.

La différence est ailleurs, dans la réversibilité. Google Data Studio Pro permet une résidence dans l’Union européenne, mais ce choix se fait à la création de l’abonnement et ne se change plus jamais. Power BI attribue une région à votre tenant à sa création, déterminée, et c’est peu connu, par la localisation du tout premier utilisateur inscrit. En changer ensuite est possible, via le support Microsoft, mais l’opération est destructive : tout est supprimé et à reconstruire à la main.

Dans les deux cas, la règle est la même : cette décision se prend au début, ou elle se paie cher. Un détail que presque personne ne regarde : dans ma mission, les données sont dans une région simple (Paris) et non dans une multi-région européenne où elles circuleraient entre plusieurs pays. C’est un choix qui se fait en dix secondes à la création, et jamais après.

Si la souveraineté est un enjeu réel chez vous (santé, juridique, expertise comptable), aucun de ces deux outils n’est la réponse par défaut, et c’est une autre conversation.

Deux pièges Google Data Studio à éviter

Deux heures perdues chacun, offertes :

1. Les fonctions de semaine ISO sont refusées dans un champ calculé Google Data Studio quand la source est BigQuery. Calculez la semaine en amont, côté BigQuery, pas dans Looker.
2. Un champ calculé créé depuis un graphique reste prisonnier de ce graphique. Vous le recréez ensuite sur chaque page, à l’identique, en vous demandant pourquoi. Règle d’or : créez toujours vos champs au niveau de la source, jamais depuis un visuel.

Mon verdict, par situation

Pas de « ça dépend ». Cinq situations, cinq réponses.

Vous êtes déjà sous Microsoft 365 avec Power BI ouvert. Prenez Power BI, ne cherchez pas plus loin. Le RLS seul justifie le choix en multi-sites, et vos données sont déjà à côté.

Votre SI est fermé, ou vous n’avez pas de licence BI, ou vos données vivent déjà chez Google. Google Data Studio, avec BigQuery derrière si le volume monte. Vous serez autonome, vite, pour presque rien.

Vous devez cloisonner strictement des dizaines de sites. Power BI, ou Google Data Studio à condition d’assumer de construire la sécurité en amont. Décidez-le maintenant, pas après la première fuite de chiffres entre deux magasins.

Votre contrôle de gestion ne lâchera jamais Excel. Budget contre réalisé, cumul depuis janvier, comparaison à N-1 sur douze mois glissants : ces calculs sont natifs dans Power BI, et son tableau croisé Excel se branche en direct sur le modèle publié : vos équipes gardent leur interface, les chiffres se mettent à jour tout seuls. Google Data Studio n’a aucune fonction de ce type dans ses champs calculés : chaque cumul, chaque comparaison annuelle est à précalculer en amont, dans la source. Si votre finance vit dans le tableur, le débat est clos avant d’avoir commencé.

Vos équipes refont déjà un tableau à la main chaque semaine. Avant de choisir un outil, ouvrez ce tableau et regardez sa structure. Si ses blocs n’ont pas les mêmes colonnes, si ses lignes mélangent les euros, les pourcentages et les décomptes, si des cases sont vides par construction, alors ce n’est pas un tableau de bord, c’est un document. Aucun outil de BI ne le reproduira. Générez le document.

Et si vous ne deviez retenir qu’une chose : ne commencez pas par « quel outil ? ». Commencez par deux questions. Qui, chez nous, a le droit d’ouvrir quoi ? Et ce que mes équipes regardent le lundi matin, est-ce vraiment un tableau de bord ? Le reste en découle.

Vous voulez y voir clair sur votre réseau ?

C’est exactement ce que je fais en Audit Flash : deux jours pour cartographier vos données, identifier ce qui est pilotable tout de suite, et vous dire quel outil est réellement branchable chez vous, ou s’il vaut mieux automatiser ce que vous avez déjà. Contactez-moi.