Migrer de Looker Studio vers Looker : quand et comment

Migrer de Looker Studio vers Looker se justifie quand vos rapports se contredisent, quand vous devez filtrer les données par utilisateur, ou quand la facture BigQuery derrière les rapports n'est plus pilotable. Ce n'est pas une conversion de fichiers : on modélise d'abord les indicateurs dans LookML, puis on reconstruit les quelques dashboards qui comptent. Pour un périmètre bien cadré, comptez six à douze semaines et un budget de conseil entre 10 000 et 30 000 euros, hors licences Looker.

Rappel de vocabulaire : Google a renommé Looker Studio en Data Studio en avril 2026. Le produit et vos rapports sont inchangés ; cet article garde le nom que vous cherchez.

Faut-il vraiment migrer ?

Avant de planifier quoi que ce soit, vérifiez que le problème vient de l'outil. Trois cas fréquents où la migration n'est pas la réponse.

Vos rapports sont lents parce qu'ils interrogent des tables brutes. La solution est une table BigQuery agrégée, éventuellement une couche dbt, pas Looker. Coût : quelques jours.

Vos rapports sont éparpillés dans les Drive personnels. Data Studio Pro (9 dollars par utilisateur, par projet et par mois) apporte les espaces d'équipe. Coût : presque rien.

Une seule personne produit tous les rapports et personne ne conteste les chiffres. Looker ajouterait un modèle à maintenir sans bénéfice.

La migration est la bonne réponse quand au moins deux de ces conditions sont réunies : plusieurs équipes publient des indicateurs qui divergent, vous avez besoin d'une sécurité au niveau ligne opposable, vous voulez un historique et une revue des modifications, ou vous préparez des agents conversationnels qui doivent répondre juste.

Ce que la migration n'est pas

Il n'existe pas d'outil qui convertit un rapport Looker Studio en dashboard Looker, et c'est une bonne nouvelle. Les deux produits partent de bouts opposés : Looker Studio part d'un visuel et y attache des données, Looker part d'un modèle et y attache des visuels. Reproduire tel quel un parc de soixante rapports Looker Studio dans Looker, c'est importer le désordre avec les données.

La migration réussie ressemble plutôt à ceci : un inventaire, un tri sévère, un modèle LookML pour les indicateurs qui restent, et une dizaine de dashboards reconstruits proprement.

Les étapes

Semaine 1 : inventaire et tri

Listez tous les rapports Looker Studio avec leur propriétaire, leur audience réelle (les statistiques de consultation de Looker Studio aident), leurs sources et leurs champs calculés. Le résultat habituel : 20 % des rapports concentrent 90 % des consultations, et la moitié n'ont pas été ouverts depuis trois mois.

Pour chaque rapport conservé, extrayez les indicateurs et leurs formules. C'est ici que les divergences apparaissent : le « taux de conversion » du marketing et celui des ventes n'ont ni le même numérateur ni le même dénominateur. Ces divergences doivent être arbitrées par le métier avant d'écrire une ligne de LookML.

Semaines 2 et 3 : préparer BigQuery

Looker suppose des tables propres en dessous. Si vos rapports Looker Studio lisaient directement GA4, Google Ads ou Sheets, il faut d'abord ramener ces sources dans BigQuery (transferts natifs BigQuery Data Transfer pour Google Ads et GA4, connecteurs pour le reste) et construire des tables de faits et de dimensions au bon grain, idéalement avec dbt.

Cette étape est souvent sous-estimée. Elle représente la moitié de l'effort, et c'est elle qui rend le reste simple.

Semaines 3 à 6 : modéliser dans LookML

Commencez par un seul explore, celui qui porte l'indicateur le plus contesté, généralement le chiffre d'affaires ou les commandes. Une vue de faits, deux ou trois dimensions (date, client, produit), les mesures arbitrées à l'étape 1, un datagroup aligné sur votre chargement quotidien.

explore: orders {
  persist_with: daily_load
  join: customers {
    sql_on: ${orders.customer_id} = ${customers.customer_id} ;;
    relationship: many_to_one
  }
}

Validez cet explore avec les personnes qui contestaient les chiffres, jusqu'à ce qu'elles obtiennent le même résultat que dans leur ancien rapport, ou qu'elles comprennent pourquoi l'ancien était faux. Ensuite seulement, élargissez aux autres domaines.

Dès le premier explore, posez les fondations qui coûtent cher à rattraper : primary_key sur chaque vue, label et description sur chaque champ, access_filter si vous avez des données multi-entités, et un dépôt Git avec PR obligatoires.

Semaines 6 à 9 : reconstruire les dashboards

Reconstruisez les dix à quinze dashboards conservés, en partant de zéro et non en imitant l'ancien. Moins de tuiles, des filtres communs, des liens de drill vers les explores plutôt que des rapports détaillés séparés. Pour les dashboards de direction, visez moins de douze tuiles et un temps d'ouverture sous dix secondes.

Faites tourner ancien et nouveau en parallèle pendant deux à quatre semaines. Publiez la date de fin des anciens rapports et tenez-la.

Semaines 9 à 12 : ouvrir, former, décommissionner

