La demande pour les professionnels maîtrisant Looker et LookML continue de croître en 2026. Avec l'intégration de Google Cloud et les nouvelles fonctionnalités d'intelligence artificielle, Looker s'impose comme une plateforme incontournable de Business Intelligence. Ce guide complet prépare les candidats aux entretiens techniques tout en offrant une base solide pour les analystes en poste.

Looker se distingue des autres outils BI par son approche "modeling layer first". Comprendre LookML avant d'explorer l'interface permet de saisir la philosophie de la plateforme et de répondre efficacement aux questions d'entretien.

Comprendre l'Architecture Looker

Looker fonctionne sur une architecture unique qui sépare la couche sémantique de la visualisation. Cette approche permet aux équipes de définir une source de vérité unique pour les métriques, évitant les incohérences entre rapports.

L'architecture se compose de trois couches principales :

La couche de données : connexion directe aux entrepôts de données (BigQuery, Snowflake, Redshift)
La couche sémantique : définitions LookML qui modélisent les relations et calculs
La couche de présentation : Explores, Looks et Dashboards pour les utilisateurs finaux

yaml

# Exemple de connexion dans looker.ini
[database]
host: your-project.region.bigquery.googleapis.com
port: 443
ssl: true
database: your_dataset
schema: analytics

Fondamentaux de LookML

LookML utilise une syntaxe déclarative pour définir les modèles de données. Les quatre éléments fondamentaux sont les projects, models, views et explores.

Structure d'un Projet LookML

Chaque projet contient des fichiers organisés hiérarchiquement. Les conventions de nommage et la structure des dossiers facilitent la maintenance à long terme.

lookml

# model: ecommerce.model.lkml
connection: "bigquery_production"

include: "/views/**/*.view.lkml"
include: "/explores/**/*.explore.lkml"

explore: orders {
  label: "Sales Analysis"
  description: "Explore orders with customer and product details"
  
  join: customers {
    type: left_outer
    sql_on: ${orders.customer_id} = ${customers.id} ;;
    relationship: many_to_one
  }
  
  join: products {
    type: left_outer
    sql_on: ${order_items.product_id} = ${products.id} ;;
    relationship: many_to_one
  }
}

Définition des Views

Les views représentent les tables ou les requêtes dérivées. Chaque view contient des dimensions et des mesures qui définissent comment les données peuvent être analysées.

lookml

# view: orders.view.lkml
view: orders {
  sql_table_name: `analytics.orders` ;;

  dimension: id {
    primary_key: yes
    type: number
    sql: ${TABLE}.order_id ;;
  }

  dimension_group: created {
    type: time
    timeframes: [raw, date, week, month, quarter, year]
    sql: ${TABLE}.created_at ;;
  }

  dimension: status {
    type: string
    sql: ${TABLE}.status ;;
  }

  dimension: total_amount {
    type: number
    sql: ${TABLE}.total_amount ;;
    value_format_name: usd
  }

  measure: count {
    type: count
    drill_fields: [id, created_date, status, total_amount]
  }

  measure: total_revenue {
    type: sum
    sql: ${total_amount} ;;
    value_format_name: usd
  }

  measure: average_order_value {
    type: average
    sql: ${total_amount} ;;
    value_format_name: usd
  }
}

Techniques Avancées de Modélisation

Les entretiens techniques évaluent souvent la capacité à résoudre des problèmes complexes de modélisation. Les derived tables et les paramètres dynamiques sont des sujets fréquemment abordés.

Derived Tables et PDTs

Les derived tables permettent de créer des tables intermédiaires pour optimiser les performances ou simplifier les requêtes complexes.

lookml

view: daily_sales_summary {
  derived_table: {
    sql:
      SELECT
        DATE(created_at) as sale_date,
        COUNT(DISTINCT order_id) as order_count,
        SUM(total_amount) as daily_revenue,
        COUNT(DISTINCT customer_id) as unique_customers
      FROM ${orders.SQL_TABLE_NAME}
      WHERE status = 'completed'
      GROUP BY 1
    ;;
    
    datagroup_trigger: daily_refresh
    indexes: ["sale_date"]
  }

  dimension: sale_date {
    type: date
    sql: ${TABLE}.sale_date ;;
  }

  measure: total_orders {
    type: sum
    sql: ${TABLE}.order_count ;;
  }

  measure: revenue {
    type: sum
    sql: ${TABLE}.daily_revenue ;;
    value_format_name: usd
  }
}

Paramètres et Templated Filters

