Par Elisha Bajemon, Ingénieur IA chez TW3 Partners. Dernière mise à jour : 20 octobre 2026.

En bref

Pour interroger une base en langage naturel, un agent reçoit la question en français et appelle des outils SQL via un serveur MCP sur des tables documentées. La fiche TW3 Partners « Questions en langage naturel sur l’entrepôt de données », sans date, décrit un entrepôt de plus de 600 tables réparties en 70 schémas. Le modèle appelle les outils de façon autonome sur un sous-ensemble documenté. La fiche indique « Évaluation (non faite) » : aucun taux de bonnes réponses ne peut être attribué à cette réalisation. Sélectionner le périmètre avant de choisir le modèle constitue ici une recommandation de conception, dont l’effet reste à mesurer. La spécification MCP du 18 juin 2025 recommande de conserver une intervention humaine permettant de refuser un appel d’outil.

1. Peut-on interroger un entrepôt de données en langage naturel ?

Oui : un agent peut recevoir une question en français et interroger l’entrepôt par les outils SQL mis à sa disposition. C’est le fonctionnement décrit par la fiche TW3 Partners, sans date. Le problème de départ était concret : chaque question métier demandait une requête écrite par un spécialiste.

Le text to SQL désigne la conversion d’une demande en langage naturel en requête SQL. Dans sa note de transparence sur Copilot dans SQL Server Management Studio, mise à jour le 19 mai 2025, Microsoft définit ainsi le passage du texte conversationnel à une requête T-SQL. Cette définition situe le vocabulaire employé pour ces projets ; le produit décrit par Microsoft est distinct de la réalisation TW3.

Pour préparer un projet de ce type, nous recommandons de partir des demandes que les équipes adressent déjà aux spécialistes de la donnée. Le métier doit préciser ce qu’il entend mesurer, tandis que le responsable de l’entrepôt identifie les données correspondantes. Ce travail fournit un périmètre initial et les réponses de référence qui serviront à l’évaluation.

2. Qu’est-ce qu’un serveur MCP, et que fait-il ici ?

Un serveur MCP expose des outils qu’une application d’IA peut appeler pour interagir avec un système externe. La documentation Model Context Protocol, version affichée du 28 juillet 2026, définit MCP comme un « open-source standard for connecting AI applications to external systems », soit un standard ouvert pour relier des applications d’IA à des systèmes externes.

La page « Tools » de la spécification du 18 juin 2025 précise que ces outils peuvent interroger des bases de données. Chaque outil possède un nom et une description de ses paramètres attendus. Le modèle dispose ainsi d’une description des fonctions qu’il peut appeler.

Dans la réalisation TW3, sans date, ces fonctions sont des outils SQL exposés sur l’entrepôt. Pour cadrer l’architecture, nous recommandons de distinguer la question formulée par l’utilisateur, le choix des appels par l’agent et l’exécution par les outils. Cette décomposition donne à la DSI des éléments à examiner séparément : le sens de la demande, les paramètres envoyés et les droits appliqués lors de l’exécution.

3. Pourquoi sélectionner et documenter un sous-ensemble de tables avant tout ?

Le périmètre documenté détermine les données sur lesquelles on prévoit de faire travailler l’agent. La fiche TW3 Partners, sans date, place la sélection des tables utiles au début de la réalisation et décrit un sous-ensemble documenté. L’entrepôt complet compte plus de 600 tables réparties en 70 schémas.

Notre recommandation consiste à retenir d’abord les questions métier à traiter, puis à documenter les tables nécessaires pour y répondre. Pour chaque table retenue, nous proposons de préciser le sens des colonnes, les relations utilisables avec les autres tables et les règles de calcul attendues. Les conventions de date et les valeurs manquantes méritent aussi une décision explicite du responsable métier.

Cette documentation devrait être relue conjointement par un spécialiste de l’entrepôt et par une personne responsable des indicateurs. Nous conseillons de conserver les désaccords sur les définitions comme des points à résoudre avant d’inclure les questions concernées dans le périmètre ouvert aux équipes.

Ce séquencement est un choix de conception proposé par le cabinet. Pour en mesurer l’effet, nous recommandons de reprendre les mêmes questions après une modification de la documentation, en conservant le modèle et les données de référence. L’équipe pourra alors examiner les changements de réponse sans les confondre avec un changement de modèle.

4. Comment le modèle choisit-il les outils SQL à appeler ?

Le modèle choisit les outils à appeler à partir de la question et du contexte dont il dispose. La spécification MCP du 18 juin 2025 qualifie ces outils de « model-controlled », c’est-à-dire pilotés par le modèle : il peut les découvrir et les invoquer automatiquement.

La fiche TW3 Partners, sans date, confirme l’appel autonome des outils et indique l’utilisation de Gemini 3 Flash via Vertex AI et LiteLLM. Ces éléments décrivent la configuration de cette réalisation.

Pour suivre le fonctionnement d’un agent SQL, nous recommandons de conserver la question initiale avec les appels effectués et le résultat utilisé pour rédiger la réponse. Cette trace doit permettre au spécialiste de vérifier si l’agent a interrogé le périmètre attendu et si la réponse correspond au résultat obtenu. Nous conseillons également de prévoir une demande de précision lorsque le sens métier de la question reste ambigu, avec des critères définis lors de la préparation du banc d’essai.

5. Quels garde-fous prévoir autour des outils SQL ?

