Google Cloud étend l’analytique conversationnelle, mais la confiance des entreprises reste la véritable épreuve

Google Cloud a fait passer deux produits d’analytique conversationnelle en disponibilité générale, malgré des doutes persistants quant à la confiance à accorder à l’IA générative pour les données métiers critiques. BigQuery Conversational Analytics et l’API Conversational Analytics disposent désormais d’un statut prêt pour la production pour BigQuery et Looker. La prise en charge des bases de données reste en préversion.

L’annonce du 28 juillet va au-delà du lancement d’un chatbot supplémentaire. Google met en place une couche d’analytique gouvernée couvrant les entrepôts de données, les bases de données opérationnelles, les outils de business intelligence, les applications personnalisées et les assistants de travail. L’entreprise veut que l’analyse en langage naturel accompagne les employés dans cet environnement sans perdre les contrôles d’accès ni les définitions métier convenues.

Cette stratégie met sous pression Snowflake, Microsoft, Databricks et les fournisseurs spécialisés dans l’analytique. Toutefois, la compétition de fond n’oppose pas Google à un seul concurrent. Elle oppose les agents de données gouvernés aux interfaces génériques reposant sur des modèles de langage, qui produisent des réponses plausibles sans comprendre la manière dont une entreprise définit ses chiffres.

Google Cloud fait passer l’analytique conversationnelle en production

Le changement immédiat est que l’analytique conversationnelle est passée d’un ensemble d’expériences à une architecture produit Google Cloud prise en charge.

L’entreprise a rendu BigQuery Conversational Analytics et son API Conversational Analytics généralement disponibles. L’API offre aux développeurs une voie programmatique pour intégrer les mêmes capacités dans des applications au-delà des interfaces natives de Google.

Conversational Analytics dans Looker avait déjà atteint la disponibilité générale. Google ajoute désormais une prise en charge en préversion pour AlloyDB, Cloud SQL et Spanner, étendant l’analyse en langage naturel des entrepôts analytiques aux bases de données opérationnelles.

Cette distinction est importante, car un entrepôt contient généralement des données sélectionnées et préparées pour le reporting. Les bases de données opérationnelles conservent les enregistrements en direct derrière les applications, les transactions, les systèmes de stocks et les expériences client. Les questions portant sur ces systèmes exigent des contrôles plus stricts et une interprétation plus prudente.

L’annonce produit officielle étend également le patrimoine de données accessible. Les agents peuvent analyser les tables Lakehouse Managed Service, les catalogues Apache Iceberg REST et les catalogues Unity Catalog AWS S3 fédérés.

Google ne limite donc pas le produit aux données entièrement stockées dans son cloud. L’entreprise présente l’analytique conversationnelle comme une interface capable de s’étendre à des configurations de stockage et de cloud hétérogènes.

Les employés peuvent rencontrer ces agents dans BigQuery Studio, BigQuery Data Canvas, Database Studio, Looker, Data Studio et Gemini Enterprise. Les équipes de données peuvent publier des agents depuis plusieurs produits de données Google vers Gemini Enterprise afin d’en élargir l’accès dans l’organisation.

Les développeurs disposent d’un autre canal de distribution. L’API généralement disponible propose des SDK pour Node.js, Java, Go, Python, PHP, Ruby et .NET. Google prend également en charge les intégrations construites avec son Agent Development Kit et le Model Context Protocol, ou MCP.

MCP est une norme permettant de connecter des systèmes d’IA à des outils et à du contexte externes. Dans ce cas, il peut permettre à un autre agent d’appeler un agent d’analytique gouverné plutôt que de générer indépendamment de la logique de base de données.

Un assistant de chaîne d’approvisionnement, par exemple, pourrait demander à un agent de données financières de calculer l’effet sur la marge d’un retard d’expédition. Le calcul resterait connecté aux définitions financières gouvernées et aux autorisations de l’employé demandeur.

Google mentionne également les bots Slack et les applications personnalisées comme destinations possibles. Cela fait évoluer le modèle de déploiement : au lieu de consulter un produit d’analytique, les utilisateurs peuvent invoquer l’analytique partout où une décision est prise.

