Qu’est-ce que Looker ? Guide de LookML, jointures multi-sources, métriques calculées et gouvernance

La plupart des gens découvrent Looker en pensant à un autre Tableau ou à un autre Looker Studio / Data Studio. Ils l’ouvrent, cherchent un constructeur de graphiques en glisser-déposer, et se sentent perdus. Cette confusion est le premier signe qu’ils ont affaire à quelque chose de fondamentalement différent.

Looker n’est pas un outil de visualisation, c’est une plateforme de couche sémantique. Un outil de visualisation connecte des données et construit des graphiques. Une plateforme de couche sémantique définit ce que vos données signifient, puis impose ce sens à chaque graphique, chaque analyste et chaque question métier, pour toujours. Cet article est le socle d’une série sur l’usage de Looker pour réconcilier GA4, SFCC et les commandes hors ligne : avant de toucher à une jointure ou à un dashboard, il faut comprendre comment Looker pense la donnée.

Looker contre Looker Studio / Data Studio : arrêtez de confondre les noms

Google possède les deux produits, et le nommage prête à confusion même en interne. Voici la comparaison :

Dimension	Data Studio (gratuit ; appelé Looker Studio de 2022 à 2026)	Looker (payant, entreprise)
Anciens noms	Google Data Studio, puis Looker Studio (redevenu Data Studio en avril 2026, voir les release notes)	Looker (racheté par Google, opération conclue en 2020)
Rôle	Reporting et visualisation	Modélisation sémantique + plateforme BI
Couche de modélisation	Aucune : on connecte les données brutes	LookML : la logique métier en code
Jointures	Data blending : jusqu’à 5 tables, jointures inner/left/right/full outer/cross, sans modèle réutilisable	Sémantique SQL complète : inner, left, right, full outer, cross
Définition des métriques	Par rapport, donc divergente entre dashboards	Définie une fois dans LookML, cohérente partout
Versionnement	Historique des versions (pas de Git)	Git natif : chaque changement de modèle est un commit
Sécurité par ligne	Basique : filtre par e-mail du lecteur	Access filters au niveau Explore, attributs utilisateur
Envois et alertes	Envoi planifié par e-mail ; alertes de graphique et 200 planifications en Pro	Envois planifiés, alertes à seuil, intégration Slack/webhook
API	API de lecture limitée	API REST complète : requêtes, utilisateurs, embed de dashboards
Cible	Analyste isolé ou petite équipe	Équipe data au service d’une organisation

La différence d’architecture : Looker Studio / Data Studio met la logique métier dans les dashboards, Looker la met dans un modèle. Cela semble un détail d’implémentation, jusqu’à ce que vous ayez 50 dashboards et qu’on vous demande de changer la définition du « chiffre d’affaires ».

L’architecture complète de Looker

LookML : le langage au cœur de Looker

LookML (Looker Modeling Language) est le langage de modélisation déclaratif de Looker, que Google décrit comme « un langage de dépendances comme make ». C’est la chose la plus importante à comprendre : dashboards, Explores et rapports planifiés en dépendent. Un projet LookML est un ensemble de fichiers stockés dans Git :

• Fichiers view (.view.lkml) : décrivent les tables et leurs champs.
• Fichiers model (.model.lkml) : définissent les connexions à la base et les Explores.
• Explores : parfois dans les fichiers model, ils définissent les jointures.
• Fichier manifest : configuration du projet, modèles importés.

Un projet correspond à un dépôt Git. Un modèle définit une connexion et l’ensemble des Explores disponibles. Un projet peut contenir plusieurs modèles, utile pour exposer des vues différentes à des équipes différentes.

# File: reconciliation.model.lkml
connection: "bigquery_production"

include: "/views/*.view.lkml"  # Include all view files

explore: order_reconciliation {
  label: "GA4 + SFCC + Offline Reconciliation"
  description: "Compare GA4 reported revenue against SFCC billed revenue across all channels"

  join: sfcc_orders {
    type: left_outer
    sql_on: LOWER(TRIM(${order_reconciliation.transaction_id}))
             = LOWER(TRIM(${sfcc_orders.order_id})) ;;
    relationship: one_to_one
  }

  join: offline_orders {
    type: left_outer
    sql_on: ${sfcc_orders.order_id} = ${offline_orders.reference_id} ;;
    relationship: one_to_many
  }
}

Les views : la couche d’abstraction des tables

