Google Next 2026 pour l’ingénierie des données : Looker, BigQuery et les serveurs MCP.

Google Cloud Next 2026 à Las Vegas s’est déroulé à l’échelle que la marque suggère, avec des conférences principales et des ateliers répartis sur un vaste site. Pour ceux qui travaillent sur des projets Looker ou BigQuery, les sessions consacrées à l’analyse, à l’intégration des données et à l’analyse agente étaient les plus importantes. Ce qui suit présente les annonces susceptibles de changer la manière dont de tels projets sont planifiés au cours des douze prochains mois, puis ajoute des enseignements tirés des entretiens avec les clients, qui se sont avérés plus utiles que la plupart des nouvelles concernant les produits.

Le cadre : de la réponse à l’action

Le message global de Google concernant les plateformes d’analyse et de données est un passage d’un « système d’intelligence » à un « système d’action ». Le premier correspond à une BI réactive qui répond aux demandes. Le second consiste en un ensemble d’agents proactifs qui surveillent les métriques, résument leurs constatations et agissent au profit de l’entreprise.

Rien de tout cela n’est nouveau en termes de principe. Les alertes déclenchées par des événements et les réponses automatisées existent depuis vingt ans dans les outils de BI d’entreprise. Néanmoins, cette nouvelle insistance est utile, car elle modifie ce qui fait partie du périmètre d’un projet Looker commandé en 2026.

Cela a une conséquence pratique pour quiconque rédige une description des travaux. Auparavant, les rapports et les tableaux de bord constituaient l’ensemble des livrables. Désormais, il faut également définir qui ou quoi consomme les données (des personnes ou des agents), quelles questions ces agents doivent traiter seuls, et qui certifie les règles métier sur lesquelles ils s’appuient. Les projets qui omettent cette étape ont tendance à la découvrir plus tard, au cours de la réalisation, à un coût plus élevé.

Agentic Data Cloud et ses trois idées

Le discours principal portait sur le Agentic Data Cloud, la réponse de Google à un décalage : les outils conçus pour aider les humains à comprendre les données n’étaient jamais destinés à un monde où des agents IA agissent seuls sur ces données. Trois idées en soutiennent le fonctionnement.

Les agents ont besoin de sens en plus des données. Diriger un agent puissant vers un ensemble de données brutes en espérant qu’il comprenne la situation commerciale est un pari coûteux. Il doit apprendre que le « chiffre d’affaires net » exclut les retours, que une métrique est calculée différemment dans deux unités commerciales, ou qu’une clause d’un contrat modifie la manière dont une livraison est acheminée. Le Knowledge Catalog a pour but de capturer et de maintenir en permanence ces connaissances institutionnelles, afin que chaque agent qui travaille avec les données parte de la même compréhension encadrée.

Les agents doivent agir, et non seulement faire des rapports. Exemple tiré d’une conférence : au lieu d’un tableau de bord montrant une augmentation soudaine des annulations de commandes, un agent remarque cette hausse, effectue une analyse des causes profondes à partir des données logistiques et commerciales, identifie le centre de distribution responsable, recommande un réaffectement des livraisons, et active un agent de surveillance pour voir quand la situation s’améliore. Personne n’a eu besoin de demander quoi que ce soit.

Les données restent là où elles se trouvent. Les plateformes cloud exigent depuis longtemps que tout soit rassemblé en un seul endroit avant que la valeur ne puisse être exploitée. Ici, les agents peuvent interroger les données où qu’elles se trouvent, que ce soit sur Google Cloud, AWS, Azure, Snowflake, Databricks ou des systèmes locaux, sans avoir à effectuer au préalable une migration coûteuse.

Looker en tant que couche sémantique et couche d’expérience

En termes concrets, le Agentic Data Cloud combine BigQuery, le Knowledge Catalog, Gemini et Looker, Looker servant de couche d’expérience tandis que ces quatre outils fonctionnent comme un seul système plutôt que comme des produits distincts. L’analyse conversationnelle, les agents de tableau de bord, les workflows déclenchés et les autres fonctionnalités de Looker sont les moyens par lesquels cette architecture atteint les utilisateurs, c’est là que l’on perçoit la différence entre une BI qui rapporte des informations et une BI qui agit.