Les notes de version de l’API datent la disponibilité générale du 23 juin 2026. Elles documentent également les points de terminaison REST de version 1, les fonctionnalités de résidence des données et les contrôles de sécurité destinés aux entreprises.

L’annonce de blog ultérieure rassemble ces jalons techniques dans une histoire produit plus large. Google Cloud veut une couche conversationnelle unique couvrant les systèmes de données, les interfaces utilisateur et les workflows d’agents.

Cette ampleur crée la tension centrale. La distribution peut accroître l’adoption, mais chaque surface supplémentaire crée aussi un nouvel endroit où une réponse incorrecte peut influencer une décision.

Google Cloud parie que la gouvernance l’emportera sur un chatbot générique

Google Cloud considère le sens métier comme une infrastructure, et non comme du texte de prompt supplémentaire ajouté après le déploiement.

Un chatbot générique peut traduire une question en SQL. Cela ne signifie pas qu’il sait ce que l’organisation considère comme un chiffre d’affaires comptabilisé, un client actif ou une transaction éligible.

Ces définitions dépendent souvent de filtres, jointures, exclusions, règles comptables et périodes de reporting approuvés. Deux requêtes syntaxiquement valides peuvent produire des réponses différentes tout en paraissant tout aussi sûres d’elles à un employé non technique.

La réponse de Google associe le modèle de langage à des métadonnées, des modèles sémantiques, des requêtes vérifiées et les autorisations de données existantes. Un modèle sémantique fournit des définitions cohérentes des concepts métier que les applications peuvent réutiliser.

Dans Looker, cet ancrage provient de LookML, son langage de modélisation destiné à gérer de manière centralisée les dimensions, mesures, jointures et règles d’accès. Un agent peut récupérer ces définitions au lieu d’inventer une logique métier à partir de noms de tables et de colonnes.

Google utilise également ce qu’il appelle les Golden Queries. Il s’agit d’exemples validés qui capturent la logique métier acceptée pour des questions récurrentes. Ils fournissent à l’agent des schémas fiables lorsqu’il construit de nouvelles requêtes.

Knowledge Catalog apporte des descriptions, des glossaires et du contexte sur les relations. BigQuery Graph et Spanner Graph peuvent représenter des connexions couvrant plusieurs entités, aidant les agents à raisonner sur des relations à plusieurs étapes.

Cette conception est importante, car les schémas de bases de données s’expliquent rarement d’eux-mêmes. Une colonne appelée status peut désigner le statut d’un paiement, d’une expédition, d’un compte ou d’un processus interne.

Le modèle a besoin d’un contexte métier avant de pouvoir faire le bon choix. Ajouter ce contexte à l’aide d’un catalogue et d’une couche sémantique est plus fiable que d’attendre des employés qu’ils expliquent chaque définition dans chacune de leurs questions.

La couche de gouvernance limite également les personnes pouvant voir les résultats. Google affirme que les agents appliquent les contrôles d’accès existants fondés sur les rôles, y compris les autorisations au niveau des lignes et des colonnes.

Un responsable régional pourrait poser la même question qu’un dirigeant mondial tout en recevant un résultat plus restreint. L’agent devrait hériter de l’autorisation de la plateforme sous-jacente plutôt que de créer un système d’accès distinct.

Google a ajouté les Customer-Managed Encryption Keys, des contrôles de réseau privé et des options de résidence des données. L’entreprise affirme que le traitement par apprentissage automatique peut rester au sein de points de terminaison multirégionaux pris en charge aux États-Unis ou dans l’Union européenne.

L’entreprise cite également la conformité HIPAA parmi les contrôles disponibles. Ces fonctionnalités répondent aux exigences des achats, mais elles n’établissent pas à elles seules l’exactitude des réponses.

L’exactitude exige une évaluation continue une fois qu’un agent est accessible aux employés. Google permet aux administrateurs d’exporter des métriques de latence, de consommation de jetons, d’état de santé et d’utilisation des outils via OpenTelemetry, une norme sectorielle d’observabilité des systèmes.

