Donner la parole aux données métier : querychat et la fin du SQL ad hoc

À la une

querychat multi-tables : vers le self-service analytics piloté par le langage naturel

Dans beaucoup d'entreprises, l'accès aux données reste un goulot d'étranglement : un métier a une question, il la formule mal dans un ticket, un analyste traduit en SQL, renvoie un export, et le métier reformule sa question trois jours plus tard parce que la première réponse ne correspondait pas à son besoin réel. querychat a été conçu pour casser cette boucle en traduisant le langage naturel en SQL vérifiable, directement intégré dans une app Shiny ou un dashboard Quarto.

La nouveauté qui change la donne, c'est le passage au multi-tables. Jusqu'ici, querychat fonctionnait bien sur une table unique bien dénormalisée, ce qui limitait son usage aux cas simples. Avec add_table() et add_tables(), on peut désormais déclarer plusieurs tables liées — commandes, clients, produits — et laisser le modèle comprendre les relations pour générer des jointures pertinentes. C'est ce qui rapproche querychat d'un vrai cas d'usage d'entreprise, où les données vivent rarement dans une seule table plate.

Deux autres apports consolident l'outil pour un usage professionnel. L'historique de conversation persistant évite de perdre le fil d'une analyse entre deux sessions, ce qui compte dès qu'un utilisateur métier revient sur un sujet après une nuit de réflexion. Et la commande /handoff permet de transformer les résultats d'une session de chat en dashboard Quarto ou application Shiny téléchargeable : l'exploration ad hoc devient un livrable réutilisable, sans repartir de zéro en code.

Ce que ça permet concrètement : un analyste publie une app querychat connectée à son entrepôt de données, les équipes métier posent leurs questions en français, le SQL généré reste visible et vérifiable (point essentiel en entreprise, surtout dans des secteurs réglementés comme le pharma, où le cas d'usage de traduction en langage naturel vers SQL vérifiable est déjà documenté), et si une analyse mérite de devenir un outil permanent, elle se fige en dashboard sans réécriture.

Les limites restent réelles. Le multi-tables fonctionne bien quand le schéma est propre et documenté ; sur un entrepôt mal modélisé, le modèle génère des jointures fausses avec la même assurance que des jointures justes. L'historique persistant pose aussi une question de gouvernance : où sont stockées ces conversations, qui y a accès, combien de temps on les garde. Avant de déployer querychat au-delà d'un pilote, il faut traiter ces questions comme on traiterait celles d'un outil de BI classique, pas comme un gadget conversationnel.

CODE R

library(querychat)

# Connexion a une base avec plusieurs tables liees
con <- DBI::dbConnect(RSQLite::SQLite(), "ventes.sqlite")

config <- querychat_init(con)
config <- config$add_table(
  table_name = "commandes",
  description = "Une ligne par commande, avec id_client et id_produit"
)
config <- config$add_table(
  table_name = "clients",
  description = "Un client par ligne, avec sa region et son segment"
)
config <- config$add_tables(
  list(
    list(table_name = "produits", description = "Catalogue produits avec categorie et prix")
  )
)

# Dans l'app Shiny
server <- function(input, output, session) {
  chat <- querychat_server("chat", config)
}

ui <- bslib::page_fluid(
  querychat_ui("chat")
)

shiny::shinyApp(ui, server)

Le schéma déclare trois tables liées avant de lancer le chat, ce qui permet au modèle de générer des jointures cohérentes plutôt que de se limiter à une seule table plate.

Notre avis

querychat franchit un cap réel avec le multi-tables : c'est la différence entre une démo et un outil déployable sur un vrai schéma de données d'entreprise. Le /handoff vers Shiny ou Quarto est l'idée la plus maline du lot, car elle évite l'écueil classique du chatbot qui ne produit rien de durable. Reste à cadrer la gouvernance des conversations avant tout déploiement au-delà d'un pilote.

→ Pour qui : Data analysts et data scientists qui gèrent des demandes ad hoc des métiers et veulent industrialiser l'accès aux données sans réécrire du SQL à chaque requête.

LES BRÈVES

OUTILS

Import Data arrive dans Positron

La fonctionnalité la plus demandée par les utilisateurs de Positron entre en préversion : importer un fichier via une interface graphique qui génère le code R correspondant. Un gain de temps pour les analystes qui jonglent entre CSV, Excel et bases de données sans vouloir retenir la syntaxe exacte de chaque fonction d'import.

Source : opensource.posit.co ↗

OUTILS

Positron généralise l'édition de notebooks Jupyter

L'éditeur de notebooks devient le défaut pour les fichiers .ipynb, avec exploration de données interactive et conversion automatique du point-and-click en code reproductible. Les Data Connections gagnent un pilote ODBC générique et l'authentification OAuth pour Databricks, ce qui simplifie la connexion aux entrepôts d'entreprise sans gérer des identifiants à la main.

Source : github.com ↗

LE TIP R DU JOUR

Nommer les éléments d'un vecteur à la volée pour un code plus lisible

setNames() permet d'attribuer des noms à un vecteur ou une liste sans passer par une étape intermédiaire d'affectation à names(). Pratique pour construire des structures nommées en une seule expression, notamment dans un sapply ou un Map.

CODE R

resultats <- setNames(c(10, 20, 30), c("janvier", "fevrier", "mars"))
print(resultats)

# Utile aussi pour nommer le resultat d'une boucle fonctionnelle
fichiers <- c("a.csv", "b.csv", "c.csv")
lignes <- setNames(sapply(fichiers, function(f) nchar(f)), fichiers)
print(lignes)

SOURCES

VOUS CODEZ EN R ?

Nous formons vos équipes à R, Shiny et l'IA, et industrialisons vos apps et modèles.

Parlons-en →

← Tout R Underground