Accueil › Glossaire › Database Access LLM

Database Access LLM

Un database access LLM est un grand modèle de langage capable de se connecter à une base de données, de traduire des questions en langage naturel en requêtes SQL (ou NoSQL), d’exécuter ces requêtes, et de restituer les résultats dans une réponse structurée et compréhensible.

C’est la promesse qui fascine chaque organisation : permettre à n’importe quel collaborateur de poser une question en français à ses données d’entreprise (« quels sont les clients à Paris qui ont commandé plus de 10 000€ ce trimestre ? ») et d’obtenir une réponse fiable sans écrire une ligne de SQL. Le database access LLM rend cela possible en combinant la compréhension du langage naturel avec l’exécution de requêtes structurées.

C’est un cas spécifique de tool-augmented LLM où l’outil est un connecteur de base de données. La technique sous-jacente, le text-to-SQL, existe depuis 1973 (le système LUNAR de la NASA), mais les LLM l’ont transformée d’une curiosité académique en capacité de production.

Comment fonctionne le text-to-SQL

Le processus de traduction d’une question en langage naturel vers une requête SQL suit un pipeline en plusieurs étapes.

Le pipeline text-to-SQL

1. Compréhension de la question : le LLM parse la question utilisateur pour en extraire l’intention (filtrer, agréger, compter, trier…), les entités mentionnées (clients, ventes, produits…) et les conditions (dates, seuils, localisations…).

2. Schema linking : le LLM fait correspondre les termes de la question avec les éléments du schéma de la base de données. « Clients » correspond à la table customers, « ce trimestre » se traduit en filtre WHERE order_date >= '2026-01-01'. C’est l’étape la plus critique : une erreur de mapping produit une requête techniquement valide mais qui interroge les mauvaises données.

3. Génération SQL : le LLM produit la requête SQL complète, incluant les JOINs entre tables, les agrégations, les filtres et le tri. La qualité dépend directement de la compréhension du schéma et de la complexité de la question.

4. Validation : la requête est vérifiée syntaxiquement et, idéalement, testée pour s’assurer qu’elle ne contient pas d’opérations destructives (pas de DELETE, UPDATE, DROP).

5. Exécution : la requête validée est exécutée sur la base de données réelle.

6. Synthèse : les résultats bruts (tableau de données) sont renvoyés au LLM qui les reformule en réponse en langage naturel, souvent accompagnée de la requête SQL pour transparence.

Le défi du schéma

Pour générer du SQL correct, le LLM a besoin de connaître le schéma de la base : noms des tables, noms des colonnes, types de données, clés étrangères, contraintes. Ce schéma est fourni dans le prompt (ou via un outil de découverte du schéma).

Pour une base simple avec 5 tables et 20 colonnes, c’est trivial. Pour une base d’entreprise avec des centaines de tables, le schéma complet peut dépasser la fenêtre de contexte du LLM. Les solutions incluent :

Le routage par domaine : diviser la base en domaines fonctionnels (ventes, RH, logistique). Le LLM identifie d’abord le domaine pertinent, puis ne charge que le schéma correspondant. C’est l’approche recommandée par AWS et Cisco pour les déploiements entreprise.

La sélection dynamique de tables : un premier appel LLM identifie les tables pertinentes à partir des noms et descriptions, puis un second appel génère le SQL avec uniquement les schémas des tables sélectionnées.

Les métadonnées enrichies : ajouter des descriptions en langage naturel aux tables et colonnes (par exemple, mrr = « Monthly Recurring Revenue en euros ») améliore considérablement la précision du schema linking.

Les quatre types d’erreurs courantes

Une étude de benchmark sur 24 LLM (BIRD-SQL, 500 questions de difficulté modérée) identifie quatre catégories d’erreurs récurrentes en text-to-SQL :

L’hallucination de noms de colonnes est particulièrement problématique : le LLM invente un nom de colonne plausible qui n’existe pas dans la base. La validation du SQL contre le schéma réel avant exécution est indispensable.

Accès aux bases de données via MCP

Le Model Context Protocol a transformé l’accès aux bases de données pour les LLM. Au lieu de construire un pipeline text-to-SQL custom pour chaque projet, vous installez un serveur MCP database et votre LLM peut interroger la base immédiatement.

Serveurs MCP disponibles

L’écosystème MCP propose de nombreux serveurs de bases de données :

Ces serveurs MCP s’intègrent avec Claude Desktop, Claude Code, Cursor, Gemini CLI, VS Code et tout client MCP compatible. La configuration se résume à un fichier JSON avec les informations de connexion à la base.

Sécurité des serveurs MCP database

La sécurité est le point critique. Un LLM avec un accès écriture à votre base de production peut causer des dégâts irréversibles. Les bonnes pratiques :

Lecture seule par défaut : tous les serveurs MCP sérieux exécutent les requêtes en mode lecture seule (transactions READ ONLY). Seules les requêtes SELECT sont autorisées.

Utilisateur dédié avec permissions minimales : créez un utilisateur PostgreSQL/MySQL avec uniquement les permissions SELECT sur les tables nécessaires. Jamais l’utilisateur root ou admin.

Réplica en lecture : en production, connectez le serveur MCP à un réplica en lecture de la base, pas à l’instance principale. Aucun risque d’impact sur les performances de production.

Timeout strict : limitez le temps d’exécution des requêtes (10 secondes est un bon défaut) pour éviter qu’une requête mal formée ne bloque la base.

Frameworks pour construire un pipeline text-to-SQL

Si vous avez besoin de plus de contrôle qu’un serveur MCP prêt à l’emploi, plusieurs frameworks facilitent la construction d’un pipeline text-to-SQL custom :