Les équipes peuvent également examiner les traces et les retours des utilisateurs. Les libellés de requêtes BigQuery et les journaux d’activité Looker offrent un autre moyen de comprendre l’usage et d’enquêter sur des demandes étonnamment coûteuses ou discutables.

Des limites natives peuvent restreindre le nombre maximal d’octets traités par une requête. Ce contrôle est important lorsqu’une question informelle en langage naturel pourrait autrement déclencher une analyse étendue d’un grand jeu de données.

Ces éléments font de l’analytique conversationnelle un service exploité plutôt qu’une démonstration. Ils placent également une responsabilité importante sur les équipes de données.

Un catalogue faible, des définitions incohérentes des métriques ou des politiques d’accès incomplètes produiront toujours des résultats faibles. L’agent ne peut pas corriger tous les problèmes de gouvernance qui existent déjà sous-jacents.

Les organisations qui envisagent un déploiement large devraient traiter la préparation sémantique comme la maintenance d’une couche de connaissances partagée. La valeur provient de la connexion du contexte pertinent tout en préservant son origine, sa portée et son sens.

La véritable compétition oppose les agents de données gouvernés aux réponses plausibles

Le marché converge vers une leçon : l’analytique conversationnelle dépend davantage d’une sémantique préparée que de l’aisance conversationnelle d’un modèle.

Google Cloud n’est pas seul à parvenir à cette conclusion. Snowflake et Microsoft ont élaboré leurs propres approches autour du contexte sémantique, d’exemples vérifiés, des autorisations et de requêtes inspectables.

Cortex Analyst de Snowflake utilise des modèles sémantiques et un Verified Query Repository. Ce dépôt associe des questions en langage naturel à du SQL qu’un humain a vérifié.

Son système de requêtes vérifiées peut récupérer des exemples pertinents lorsqu’une nouvelle question ressemble à une question approuvée. Snowflake avertit que des requêtes vérifiées invalides peuvent réduire la qualité des réponses.

Cet avertissement révèle une réalité importante. La validation humaine ne disparaît pas avec l’arrivée d’une interface d’IA. Elle intervient plus tôt dans le processus, lorsque les équipes définissent les métriques et approuvent des requêtes représentatives.

Snowflake a également développé une boucle de retour qui étudie l’historique des requêtes et propose des filtres, métriques ou exemples vérifiés manquants. Ses suggestions de modèles exigent une revue humaine avant d’intégrer la couche sémantique.

Microsoft Fabric suit une approche similaire. Son agent de données peut interroger des entrepôts, des lakehouses, des modèles sémantiques Power BI, des bases de données KQL, des ontologies et des données organisationnelles exposées via Microsoft Graph.

Microsoft indique que l’accès aux données s’exécute sous l’identité de l’employé et ses autorisations existantes. Son agent produit des requêtes en lecture seule et expose les étapes intermédiaires à l’inspection.

Le guide de l’agent de données de l’entreprise indique également une limite importante. L’agent ne réalise pas d’analyses avancées, d’apprentissage automatique ni d’inférence causale.

Cette limite est utile, car des réponses fluides peuvent faire passer une agrégation ordinaire pour une analyse plus approfondie. Un système qui identifie une corrélation dans des données historiques n’a pas expliqué pourquoi cette relation existe.

Google élargit cette frontière avec des outils analytiques intégrés. Ses agents peuvent invoquer des fonctions de prévision, de détection d’anomalies, d’embeddings, de classification, de scoring et d’analyse des contributions.

TimesFM, le modèle de fondation de Google pour la prévision des séries temporelles, prend en charge certaines tâches de prévision et de détection d’anomalies. La fonction ai.key_drivers vise à identifier les facteurs associés à une variation inattendue d’une métrique.

Les Agentic Workflows poussent le système plus loin. En préversion, ils peuvent planifier des rapports, surveiller des métriques et enquêter sur des anomalies sans attendre qu’une personne formule la première question.

Google indique qu’une enquête multidimensionnelle peut examiner 10 à 20 facteurs contribuant à une variation de métrique. La détection d’anomalies en streaming peut également lancer une enquête lorsqu’une mesure franchit un seuil défini.