Le nouveau Explore va encore plus loin. Le modèle ancien basé sur le choix des champs et les filtres est remplacé par une interface visuelle de type glisser-déposer, similaire à Google Search ou Google Docs. Trois assistants Gemini y sont intégrés : un pour naviguer en langage naturel, un pour rédiger des expressions Looker à partir d’un anglais simple, et un pour choisir le type de graphique le plus adapté à la question posée.

Pour les équipes de livraison, cela signifie moins de temps consacré à guider les utilisateurs à travers la couche de visualisation et plus de temps consacré à la qualité de LookML ainsi qu’à sa correction sémantique, puisque les assistants déduisent leurs réponses à partir de ce que définit le modèle. Une couche sémantique négligée produira des réponses de même qualité, mais à l’échelle de conversations réelles.

Les agents de tableau de bord sont désormais généralement disponibles. Les tableaux de bord cessent d’être des artefacts statiques destinés uniquement à une diffusion : les utilisateurs peuvent les interroger, demander des résumés du contenu et des modifications, et comprendre les raisons derrière un chiffre au cours d’une conversation. Le meilleur exemple d’entreprise provient de YouTube, où les gestionnaires de partenaires consultent les portfolios des créateurs à partir de quinze sources de données fusionnées, tout cela depuis ce qui ressemble à un tableau de bord Looker ordinaire.

Les workflows déclenchés transforment les agents de simples répondants passifs en surveillants proactifs. Les métriques sont suivies en permanence, et les équipes reçoivent une alerte dès que un seuil est dépassé. Le plan à court terme prévoit des agents capables de rédiger des e-mails ou de publier des messages sur Slack de leur propre initiative. Pour l’analyse opérationnelle, cela représente une valeur bien supérieure à ce qu’on pourrait croire, et c’est un type de demande que les clients n’avaient pas encore formulée il y a deux ans.

D’autres annonces concernant Looker méritent également d’être mentionnées :

• Les agents Looker intégrés à Gemini Enterprise. Les agents développés dans Looker peuvent être publiés dans Gemini Enterprise et gérés aux côtés des autres agents d’entreprise. Pour les clients qui y investissent, Looker fait alors partie d’une stratégie d’IA plus large plutôt que d’être un outil BI indépendant.
• API d’analyse conversationnelle, désormais GA. Elle intègre nativement le SDK Looker, permet l’incorporation via iframe et dispose d’une implémentation de référence open source. Les équipes qui intégrent des fonctionnalités d’analyse conversationnelle dans leurs propres applications disposent enfin d’une solution officiellement prise en charge, et les conversations qui étaient bloquées parce que l’API n’était qu’en version bêta peuvent être relancées.
• LookML Agent pour VS Code (version bêta). Une extension couvrant l’ensemble du cycle de vie de LookML, depuis le langage naturel.
• Looker MCP en tant que standard ouvert. Un serveur MCP géré existe en parallèle des options open source via MCP Toolbox. Relier Looker à des assistants tels que Claude permet une analyse croisée et un raisonnement agentiel au-delà de ce que Looker peut gérer seul.
• Intégrations natives avec les couches sémantiques. Looker lit directement les définitions de graphes de BigQuery ainsi que les vues sémantiques de Snowflake, de sorte que la logique sémantique déjà présente dans BigQuery n’a plus besoin d’être reconstituée en LookML.
• Agents multi-exploitation. Un agent peut utiliser jusqu’à cinq explorations en même temps. La configuration de Yahoo combine des données RH, financières, de recherche et de support au sein d’agents uniques sur plusieurs instances Looker.

Ce que Yahoo et Virgin Media O2 ont appris

Les sessions d’analyse conversationnelle menées par Yahoo et Virgin Media O2 se sont révélées les plus utiles pour ceux qui travaillent dans ce domaine. La principale conclusion : la précision dépend principalement de deux facteurs, à savoir les requêtes clés et les instructions destinées aux agents, écrites en YAML. Yahoo a constaté une amélioration de la qualité des résultats après avoir transféré les instructions des agents de JSON vers YAML. Ils ont ensuite déplacé les requêtes clés ainsi que le glossaire métier vers LookML au lieu de les conserver ailleurs, ce qui a considérablement réduit la complexité des instructions, car le modèle raisonne désormais à partir de la couche sémantique et non à partir d’un contexte manuellement rédigé.

