Comment connecter Snowflake et Google BigQuery à Dust pour exécuter des requêtes SQL en langage naturel

Les équipes d'analyse de données et d'opérations techniques font face à un goulot d'étranglement récurrent : les départements métiers multiplient les demandes de rapports et d'indicateurs ponctuels, tandis que les outils de BI en libre-service restent trop complexes pour les utilisateurs non spécialistes. Cependant, les bases de connaissances reposant sur la génération augmentée de récupération (RAG) classique ne permettent pas de répondre à ce besoin. La recherche sémantique s'appuie sur la similarité vectorielle de fragments textuels ; elle est incapable d'additionner des montants, d'agréger des données par catégorie ou de calculer des taux de rétention sur des millions de lignes.

Dust lève cet obstacle grâce à ses intégrations de données structurées et à sa fonctionnalité Table queries (requêtes sur tables). Plutôt que de déplacer ou de dupliquer les enregistrements clients, Dust se connecte directement à Snowflake et Google BigQuery, indexe uniquement les métadonnées des schémas de table (Table Schema) et permet à des agents d'IA de générer et d'exécuter des requêtes SQL contrôlées et strictement limitées à la lecture. Les données tabulaires extraites sont ensuite traduites en synthèses claires et en graphiques dynamiques.

Ce guide détaille l'architecture technique, les paramètres de sécurité, l'attribution des droits et les règles de configuration nécessaires pour connecter Snowflake et BigQuery à Dust et déployer des agents analytiques fiables.

Architecture : comment Dust interroge les entrepôts de données sans stocker de données brutes

Lorsqu'il s'agit de relier un entrepôt de données central à une plateforme d'IA tierce, la sécurité et la gouvernance des données sont primordiales. Dust s'appuie sur une architecture exclusive aux métadonnées :

1. Zéro synchronisation de données brutes : Dust ne synchronise, ne copie et ne stocke aucune ligne de données transactionnelles issues de Snowflake ou de BigQuery. La plateforme indexe uniquement les métadonnées structurelles : noms des bases de données, identifiants des jeux de données (datasets), schémas, noms des tables, noms des colonnes, types de données et descriptions natives renseignées dans l'entrepôt.
2. Injection du contexte de schéma : Lorsqu'un utilisateur pose une question quantitative (par exemple : « Quel a été le panier moyen par région au trimestre dernier ? »), l'agent consulte les schémas enregistrés pour identifier les entités et métriques pertinentes.
3. Génération SQL encadrée : Le grand modèle linguistique (LLM) rédige une requête conforme au dialecte cible (Snowflake SQL ou GoogleSQL).
4. Exécution directe en lecture seule : La requête est transmise via une liaison chiffrée à l'entrepôt et exécutée sous des identifiants restreints aux opérations de lecture.
5. Restitution et transparence d'audit : Dust synthétise les données retournées en langage naturel et génère des graphiques. Le bouton Tools inspection (inspection des outils) permet d'examiner le code SQL exécuté, la durée du traitement et les données brutes renvoyées.

Option 1 : Connecter Snowflake à Dust

Dust propose deux modes d'intégration pour Snowflake : la Snowflake Connection (connexion gérée) via Spaces > Connections et le Snowflake Tool (outil d'agent basé sur OAuth). Pour mettre à disposition des tables analytiques validées auprès des utilisateurs métiers, la connexion gérée est l'option standard.

1. Configuration de la sécurité et des ressources dans Snowflake

En appliquant le principe du moindre privilège, créez un entrepôt de calcul, un utilisateur technique et un rôle dédiés à Dust dans Snowflake :

-- Étape 1 : Créer le rôle dédié
CREATE ROLE dust_role;

-- Étape 2 : Créer un entrepôt de calcul avec mise en veille automatique
CREATE WAREHOUSE dust_warehouse
WITH WAREHOUSE_SIZE = 'XSMALL'
AUTO_SUSPEND = 300
AUTO_RESUME = TRUE;

GRANT USAGE ON WAREHOUSE dust_warehouse TO ROLE dust_role;

Choix de la méthode d'authentification : paire de clés vs mot de passe

Snowflake restreignant progressivement l'authentification par simple mot de passe pour les accès automatisés, l'authentification par paire de clés RSA (Key Pair Authentication) est fortement recommandée en production.

Configuration de l'authentification par paire de clés RSA (Recommandée) :