C’est plus conséquent qu’un simple chat. Un chatbot attend un utilisateur, tandis qu’un agent de surveillance décide quand un élément mérite de l’attention et construit une explication.

Ce modèle concurrence l’évolution de Microsoft, des agents de données vers les agents opérationnels. Il remet également en cause les flux de travail traditionnels de business intelligence, organisés autour de tableaux de bord, d’alertes et de rapports créés par des analystes.

Pourtant, tous les fournisseurs se heurtent au même goulot d’étranglement. Une requête générée peut être valide tout en répondant à la mauvaise question métier.

Prenons le cas d’un dirigeant commercial qui demande pourquoi les revenus ont baissé. La bonne analyse peut exiger une normalisation des taux de change, l’exclusion des commandes annulées, des ajustements liés aux calendriers régionaux et des règles de comptabilisation.

Un modèle de langage peut produire un SQL impressionnant sans appliquer ces règles. Un agent gouverné a davantage de chances d’y parvenir, car les règles peuvent résider dans sa couche sémantique et dans des exemples vérifiés.

L’avantage de Google réside dans l’éventail de surfaces connectées à ses produits de données. La force de Snowflake consiste à maintenir la conversation au plus près des données gouvernées au sein de sa plateforme.

Microsoft peut relier l’analytique à Microsoft 365, Teams, Power BI et Copilot Studio. Databricks apporte son propre contexte d’intelligence des données et de lakehouse à cette même compétition.

Le vainqueur ne sera pas désigné uniquement par la précision obtenue sur des benchmarks fondés sur des questions préparées. Les entreprises examineront l’effort de maintenance, la traçabilité, l’application des accès, la latence et le traitement des défaillances sur des milliers de demandes réelles.

C’est pourquoi l’adversaire principal est l’approche de l’enveloppe générique. Elle promet une démonstration rapide, tandis que les agents gouvernés exigent une modélisation sémantique et une discipline opérationnelle avant un déploiement à grande échelle.

L’enveloppe est plus facile à lancer. Le système gouverné a davantage de chances de résister au contact de la finance, de la conformité, de la sécurité et de la prise de décision des dirigeants.

Un accès accru aux données crée aussi davantage de façons de se tromper

Google Cloud a étendu la portée de l’agent plus rapidement que quiconque n’a établi une norme universelle pour mesurer la confiance analytique.

La disponibilité générale signale la maturité du produit et des engagements de support. Elle ne signifie pas que chaque réponse générée est exacte pour chaque schéma, chaque question ou chaque définition organisationnelle.

Google emploie un langage prudent à propos de ses fonctionnalités d’ancrage. Les modèles sémantiques et les Golden Queries contribuent à réduire les jointures supposées, mais ils ne peuvent pas garantir que chaque nouvelle question corresponde à une interprétation approuvée.

Un exemple vérifié peut couvrir les revenus mensuels sans couvrir les remboursements enregistrés après la période de reporting. Une variation inhabituelle peut conduire le système vers une logique qui paraît raisonnable mais enfreint les règles.

La qualité des métadonnées varie également selon les entreprises. De nombreuses organisations disposent de métriques dupliquées, de tables non documentées, de tableaux de bord abandonnés et de conventions de nommage incohérentes.

L’accès conversationnel peut exposer ces incohérences à un public plus large. L’agent peut rendre plus visible un problème de gouvernance existant sans le résoudre.

Les bases de données opérationnelles ajoutent une autre difficulté. Leurs schémas privilégient souvent les performances applicatives et l’intégrité transactionnelle plutôt que des concepts analytiques faciles à comprendre.

Joindre des données entre BigQuery, Cloud SQL, Spanner, AlloyDB et des catalogues externes peut introduire des différences de fraîcheur, de disponibilité régionale, de correspondance des identités et de définition des métriques.

Le système doit aussi fournir une réponse claire lorsque les sources divergent. Choisir silencieusement une réponse créerait une fausse certitude, tandis qu’énumérer chaque conflit peut rendre l’assistant moins utile.

La sécurité hérite d’une complexité similaire. Les autorisations au niveau des lignes peuvent contraindre les résultats des requêtes, mais l’explication d’un agent peut toujours révéler des tendances sensibles par le biais de résumés ou de comparaisons.