Les paramètres permettent aux utilisateurs de contrôler dynamiquement les requêtes SQL générées.

lookml

view: orders_with_params {
  parameter: date_granularity {
    type: unquoted
    allowed_values: {
      label: "Day"
      value: "day"
    }
    allowed_values: {
      label: "Week"
      value: "week"
    }
    allowed_values: {
      label: "Month"
      value: "month"
    }
  }

  dimension: dynamic_date {
    type: string
    sql:
      {% if date_granularity._parameter_value == 'day' %}
        DATE(${created_raw})
      {% elsif date_granularity._parameter_value == 'week' %}
        DATE_TRUNC(${created_raw}, WEEK)
      {% else %}
        DATE_TRUNC(${created_raw}, MONTH)
      {% endif %}
    ;;
  }
}

Questions d'Entretien Looker Courantes

Les recruteurs évaluent la compréhension théorique et pratique des candidats. Cette section présente les questions les plus fréquentes avec des réponses détaillées.

Question : Quelle est la différence entre une dimension et une mesure ?

Les dimensions sont des attributs qualitatifs utilisés pour grouper ou filtrer les données (catégories, dates, identifiants). Les mesures sont des calculs agrégés sur les données (sommes, moyennes, comptages). Une dimension correspond à une colonne dans un GROUP BY, tandis qu'une mesure applique une fonction d'agrégation.

Question : Comment optimiser les performances d'un Explore lent ?

Plusieurs stratégies permettent d'améliorer les performances :

lookml

# 1. Utiliser des PDTs pour pré-agréger les données
view: monthly_metrics {
  derived_table: {
    sql:
      SELECT
        DATE_TRUNC(created_at, MONTH) as month,
        category,
        SUM(revenue) as total_revenue
      FROM orders
      GROUP BY 1, 2
    ;;
    datagroup_trigger: monthly_refresh
    indexes: ["month", "category"]
  }
}

# 2. Implémenter des always_filter pour limiter les scans
explore: large_transactions {
  always_filter: {
    filters: [created_date: "last 90 days"]
  }
}

# 3. Utiliser sql_always_where pour des restrictions permanentes
explore: active_customers {
  sql_always_where: ${customers.status} = 'active' ;;
}

Question : Expliquez les différents types de joins en LookML

Looker supporte quatre types de jointures avec des implications sur les performances et les résultats :

lookml

explore: orders {
  # LEFT OUTER: garde tous les enregistrements de orders
  join: customers {
    type: left_outer
    sql_on: ${orders.customer_id} = ${customers.id} ;;
    relationship: many_to_one
  }
  
  # INNER: uniquement les correspondances
  join: payments {
    type: inner
    sql_on: ${orders.id} = ${payments.order_id} ;;
    relationship: one_to_many
  }
  
  # FULL OUTER: tous les enregistrements des deux tables
  join: returns {
    type: full_outer
    sql_on: ${orders.id} = ${returns.order_id} ;;
    relationship: one_to_one
  }
  
  # CROSS: produit cartésien (rarement utilisé)
  join: date_spine {
    type: cross
    relationship: many_to_many
  }
}

Prêt à réussir tes entretiens Data Analytics ?

Entraîne-toi avec nos simulateurs interactifs, fiches express et tests techniques.

Explorer Data Analytics

Bonnes Pratiques de Développement LookML

Les équipes performantes adoptent des conventions et des pratiques qui facilitent la collaboration et la maintenance du code.

Organisation du Code

lookml

# Structure recommandée pour un projet d'entreprise
# /models
#   └── ecommerce.model.lkml
# /views
#   └── /core
#       ├── orders.view.lkml
#       ├── customers.view.lkml
#       └── products.view.lkml
#   └── /derived
#       └── daily_summary.view.lkml
# /explores
#   └── sales.explore.lkml
# /dashboards
#   └── executive_summary.dashboard.lookml

# Utilisation des extends pour la réutilisation
view: base_order_metrics {
  extension: required
  
  measure: total_revenue {
    type: sum
    sql: ${amount} ;;
  }
  
  measure: order_count {
    type: count_distinct
    sql: ${id} ;;
  }
}

view: orders {
  extends: [base_order_metrics]
  sql_table_name: analytics.orders ;;
}

Gestion des Versions et Tests

Looker s'intègre avec Git pour le contrôle de version. Les tests de données valident la cohérence des définitions.

lookml

# Tests de validation des données
test: orders_have_positive_amounts {
  explore_source: orders {
    column: order_count { field: orders.count }
    filters: [orders.total_amount: "<0"]
  }
  assert: order_count {
    expression: ${orders.count} = 0 ;;
  }
}