1. Générez une clé privée RSA 2048 bits et la clé publique associée :

   openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out dust_rsa_key.p8 -nocrypt
   openssl rsa -in dust_rsa_key.p8 -pubout -out dust_rsa_key.pub
   

2. Extrayez la chaîne de la clé publique sans en-tête, pied ni retours à la ligne :

   cat dust_rsa_key.pub | grep -v "BEGIN PUBLIC KEY" | grep -v "END PUBLIC KEY" | tr -d '\n'
   

3. Créez l'utilisateur Snowflake associé à la clé publique :

   CREATE USER dust_user
     DEFAULT_ROLE = dust_role
     RSA_PUBLIC_KEY = '<COLLER_ICI_LA_CLE_PUBLIQUE_NETTOYEE>';
   
   GRANT ROLE dust_role TO USER dust_user;
   

Alternative (authentification par mot de passe) :

CREATE USER dust_user
  PASSWORD = 'YourStrongPasswordHere'
  DEFAULT_ROLE = dust_role;

GRANT ROLE dust_role TO USER dust_user;

2. Politiques réseau et octroi des autorisations de lecture seule

Si votre compte Snowflake applique des règles de filtrage d'adresses IP via des Network Policies, ajoutez les adresses IP statiques de sortie de Dust à votre liste blanche :