Une view correspond à une table, une requête SQL ou une table dérivée. C’est là que l’on définit chaque champ disponible. Un bon fichier view se documente lui-même : tout analyste qui l’ouvre doit comprendre la table, le sens de chaque champ et les cas limites. Voici l’essentiel d’une view de commandes SFCC :

# File: sfcc_orders.view.lkml
view: sfcc_orders {
  sql_table_name: `project.reconciliation.normalised_sfcc_orders` ;;

  dimension: order_id {
    type: string
    sql: ${TABLE}.normalised_order_id ;;
    primary_key: yes
    hidden: yes
    description: "Normalised SFCC order ID (LOWER + TRIM applied). Use for joins."
  }

  measure: order_count {
    label: "Orders"
    type: count_distinct
    sql: ${order_id} ;;
    description: "Count of distinct SFCC orders. Includes all statuses unless filtered."
  }

  measure: net_revenue {
    label: "Net Revenue (SFCC)"
    type: sum
    sql: ${TABLE}.order_value - COALESCE(${TABLE}.refund_amount, 0) ;;
    value_format_name: decimal_2
    description: "Gross revenue minus processed refunds. Does not include pending refunds."
    filters: [order_status: "-cancelled,-fraud"]
  }

}

Les Explores : des jointures prêtes pour le self-service

Un Explore est l’interface avec laquelle les utilisateurs construisent leurs requêtes : une jointure SQL préconfigurée exposée dans l’UI. L’idée clé : les jointures sont définies une fois dans l’Explore, pas dans chaque dashboard. Chaque utilisateur obtient la même logique, et une fois un changement de jointure déployé en production, tous les rapports enregistrés l’appliquent.

Types de jointures et déclaration de relation

Les jointures LookML portent un paramètre relationship crucial. Le déclarer faux provoque un fan-out de mesures : une corruption silencieuse où les mesures agrégées sont gonflées parce que des lignes sont dupliquées avant l’agrégation.

explore: ga4_sessions {
  label: "GA4 Sessions + Order Reconciliation"

  # one_to_many if a session can hold several orders; use one_to_one only after
  # deduplicating purchases by transaction_id
  join: sfcc_orders {
    type: left_outer
    sql_on: LOWER(TRIM(${ga4_sessions.transaction_id}))
             = LOWER(TRIM(${sfcc_orders.order_id})) ;;
    relationship: one_to_one
  }

  # one_to_many: one order has many line items
  join: order_line_items {
    type: left_outer
    sql_on: ${sfcc_orders.order_id} = ${order_line_items.order_id} ;;
    relationship: one_to_many
    # Without symmetric aggregates this would inflate sfcc_orders measures
  }
}

Les symmetric aggregates : comment Looker évite le fan-out

Le fan-out est un classique du SQL : on joint une relation un-à-plusieurs puis on fait un SUM côté « un », et chaque ligne est dupliquée autant de fois qu’il y a de lignes côté « plusieurs ». En SQL pur, on le traite à la main avec des sous-requêtes ou des CTE. Looker le gère automatiquement avec les symmetric aggregates : il réécrit le SQL avec un motif COUNT DISTINCT / SUM DISTINCT qui déduplique correctement (en simplifiant : il ajoute un hash MD5 de la clé primaire à chaque valeur, applique SUM(DISTINCT …), puis retranche la somme des hash ; voir « Understanding symmetric aggregates » chez Google). Cela ne marche que si deux conditions sont réunies :

• la view déclare un primary_key ;
• le relationship est correctement déclaré dans la jointure.

Les métriques calculées : le bénéfice de la gouvernance

La vraie valeur de LookML apparaît quand on construit des métriques calculées sur plusieurs sources. Elles sont définies une fois, documentées en ligne et disponibles pour tous immédiatement : plus de copier-coller, plus de dérive de versions, plus de débat sur « quelle formule est la bonne ». Exemple d’écart de revenu entre SFCC et GA4 :

measure: revenue_discrepancy {
  label: "Revenue Gap SFCC vs GA4 (€)"
  type: number
  sql: ${sfcc_orders.net_revenue} - ${ga4_sessions.reported_revenue} ;;
  value_format_name: decimal_2
  description: "Positive = SFCC reports more than GA4 (normal). Negative = GA4 over-reports (check refund events)."
}

Les tables dérivées : des tables virtuelles pour les transformations complexes