Formez les analystes à l'exploration (deux heures suffisent pour l'essentiel), les développeurs à LookML et au flux Git. Convertissez les anciens rapports Looker Studio en lecture seule, puis archivez-les. Si des équipes veulent continuer à bricoler des visuels rapides, le connecteur Looker pour Looker Studio leur donne accès aux explores gouvernés sans toucher au modèle.

Que modéliser en premier

L'ordre a de l'importance parce que le premier explore fixe les conventions.

Priorité	Domaine	Pourquoi d'abord
1	Chiffre d'affaires et commandes	L'indicateur le plus contesté, le plus visible en direction
2	Clients et segments	Nécessaire pour toute analyse par cohorte, alimente les filtres
3	Acquisition (GA4, Ads)	Fort volume de rapports existants, souvent la source des divergences
4	Opérations, stock, support	Domaines plus stables, migrés en dernier

Ne modélisez pas les rapports « au cas où ». Si un indicateur n'apparaît dans aucun des dashboards conservés, il attend.

Les pièges

Migrer les rapports un par un, à l'identique. Vous obtenez un Looker aussi désordonné que l'ancien Looker Studio, avec en plus une licence annuelle.

Brancher Looker sur des tables brutes. Les explores seront lents, les PDT prolifèreront pour compenser, et la facture BigQuery montera. La modélisation appartient à dbt ou à des tables préparées, Looker est la couche sémantique.

Sauter l'arbitrage métier. Si finance et ventes ne sont pas d'accord sur la définition du chiffre d'affaires avant la migration, vous aurez deux mesures dans LookML et le même problème qu'avant, en plus cher.

Sous-estimer les licences. Chaque lecteur Looker a une licence. Un rapport Looker Studio partagé par lien à deux cents personnes ne se transpose pas gratuitement. Comptez les lecteurs réels et prévoyez des licences Viewer, ou conservez Looker Studio (via le connecteur Looker) pour la diffusion large.

Ne pas nommer de propriétaire du modèle. Sans une personne responsable du LookML, interne ou externe, le modèle se dégrade en six mois.

Délais et budget réalistes

Les ordres de grandeur ci-dessous correspondent à des projets menés à distance, en asynchrone, avec un interlocuteur métier disponible deux heures par semaine.

Périmètre	Délai	Conseil (hors licences)
Un domaine (CA, commandes), 3 à 5 dashboards	4 à 6 semaines	sur devis après inventaire
Deux ou trois domaines, 10 à 15 dashboards	8 à 12 semaines	sur devis, découpé en lots
Périmètre multi-entités avec sécurité au niveau ligne et dbt complet	3 à 5 mois	sur devis

À ajouter : les licences Looker (engagement annuel, prix sur devis auprès de Google, dix utilisateurs Standard et deux développeurs inclus dans chaque édition), les coûts BigQuery, et le temps interne de validation. Une maintenance de deux à trois jours par mois, une fois la migration livrée, évite que le modèle ne se dégrade.

Ce qui s'observe en production : dans un grand groupe industriel, la couche sémantique Looker sur BigQuery sert les dashboards de direction depuis plusieurs années. Ce qui a tenu dans le temps n'est pas le nombre de dashboards livrés mais le fait d'avoir commencé par un seul explore validé par ceux qui contestaient les chiffres.

FAQ

Peut-on garder Looker Studio après la migration ?

Oui, et c'est souvent le bon schéma. Le connecteur Looker pour Looker Studio lit les explores gouvernés ; les équipes marketing gardent leur outil, les définitions restent dans LookML. Les clients Looker (Google Cloud core) peuvent obtenir des licences Pro complémentaires.

Faut-il dbt pour migrer vers Looker ?

Pas obligatoirement, mais fortement recommandé dès que vous avez plus de deux sources. dbt porte les transformations et les tests, Looker porte la sémantique. Sans dbt, la logique de transformation finit dans des tables dérivées Looker difficiles à tester.

Combien de temps les anciens rapports doivent-ils rester ouverts ?

Deux à quatre semaines en parallèle, avec une date de fin annoncée dès le début. Au-delà, les utilisateurs ne basculent pas et vous maintenez deux systèmes.

Une PME peut-elle se permettre Looker ?

L'édition Standard vise les organisations de moins de 50 utilisateurs, mais l'engagement est annuel et le coût de conseil s'ajoute. En dessous de vingt lecteurs et sans exigence de gouvernance, une couche dbt propre sous Looker Studio donne 80 % du bénéfice pour une fraction du prix.

Et ensuite

Si vous avez reconnu vos rapports dans les premières lignes, commencez par l'inventaire : une feuille de calcul, les rapports, les audiences, les indicateurs et leurs formules. Elle révèle à elle seule si la migration se justifie, et dans quel ordre.

Voir l'offre Couche sémantique BigQuery, dbt, Looker, et pour aller plus loin : Looker vs Looker Studio et Le prix de Looker en 2026.

Sources

• Looker Studio is Data Studio, Google Cloud Blog, avril 2026
• Looker pricing, éditions de plateforme
• Page produit Data Studio, tarif Pro