• Espaces US (https://dust.tt) : 34.46.9.232
• Espaces UE (https://eu.dust.tt) : 35.195.191.222

Accordez ensuite les droits d'accès aux métadonnées et aux tables. Le connecteur Dust rejette tout rôle disposant de privilèges de modification ou d'écriture (INSERT, UPDATE, DELETE, MERGE) :

-- Droit USAGE sur la base de données et le schéma
GRANT USAGE ON DATABASE analytics_dw TO ROLE dust_role;
GRANT USAGE ON SCHEMA analytics_dw.marts TO ROLE dust_role;

-- Droit SELECT sur les tables physiques
GRANT SELECT ON ALL TABLES IN SCHEMA analytics_dw.marts TO ROLE dust_role;
GRANT SELECT ON FUTURE TABLES IN SCHEMA analytics_dw.marts TO ROLE dust_role;

Remarque importante : La connexion gérée Snowflake prend uniquement en charge les tables physiques. Les vues standards et les vues matérialisées sont ignorées. Si votre architecture exige d'interroger directement des vues, utilisez l'outil Snowflake Tool via OAuth.

3. Enregistrement de la connexion dans Dust

1. Dans Dust, accédez à Spaces > Connections, cliquez sur Add Connections et choisissez Snowflake.
2. Sélectionnez Key Pair Authentication (ou mot de passe).
3. Renseignez les paramètres demandés :
   • Account Identifier : Identifiant de compte (par exemple xy12345.us-east-1 ou organisation-compte).
   • Role : dust_role.
   • Warehouse : dust_warehouse.
   • Username : dust_user.
   • Private Key : Collez l'intégralité du contenu du fichier PEM de la clé privée, y compris les lignes d'en-tête et de fin.
4. Sélectionnez les bases de données, schémas et tables à rendre accessibles aux agents.

Option 2 : Connecter Google BigQuery à Dust

Google BigQuery s'interface avec Dust à l'aide d'une clé de compte de service Google Cloud Platform (GCP) IAM, assurant le cloisonnement géographique des requêtes et l'importation native des descriptions de champs.

1. Configuration du compte de service dans GCP

1. Dans la console Google Cloud, accédez à IAM et administration > Comptes de service.
2. Cliquez sur Créer un compte de service et nommez-le dust-warehouse-sa.
3. Attribuez les deux rôles IAM minimaux requis :
   • roles/bigquery.user : Autorise Dust à lancer des tâches de requête (Query Jobs), à lister les jeux de données et à consommer des ressources de calcul.
   • roles/bigquery.dataViewer : Permet de consulter la structure des schémas et de lire les enregistrements des tables.
4. Ouvrez l'onglet Clés du compte de service créé.
5. Cliquez sur Ajouter une clé > Créer une clé > JSON.
6. Enregistrez le fichier de clé téléchargé en lieu sûr.

2. Déclaration de BigQuery dans Dust

1. Dans Dust, rendez-vous dans Spaces > Connections > Add Connections et sélectionnez BigQuery.
2. Collez l'intégralité du contenu du fichier JSON de clé du compte de service.
3. Sélectionner l'emplacement BigQuery (Location) : BigQuery interdit l'exécution de requêtes croisées entre différentes régions (par exemple une jointure entre un jeu de données en EU et un autre aux US). Vous devez définir la région cible (par exemple US, EU, us-central1), et tous les jeux de données reliés à cette connexion doivent résider dans ce même emplacement.
4. Cochez les jeux de données et les tables à exposer.
5. Activer l'option « Use BigQuery descriptions » : En cochant cette case, Dust intègre automatiquement les commentaires et descriptions configurés au niveau des tables et colonnes dans BigQuery, dispensant ainsi l'équipe de documenter manuellement les champs dans les invites de commandes (prompts).

Comparatif : Snowflake Connection vs Snowflake Tool

Avant le déploiement sur Snowflake, comparez les spécificités des deux modes d'intégration :

Configuration et conception des instructions pour les agents d'analyse

Une fois les tables Snowflake ou BigQuery associées à un Space, les data analysts peuvent concevoir des agents spécialisés (par exemple @assistant-ventes ou @analyste-financier).

1. Ajout de l'outil Query Tables

1. Ouvrez l'interface d'édition dans Agent Builder > Instructions & Tools.
2. Dans la section Action & Data sources, cliquez sur Add a tool et choisissez Query Tables.
3. Cochez les tables de l'entrepôt à attribuer à l'agent (par exemple marts.fct_daily_orders).

2. Définition des règles de jointure (JOIN) et de la logique métier

Même si le modèle reconnaît les types de colonnes, des règles claires sont indispensables pour fiabiliser les calculs statistiques complexes :

Vous êtes un agent d'analyse de données chargé de répondre aux questions des équipes opérationnelles. Vous avez accès aux tables suivantes :
- fct_orders : Historique des transactions, montants et statut de commande.
- dim_customers : Typologie client, date d'inscription et profil d'entreprise.

Consignes pour la génération de requêtes SQL :
1. Pour relier ces tables, utilisez systématiquement dim_customers.customer_id = fct_orders.customer_id.
2. Pour calculer le chiffre d'affaires effectif, filtrez obligatoirement par order_status = 'COMPLETED', sauf demande explicite du pipeline brut.
3. Évitez SELECT * ; ne sélectionnez que les colonnes nécessaires à la réponse.
4. Pour les analyses chronologiques, convertissez les horodatages UTC en mois ou trimestres calendaires.
5. Accompagnez chaque résultat chiffré d'un commentaire synthétique en langage naturel mettant en évidence le constat opérationnel majeur.

3. Traçabilité et audit avec Tools Inspection

À chaque requête d'un utilisateur, Dust gère l'injection des schémas, la compilation du code SQL, son exécution dans l'entrepôt et la mise en forme de la réponse. Les membres de l'équipe peuvent cliquer sur Tools inspection pour examiner le code SQL généré, le temps d'exécution et les enregistrements bruts reçus, écartant tout doute lié à l'effet « boîte noire » de l'IA.

Bonnes pratiques pour les équipes de données

1. Exposer des datamarts modélisés (couche Gold) : Reliez Dust à des tables dimensionnelles propres (modélisées avec dbt par exemple) plutôt qu'à des tables brutes d'ingestion. La clarté des schémas augmente directement la justesse du SQL produit.
2. Documenter les colonnes au sein même de l'entrepôt : Renseignez les commentaires DDL (COMMENT) dans Snowflake et BigQuery. L'intégration de ces descriptions permet à l'IA d'interpréter fidèlement les acronymes métiers (MRR, CAC, LTV) sans surcharger les prompts.
3. Maîtriser les coûts de calcul :
   • Sur Snowflake, allouez un entrepôt de taille XSMALL avec un paramètre AUTO_SUSPEND inférieur ou égal à 300 secondes.
   • Sur BigQuery, configurez des limites d'octets analysés par requête sur le compte de service afin de prévenir les balayages de tables volumineuses.
4. Allier données quantitatives et documents qualitatifs : Un agent peut combiner l'outil Query Tables avec l'outil Search Data Source (recherche documentaire RAG). Il peut ainsi extraire les données consolidées dans BigQuery tout en consultant des bilans stratégiques sur Notion ou Google Drive pour éclairer les causes sous-jacentes des variations constatées.

Références

• Snowflake - Multiplayer AI
• BigQuery - Multiplayer AI
• Table queries - Multiplayer AI
• Snowflake - Multiplayer AI
• AI Data Analytics Agents: Turn Data Into Business Decisions | Dust
• Integrations | Dust AI Agents