Les organisations ont besoin de tests portant sur les risques d’inférence, l’injection de prompts, les métadonnées malveillantes et les appels d’outils non autorisés. Elles doivent examiner à la fois la requête générée et le langage utilisé pour décrire son résultat.

Publier un agent d’analytique dans un assistant généraliste de travail élargit l’audience au-delà des analystes formés. Cette expansion améliore la facilité d’utilisation, mais réduit la probabilité que chaque utilisateur inspecte la logique générée.

Un analyste peut contester un résultat suspect en lisant le SQL et en vérifiant les tables sources. Un responsable commercial recevant une réponse dans un chat peut accepter le même résultat parce que sa formulation semble assurée.

Les flux de travail proactifs relèvent encore les enjeux. Un résumé planifié peut diffuser une interprétation erronée avant même que quelqu’un ne la demande.

Une enquête déclenchée peut également sélectionner des facteurs contributifs non pertinents. L’analyse des contributions identifie des associations statistiques, et non nécessairement des facteurs causaux.

Les contrôles d’observabilité du produit offrent une voie pour surveiller ces défaillances. Les administrateurs peuvent inspecter les traces des agents, les retours, la latence, l’utilisation des tokens et les appels d’outils sous-jacents.

Cependant, collecter de la télémétrie n’est que la première étape. Les entreprises ont toujours besoin de jeux d’évaluation, de voies d’escalade, de responsables des définitions métier et d’un processus pour corriger les mauvaises réponses.

Elles ont également besoin de métriques distinguant l’adoption de la confiance. Un nombre élevé de questions peut refléter un usage enthousiaste, des tentatives répétées ou des employés vérifiant des réponses incohérentes.

De même, les retours positifs peuvent être trompeurs. Les utilisateurs récompensent souvent une présentation claire même lorsqu’ils ne peuvent pas vérifier le calcul sous-jacent.

Les évaluations les plus utiles compareront les réponses des agents à des résultats examinés par des analystes, sur des questions récurrentes comme inhabituelles. Les tests devraient inclure un langage ambigu, des enregistrements restreints, des données incomplètes et des définitions contradictoires.

Les équipes devraient consigner si l’agent demande des précisions lorsque l’incertitude est significative. Refuser de deviner peut constituer un meilleur résultat que produire immédiatement un graphique.

Les contrôles des coûts exigent une vigilance similaire. Une limite maximale de taille de requête peut empêcher des analyses excessives, mais elle peut aussi produire une analyse partielle si l’utilisateur ne comprend pas cette restriction.

Les mesures de tokens ne couvrent qu’une partie des dépenses. La maintenance des modèles sémantiques, l’évaluation, l’examen des incidents et la vérification humaine façonneront également la charge opérationnelle totale du déploiement.

L’architecture de Google Cloud répond à nombre de ces préoccupations plus directement qu’une enveloppe générique de chatbot. L’entreprise n’a toutefois pas publié de preuves indépendantes montrant que le système complet élimine les hallucinations analytiques.

La conclusion défendable est plus limitée. L’ancrage, les autorisations, la logique vérifiée et l’observabilité créent de meilleures conditions pour une analyse fiable.

La capacité de ces conditions à produire des réponses fiables dépend de la qualité des données de chaque organisation, de sa discipline sémantique, de son processus d’évaluation et de sa volonté de maintenir des humains responsables des décisions importantes.

Ce qu’il faut surveiller après le lancement de Google Cloud

La prochaine étape sera décidée par les preuves en production, la préparation des bases de données et les réponses concurrentielles, plutôt que par une nouvelle démonstration de chat soignée.

Le premier signal sera l’adoption mesurable des produits BigQuery et Looker désormais généralement disponibles. Google a décrit une transition des expérimentations vers les déploiements en entreprise, mais les acheteurs ont besoin de preuves opérationnelles plus claires.

Les indicateurs utiles comprennent les utilisateurs actifs, l’usage répété, les taux de réussite des questions, les volumes de requêtes et la part des réponses nécessitant une correction par un analyste. Les outils de surveillance de Google peuvent saisir une partie de cette image.

