Exporter ses données BigQuery vers Power BI, Tableau et Looker

La plupart des guides vous expliquent comment faire entrer vos données GA4 dans BigQuery. Personne ne vous dit comment les faire ressortir. Et c’est pourtant là que la vraie question se pose : une fois vos événements bien rangés dans BigQuery, comment les brancher sur Power BI, Tableau ou Looker Studio sans y passer la semaine, et surtout sans recevoir une facture qui pique ? Ce guide couvre les trois chemins concrets pour exporter ses données BigQuery vers un outil de dataviz, le piège spécifique aux données GA4, et un bonus que quasiment personne ne fait encore : sortir une table vers un LLM pour l’analyser en langage naturel.

Si l’étape d’avant vous manque, l’ingestion GA4 vers BigQuery est traitée en détail dans le guide exploiter l’export GA4 dans BigQuery. Ici, on part du principe que vos tables events_* sont déjà là.

Pourquoi exporter ses données BigQuery vers un outil BI

BigQuery est excellent pour stocker et requêter, beaucoup moins pour raconter une histoire à un dirigeant. Vos décideurs ne vont pas ouvrir la console GCP pour lire du SQL. Ils veulent un dashboard, une courbe, un chiffre qui bouge. C’est exactement le rôle d’un outil BI.

L’autre raison est le croisement. Vos données GA4 vivent dans BigQuery, mais votre CRM, vos coûts publicitaires et vos données produit vivent ailleurs. Un outil comme Power BI ou Tableau devient le point de rencontre où tout se recoupe. BigQuery reste la source de vérité, la BI devient la couche de présentation.

Le vrai sujet n’est donc pas “est-ce possible” (ça l’est, les trois outils ont un connecteur natif), mais “comment le faire proprement”. Deux décisions comptent vraiment : la structure de la table que vous exposez, et le mode de connexion. On va traiter les deux.

Le piège des données GA4 : des tables imbriquées

Voici l’erreur que je vois le plus souvent. On branche directement la table events_* de GA4 sur Power BI, et là, c’est le drame. Les données GA4 dans BigQuery sont événementielles et imbriquées : event_params et items sont des colonnes de type RECORD / REPEATED, c’est-à-dire des tableaux dans des tableaux. Un outil BI ne sait pas les lire correctement. Résultat : une modélisation illisible, des jointures qui explosent, et des requêtes qui coûtent une fortune.

La solution n’est pas de bricoler côté BI, mais d’aplatir en amont, dans BigQuery, avec une vue ou une table dédiée :