test: customer_ids_are_unique {
  explore_source: customers {
    column: duplicate_count {
      field: customers.count
    }
    column: id_count {
      field: customers.id_count
    }
  }
  assert: no_duplicates {
    expression: ${duplicate_count} = ${id_count} ;;
  }
}

Intégration avec l'Écosystème Google Cloud

Depuis l'acquisition par Google, Looker s'intègre profondément avec les services GCP. Cette synergie offre des avantages significatifs pour les entreprises utilisant BigQuery.

lookml

# Utilisation de BigQuery ML directement dans LookML
view: customer_predictions {
  derived_table: {
    sql:
      SELECT
        customer_id,
        predicted_ltv,
        predicted_churn_probability
      FROM ML.PREDICT(
        MODEL `project.dataset.customer_ltv_model`,
        (SELECT * FROM ${customers.SQL_TABLE_NAME})
      )
    ;;
    datagroup_trigger: weekly_predictions
  }
}

# Connexion optimisée pour BigQuery
# Looker utilise les sessions BigQuery pour réduire les coûts
connection: "bigquery_optimized" {
  host: "bigquery.googleapis.com"
  maximum_billing_gigabytes: 100
  query_timeout: 3600
}

Préparation aux Entretiens Techniques

Les candidats doivent démontrer leur capacité à résoudre des problèmes concrets. Les exercices pratiques suivants représentent des scénarios d'entretien typiques.

Exercice : Modéliser une Analyse de Cohorte

lookml

view: cohort_analysis {
  derived_table: {
    sql:
      WITH first_purchase AS (
        SELECT
          customer_id,
          DATE_TRUNC(MIN(created_at), MONTH) as cohort_month
        FROM ${orders.SQL_TABLE_NAME}
        GROUP BY 1
      )
      SELECT
        fp.cohort_month,
        DATE_DIFF(
          DATE_TRUNC(o.created_at, MONTH),
          fp.cohort_month,
          MONTH
        ) as months_since_first,
        COUNT(DISTINCT o.customer_id) as customers,
        SUM(o.total_amount) as revenue
      FROM ${orders.SQL_TABLE_NAME} o
      JOIN first_purchase fp ON o.customer_id = fp.customer_id
      GROUP BY 1, 2
    ;;
    datagroup_trigger: daily_refresh
  }

  dimension: cohort_month {
    type: date
    sql: ${TABLE}.cohort_month ;;
  }

  dimension: months_since_first {
    type: number
    sql: ${TABLE}.months_since_first ;;
  }

  measure: customer_count {
    type: sum
    sql: ${TABLE}.customers ;;
  }

  measure: cohort_revenue {
    type: sum
    sql: ${TABLE}.revenue ;;
    value_format_name: usd
  }
}

Conclusion

La maîtrise de Looker et LookML représente un atout majeur pour les professionnels de la data en 2026. L'approche unique de Looker, centrée sur la couche sémantique, permet de créer des analyses reproductibles et fiables. Les candidats qui comprennent l'architecture sous-jacente, maîtrisent les techniques de modélisation avancées et connaissent les bonnes pratiques de développement se démarquent lors des entretiens techniques. La pratique régulière avec des projets concrets reste le meilleur moyen de consolider ces compétences et de se préparer aux défis du métier d'analyste BI.

Looker et LookML en 2026 : Guide Complet pour Analystes BI et Questions d'Entretien

Comprendre l'Architecture Looker

Fondamentaux de LookML

Structure d'un Projet LookML

Définition des Views

Techniques Avancées de Modélisation

Derived Tables et PDTs

Paramètres et Templated Filters

Questions d'Entretien Looker Courantes

Question : Quelle est la différence entre une dimension et une mesure ?

Question : Comment optimiser les performances d'un Explore lent ?

Question : Expliquez les différents types de joins en LookML

Prêt à réussir tes entretiens Data Analytics ?

Bonnes Pratiques de Développement LookML

Organisation du Code

Gestion des Versions et Tests

Intégration avec l'Écosystème Google Cloud

Préparation aux Entretiens Techniques

Exercice : Modéliser une Analyse de Cohorte

Conclusion

Articles similaires

Apache Superset en 2026 : tableaux de bord, SQL Lab et questions d'entretien

Power BI vs Tableau en 2026 : Quel Outil de Data Visualization Choisir ?

Maitriser dbt en 2026 : Modelisation SQL, Tests de Qualite et Preparation aux Entretiens Data Analyst