OUTILS IA — CHOISIR, MESURER, CONTRÔLER · INTERROGER SES DONNÉES EN LANGAGE NATUREL
Sources vérifiées au 19 juillet 2026, sur documentation officielle d'éditeur et publications de recherche.
« Quel a été notre chiffre d'affaires net sur le trimestre ? » La question prend cinq secondes à écrire, et l'interface répond un nombre. Ce nombre a la bonne magnitude, le bon format, le bon séparateur de milliers. Il est présenté sans réserve. Rien, dans la réponse, n'indique que la requête sous-jacente a additionné des lignes annulées, ignoré les remises, ou pris une devise pour une autre.
Nous avons déjà traité le cas du tableur interrogé en langage naturel : là, le périmètre est visible, les colonnes tiennent à l'écran, et l'enjeu est la commodité. Ici, il s'agit de la base de production ou de l'entrepôt de l'entreprise — des centaines de tables, des conventions de nommage sédimentées sur dix ans, et un utilisateur qui n'a aucun moyen de recompter. L'enjeu n'est plus la commodité : c'est la justesse.
Un chiffre faux ne ressemble pas à une erreur
C'est la particularité de ce type d'outil, et elle le distingue de presque tous les autres. Un assistant de rédaction qui se trompe produit une phrase bancale que l'on repère. Un générateur de code qui se trompe produit une erreur d'exécution. Un système texte vers requête qui se trompe produit un nombre parfaitement formé. Il n'y a pas de signal d'anomalie, parce qu'il n'y a pas d'anomalie : la requête était syntaxiquement valide, elle s'est exécutée, elle a renvoyé un résultat. C'est la définition même du chiffre plausible et faux, dont nous avons décrit le mécanisme général dans pourquoi l'IA hallucine.
La tentation est alors de se rassurer avec des scores. Le banc d'essai public de référence pour cette tâche, BIRD, publie un classement d'exactitude à l'exécution : le meilleur score enregistré sur son jeu de test s'établit à 81,95 %, obtenu en conditions de laboratoire et avec connaissance oracle, contre 92,96 % pour la performance humaine mesurée par les auteurs sur le jeu de développement. Ces mêmes auteurs énumèrent d'ailleurs les raisons pour lesquelles leur chiffre ne se transpose pas à une base d'entreprise : valeurs sales dans les données réelles, connaissances externes au schéma indispensables, et exigence d'efficacité de la requête et pas seulement de justesse.
Mais le fait le plus utile n'est pas ce score. C'est sa contestation. Un article de recherche référencé VLDB 2026, « Pervasive Annotation Errors Break Text-to-SQL Benchmarks and Leaderboards », a réannoté deux bancs d'essai de référence et y mesure 52,8 % d'erreurs d'annotation sur BIRD Mini-Dev et 62,8 % sur Spider 2.0-Snow. Après correction d'un sous-ensemble, les performances des systèmes évalués varient de −7 % à +31 % en relatif, les rangs bougent de neuf positions dans les deux sens, et la corrélation entre le classement avant et après correction chute de r=0,85 à r=0,32. Autrement dit : les classements sur lesquels une équipe s'appuierait pour choisir ne sont pas stables. Le jeu de données corrigé est public, et la vérification est reproductible.
Conclusion opérationnelle : ne choisissez pas sur un score, et n'attendez pas d'un score qu'il vous dise quoi que ce soit sur votre base. La seule mesure qui compte est celle que vous construisez sur vos propres questions — c'est exactement la démarche décrite dans évaluer les sorties d'une IA avec des evals.
Le schéma ne suffit pas : pourquoi il faut une couche sémantique
Voici la thèse de cet article, et elle n'a rien d'une opinion : la couche sémantique compte davantage que le modèle. Quatre acteurs qui ne s'accordent sur presque rien d'autre — deux plateformes de données concurrentes, un outil de transformation, une brique open source — décrivent le même remède, dans leurs propres termes.
Le problème qu'ils décrivent est trivial à énoncer et coûteux à ignorer. Un schéma de base de données contient des noms de colonnes, pas des définitions métier. Snowflake donne l'exemple canonique dans sa documentation : ce que l'entreprise appelle gross_revenue peut être stocké sous amt_ttl_pre_dsc. Aucun modèle, aussi capable soit-il, ne peut deviner cette correspondance à partir du seul schéma. Il devinera quelque chose, et ce quelque chose aura la forme d'un nombre.
La couche sémantique s'interpose entre la question et le schéma : elle ne stocke pas de données, elle stocke les définitions qui rendent la traduction déterminable. Sans elle, le modèle infère la correspondance entre un terme métier et une colonne technique ; avec elle, la correspondance est déclarée en amont par ceux qui la connaissent.
Snowflake a formalisé cet objet sous le nom de vue sémantique : un objet de base de données de niveau schéma qui stocke les concepts métier et permet de définir indicateurs, dimensions et relations entre entités. Sa documentation en fait le chemin recommandé pour son assistant d'interrogation, les anciens fichiers de description déposés sur un emplacement de stockage restant supportés à titre d'héritage.
dbt défend la même idée depuis l'angle de la modélisation : en centralisant les définitions d'indicateurs, les équipes garantissent un accès cohérent en libre-service dans tous les outils en aval ; et sortir ces définitions de la couche de restitution pour les remonter dans la couche de modélisation permet, selon sa documentation, que différentes unités opérationnelles travaillent sur les mêmes définitions quel que soit leur outil de prédilection.
Databricks commercialise une brique dédiée, présentée comme une couche sémantique unifiée pour sa plateforme, centralisant les définitions métier. Wren AI, la principale brique open source vivante du domaine, est architecturée autour d'une couche de contexte ouverte fournissant sémantique métier, définitions approuvées, exemples, mémoire et gouvernance.
Quatre formulations, un seul diagnostic. Ce constat a une conséquence budgétaire directe : l'essentiel du travail à fournir n'est pas un travail d'intégration d'outil, c'est un travail de définition, et il incombe aux personnes qui connaissent le métier, pas à celles qui connaissent la base.
Droits de lecture, périmètre, coût des requêtes : trois garde-fous
C'est le point le plus mal traité dans les discussions sur ces outils, et le plus lourd de conséquences. La question paraît simple : sous quelle identité la requête générée s'exécute-t-elle ? Elle n'a pas de réponse unique, et surtout, elle n'a pas toujours de réponse fournie par la plateforme.
Chez Databricks, le modèle est hybride et mérite d'être compris précisément. Sa documentation indique que lorsqu'une sélection d'entrepôt est enregistrée, les identifiants de calcul de l'auteur sont incorporés à l'agent et utilisés pour traiter toutes les requêtes, pour tous les utilisateurs. Mais l'accès aux données, lui, reste évalué par utilisateur : chacun ne voit que ce qu'il a le droit de voir, et un utilisateur dépourvu du privilège de lecture sur une table obtient une réponse vide plutôt que le contenu de la table. Les utilisateurs finaux doivent disposer au minimum du privilège de lecture sur tous les objets de catalogue employés par l'agent. L'identité qui calcule et l'identité qui donne droit aux données sont donc deux choses distinctes.
Chez Snowflake, la documentation de son assistant d'interrogation affirme une intégration complète avec le contrôle d'accès par rôles, de sorte que les requêtes générées et exécutées respectent les contrôles d'accès établis. Mais une lecture attentive de la documentation de son interface applicative impose une nuance décisive : l'interface renvoie la requête, elle ne l'exécute pas. La réponse contient un champ portant l'instruction SQL. C'est l'application appelante qui décide de l'exécuter — et donc sous quelle identité. Une intégration qui exécuterait cette instruction sous un compte de service unique contournerait entièrement le contrôle d'accès dont la plateforme se prévaut, sans que la plateforme y soit pour rien.
La chaîne d'identité d'une requête générée. Trois maillons peuvent porter trois identités différentes : celle qui interroge, celle qui calcule, celle sous laquelle la lecture est autorisée. La rupture la plus fréquente se situe au dernier maillon, dans l'application d'intégration — donc hors du périmètre de garantie de la plateforme.
Deuxième garde-fou, le périmètre. Ouvrir un accès en langage naturel, c'est ouvrir une surface d'interrogation, pas une liste de rapports. Un utilisateur autorisé sur une table de commandes pourra formuler des questions que personne n'avait anticipées — croisements, agrégats, recoupements. La restriction utile ne se fait pas sur les questions, elle se fait sur les objets exposés à l'agent, et elle doit être décidée avant l'ouverture, pas après le premier incident.
Troisième garde-fou, le coût, et il se compte deux fois. La documentation de Snowflake est explicite sur ce point : la consommation de crédits de son assistant est fondée sur le nombre de messages traités, et des coûts d'entrepôt supplémentaires s'appliquent lors de l'exécution de la requête générée. Deux lignes de facturation distinctes, dont la seconde n'est pas plafonnée par la première : une question mal cadrée sur une table volumineuse coûte le prix d'un message plus le prix du balayage. Chez Databricks, aucune grille tarifaire propre n'est publiée sur la page produit ; la consommation relève de l'entrepôt sous-jacent.
Définir ses indicateurs avant d'ouvrir l'accès
La couche sémantique dit ce que les colonnes signifient. Elle ne dit pas encore ce qu'une bonne réponse ressemble. C'est le rôle d'un second dispositif, que les deux plateformes documentent sous des noms différents et selon la même logique.
Snowflake décrit un dépôt de requêtes vérifiées : un ensemble de questions pré-approuvées et de la requête correspondante, stocké dans le modèle sémantique, avec deux champs qui font toute la différence — l'identité du valideur et la date de validation. L'éditeur assortit ce mécanisme d'un avertissement qui mérite d'être lu à l'envers : des requêtes invalides ou inexactes peuvent dégrader la performance et la justesse du système. Un dépôt de requêtes vérifiées mal tenu ne rend pas le système neutre, il le rend confiant dans l'erreur.
Databricks documente un dispositif équivalent sous le nom d'actifs de confiance : fonctions et exemples de requêtes prédéfinis, destinés à fournir des réponses vérifiées aux questions anticipées. Un détail compte beaucoup plus qu'il n'y paraît : lorsqu'un actif de confiance est mobilisé, la réponse le signale explicitement à l'utilisateur. C'est le seul mécanisme du dossier qui informe le destinataire final du régime de confiance dans lequel il se trouve.
Panorama : brique open source contre fonction intégrée à la plateforme
Une remarque de cadrage s'impose avant le tableau : deux des trois options historiques ne sont pas des outils, ce sont des fonctions intégrées à une plateforme de données propriétaire. On ne les adopte pas, on les active parce que l'entrepôt est déjà là. Cela déplace la question : ce n'est pas un choix d'outil, c'est une conséquence d'un choix de plateforme fait antérieurement, souvent par d'autres, et pour d'autres raisons.
| Option | Nature | Statut relevé | Licence / facturation | À vérifier vous-même |
|---|---|---|---|---|
| Wren AI | Brique open source auto-hébergeable, architecturée autour d'une couche de contexte | Vivant — dépôt non archivé, dernière poussée de code le 2026-07-17, version wren-v0.13.0 du 2026-07-13 |
Dépôt multi-licencié : cœur, kit de développement et exemples sous Apache-2.0, documentation sous CC BY 4.0, et le fichier annonce des modules à venir sous AGPL-3.0, dont le texte est déjà déposé. La forge classe le dépôt en NOASSERTION |
Ouvrir le fichier LICENSE à la racine et lire sa première phrase |
| Vanna | Brique open source historique + offre hébergée du même éditeur | Dépôt archivé le 2026-03-29, en lecture seule. Dernière version v2.0.2 du 2026-02-02, confirmée par l'index de paquets. Aucun dépôt successeur maintenu dans l'organisation. L'offre commerciale, elle, continue | MIT — texte standard vérifié par lecture intégrale, sans clause de marque ni limite d'utilisateurs. Tarifs de l'offre hébergée non relevés | Comparer l'en-tête du dépôt et la page d'accueil commerciale |
| Cortex Analyst (Snowflake) |
Fonction intégrée à une plateforme de données propriétaire | Vivant, documenté comme entièrement infogéré. Chemin recommandé : les vues sémantiques | Propriétaire. Facturation au nombre de messages traités, plus les coûts d'entrepôt à l'exécution de la requête — deux lignes distinctes | Vérifier dans votre intégration qui exécute l'instruction renvoyée |
| Genie Agents (Databricks) |
Fonction intégrée à une plateforme de données propriétaire | Vivant, renommé — note de version du 2026-07-09 actant « Genie Agents, anciennement Genie Spaces », et avant cela AI/BI Genie. Disponibilité à dater par composant : Genie One au 2026-01-20, interface de conversation au 2026-03-12, mode agent au 2026-07-02 | Propriétaire. Aucune grille tarifaire propre publiée sur la page produit ; consommation de l'entrepôt sous-jacent | Relever la date de la note de version qui documente le nom actuel |
Le cas de Vanna mérite d'être lu pour ce qu'il est, sans jugement sur l'éditeur. Ce n'est pas « un projet mort » — c'est un cœur ouvert qui s'arrête pendant que l'offre payante avance. Le dépôt est passé en lecture seule le 29 mars 2026 ; le site commercial, lui, continue de présenter son composant central comme open source, sans signaler l'archivage. Aucune déclaration publique n'explique le motif de cet archivage, et il serait malhonnête d'en inventer un. Le fait suffit : une équipe qui bâtirait aujourd'hui son accès aux données sur cette brique reprendrait, de facto, la maintenance d'un code figé — correctifs de sécurité compris.
Le cas de Wren AI livre l'enseignement complémentaire, et il vaut bien au-delà de cet outil. Un résumé de licence aurait affiché « Apache-2.0 » et vous aurait induit en erreur : le fichier réel commence par annoncer que le dépôt est multi-licencié selon le chemin, et prévient qu'il pourra accueillir des modules sous licence copyleft réseau. Lisez le fichier de licence, jamais son résumé. Cette règle coûte trente secondes et évite des mois de reprise.
Montrer la requête générée : nécessaire, jamais suffisant
Toutes ces solutions exposent la requête produite, sous une forme ou une autre. L'interface applicative de Snowflake la renvoie dans un champ dédié. Wren AI la rend rejouable en ligne de commande et propose une validation de plan à blanc avant exécution. Databricks permet de la relire. Cette exposition est indispensable : sans elle, aucun audit n'est possible, aucune reprise, aucun débogage.
Mais elle est régulièrement présentée comme le garde-fou, et c'est là que le raisonnement casse. Le destinataire d'un accès en langage naturel est, par construction, une personne qui ne sait pas écrire de requête — c'est précisément la raison pour laquelle on lui ouvre cet accès. Lui afficher trente lignes de SQL comportant trois jointures, une sous-requête et un filtre de date ne lui donne aucun moyen de juger si le résultat est juste. Cela lui donne l'impression d'avoir eu accès à la preuve.
Montrer la requête à qui ne sait pas la lire n'est pas un garde-fou : c'est un déplacement de la charge de vérification vers la personne la moins armée pour l'assumer. Et ce déplacement a un effet secondaire redoutable : il fabrique de la confiance, puisque le système paraît transparent. Un chiffre affiché avec sa requête inspire plus confiance qu'un chiffre affiché seul, indépendamment de sa justesse.
Le vrai garde-fou est en amont, et il est documenté par les éditeurs eux-mêmes. C'est la requête vérifiée, validée par une personne identifiée à une date connue. C'est l'actif de confiance, signalé comme tel dans la réponse — de sorte que l'utilisateur sache s'il lit une réponse pré-approuvée ou une réponse improvisée. C'est la définition d'indicateur arbitrée par le métier plutôt qu'inférée par un modèle. La transparence, elle, sert le relecteur compétent qui viendra auditer après coup. Elle ne remplace pas ce dispositif : elle le complète.
Comment le vérifier vous-même
Cet article ne repose sur aucun essai. Le protocole ci-dessous, lui, est exécutable en une demi-journée, et chaque étape produit un constat que vous pourrez opposer à n'importe quelle démonstration commerciale.
Il reste une décision à prendre, et elle est plus politique que technique. Ouvrir l'interrogation d'une base métier en langage naturel, ce n'est pas déployer un outil : c'est publier un contrat implicite selon lequel les chiffres obtenus font foi. Ce contrat n'est tenable que si quelqu'un, quelque part, a écrit les définitions, validé les requêtes de référence, et arbitré ce qui se trouve dans le périmètre. Si ce travail n'a pas été fait, l'outil ne le fera pas — il en produira seulement l'apparence, avec une mise en forme irréprochable.
Une question, un projet IA ?
Vous envisagez d'ouvrir l'accès à vos données métier en langage naturel, et vous vous demandez ce qu'il faut poser avant — définitions, droits, périmètre, coût ? Échangeons sur votre contexte.
Prendre contact →