Le résumé fourni par Yahoo lui-même était la phrase la plus citée de l’événement : l’analyse conversationnelle commence par la couche sémantique, et non par l’IA. Une fois que les données et le modèle sont prêts, l’analyse conversationnelle constitue presque l’étape suivante dans l’évolution de ces technologies.

La démarche pratique pour les équipes consiste à changer d’approche. Écrire des prompts longs et soigneusement réglés pour les agents cède la place à l’enrichissement du modèle lui-même, car tout ce qui est placé dans LookML est accessible à chaque agent et à chaque utilisateur, tandis que tout ce qui se trouve dans un prompt ne sert qu’un seul agent et devient rapidement obsolète.

Un bon modèle LookML pour l’analyse conversationnelle a donc évolué. La version de base inclut désormais des étiquettes, des descriptions, des synonymes et des commentaires pour chaque champ, des requêtes types intégrées dans LookML, ainsi qu’un glossaire métier au format YAML au sein du modèle. Les instructions destinées aux agents restent délibérément succinctes, car la couche sémantique s’occupe du travail principal. La configuration des agents de tableau de bord, des workflows déclenchés et des requêtes types doit désormais faire partie intégrante des exigences de base de tout projet Looker sérieux, et non figurer dans une liste d’options supplémentaires.

Le retour de Data Studio

Looker Studio a été rebaptisé Data Studio, avec des missions élargies. Il gère désormais trois types d’artefacts. Le premier est le rapport ou le tableau de bord bien connu, alimenté par BigQuery, les connecteurs Google et des partenaires SaaS, ou la couche sémantique de Looker. Le deuxième est un agent d’analyse conversationnel développé dans BigQuery puis publié là-bas. Le troisième est une nouvelle idée de « applications de données », dans laquelle les notebooks de Colab sont publiés sous forme d’applications interactives.

Les applications de données se situent entre un tableau de bord et une application complète. Elles sont utiles pour les clients qui comptent sur Looker pour les rapports opérationnels, souhaitent plus d’interactivité et préfèrent ne pas faire développer une application intégrée complète.

Une conséquence du changement de marque et des nouvelles fonctionnalités de type self-service : le « Studio in Looker » intégré, autrefois présenté comme l’avenir de l’interface utilisateur de Looker, n’est plus disponible pour les organisations qui ne l’avaient pas activé, et son arrêt est prévu pour le 15 juin 2026.

BigQuery : agents d’ingénierie des données et serveur MCP géré

Une grande partie des versions préliminaires de l’année dernière est désormais disponible en version générale. Cela inclut les agents pour l’ingénierie des données et la science des données, les analyses conversationnelles au sein de BigQuery et son API, le BigQuery ADK, un serveur MCP distant géré pour BigQuery, le MCP Toolbox open source, ainsi qu’un plugin permettant de collecter des données sur les performances des agents.

Certains éléments plus récents sont en réalité plus importants qu’ils ne le semblent au premier abord.

Échelle dynamique des ressources. BigQuery ajoute des ressources de calcul lorsque les agents sont actifs et les retire lorsqu’ils sont inactifs, sans nécessité de configuration manuelle de l’échelle. L’objection courante concernant le coût des analyses conversationnelles à grande échelle s’atténue considérablement.

Graphes de BigQuery. Un moteur de graphes natif sans étape ETL, capable de s’adapter à des milliards de nœuds et prenant en charge le langage ISO GQL. L’ajout le plus intéressant est Measures dans BigQuery Graph, qui associe des métriques contrôlées à une cartographie des relations, permettant ainsi aux agents de raisonner sur des dépendances à plusieurs étapes.

Les mesures en tant qu’extensions du raisonnement. Une façon utile de distinguer ces deux types de mesures : les mesures LookML régissent le calcul, en définissant ce qu’une métrique signifie et en garantissant une syntaxe SQL cohérente pour tous les analystes et agents utilisant Looker. Les mesures graphiques, quant à elles, gèrent le raisonnement en plaçant les mêmes définitions de métriques au sein d’un graphique d’entités connectées telles que des produits, des fournisseurs, des hubs et des itinéraires, permettant ainsi à un agent de comprendre pourquoi une métrique a changé en suivant les relations entre les facteurs influents.