LangChain fournit une abstraction SQLDatabase (wrapper autour de SQLAlchemy) et create_sql_query_chain pour générer du SQL à partir de n’importe quel LLM. Il supporte différents dialectes SQL et peut être combiné avec un agent qui itère sur les erreurs.

LlamaIndex propose NLSQLRetriever et NLSQLQueryEngine qui récupèrent le schéma des tables, une vue structurelle et des lignes échantillons pour améliorer la qualité du SQL généré.

Instructor (par Jason Liu) excelle dans l’extraction de paramètres structurés à partir du langage naturel via des modèles Pydantic, ce qui peut alimenter un pipeline de génération SQL avec validation des types.

SQLCoder (Defog) est une famille de LLM open source spécialement fine-tunés pour le text-to-SQL, qui surpassent GPT-4 sur le benchmark sql-eval de Defog. Ils se déploient localement via Ollama.

Table-Augmented Generation (TAG)

Le TAG est une évolution du RAG appliquée aux données structurées. Au lieu de vectoriser des documents texte, le TAG connecte le LLM directement aux tables de la base de données. Le LLM génère une requête SQL, récupère les données pertinentes, et les utilise comme contexte pour produire sa réponse.

L’avantage du TAG sur le RAG classique pour les données tabulaires : pas besoin de pré-indexer les données dans une base vectorielle, les résultats sont exacts (pas d’approximation par similarité), et les agrégations (sommes, moyennes, comptages) sont calculées par le moteur SQL, pas estimées par le LLM.

Cas d’usage concrets

Business Intelligence conversationnelle

« Quel est notre chiffre d’affaires par région ce trimestre comparé au trimestre précédent ? » Au lieu d’ouvrir un outil de BI, naviguer dans les dashboards, et construire un filtre, l’utilisateur pose sa question en français et obtient un tableau ou un graphique en réponse.

Support client augmenté

Un chatbot de support connecté à la base clients peut répondre à « où en est ma commande #12345 ? » en interrogeant directement la table des commandes, sans escalade vers un agent humain. Le LLM génère la requête, récupère le statut, et formule une réponse personnalisée.

Analyse de données ad hoc

Les data analysts utilisent le text-to-SQL pour les requêtes exploratoires : « montre-moi les 10 produits avec le taux de retour le plus élevé le mois dernier ». Le LLM génère le SQL, l’exécute, et peut enchaîner avec des analyses complémentaires (« y a-t-il une corrélation avec le fournisseur ? »).

Développement et debugging

Les développeurs utilisent les serveurs MCP database dans Claude Code et Cursor pour explorer le schéma, comprendre les relations entre tables, optimiser les requêtes, et diagnostiquer les problèmes de performance. Postgres MCP Pro va plus loin en proposant des outils de tuning d’index et d’analyse de plans d’exécution.

Limites et précautions

Précision imparfaite

Aucun LLM ne génère du SQL parfait à 100%. Sur le benchmark BIRD-SQL (requêtes de difficulté modérée), même les meilleurs modèles font des erreurs sur 20 à 40% des questions. Les requêtes multi-tables avec des JOINs complexes, des sous-requêtes imbriquées et des agrégations conditionnelles restent un défi. Pour les décisions critiques, vérifiez toujours la requête SQL générée.

Sécurité des données

Un LLM avec accès à une base d’entreprise pourrait être manipulé (via prompt injection) pour extraire des données sensibles (PII, données financières). Les garde-fous incluent : le masquage dynamique des données sensibles, l’utilisation d’un utilisateur avec permissions minimales, la restriction des tables accessibles, et le monitoring des requêtes exécutées.

Ambiguïté du langage naturel

« Quels sont les meilleurs clients ? » Meilleurs par chiffre d’affaires ? Par ancienneté ? Par fréquence d’achat ? Le langage naturel est intrinsèquement ambigu, et les bases de données sont intrinsèquement précises. Le LLM doit faire un choix (ou demander une clarification), et ce choix peut être erroné. Fournir des exemples de requêtes dans le prompt et des descriptions de colonnes riches réduit considérablement cette ambiguïté.

Schémas complexes

Les bases d’entreprise avec des structures embarquées (JSON dans des colonnes, XML, colonnes multi-valeurs), des conventions de nommage cryptiques (tbl_cust_ord_dtl), et des centaines de tables interconnectées dépassent la capacité de la plupart des LLM sans optimisation. La décomposition en domaines et l’enrichissement des métadonnées sont indispensables.

Bonnes pratiques pour la production

Enrichissez les métadonnées du schéma. Ajoutez des descriptions en langage naturel à chaque table et chaque colonne. « revenue_mtd » sans contexte est ambigu ; « revenue_mtd : chiffre d’affaires month-to-date en euros HT » est sans équivoque.

Fournissez des exemples de requêtes. Les approches few-shot (quelques exemples de questions → SQL dans le prompt) améliorent significativement la précision par rapport au zero-shot.

Validez avant d’exécuter. Vérifiez que la requête SQL ne contient que des SELECT, que les tables et colonnes référencées existent dans le schéma, et que la requête ne risque pas de scanner des millions de lignes sans filtre.

Utilisez un agent itératif. Si la requête échoue ou produit un résultat vide, laissez le LLM corriger et réessayer. Un framework agentique (LangChain agent) avec 2 à 3 tentatives maximales résout une bonne partie des erreurs de première génération.

Connectez-vous à un réplica en lecture. Jamais à la base de production en écriture. C’est la règle la plus simple et la plus importante.