Les études de cas clients devraient également expliquer l’ampleur du déploiement. Un petit groupe de spécialistes des données présente un défi de confiance différent de celui de dizaines de milliers d’employés métier.

Des preuves d’une large adoption avec de faibles taux de correction renforceraient l’affirmation de Google selon laquelle l’analytique conversationnelle peut devenir une interface de données standard. Un examen manuel intensif affaiblirait l’argument en faveur d’une large autonomie.

Le deuxième signal sera de savoir si les capacités en preview atteignent un statut de production stable. Conversational Analytics for AlloyDB, Cloud SQL, and Spanner représente une expansion majeure au-delà de l’analyse centrée sur les entrepôts de données.

Agentic Workflows reste également en preview. Son évolution montrera à quelle vitesse Google peut passer de la réponse aux questions à la surveillance des métriques et au lancement d’enquêtes.

La disponibilité générale de ces fonctionnalités indiquerait que Google a résolu suffisamment de problèmes de fiabilité, de sécurité et de support pour prendre des engagements de production. Une longue période de preview suggérerait une complexité non résolue.

Les détails comptent davantage que l’étiquette. Les acheteurs devraient examiner les régions prises en charge, le comportement des autorisations, la couverture d’audit, la latence et les différences de fonctionnalités entre chaque base de données.

Ils devraient également surveiller si les flux de travail proactifs bénéficient de garde-fous d’approbation plus stricts. L’enquête automatisée est utile, mais les actions à fort impact exigent toujours un contrôle humain clair.

Le troisième signal est la manière dont Snowflake, Microsoft et Databricks réagissent. Chaque fournisseur dispose déjà d’un chemin reliant le langage naturel aux données d’entreprise gouvernées.

Surveillez une couverture des sources plus étendue, des intégrations plus profondes avec les outils de travail, une automatisation sémantique renforcée et des méthodes d’évaluation publiées. Les systèmes de requêtes vérifiées deviendront probablement plus centraux dans l’ensemble de cette catégorie.

Les progrès de Microsoft méritent une attention particulière, car Fabric combine des modèles sémantiques, l’identité organisationnelle, des outils de collaboration et l’automatisation des flux de travail. Snowflake peut répliquer avec une analytique étroitement gouvernée, proche de sa plateforme de données.

La pression concurrentielle pourrait améliorer l’interopérabilité. Les entreprises conservent rarement toutes leurs données opérationnelles et analytiques à l’intérieur des frontières d’un seul fournisseur, quelle que soit leur stratégie de plateforme.

La prise en charge des catalogues ouverts, des connexions MCP et des sources fédérées peut réduire l’enfermement propriétaire. Toutefois, l’accès interplateforme complique aussi les examens de sécurité et la cohérence sémantique.

La question décisive pour les clients n’est pas de savoir si un agent peut répondre à un prompt impressionnant. Il s’agit de savoir si les employés peuvent se fier aux réponses courantes sans créer une file cachée de travail de vérification.

Google Cloud a élaboré une réponse sérieuse à ce problème. Elle combine l’accès aux données, l’ancrage sémantique, les autorisations, l’observabilité, les API et la distribution dans les outils de travail au sein d’une seule architecture.

Le résultat transforme la conversation en entreprise. Un chatbot personnalisé enveloppé autour d’une base de données ressemble désormais moins à un produit fini qu’à un prototype précoce.

Pourtant, les fonctionnalités de gouvernance ne fabriquent pas automatiquement la confiance. Les organisations doivent définir leurs métriques, corriger leurs métadonnées, tester les questions ambiguës et attribuer des responsables pour les défaillances.

Avant d’étendre l’analytique conversationnelle, choisissez un flux de travail important et mesurez l’ensemble de son parcours. Suivez les questions, la logique générée, les corrections, les autorisations, la latence et les décisions métier qui en découlent.

Si Google Cloud peut transformer ces déploiements contrôlés en preuves reproductibles, l’analytique conversationnelle ira au-delà du chat. Elle deviendra une interface gouvernée permettant aux entreprises d’enquêter sur leurs propres opérations.