Services de migration

Le BigQuery Migration Service a été renommé Data Analytics Migration Services, et les modifications sont importantes ; par conséquent, toute personne qui prévoit de passer de Snowflake, Cloudera ou Databricks en 2026 devrait en réévaluer la faisabilité. Pour Cloudera et Databricks, l’évaluation se fait automatiquement et produit un plan détaillant les charges de travail avec des estimations du coût total de possession. Le SQL provenant de Hive, Snowflake et d’autres dialectes est traduit en GoogleSQL au niveau du compilateur. La migration de type Lakehouse prend en charge les tables Iceberg, Parquet et Hive, et un service de validation automatisé fonctionne en temps réel, évaluant la précision table par table et colonne par colonne. Comme les API de migration sont accessibles via MCP, un outil tel que Claude Code peut orchestrer l’ensemble du processus de migration.

Les versions précédentes du service présentaient des résultats mitigés en matière de traduction complexe de SQL, tandis que la nouvelle génération semble bien plus performante. Le tableau de bord de validation se distingue, car il prend en charge une grande partie des vérifications manuelles qui ont retardé les calendriers de migration pendant des années. Les équipes qui avaient initialement prévu des semaines de travail pour que des analystes comparent manuellement le nombre de lignes et les valeurs des colonnes devraient revoir ces estimations.

Fédération entre clouds

En ce qui concerne la fédération, le Databricks Unity Catalog sur AWS S3 peut désormais être lu dans les deux sens, et Snowflake Polaris ainsi que AWS Glue peuvent également être lus depuis BigQuery. Tout repose sur la norme de catalogue REST Apache Iceberg, ce qui permet à BigQuery de consulter directement ces catalogues externes sans transfert de données.

Pour les clients qui ne peuvent pas ou ne veulent pas migrer complètement, l’approche change. Au lieu d’exiger que tout soit transféré dans BigQuery, l’offre consiste à laisser les données en place, à y accéder via BigQuery, et à ajouter Looker et Conversational Analytics par-dessus. Les entreprises utilisant Snowflake, qui seraient autrement exclues d’une approche analytique axée sur GCP, disposent ainsi d’une véritable option, susceptible de servir de tremplin vers des migrations plus complètes.

Leçons de migration tirées de Target, Wells Fargo et Virgin Media O2

Un panel réunissant ces trois entreprises a mis en évidence des schémas que beaucoup ont appris à leurs dépens, mais qui méritent d’être rappelés.

La première règle, et la plus importante : transférer d’abord la couche sémantique. Mettez en place la couche Looker ou BI sur GCP afin que les utilisateurs métier puissent accéder aux données pendant que le transfert technique est encore en cours, et comblez l’écart grâce à des tâches de réplication tactique qui copient les ensembles de données clés dans BigQuery. Virgin Media O2 a réussi cela grâce à six grandes migrations de plateforme, et Wells Fargo a approuvé cette approche.

Autres modèles :

• Réduisez l’empreinte avant de migrer. L’IA peut identifier à l’avance les données inutilisées et les doublons ; une entreprise du groupe a découvert que plus de 80 % de ses données étaient dupliquées.
• Migrez d’abord sans modification, puis modernisez. Le refactoring en cours de migration allonge indépendamment les délais.
• Mettre en place une gouvernance dès le premier jour. Les contrats de données, un glossaire métier et des règles de qualité des données font partie intégrante du programme de migration, car leur intégration ultérieure échoue souvent une fois la fenêtre politique fermée.
• Commencer petit avec les contrats de données. Choisissez une zone délimitée, élaborez des contrats clairs entre le fournisseur et l’utilisateur pour ce cas précis, et utilisez-les comme modèle de ce qu’est une bonne pratique avant d’élargir l’échelle.

Target a également proposé une notion intéressante à retenir : les « objectifs irrationnels » : choisissez des objectifs qui ne peuvent être atteints que si la plateforme est reconstruite autour de méthodes natives de l’IA. Cela déplace le débat de la manière de migrer vers la manière de transformer.

Kit de l’agent de données

Dans sa version préliminaire, le Data Agent Kit associe une extension VS Code à des plugins pour Gemini CLI, Cloud Code et Codex. Ensemble, ils regroupent des compétences et des outils MCP destinés aux workflows de données BigQuery : des compétences agentic, des serveurs MCP, des outils pour se connecter à BigQuery, ainsi que des plugins pour une personnalisation approfondie de VS Code. Ces compétences elles-mêmes sont open source et peuvent être adaptées.

