Discuter avec une base de données
Le projet
Interrogez en langage naturel une base de données de relevés météo journaliers de villes françaises. Un agent ReAct construit avec LangChain et LangGraph écrit la requête SQL, l'exécute sur DuckDB, corrige lui-même ses erreurs quand le moteur en signale une, puis répond en français. Le modèle est Grok (xAI). La météo n'est ici qu'un support de démonstration : le même principe s'applique à n'importe quelle base métier.
Les questions de suivi fonctionnent : l'agent garde le fil de la conversation, « Et pour Lyon ? » suffit après une première question sur Toulouse.
La valeur
Accéder à une base de données suppose habituellement de savoir écrire du SQL, ce qui réserve l'exploration des données à un petit nombre de profils techniques. Ici, la question se pose en français : l'utilisateur métier interroge directement la donnée, sans intermédiaire ni formation préalable, et reçoit une réponse rédigée plutôt qu'un tableau brut à interpréter.
Le recours à un agent, plutôt qu'à un enchaînement figé de traitements, change la nature de l'échange : l'agent décide lui-même s'il doit interroger la base, réessaie quand sa requête échoue et suit le contexte d'une question à l'autre. L'utilisateur dialogue avec la donnée au lieu de lancer des requêtes isolées.
La donnée, elle, ne quitte jamais son environnement : seul le schéma de la table est transmis au modèle, jamais le contenu de la base.
La stack technique
Le cœur du projet est un agent ReAct construit avec LangChain et LangGraph. Le graphe boucle entre deux nœuds : le modèle, qui décide à chaque tour s'il doit appeler un outil ou répondre, et l'exécution de cet outil, ici un unique outil de requête SQL en lecture seule. La boucle est bornée par une limite de récursion, au-delà de laquelle LangGraph l'interrompt proprement.
Il n'y a volontairement pas de nœud de réparation : quand une requête échoue, l'outil renvoie le message d'erreur du moteur sous forme de texte, le modèle le lit et se corrige au tour suivant. La capacité d'auto-correction vient de l'agent lui-même, pas d'une mécanique ajoutée autour.
Le schéma de la table (colonnes, types et quelques lignes d'exemple) est injecté directement dans le prompt système plutôt que découvert par un outil dédié. Sur un schéma petit et stable, cela évite un aller-retour supplémentaire avec le modèle à chaque question et rend le prompt système cachable côté fournisseur. Le passage à un schéma multi-tables serait l'extension naturelle du dispositif : il faudrait alors réintroduire des outils de découverte et retirer le schéma du prompt.
La mémoire de conversation repose sur le réducteur add_messages de LangGraph, couplé à un checkpointer et à un identifiant de fil par session : c'est ce qui rend possibles les questions de suivi. Un nœud d'élagage retire en fin de tour les appels d'outils et leurs résultats, si bien que le fil ne conserve que les questions et les réponses, le SQL généré n'y persiste jamais et ne peut pas ressortir dans une réponse ultérieure.
Le modèle est Grok (xAI), appelé via son API compatible OpenAI. Les requêtes s'exécutent localement sur DuckDB, qui charge le jeu de données en table mémoire puis coupe l'accès au système de fichiers ; une garde de préfixe (SELECT / WITH) limite l'agent à la lecture seule. L'interface est développée avec Gradio.
L'observabilité passe par LangSmith, activé uniquement lorsqu'une clé est fournie : chaque nœud du graphe, appel au modèle et appel d'outil devient une trace, avec tokens, latence et coût associés.
