Conversational Analytics Looker : les 6 prérequis

Conversational Analytics dans Looker permet de poser une question en langage naturel et d'obtenir une réponse chiffrée, un graphique et l'explication du calcul. En 2026, la fonction est en disponibilité générale, une API du même nom permet de l'intégrer dans vos applications, et un serveur MCP géré par Looker ouvre le modèle à Gemini CLI, Claude ou Cursor. Tous ces agents ont un point commun : ils ne répondent juste que si le modèle LookML en dessous est juste. Voici les six prérequis et un plan de pilote en quatre semaines.

Ce que ces outils font, concrètement

Le vocabulaire Google a beaucoup bougé ; voici l'état en septembre 2026, d'après la documentation et le blog Google Cloud.

Fonction	Statut	Ce qu'elle fait
Conversational Analytics dans Looker	Disponibilité générale depuis novembre 2025	Chat sur un ou plusieurs explores (jusqu'à cinq par agent), graphique, explication « comment a été calculé ce chiffre »
Agents de données (data agents)	GA	Agents nommés, partageables, avec instructions, glossaire, requêtes vérifiées et filtres par défaut
Agents de dashboard	Déployés en 2026	Un panneau de conversation intégré à un dashboard, limité à ses données
Advanced Analytics (Code Interpreter)	Disponible, pas pour les agents de dashboard	Génère et exécute du Python pour des analyses au-delà du SQL (prévisions, corrélations)
Conversational Analytics API	GA depuis l'été 2026	Intégrer des agents dans vos applications, Slack, portails ; SDK Node, Python, Java, Go, .NET
Serveur MCP géré par Looker	Preview (août 2026)	Gemini CLI, Claude Code et Desktop, Cursor, VS Code interrogent le modèle LookML avec les droits de l'utilisateur, OAuth 2.1
Publication dans Gemini Enterprise	Preview	Les agents créés dans Looker apparaissent dans l'espace de travail Gemini de l'entreprise

Le mécanisme est le même partout : l'agent ne génère pas de SQL contre vos tables. Il choisit des champs et des filtres dans un explore, et Looker compose la requête à travers LookML. Les jointures, les agrégations, les définitions et les permissions sont celles du modèle.

Pourquoi la couche sémantique décide de tout

Google le dit lui-même : la couche sémantique de Looker « réduit les erreurs de données des requêtes en langage naturel jusqu'à deux tiers ». La raison est simple. Un LLM qui écrit du SQL directement sur des tables doit deviner quelle table est la bonne, quelle colonne porte le montant net, comment joindre commandes et clients sans doubler les lignes. Sur un entrepôt réel, il se trompe souvent, et de manière plausible.

Avec un explore, il n'a plus qu'à choisir parmi des champs nommés, décrits, déjà joints correctement. La mesure net_revenue existe, sa description dit ce qu'elle inclut, la sécurité au niveau ligne s'applique automatiquement.

Le revers : l'agent hérite de tous les défauts du modèle. Trois mesures nommées « CA » avec des formules différentes, et l'agent en choisira une au hasard. Quatre cents champs dont soixante utiles, et il se perdra. Pas de description, et il devinera. Un pilote Conversational Analytics sur un modèle non audité produit des réponses fausses avec assurance, et l'organisation en conclut que « l'IA ne marche pas ».

Les six prérequis

1. Un explore par domaine, avec les champs utiles seulement

L'agent travaille sur un à cinq explores. Chacun doit répondre à une famille de questions (ventes, marketing, support) avec des champs limités par fields: et les champs techniques masqués. Un explore de soixante à cent champs bien choisis donne de meilleures réponses qu'un explore de quatre cents.

2. Des labels et des descriptions sur chaque champ

C'est le prérequis le plus rentable. label en langage métier, description qui dit ce que le champ inclut et exclut, avec les synonymes que les utilisateurs emploient. L'agent lit ces descriptions pour choisir.

measure: net_revenue {
  label: "CA net"
  description: "Chiffre d'affaires HT facturé, remises et avoirs déduits. Synonymes : revenu net, ventes nettes. Date de référence : facture."
  type: sum
  sql: ${invoiced_amount_excl_tax} - ${discount_amount} - ${credit_note_amount} ;;
}

3. Une seule définition par indicateur

Aucune mesure dupliquée entre vues, aucun champ mort. La check-list d'audit LookML couvre ce point ; sans lui, l'agent est un tirage au sort entre définitions concurrentes.

4. La sécurité au niveau ligne dans le modèle

Les agents respectent access_filter et les access grants parce qu'ils passent par Looker. Si vos restrictions vivaient dans des dashboards filtrés à la main ou dans des rapports séparés, elles n'existent pas pour l'agent. Elles doivent être dans le modèle avant d'ouvrir la conversation à quiconque.

5. Des questions de référence et leurs réponses attendues

Avant le pilote, collectez vingt à trente questions réelles des utilisateurs et calculez la réponse attendue à la main. Ce jeu de test sert à mesurer l'agent, puis à l'alimenter en « requêtes vérifiées » (verified queries) qui améliorent ses réponses aux questions proches.

6. Un propriétaire et un budget de tokens

Depuis la page tarifaire 2026, l'usage est mesuré en data tokens avec un quota inclus par édition (60 M d'entrée et 1,2 M de sortie par mois en Standard, 300 M et 6 M en Enterprise). Gratuit jusqu'au 30 septembre 2026, facturé au-delà du quota à partir du 1er octobre (3 dollars par million de tokens d'entrée, 20 dollars par million en sortie). Quelqu'un doit suivre la consommation dans System Activity et être responsable de la qualité des réponses.