Les cabinets de conseil et les équipes de clients qui développent déjà des outils internes d’exécution agentic devraient les examiner sérieusement. D’après une première analyse, il couvre l’ingénierie au niveau de BigQuery et complète les solutions plus larges d’orchestration des livrables ainsi que LookML, s’intégrant ainsi aux approches basées sur des compétences déjà en usage.

Le catalogue de connaissances, anciennement Dataplex, en tant que contexte pour les agents

Dataplex est désormais Knowledge Catalog, redéfini comme le backend contextuel pour les workflows agents de Google Cloud. Trois piliers le soutiennent. Le premier agrège des métadonnées provenant des services Google, y compris Looker, ainsi que de catalogues de partenaires tels qu’Atlan, Collibra et SAP. Le deuxième enrichit ces métadonnées grâce à une génération automatisée et à un glossaire métier déjà mis en production. Le troisième propose une recherche sémantique, avec une API Context permettant aux agents de récupérer ce dont ils ont besoin.

Le cas le plus instructif provient de Bloomberg Media. Son « Knowledge Gap Agent » apprend des échecs des agents, détecte les endroits où le contexte des données est incorrect ou manquant, et propose des mises à jour pour Knowledge Catalog afin d’obtenir une validation humaine. Résultat majeur : 102 notes d’utilisation générées automatiquement pour vingt tables MVP, ce qui a amélioré de 63 % la précision d’un agent d’accès aux données en SQL.

Pour des projets de moindre envergure, Knowledge Catalog restera en arrière-plan. Pour les clients qui développent des agents d’analyse conversationnelle à grande échelle, dont les connaissances institutionnelles ne sont pas encore codifiées dans un endroit accessible aux agents, c’est l’élément manquant. Bloomberg a qualifié ce problème fondamental de « problème des 42 dollars », qui affecte à la fois les analystes humains et les agents d’IA : des connaissances qui ne sont documentées nulle part dans la plateforme de données.

Dans leur exemple, un analyste junior a sélectionné les bons tableaux, écrit un SQL valide et appliqué la logique standard de calcul du chiffre d’affaires net, mais a obtenu un résultat incorrect. Le fournisseur de services de paiement facture 42 dollars pour chaque litige client, et ce montant doit être ajouté au calcul du chiffre d’affaires. Cette règle n’était présente dans aucun schéma, dans aucun pipeline et dans aucun document accessible. Elle se trouvait sur une page Confluence de 2017 dont l’auteur avait quitté l’entreprise.

Le moteur sémantique fait-il défaut ?

Une critique qui circule par la suite affirme que Google mise entièrement sur la couche d’agents, tandis que son contexte sémantique et commercial reste relativement faible. Selon cette perspective, le Knowledge Catalog ressemble à un agrégateur de métadonnées, sans vraiment les caractéristiques d’un véritable système d’exploitation d’entreprise comme Frontier d’OpenAI ou Foundry de Palantir. Sans un moteur sémantique puissant qui relie les significations commerciales aux agents, même les outils avancés risquent de produire des résultats erronés, des hallucinations ou de donner une réponse correcte à la mauvaise question.

La plupart de ces constats restent valables, et la couche sémantique revêt une importance plus grande dans un monde basé sur des agents qu’elle ne l’a jamais été dans un tableau de bord. Une interprétation plus optimiste est que la couche sémantique LookML couvre déjà la majeure partie des fonctions liées au contexte métier que l’on attendrait d’un système d’exploitation d’entreprise. Elle élimine le problème des multiples versions de la vérité, fournit des définitions de métriques réglementées, et sert de stock fiable de métriques pour des assistants tels que Claude via le MCP Toolbox.

Le fait que le Knowledge Catalog ait parlé peu de l’intégration LookML lors de la conférence ne signifie pas que LookML est inactif. Le travail se déroule à un niveau inférieur à celui où les critiques le cherchent.