Nous recommandons de prévoir des contrôles d’accès et un moyen pour l’utilisateur de comprendre et de refuser les appels. La spécification MCP du 18 juin 2025 recommande « the ability to deny tool invocations », soit la possibilité de refuser l’appel d’un outil. Elle recommande également d’afficher les outils exposés au modèle, de signaler leurs appels et de présenter des demandes de confirmation.

La même page exige côté serveur la validation des entrées, des contrôles d’accès adaptés et une limitation de la fréquence des appels. Côté application cliente, elle recommande notamment la confirmation des opérations sensibles, des délais maximaux d’exécution et la journalisation des usages pour l’audit.

Pour un premier périmètre de consultation, TW3 recommande de traduire ces principes en décisions vérifiables par la DSI :

Décision à prendreContrôle recommandé avant ouverture
Droits du compte SQLVérifier que le compte ne peut que lire les données autorisées
Tables accessiblesVérifier les autorisations effectives sur le périmètre retenu
Intervention humaineTester le refus d’un appel et son effet sur la suite de la conversation
JournalisationRetrouver la question, l’appel exécuté et son issue dans les traces autorisées

Les droits SQL et la présence d’une validation humaine restent à préciser pour la réalisation décrite. Le tableau exprime nos recommandations de contrôle. Nous conseillons de faire constater leur application par la DSI avant l’accès des premiers utilisateurs, puis de reprendre ces contrôles lors d’une extension du périmètre.

6. Comment évaluer un tel agent avant de l’ouvrir aux équipes ?

Nous recommandons de confronter les réponses de l’agent à des résultats de référence validés par les métiers. Pour cette réalisation, la fiche TW3 Partners, sans date, classe explicitement cette étape en « Évaluation (non faite) ».

D’autres réalisations du cabinet donnent des appuis de méthode. La fiche du garde-fou d’entrée, sans date, décrit un banc de 500 messages annotés à la main. Celle de la passerelle multi-modèles, sans date, décrit des bancs de mesure utilisant des critères vérifiables par programme. Nous proposons d’en reprendre les principes pour un agent SQL, avec un jeu propre aux données et aux questions concernées.

Le responsable métier devrait valider, pour chaque question retenue, le résultat attendu et les règles de calcul. Le spécialiste de l’entrepôt devrait préparer la requête de référence correspondante. Nous recommandons de figer les données utilisées pendant la comparaison pour pouvoir expliquer les écarts.

La relecture porterait ensuite sur la sélection des tables, les filtres appliqués et la fidélité de la réponse au résultat SQL. Nous conseillons d’inclure des demandes ambiguës et des demandes hors périmètre, en précisant à l’avance la clarification ou le refus attendu. Une requête qui s’exécute devrait donc faire l’objet d’une vérification de son résultat métier.

Enfin, nous recommandons de conserver ce jeu pour les modifications suivantes : évolution de la documentation, des outils ou du modèle. La décision d’élargir le service devrait s’appuyer sur les erreurs observées et les critères d’acceptation convenus avec les métiers.

7. Que reçoivent les équipes métier ?

La réalisation comprend une API de chatbot et une interface web. La fiche TW3 Partners, sans date, indique un hébergement sur Azure Container Apps et un entrepôt Azure SQL. Le parcours décrit permet aux équipes de poser leurs questions en français, l’agent interrogeant lui-même l’entrepôt par les outils SQL.

Pour préparer l’ouverture de cette interface, nous recommandons de remettre aux utilisateurs une description du périmètre accessible et une procédure de signalement des réponses à examiner. Le responsable métier pourrait qualifier ces retours avec le spécialiste de la donnée, puis ajouter les questions retenues au jeu d’évaluation. L’équipe disposerait ainsi d’une manière explicite de décider quelles corrections vérifier avant d’étendre l’usage.

Un sujet voisin figure dans l’article « Piloter un portefeuille de programmes de R&D avec une vue unique interrogeable en langage naturel ».

FAQ

L’agent voit-il toutes les données de l’entrepôt ?
La fiche TW3 Partners, sans date, décrit un travail sur un sous-ensemble de tables documenté. Pour ouvrir un service comparable, nous recommandons à la DSI de vérifier les droits effectifs sur ce périmètre.

Les réponses ont-elles été évaluées ?
Non : la fiche TW3 Partners, sans date, indique « Évaluation (non faite) ». Le banc proposé dans cet article constitue une recommandation pour cette étape.

MCP est-il propre à un fournisseur de modèles ?
MCP se présente comme un standard ouvert dans sa documentation, version du 28 juillet 2026. Cette documentation décrit des connexions entre des applications d’IA et des systèmes externes.

Quel modèle est utilisé ?
La fiche TW3 Partners, sans date, indique Gemini 3 Flash via Vertex AI et LiteLLM. Pour retenir une configuration sur un autre périmètre, nous recommandons une évaluation sur les questions des équipes concernées.

L’agent peut-il modifier les données ?
Cela dépend des droits accordés aux outils SQL, un point à trancher par la DSI pour cette réalisation. Pour un usage de consultation, notre recommandation est de vérifier une configuration en lecture seule, en application des contrôles d’accès exigés par la spécification MCP du 18 juin 2025.

Faut-il documenter les tables soi-même ?
La réalisation TW3, sans date, commence par sélectionner les tables utiles et s’appuie sur un sous-ensemble documenté. Nous recommandons d’organiser la rédaction et la validation de cette documentation avec les responsables métier et les spécialistes de l’entrepôt.

Pour aller plus loin

Sources