Une démonstration d'interrogation de base en langage naturel est toujours convaincante. On tape une question, un tableau apparaît, la salle hoche la tête. Le problème arrive trois semaines plus tard, quand un utilisateur pose la vraie question de son métier et obtient un chiffre faux sans s'en rendre compte.
Cet article ne parle pas de la démonstration. Il parle de ce qui tient en production et de ce qui lâche, à partir de ce qu'on observe sur des bases d'entreprise réelles.
Les questions qui marchent presque toujours
Certaines familles de questions passent bien dès la première mise en service, à condition que les vues soient correctement définies.
- Le filtrage simple. « Quels clients du secteur industrie ont commandé en juillet ? » Une condition, une période, une liste. C'est le cas le plus robuste.
- L'agrégation sur une dimension. « Combien de commandes par région ce trimestre ? » Le calcul est fait par la base, pas par le modèle, donc le total est juste par construction.
- La comparaison de deux périodes. « Ce mois-ci par rapport au même mois l'an dernier. » Le piège classique, les mois incomplets, se règle une fois pour toutes dans la définition de la vue.
- La recherche d'absence. « Quels clients n'ont rien commandé depuis six mois ? » Très utile en commerce, et rarement disponible dans les tableaux de bord existants.
- Le contrôle de cohérence. « Y a-t-il des factures sans commande rattachée ? » C'est souvent l'usage que les équipes découvrent après coup, et celui qui remonte le plus d'anomalies.
Ce qui casse, et pourquoi
Le vocabulaire ambigu
Le mot « client » désigne rarement la même chose dans deux services. Pour le commerce, c'est une entreprise avec qui on a une opportunité ouverte. Pour la comptabilité, c'est une entité facturée. Pour le support, c'est un contact qui ouvre des tickets.
Si les trois notions cohabitent dans la base sous des tables différentes, une question sur « le nombre de clients » n'a pas de réponse unique. Le modèle en choisira une, plausiblement, et personne ne verra qu'il a pris la mauvaise.
La correction n'est pas technique. Elle consiste à nommer les vues sans ambiguïté : clients facturés, comptes commerciaux, contacts support. Chacune répond à une question différente, et l'utilisateur voit laquelle il interroge.
Les règles métier non écrites
Toute base de production porte des règles que personne n'a documentées. Une commande annulée reste dans la table avec un statut particulier. Les lignes de test créées en 2019 n'ont jamais été purgées. Un montant négatif signifie un avoir. Une entité juridique fermée en 2022 apparaît encore.
Ces règles sont dans la tête de deux ou trois personnes. Tant qu'elles n'ont pas été inscrites dans les vues, chaque total sera légèrement faux, et légèrement faux est pire que franchement faux : on ne le détecte pas.
Les jointures profondes
Une question qui suppose de traverser cinq tables pour relier une facture à un chantier, puis à un client, puis à un commercial, puis à une région, est fragile. Le modèle peut construire la chaîne, mais le risque d'erreur grimpe à chaque saut, et le résultat est difficile à vérifier.
La bonne réponse consiste à préparer la jointure en amont dans une vue, plutôt qu'à espérer que le modèle la reconstitue à chaque fois. Le travail est fait une fois, il est relu par quelqu'un qui connaît le métier, et il devient fiable.
Les questions qui n'en sont pas
« Pourquoi les ventes ont-elles baissé ? » n'est pas une question à poser à une base. Elle appelle une interprétation, pas un calcul. Le modèle produira une explication cohérente à partir des chiffres qu'il aura vus, ce qui ressemble à une analyse mais n'en est pas une.
La formulation utile est « qu'est-ce qui a baissé, sur quel périmètre, et depuis quand ». L'interprétation reste humaine, et c'est très bien ainsi.
Ce qui fait la différence entre les deux catégories
Le facteur déterminant n'est ni la taille de la base, ni la qualité du modèle. C'est le travail de définition des vues, fait en amont avec quelqu'un qui connaît le métier.
Une base de dix millions de lignes correctement exposée en huit vues claires donne des résultats plus fiables qu'une base de cent mille lignes ouverte en intégralité. C'est contre-intuitif quand on aborde le sujet par la technique, et c'est pourtant ce qu'on constate sur chaque mission.
Ce travail suppose de s'asseoir avec les utilisateurs, de partir de leurs questions réelles et de remonter vers les tables, pas l'inverse. Partir du schéma pour aller vers les usages produit des vues techniquement correctes que personne n'utilise.
Trois précautions à prendre dès le départ
Exiger la provenance. Une réponse doit indiquer sur quelles vues elle a été construite. Sans cela, l'utilisateur n'a aucun moyen de vérifier, et il finira soit par tout croire, soit par ne plus rien croire.
Plafonner la volumétrie. Une question mal cadrée sur une grosse base peut lancer une requête coûteuse. Le plafond protège la production autant que le budget.
Confronter les premiers résultats aux chiffres connus. Pendant les deux premières semaines, chaque réponse doit être recoupée avec une source déjà validée : un état comptable, un tableau de bord existant. C'est ce qui révèle les règles métier oubliées, et c'est irremplaçable.
Quand ce n'est pas la bonne réponse
Si vos équipes consultent les mêmes cinq indicateurs chaque semaine, un tableau de bord classique reste plus simple, plus rapide et moins cher. Interroger en langage naturel prend son sens quand les questions ne sont pas connues d'avance, et quand leur variété rend impossible de toutes les prévoir.
De même, si la réponse cherchée se trouve dans des documents plutôt que dans des tables, le sujet relève du RAG et non du MCP, et l'article dédié explique comment trancher.
En résumé
L'interrogation d'une base en langage naturel fonctionne bien, à condition d'accepter que l'essentiel du travail se situe avant la technique : nommer sans ambiguïté, inscrire les règles métier dans les vues, préparer les jointures, et vérifier les premiers résultats contre des chiffres connus.
C'est exactement ce que couvre la phase de cadrage décrite sur la page serveur MCP et interrogation des données en langage naturel, et la raison pour laquelle nous livrons d'abord un périmètre restreint entre les mains d'utilisateurs réels plutôt qu'une démonstration complète.