Quand la logique ne tient pas dans un simple calcul de champ, Looker propose des tables dérivées : des tables virtuelles définies par une requête SQL dans LookML. Elles se comportent comme de vraies tables du modèle : on les joint, on expose leurs champs dans les Explores et on construit des mesures dessus. Dans l’exemple de l’article, une table reconciliation_base joint les commandes SFCC aux achats GA4 normalisés, exclut les statuts annulé, fraude et test, et classe chaque commande par origine (tracked_web, offline_store, offline_callcenter, b2b_wholesale, dark_traffic_web, subscription, unknown), avec un écart de revenu par commande.

Pour les tables lourdes à calculer, les Persistent Derived Tables (PDT) sont matérialisées en base et mises en cache jusqu’au déclenchement d’une reconstruction. Cela améliore fortement les performances des jointures complexes :

view: reconciliation_pdt {
  derived_table: {
    sql: SELECT ... FROM `project.sfcc.orders` s
         LEFT JOIN `project.ga4.purchases` g ON ... ;;

    # Rebuild every night at 3am after GA4 and SFCC exports complete
    datagroup_trigger: nightly_etl
  }
}

# Define the datagroup in the model file
datagroup: nightly_etl {
  sql_trigger: SELECT MAX(loaded_at) FROM `project.reconciliation.etl_log` ;;   # fires when the nightly ETL has finished
  max_cache_age: "24 hours"
}

Contrôle d’accès : sécurité par ligne et par champ

Le système de permissions de Looker repose sur les attributs utilisateur : des paires clé-valeur attribuées à des utilisateurs ou des groupes, pour restreindre ce que chacun voit sans créer de dashboards séparés.

# In the model file: restrict which regions a user can see
explore: order_reconciliation {
  access_filter: {
    field: sfcc_orders.region
    user_attribute: allowed_region
  }

  # User with allowed_region = "FR" only sees French orders
  # For full access: user attribute type String Filter (advanced), value: %, NULL
}

Pour la sécurité par champ, un access_grant nommé (par exemple finance_only, lié à un attribut utilisateur) s’applique à une mesure sensible via required_access_grants : les utilisateurs sans l’attribut ne voient pas le champ.

Planification, alertes et API REST

Looker n’est pas qu’un outil de requêtes, c’est une plateforme opérationnelle.

• Envois planifiés : tout Look ou dashboard peut être envoyé par e-mail, webhook, Amazon S3 ou SFTP (intégrés), ou via des services comme Slack (Action Hub) (docs Google). Les envois peuvent être filtrés par attribut utilisateur : le même dashboard envoyé à dix responsables régionaux montre à chacun sa région.
• Alertes à seuil : « préviens-moi sur Slack quand le taux de trafic sombre web dépasse 15 % ». Looker interroge la requête à intervalle régulier et déclenche l’alerte, sans ingénierie.
• API REST : elle couvre toutes les actions de l’UI : requêtes, téléchargement, gestion des utilisateurs et attributs, reconstruction de PDT, embed. Looker devient un moteur de livraison de données, pas seulement un outil de dashboards.

Performance

Looker génère du SQL pour votre entrepôt (BigQuery en général) : son plafond de performance est le sien. Trois leviers comptent : les PDT pour les jointures coûteuses, le partitionnement et le clustering des tables dérivées, et un filtre de date forcé avec always_filter pour qu’aucune requête ne scanne toute la table GA4 (always_filter). Cachez aussi les champs inutiles avec hidden: yes : un Explore de 60 champs bien choisis vaut mieux qu’un de 300.

Ce pour quoi Looker n’est pas bon

Looker est puissant et cher. Il ne convient pas à l’exploration ad hoc d’un analyste seul (un notebook ou Data Studio va plus vite), au streaming temps réel (il interroge une base à la demande), aux interfaces très personnalisées (utilisez l’API d’embed) ni aux petites équipes sans data engineer : sans quelqu’un qui maintient la base de code LookML, le modèle devient un passif.

Sources

• Bonnes pratiques LookML (docs Google)
• Symmetric aggregates et Understanding symmetric aggregates
• Tables dérivées persistantes
• Référence de l’API Looker

Pour aller plus loin, lisez la version complète de l’article (en anglais) : What Is Looker? The Complete Guide to LookML, Multi-Source Data, Joins, Calculated Metrics, and Governance.

Besoin d’aide sur ce sujet ? Consultant GA4 et audit analytics.