Un pilote en quatre semaines

Le format qui fonctionne : un domaine, un groupe d'utilisateurs, une mesure de succès chiffrée, une décision à la fin.

Semaine 1 : cadrage et audit ciblé. Choisir le domaine (celui où les demandes ad hoc encombrent le plus l'équipe data). Auditer l'explore concerné sur les prérequis 1 à 4, corriger sur une branche. Collecter les trente questions de référence avec les futurs utilisateurs. Vérifier que Gemini in Looker est activé et que les permissions sont en place.

Semaine 2 : construire l'agent. Créer un agent de données sur l'explore corrigé. Écrire les instructions (contexte métier, unités, exercice fiscal, ce qu'il ne faut pas faire), le glossaire, les filtres par défaut. Charger cinq à dix requêtes vérifiées. Passer les trente questions : noter juste, faux, ambigu. Objectif de sortie de semaine : 70 % de réponses justes.

Semaine 3 : itérer et ouvrir. Corriger les causes des réponses fausses, presque toujours dans le modèle (une description ambiguë, une mesure manquante) plutôt que dans l'agent. Repasser le jeu de test, viser 85 à 90 %. Ouvrir à dix utilisateurs réels avec un canal de retour simple. Si le cas d'usage l'exige, tester l'agent de dashboard ou l'accès MCP depuis Gemini CLI.

Semaine 4 : mesurer et décider. Compter les questions posées, la part de réponses jugées utiles par les utilisateurs, le temps économisé à l'équipe data sur les demandes ad hoc, la consommation de tokens. Décider : étendre à un deuxième domaine, intégrer via l'API dans un outil métier, ou arrêter. Documenter pourquoi.

Ce qui s'observe en production : dans un grand groupe industriel, la couche sémantique Looker sur BigQuery existait depuis plusieurs années avant que la question des agents ne se pose. Le travail préparatoire n'a pas été de construire le modèle mais de le nettoyer pour un lecteur qui ne connaît pas le contexte implicite : descriptions, suppression des doublons, explores resserrés.

Ce qu'il ne faut pas attendre

Les agents ne remplacent pas la modélisation. Ils ne réconcilient pas trois chiffres d'affaires ; ils en affichent un, avec assurance. Ils ne corrigent pas une jointure qui double les lignes. Ils n'inventent pas une mesure qui n'existe pas dans le modèle, et c'est une qualité.

Ils ne remplacent pas non plus les dashboards. Les questions récurrentes de la direction restent mieux servies par un dashboard rapide et stable. Les agents servent la longue traîne : les questions qu'on ne posait pas parce qu'il fallait attendre un analyste.

FAQ

Faut-il une édition Looker particulière pour Conversational Analytics ?

La fonction est disponible sur Looker (Google Cloud core) et Looker (original), une fois Gemini in Looker activé par un administrateur. Les quotas de data tokens diffèrent selon l'édition, et le serveur MCP géré n'est pas disponible pour les instances hébergées par le client.

L'agent peut-il voir des données auxquelles l'utilisateur n'a pas accès ?

Non, s'il passe par Looker. Les agents, l'API et le serveur MCP appliquent les rôles, les access grants et les access_filter de l'utilisateur authentifié. C'est précisément pour cela que la sécurité doit être dans le modèle et non dans les dashboards.

Que se passe-t-il si l'agent se trompe ?

Chaque réponse expose la requête générée et l'explication du calcul. L'utilisateur peut vérifier les champs et les filtres choisis. Les erreurs fréquentes se corrigent en améliorant les descriptions, en ajoutant une requête vérifiée ou en resserrant l'explore, pas en réentraînant quoi que ce soit.

Combien coûte un pilote ?

Le coût logiciel est nul jusqu'au 30 septembre 2026, puis couvert par le quota inclus pour un pilote de dix utilisateurs. Le coût réel est le temps de préparation du modèle et de construction de l'agent : quatre semaines pour un domaine, avec un interlocuteur métier disponible deux heures par semaine.

Et ensuite

Si vous envisagez un pilote, commencez par les trente questions de référence et une relecture de l'explore concerné. Ces deux livrables décident de la réussite du pilote avant même la création de l'agent.

Voir l'offre Agents analytiques, et pour aller plus loin : La check-list d'audit LookML et Pourquoi vos chiffres ne concordent pas.

Sources

• Looker Conversational Analytics now GA, Google Cloud Blog, 14 novembre 2025
• Conversational Analytics in Looker overview, documentation
• Conversational Analytics in Google Data Cloud in Q3 2026, Google Cloud Blog, 29 juillet 2026
• Understanding Looker's Conversational Analytics API, Google Cloud Blog
• Looker-managed MCP server, documentation
• Introducing Looker MCP Server, Google Cloud Blog
• Looker in the 2026 Gartner Magic Quadrant, Google Cloud Blog, 2 juillet 2026
• Looker pricing, section Conversational Analytics et data tokens