CREATE OR REPLACE TABLE `projet.dataset.bi_events` AS
SELECT
  event_date,
  event_name,
  user_pseudo_id,
  -- On sort les paramètres imbriqués en colonnes plates
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS page_location,
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'source')        AS source,
  (SELECT value.int_value    FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS session_id,
  traffic_source.medium,
  device.category AS device
FROM `projet.dataset.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260601' AND '20260630'

Cette table bi_events est plate, propre, et l’outil BI la lit sans broncher. Pour les techniques d’UNNEST et les requêtes types, j’ai détaillé les cas courants dans les 10 requêtes BigQuery indispensables pour GA4. Retenez la règle : on n’expose jamais les tables brutes à un outil BI, on expose une table aplatie et agrégée.

Chemin 1 : BigQuery vers Looker Studio

C’est le plus rapide, et c’est logique : Looker Studio et BigQuery sont deux produits Google. Le connecteur est natif, gratuit, et il enrichit automatiquement les champs (types, agrégations par défaut).

Concrètement : dans Looker Studio, ajoutez une source de données, choisissez le connecteur BigQuery, puis pointez soit vers votre table bi_events, soit vers une requête SQL personnalisée. Cette seconde option est la plus maligne : vous contrôlez exactement ce qui est scanné, donc ce qui est facturé.

Petit bonus si vous partez de la console BigQuery : le bouton “Explorer dans Looker Studio” génère un rapport en un clic sur le résultat d’une requête. Parfait pour un coup d’oeil rapide. Pour un reporting récurrent et automatisé, la mise en place propre est décrite dans le guide automatiser ses rapports avec Looker Studio et BigQuery.

Chemin 2 : BigQuery vers Power BI

Power BI a un connecteur Google BigQuery natif (Obtenir les données, puis Google BigQuery, authentification via votre compte Google). Pas besoin d’outil tiers pour démarrer. La vraie décision ici, c’est le mode de connexion, et elle a un impact direct sur votre facture :

• Import : Power BI copie les données dans son modèle. La requête BigQuery ne s’exécute qu’au rafraîchissement. Rapide à l’usage, coûts maîtrisés, idéal pour des volumes raisonnables.
• DirectQuery : Power BI interroge BigQuery en direct à chaque interaction. Données toujours fraîches, mais chaque filtre cliqué par un utilisateur peut déclencher une requête facturée. Sur un gros dataset GA4, c’est le meilleur moyen de faire flamber les coûts.

Mon conseil de praticien : commencez en mode Import sur une table déjà agrégée. Ne passez en DirectQuery que si la fraîcheur temps réel est un vrai besoin métier, pas un confort. Si le connecteur natif vous limite (planification fine, transformations), des outils tiers comme Coupler.io font le pont, mais vous ajoutez une dépendance et un coût de plus. À réserver aux cas où le natif ne suffit pas.

Chemin 3 : BigQuery vers Tableau

Tableau dispose aussi d’un connecteur BigQuery natif. Le point d’attention est le même que pour Power BI, avec un vocabulaire différent : les extraits (extracts). Un extrait est un instantané des données stocké côté Tableau, l’équivalent du mode Import. La connexion live, elle, requête BigQuery en direct comme le DirectQuery.

Là encore, privilégiez l’extrait sur une table aplatie et agrégée. Vous rafraîchissez l’extrait selon une planification (une fois par nuit, par exemple), et vos utilisateurs explorent le dashboard sans déclencher de requête facturée à chaque clic.

Le comparatif des trois chemins

Pour choisir vite, voici l’essentiel :

La logique est toujours la même quel que soit l’outil : table aplatie et agrégée en amont, mode “snapshot” plutôt que “live”, et fraîcheur temps réel seulement si le métier l’exige vraiment.

Maîtriser les coûts BigQuery côté BI

BigQuery facture sur le volume de données scannées, pas sur le nombre de lignes affichées. Une connexion live mal réglée peut rescanner des gigaoctets à chaque clic. Quelques réflexes qui font vraiment la différence :

• Exposez une table intermédiaire agrégée, jamais les tables events_* brutes. Vous scannez ce dont la BI a besoin, rien de plus.
• Utilisez des vues matérialisées pour les agrégations récurrentes : BigQuery ne recalcule que le delta.
• Partitionnez et clusterisez vos tables dérivées (par date, par exemple) pour que les filtres ne scannent que le nécessaire.
• Filtrez toujours sur la période (_TABLE_SUFFIX ou colonne de partition) dans la requête source, pas seulement dans le dashboard.
• Posez des quotas et des alertes de coûts au niveau du projet GCP. C’est votre filet de sécurité le jour où un dashboard mal configuré part en boucle.

Bonus : exporter une table BigQuery vers un LLM

Voilà l’angle que presque personne n’exploite. Un outil BI répond à “quoi” (quelle est la tendance), mais pas toujours à “pourquoi”. Pour explorer, formuler des hypothèses, croiser librement, un LLM comme Claude ou Gemini est redoutable, à condition de lui donner une table propre.

Le principe est simple. Vous exportez le résultat d’une requête agrégée (pas la table brute de plusieurs gigaoctets, un LLM n’en a ni le besoin ni la capacité) en CSV, puis vous le fournissez au modèle avec une vraie question métier : “compare le taux de conversion par source sur les deux derniers mois et dis-moi ce qui décroche”. L’export CSV se fait en une ligne depuis la console ou en bq :

bq extract --destination_format=CSV \
  'projet:dataset.bi_events_agrege' \
  gs://mon-bucket/export.csv

Encore mieux : au lieu d’exporter à la main, on peut brancher l’agent directement sur BigQuery. C’est exactement ce que permet Claude Code pour le data analyst, qui interroge GA4 et BigQuery en langage naturel, ou un serveur MCP GA4 qui connecte vos données à vos agents IA. La BI classique et le LLM ne s’opposent pas : le dashboard surveille, le LLM investigue.

Questions fréquentes

Faut-il forcément passer par BigQuery pour brancher GA4 sur Power BI ? Non. GA4 a un connecteur direct vers Looker Studio, et des connecteurs tiers existent pour Power BI. Mais dès que vous voulez de l’historique long, des données non échantillonnées et du croisement avec d’autres sources, BigQuery devient le passage quasi obligé : c’est le seul endroit où vos données GA4 sont brutes et complètes.

DirectQuery ou Import, lequel choisir ? Import par défaut. Vous ne passez en DirectQuery que si vos utilisateurs ont besoin de données rafraîchies à la minute, et que vous acceptez le coût de requête associé. Dans la grande majorité des cas d’un reporting marketing, un Import rafraîchi chaque nuit suffit largement.

Comment éviter que ma facture BigQuery explose à cause d’un dashboard ? Trois réflexes : exposez une table agrégée plutôt que les tables brutes, partitionnez par date, et posez une alerte de coût sur le projet GCP. Le piège numéro un reste une connexion live branchée sur des mois de données événementielles GA4.

Ce qu’il faut retenir

Exporter ses données BigQuery vers un outil BI n’a rien de compliqué techniquement, les trois connecteurs sont natifs. Le vrai travail est en amont : aplatir les données GA4 imbriquées dans une table propre, exposer une version agrégée plutôt que les tables brutes, et choisir le mode snapshot (Import, extrait, requête ciblée) plutôt que le live par défaut. Faites ça, et vous aurez des dashboards rapides avec une facture prévisible. Et si vous voulez aller plus loin que le “quoi”, branchez une table propre sur un LLM pour attaquer le “pourquoi”. Commencez par créer votre table bi_events aplatie dès aujourd’hui : c’est la brique dont dépendent les trois chemins.