Interroger BigQuery en langage naturel

Vous pouvez interroger BigQuery en langage naturel, et les deux facteurs qui décident si c’est sûr et abordable sont propres à BigQuery : l’accès s’accorde par des rôles IAM plutôt que par des instructions SQL GRANT, et le coût dépend des octets lus, pas du temps de calcul. Accordez deux rôles étroits, comprenez ce qu’une question peut balayer, et l’interrogation en langage naturel de BigQuery est une lecture cadrée, avec une facture lisible.

Ce qu’il vous faut côté Google Cloud

Ce guide s’adresse aux ingénieurs data et aux responsables analytics qui utilisent BigQuery, envisagent de laisser poser des questions en langage courant, et assument le projet où atterrit la facture. Il suppose que vous pouvez attribuer des rôles IAM dans la console Google Cloud. Le formulaire de connexion champ par champ, avec la provenance de chaque identifiant, est dans le guide de connexion BigQuery.

Deux projets, et les deux rôles qui les cadrent

BigQuery sépare où une requête s’exécute de où vivent les données. Un job de requête s’exécute — et se facture — toujours dans votre projet de facturation ; les tables qu’il lit peuvent appartenir à un projet de données entièrement différent. C’est cette séparation qui rend les jeux bigquery-public-data interrogeables depuis votre propre compte.

La frontière de lecture tient en deux rôles IAM, chacun sur le bon projet :

Rôle	Où l’accorder	Ce qu’il permet
`BigQuery Data Viewer`	Le projet de données (ou un seul jeu de données)	Lire les données et les métadonnées des tables
`BigQuery Job User`	Le projet de facturation	Lancer des jobs de requête payés par votre projet

Aucun des deux ne peut écrire, créer ou supprimer quoi que ce soit. Cette paire est donc une frontière que Google applique de son côté, avant qu’une requête de n’importe quel outil n’atteigne vos tables. Par-dessus vient la seconde frontière : chaque instruction générée est analysée en arbre syntaxique complet et rejetée si ce n’est pas une lecture — l’argument pour ces deux couches est dans l’analytique IA en lecture seule.

Une précision honnête pour les connexions OAuth : l’écran de consentement Google affiche l’étendue bigquery complète, dont le libellé évoque la gestion des données, parce que c’est l’étendue exigée pour exécuter une requête — une requête crée un job. Si vous voulez que la restriction de lecture soit appliquée par Google et pas seulement par le validateur, connectez un compte de service portant exactement les deux rôles ci-dessus, et rien d’autre.

La facture se compte en octets lus, et les garde-fous existent

En tarification à la demande, BigQuery facture au téraoctet balayé, selon le modèle de tarification de Google. Le stockage étant orienté colonnes, SELECT * lit chaque colonne de chaque ligne touchée — et, contre-intuitivement, ajouter LIMIT 10 ne réduit rien : le balayage a lieu avant que la limite s’applique. Les questions ad hoc génèrent plus de requêtes qu’un tableau de bord, donc les garde-fous comptent davantage, pas moins.

Trois sont livrés avec Datarelix et ne se configurent pas question par question :

Un plafond de lecture de 10 Go par requête (maximum_bytes_billed). Une question qui balaierait davantage est refusée par BigQuery avant le premier octet facturé — une question incontrôlée sur une table de plusieurs téraoctets ne coûte rien, plutôt qu’une fortune.
Un délai d’exécution de 30 secondes par requête.
Un plafond de 5 000 lignes par résultat, pour qu’une question sans borne ne renvoie pas un résultat sans borne.

Deux garde-fous restent de votre côté. Cadrez la connexion sur un jeu de données modélisé plutôt que sur les événements bruts — les schémas gouvernés battent les tables brutes sur le coût comme sur la justesse. Et pour un plafond global à vous, BigQuery propose des quotas de requête personnalisés par projet et par utilisateur, indépendants de tout outil.

Pour la dépense attendue, le calcul est court :

coût/mois  ≈  questions/jour × octets moyens lus par question × votre tarif régional à la demande × 30

Le plafond de 10 Go borne le pire terme : quelle que soit la taille de la table, une question ne balaie jamais plus de 10 Go. Sur un jeu de données modélisé et partitionné, une question analytique typique lit des mégaoctets.

Les tables qui exigent un filtre de partition

Une table BigQuery peut être configurée pour exiger un filtre de partition — une requête sans WHERE sur la colonne de partition est rejetée d’emblée, précisément pour empêcher les balayages complets accidentels. C’est là que le text-to-SQL générique casse d’habitude : le modèle ignore que l’exigence existe, et la requête échoue avec une erreur opaque.