Les preuves concrètes se trouvent dans les meilleures pratiques documentées par Google pour configurer Conversational Analytics dans Looker. Elles s’appuient sur deux sources principales : la structure, les champs, les étiquettes, les descriptions et les synonymes du modèle LookML, ainsi que des valeurs de champ distinctes extraites des données, la cardinalité (le nombre de valeurs uniques) déterminant la manière dont ces valeurs sont utilisées.

Pour récupérer les valeurs distinctes, Conversational Analytics utilise la méthode API de longue date de Looker, model_fieldname_suggestions. Il s’agit du même mécanisme qui permet les suggestions de filtres dans le sélecteur de champs et les filtres de tableau de bord, désormais réutilisé comme signal de référence pour le modèle. Ainsi, trois paramètres LookML existants, suggestions, suggest_explore et suggest_dimension, servent également de moyen pour les développeurs de déterminer quels valeurs Conversational Analytics doit prendre en compte.

Les équipes n’ont pas besoin d’attendre que le produit le fasse ; on peut assembler la même idée manuellement dans un entrepôt BigQuery. En plus d’un dictionnaire de données standard issu de INFORMATION_SCHEMA, on peut conserver un guide en markdown, mis à disposition d’un assistant sous forme de compétence et régénéré périodiquement par une étape de profilage. Ce guide décrit chaque table en indiquant le nombre de lignes, les plages de dates, ainsi que les ensembles de valeurs et les cardinalités des champs catégoriels à forte signification, permettant ainsi à l’assistant de savoir, par exemple, que la table des messages est répartie entre iMessage, Slack, WhatsApp et d’autres dans des proportions connues, au lieu de devoir deviner.

Conversational Analytics effectue désormais la même fonctionnalité au niveau de LookML, généralisée pour tous les utilisateurs de Looker. Prenons par exemple une dimension city alimentée par des données clients ou opérationnelles. Le système extrait ses valeurs distinctes, telles que Brighton, Hove et Londres, et laisse la cardinalité déterminer dans quelle mesure chaque valeur doit être prise en compte lorsque les utilisateurs posent des questions.

Les outils mis à disposition d’un développeur LookML sont ces trois paramètres, utilisés de la manière suivante :

view: customer {
  dimension: city {
    label: "Customer City"
    description: "The city associated with the customer's primary address. Most operational activity occurs in Brighton and Hove (UK head office) and London (UK secondary office)."
    type: string
    sql: ${TABLE}.customer_city ;;
    # Hard-code a curated list of values rather than letting Looker
    # run SELECT DISTINCT against a large table.
    suggestions: ["Brighton", "Hove", "London", "Edinburgh", "Manchester"]
  }
  dimension: customer_segment {
    label: "Customer Segment"
    description: "Customer tier based on annual recurring revenue."
    type: string
    sql: ${TABLE}.segment ;;
    # Pull suggestions from another view rather than scanning
    # the much larger customer fact table.
    suggest_explore: segments
    suggest_dimension: segments.segment_name
  }
}

En combinaison avec des descriptions, des synonymes et quelques requêtes clés intégrées dans le modèle, ils fournissent à la couche sémantique de LookML exactement ce que les critiques attendent d’un système d’exploitation d’entreprise : un contexte métier solide et géré pour la couche des agents, avec un échantillonnage des valeurs réelles tenant compte de la cardinalité, tout cela issu du même LookML que celui utilisé derrière les tableaux de bord et les outils d’exploration.

Ainsi, la perception du Knowledge Catalog par rapport à LookML est différente. Aujourd’hui, LookML apparaît comme une simple entrée parmi de nombreuses autres dans l’architecture du Knowledge Catalog, et il est facile de comprendre pourquoi cela peut sembler insuffisant. Au cours des douze à dix-huit prochains mois, on peut s’attendre à ce que cela change considérablement, puisque Google a toutes les raisons de faire de LookML l’entrée la plus importante du catalogue et non simplement l’une parmi plusieurs.

Le moteur sémantique que réclament les critiques n’est en réalité pas absent, car une grande partie de ses fonctionnalités existe déjà dans LookML. Ce qui reste à déterminer, c’est si Knowledge Catalog évoluera pour devenir la couche de contexte métier qui permettra à LookML de conserver son sens dans l’ensemble de la stack d’agents, ou si un autre produit remplira ce rôle. Dans tous les cas, le temps consacré à perfectionner LookML est un investissement qui se révèle fructueux.