← Retour au blog

BigQuery-Converse: ce que l'IA native change pour les analystes

Lucian BLETAN

La sortie de BigQuery-Converse début janvier 2025 marque un tournant. La promesse est simple : permettre aux analystes et aux équipes métier d’interroger les données en langage naturel, directement depuis l’interface BigQuery. Fini le blocage du “je ne sais pas écrire cette requête SQL complexe”. Mais cette nouvelle simplicité cache des défis : la précision des réponses dépend de la qualité des métadonnées, le coût peut devenir imprévisible, et la gouvernance doit être repensée. Ce n’est pas la fin du SQL, mais le début d’une collaboration homme-machine au cœur de l’entrepôt.

le nouveau workflow de l’analyste

L’analyste passe d’un rôle de “traducteur” (besoin métier -> SQL) à un rôle de “superviseur” (valider la requête générée, enrichir les métadonnées).

après avec BigQuery-Converse

question en langage naturel

génération sql par l'ia

validation & ajustement par l'analyste

exécution & analyse

avant

question métier

traduction manuelle en sql

exécution & validation

prérequis pour une adoption réussie

  • Un catalogue de données bien entretenu: Des descriptions claires pour chaque table et chaque colonne sont indispensables. Le LLM ne peut pas deviner ce que “col_trx_st” signifie.
  • Des politiques de coût (FinOps): Des budgets et des alertes sur les requêtes générées sont nécessaires pour éviter les factures explosives.
  • Une gouvernance des accès à jour: Les permissions de l’utilisateur qui pose la question sont automatiquement appliquées par le LLM. Les RLS/CLS doivent être impeccables.

comment ça marche en pratique

BigQuery-Converse analyse la question de l’utilisateur et les schémas des tables auxquelles il a accès pour générer la requête SQL la plus pertinente. Il utilise ensuite cette requête pour répondre.

étape 1: poser la question en langage naturel

L’utilisateur pose sa question dans une nouvelle interface de chat.

“Montre-moi le chiffre d’affaires par pays pour les clients de la catégorie ‘premium’ sur les 3 derniers mois.”

étape 2: validation de la requête générée

L’IA ne se contente pas de donner un résultat, elle montre le SQL qu’elle a généré. C’est une étape de transparence cruciale. L’analyste peut voir, valider ou corriger la requête.

-- SQL généré par BigQuery-Converse
SELECT
    c.country,
    SUM(o.amount_eur) AS total_revenue
FROM
    `analytics.orders` o
JOIN
    `analytics.customers` c ON o.customer_id = c.customer_id
WHERE
    c.category = 'premium'
    AND o.order_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 3 MONTH)
GROUP BY
    c.country
ORDER BY
    total_revenue DESC;

étape 3: analyse et itération

L’utilisateur obtient son résultat (tableau, graphique) et peut continuer la conversation pour affiner son analyse.

“Ok, maintenant exclus les États-Unis et ventile par mois.”

les nouveaux défis

  • Qualité des métadonnées: La performance du système dépend directement de la qualité de la documentation de vos tables. C’est le moment d’investir dans un catalogue de données propre.
  • Gestion des coûts: Une question vague peut générer une requête qui scanne des téraoctets. Il faut mettre en place des quotas et des alertes sur les estimated_bytes_processed.
  • Ambiguïté sémantique: Comment l’IA interprète-t-elle des termes métier comme “client actif” ? La réponse doit être dans le glossaire de votre catalogue.

pièges et parades

  • Symptôme: Les réponses sont souvent fausses ou à côté de la plaque.

    • Cause: Les schémas des tables sont cryptiques (c_ts, u_id).
    • Correctif: Lancer un projet de “nettoyage de printemps” des métadonnées. Chaque table et colonne critique doit avoir une description claire.
  • Symptôme: Les coûts de BigQuery ont augmenté de 50% en un mois.

    • Cause: Les utilisateurs posent des questions trop larges sans se rendre compte de l’impact.
    • Correctif: Mettre des quotas par utilisateur/rôle et utiliser les labels de BigQuery pour tracer les coûts générés par Converse.
  • Symptôme: L’IA refuse de répondre à des questions sur des données sensibles.

    • Cause: Les politiques de masquage (CLS) fonctionnent correctement.
    • Correctif: C’est un succès, pas un problème ! La gouvernance est respectée. Il faut expliquer aux utilisateurs pourquoi l’accès est restreint.

faq

  • Est-ce que cela remplace les data analysts ? Non, cela augmente leur productivité. Ils passent moins de temps sur des requêtes répétitives et plus de temps sur l’analyse à haute valeur ajoutée, la validation et l’amélioration des métadonnées.

  • Puis-je l’utiliser sur mes propres tables sans préparation ? Techniquement oui, mais les résultats seront probablement décevants. Le succès de l’outil dépend de la qualité de votre documentation de données.

  • Comment gérer les définitions métier complexes ? Intégrez votre glossaire métier dans le catalogue de données. BigQuery-Converse est conçu pour utiliser ces définitions pour mieux interpréter les questions.