Datarelix lit les métadonnées de partition pendant la découverte — la colonne de partition, son type, et si un filtre est exigé, y compris le partitionnement au moment de l’ingestion où la colonne est une pseudo-colonne plutôt qu’un champ déclaré — et inclut le filtre requis dans la requête générée. Si vous ajoutez plus tard une table à filtre obligatoire, relancez la découverte pour que l’exigence soit prise en compte.

Les particularités GoogleSQL dans les requêtes générées

BigQuery parle GoogleSQL, et un système qui génère du SQL générique produit des instructions qu’il rejette. Ce qui apparaît réellement dans les requêtes générées :

Des noms en trois parties entre accents graves — `projet.jeu_de_donnees.table` — parce que le projet de données fait partie de l’adresse.
UNNEST pour les tableaux et les structures. Les schémas BigQuery reposent souvent sur des champs imbriqués et répétés ; les questions sur des structures profondément imbriquées sont le point faible du SQL généré, sur ce moteur comme sur tous les autres.
TIMESTAMP contre DATETIME — le premier est un instant absolu, le second une heure civile sans fuseau. Un schéma qui mélange les deux invite des réponses à fenêtre temporelle fausse qu’aucune couche en langage naturel ne rattrapera.
QUALIFY pour filtrer sur une fonction de fenêtre sans sous-requête d’emballage.

Sur le jeu public des prénoms, « Combien de bébés ont été appelés Ada chaque année depuis 2000 ? » génère quelque chose comme :

SELECT year, SUM(number) AS births
FROM `bigquery-public-data.usa_names.usa_1910_current`
WHERE name = 'Ada' AND year >= 2000
GROUP BY year
ORDER BY year;

Les interprétations — correspondance exacte du prénom, années civiles, naissances sommées entre États — sont visibles dans la requête, et c’est ce qui rend la réponse vérifiable : la méthode est dans comment vérifier une réponse générée par IA.

Des contraintes déclarées, jamais appliquées

BigQuery accepte les contraintes de clé primaire et étrangère, mais uniquement comme métadonnées NOT ENFORCED — et la plupart des jeux de données n’en déclarent aucune. La découverte remonte les clés déclarées quand elles existent ; sinon, les chemins de jointure sont inférés depuis les conventions de nommage, et l’inférence se trompe parfois. Vérifiez les jointures des premières réponses sur tout jeu de données que vous n’avez pas modélisé vous-même, et décrivez les colonnes au nom cryptique — pourquoi le contexte sémantique compte montre ce que cela change.

Connecter BigQuery à Datarelix

Trois modes d’authentification : compte Google (OAuth) — une fenêtre de consentement propre à chaque connexion, avec un jeton de rafraîchissement chiffré et rattaché à cette connexion ; clé de compte de service (JSON) — la clé est stockée chiffrée, adaptée aux connexions durables ; et l’usurpation de compte de service (impersonation). Se connecter à Datarelix avec Google n’accorde que l’identité ; autoriser une connexion BigQuery est toujours une étape distincte et explicite.

La connexion nomme un projet de facturation, un emplacement et un seul jeu de données autorisé au format projet-de-donnees.jeu — un jeu explicite est exigé, et les requêtes y sont restreintes même là où le SQL de BigQuery pourrait aller plus loin. L’emplacement doit correspondre à la région du jeu de données, sinon BigQuery le déclare introuvable. La découverte passe par l’API BigQuery plutôt que par du SQL INFORMATION_SCHEMA, si bien que les jeux publics et inter-projets s’introspectent proprement. Les étapes de configuration et le tableau de dépannage sont dans le guide de connexion BigQuery.

Ce qui ne fonctionne pas sur BigQuery

Un jeu de données par connexion : les jointures inter-jeux dans une même question sont exclues — créez une connexion par jeu de données. Il n’existe aucun chemin d’écriture : ni DML, ni DDL, ni chargement. Les schémas STRUCT/ARRAY profondément imbriqués sont le point faible du SQL généré. Et le plafond de lignes fait de « exporter la table » le mauvais outil — c’est un travail pour BigQuery lui-même.

D’où viennent ces faits

Les définitions de rôles suivent le contrôle d’accès BigQuery ; la facturation suit la tarification BigQuery ; la sémantique des emplacements suit les emplacements BigQuery ; le comportement des filtres de partition suit la documentation des tables partitionnées. Les affirmations produit décrivent Datarelix tel que livré en août 2026 et sont énoncées canoniquement sur la page sécurité. L’exemple de requête s’exécute sur le jeu public usa_names de Google.

Commencez par interroger un jeu de données public

Pointez une connexion sur bigquery-public-data.usa_names avec votre propre projet comme projet de facturation — données publiques, deux rôles, rien de chez vous d’exposé — puis suivez le guide de démarrage et posez la question ci-dessus. Lisez le SQL généré avant de lire le chiffre. Vos 14 premiers jours tournent aux limites Pro, sans carte bancaire.