NL-to-SQL métier : gouverner les indicateurs et les requêtes autorisées

Le responsable commercial demande à l’assistant le montant des commandes de septembre après remboursements. La requête SQL s’exécute, le tableau affiche un total et l’explication paraît cohérente. Pourtant, le montant est faux : une jointure a répété les commandes et certains remboursements. Le problème du NL-to-SQL n’est pas seulement de produire une syntaxe valide ; une erreur de grain peut transformer une réponse fluide en mauvaise décision.

La méthode sépare définition de l’indicateur, construction de la requête et autorisation d’exécution. Une couche métier précise ce qui est compté, à quelle date et dans quel périmètre. Le service choisit ensuite une requête admissible et impose les droits indépendamment de la formulation du modèle. Le résultat conserve les hypothèses nécessaires pour être vérifié.

Nous construisons un petit exemple fictif de commandes, lignes et remboursements. Les calculs et deux refus d’accès ont été exécutés localement sur PostgreSQL 18.6 avec des données synthétiques. Cela vérifie les montants calculés, sans mesurer la qualité d’un modèle ni démontrer la sécurité d’un système complet. Le livrable est un dictionnaire d’indicateurs accompagné d’un catalogue de questions et d’une matrice de recette.

Pour cadrer une IA sur mesure reliée aux besoins métier, retenez d’abord un indicateur dont votre équipe peut expliquer le montant sans assistant. L’interrogation des données avec un agent IA SQL ajoute ensuite la compréhension de la question, la clarification et l’exécution dans le périmètre du lecteur. Notre montant ajusté sert à distinguer ces étapes : comprendre « septembre » ne suffit pas à calculer les bons remboursements.

Pour qui ouvrir des questions métier en langage naturel

Partir d’une décision et d’une population identifiées

Le sujet concerne les responsables data, produit, SI et les équipes qui posent des questions ponctuelles sur une base existante. La première mission décrit une famille de demandes, les utilisateurs et la décision attendue. « Interroger toutes nos données » ne définit ni la portée ni les conditions de réponse. Une mission limitée peut porter sur le suivi des commandes confirmées d’un établissement.

La question doit compléter le reporting existant. Si un tableau certifié répond déjà au besoin récurrent, l’assistant peut expliquer sa définition ou orienter vers ce tableau. Recalculer librement le même indicateur crée une deuxième vérité. Le propriétaire métier décide quels calculs sont officiels et lesquels restent des explorations explicitement nommées.

Prévoir une clarification avant un calcul plausible

Une demande telle que « nos ventes du mois » peut viser commandes, factures ou encaissements. L’assistant ne choisit pas silencieusement la table la plus familière. Il reformule le sens proposé et demande une précision lorsque plusieurs définitions ouvertes restent possibles. Une question courte et utile vaut mieux qu’un chiffre immédiat dont personne ne partage le sens.

La clarification d’une question NL-to-SQL ambiguë détaille ce choix avant la requête : formule, événement temporel, devise et confirmation. Des ventes fictives montrent des résultats différents et permettent de préparer la recette du dialogue sans confondre compréhension de la demande et exactitude du SQL.

La réponse peut aussi être un refus ou une orientation : indicateur non défini, période non disponible, détail interdit ou calcul déjà maintenu ailleurs. Ces issues font partie de la mission. Le taux de réponses chiffrées ne doit pas encourager à inventer une définition pour toutes les demandes, surtout lorsqu’une décision opérationnelle dépend du résultat.

Décrire le grain avant de proposer des jointures

Nommer ce que représente chaque ligne

Notre schéma possède une table orders avec une ligne par commande, son établissement, sa date, son statut et son montant HT en euros. lines contient une ligne par ligne de commande. refunds contient une ligne par remboursement accepté, lié à une commande et daté séparément. Une commande peut avoir plusieurs lignes et plusieurs remboursements.

Ces relations un-à-plusieurs ne sont pas de simples détails de schéma. Elles déterminent si une somme ou un comptage est licite après une jointure. Le dictionnaire expose clés, cardinalités et niveau d’agrégation. Il indique aussi que le montant de commande est déjà totalisé ; il ne peut pas être additionné une fois pour chaque ligne du panier.

• orders.id : identité unique de commande ; montant déjà totalisé.
• lines.order_id : plusieurs lignes peuvent appartenir à la même commande.
• refunds.order_id : plusieurs acceptations peuvent ajuster cette commande.

Faire circuler un contrat de données restreint

Le modèle reçoit les objets nécessaires à la mission : noms des vues admissibles, colonnes utiles, unités, relations permises et exemples validés. Il n’a pas besoin de tous les schémas techniques, commentaires historiques et champs confidentiels. Une description exhaustive mais contradictoire peut pousser à utiliser une ancienne colonne de montant qui n’a plus le même sens.

La couche métier peut préparer une vue avec une ligne par commande et des remboursements déjà agrégés. Cette simplification réduit les choix dangereux et sert également aux requêtes écrites sans IA. Elle possède une version, un responsable et un test. Une modification de statut ou de cardinalité doit pouvoir invalider les exemples qui dépendent du contrat précédent.

Écrire un dictionnaire qui tranche les ambiguïtés

Définir période, événements et population ensemble

Dans le contrat de démonstration, septembre désigne la date de commande entre le 1er septembre inclus et le 1er octobre exclu, dans le fuseau Europe/Paris. Seules les commandes confirmées de l’établissement A sont retenues. Les remboursements acceptés avant le 11 octobre à minuit dans ce même fuseau sont déduits, même si leur acceptation est postérieure à septembre.

Ce choix décrit une cohorte de commandes de septembre ajustée à une date d’observation. Il ne représente ni les remboursements survenus uniquement en septembre, ni un chiffre d’affaires comptable, ni un encaissement. Le nom doit porter cette différence. Les données synthétiques sont toutes en euros et hors taxes ; aucun taux de change ou régime fiscal n’est déduit du schéma.

Distinguer zéro, absence et donnée inconnue

Le comportement des agrégats sur une population vide doit être décidé dans le contrat. La documentation PostgreSQL des agrégats précise notamment que sum renvoie NULL sans ligne, alors que count renvoie zéro. Transformer NULL en zéro est un choix de restitution, pas la preuve qu’une source manquante contient zéro activité.

Une moyenne sans commande reste non applicable. Un montant inconnu ne doit pas disparaître de la population parce que l’agrégat ignore une valeur NULL. Les règles de complétude disent quand calculer, signaler une couverture partielle ou suspendre l’indicateur. Ce contrat évite que la présentation transforme un défaut de collecte en résultat commercial rassurant.

Exemple exécuté : une jointure valide double le montant

Observer la multiplication avant l’agrégation

Exemple concret : la commande 1 vaut 100 € et possède deux lignes ainsi que deux remboursements de 10 € et 15 €. La commande 2 vaut 200 €, avec une ligne et aucun remboursement. Joindre directement ces deux tables enfants produit quatre occurrences de la commande 1 et une de la commande 2. Le total brut devient 600 € ; les remboursements sont comptés deux fois, soit 50 €. Ce calcul ne doit pas être retenu pour le pilotage.

La soustraction renvoie donc 550 €, au lieu de 275 €. Cette requête a effectivement été exécutée sur le jeu fictif ; PostgreSQL ne signale aucune erreur de syntaxe. Le risque est de croire qu’un DISTINCT sur le montant corrige toute duplication. Si deux commandes distinctes valent chacune 100 €, elles doivent alors contribuer pour 200 € ; éliminer une valeur égale fausserait ce résultat. Il faut corriger la cardinalité avant la somme.

Ramener les remboursements au grain de la commande

Le calcul de référence agrège d’abord les remboursements par commande, puis les joint à une ligne par commande. Les lignes du panier ne sont pas nécessaires à cet indicateur. Les filtres de cohorte portent sur la date de commande ; la coupure des remboursements porte sur leur date d’acceptation. La requête ci-dessous est un exemple de calcul, pas une politique complète d’accès.

WITH refunds_by_order AS (
  SELECT order_id, SUM(amount_ht) AS refunded_ht
  FROM refunds
  WHERE accepted_at < '2026-10-11 00:00:00+02'
  GROUP BY order_id
)
SELECT COUNT(*) AS orders,
       SUM(o.amount_ht) AS gross_ht,
       SUM(o.amount_ht - COALESCE(r.refunded_ht, 0)) AS adjusted_ht
FROM orders o
LEFT JOIN refunds_by_order r ON r.order_id = o.id
WHERE o.tenant = 'A' AND o.status = 'confirmed'
  AND o.ordered_at >= '2026-09-01 00:00:00+02'
  AND o.ordered_at < '2026-10-01 00:00:00+02';

Résultat vérifié : 2 commandes, 300 € bruts et 275 € ajustés. En production, le service injecte les bornes comme paramètres typés à partir du calendrier autorisé. Le filtre A de cet exemple facilite la lecture du calcul ; il ne remplace pas les permissions imposées par l’exécuteur. Une colonne correctement filtrée par le modèle ne doit pas être considérée comme une frontière de sécurité.

Construire un catalogue de questions autorisées

Associer chaque question à un contrat de calcul

Le catalogue peut ouvrir le nombre de commandes, leur montant brut, le montant ajusté et une comparaison de périodes définies. Chaque famille possède indicateur, dimensions, calendrier, périmètre, paramètres et résultat de référence. Une demande reconnue sélectionne ce contrat. Le modèle aide à comprendre la formulation ; il ne redéfinit pas le calcul à chaque conversation.

Commencer par des requêtes préparées avec paramètres contrôlés est souvent adapté à quelques familles stables. Une génération SQL plus libre peut être introduite pour des explorations bornées, avec un coût de validation supérieur. Les deux modes sont distingués dans le produit et dans la recette ; une liberté plus grande ne doit pas hériter automatiquement de la preuve acquise par un modèle de requête fixe.

Conserver les demandes qui doivent rester fermées

Le catalogue indique aussi les exclusions : données d’un autre établissement, détails personnels, écritures, rapprochements sans clé validée, ou indicateurs dont la définition n’est pas décidée. « Toutes les commandes » reste limité au périmètre de l’utilisateur. Une demande de moyenne par client peut nécessiter un traitement particulier si elle permet d’isoler une personne ou un compte confidentiel.

Une nouvelle question hors catalogue est enregistrée pour étude, avec son besoin et son propriétaire. Elle ne devient pas admissible simplement parce qu’une requête a réussi sur une base de test. L’ouverture attend définition, droits, références et restitution. Cela permet d’étendre le service à partir des usages réels tout en conservant des critères d’acceptation identifiables.

Faire porter les droits par le système d’exécution

Donner une identité limitée à chaque périmètre

La passerelle choisit l’identité et le périmètre depuis la session authentifiée. Elle ne reprend pas un établissement demandé librement dans la demande. Le compte d’exécution possède les privilèges nécessaires aux objets ouverts. Le modèle ne reçoit ni secret de connexion ni capacité d’accorder des droits. Les accès directs et chemins indirects, y compris les fonctions disponibles, sont examinés.

Dans le test local, un rôle non propriétaire a reçu une lecture limitée de la table des commandes et une politique de lignes imposant A. Il voit cinq commandes A, dont celles hors période, et zéro commande B. Une table confidentielle et une écriture ont été refusées. Ces tests vérifient ce montage minimal ; ils n’évaluent pas une passerelle, un pool de connexions ou des fonctions applicatives.

Vérifier les vues et les rôles réellement utilisés

Les politiques de sécurité par ligne de PostgreSQL doivent être testées avec le rôle d’exécution réel. Les superutilisateurs et rôles BYPASSRLS les contournent ; les propriétaires de tables les contournent normalement aussi. Démontrer un filtre dans une session administrateur ne vérifie donc pas le comportement de l’assistant.

Une vue ne protège pas automatiquement un périmètre. La documentation CREATE VIEW distingue notamment les droits du propriétaire et le mode security_invoker. Ce mode vérifie les relations sous-jacentes avec les droits de l’appelant ; il ne constitue pas une solution universelle à lui seul. Vues, politiques, fonctions et droits associés sont revus ensemble, avec des tests de refus.

Valider une requête avant de lui donner une connexion

Contrôler les objets et opérations plutôt qu’un préfixe

Un contrôle « commence par SELECT » laisse trop de liberté. L’analyse de la requête vérifie sa structure, les objets et colonnes référencés, les fonctions, les sous-requêtes et le nombre d’instructions. Les paramètres ne peuvent pas devenir des identifiants arbitraires. Les noms de tables et dimensions proviennent d’une liste serveur ; les valeurs passent par des paramètres typés.

Le contrôle sémantique vérifie ensuite les relations et agrégations admises. Une requête peut être autorisée techniquement mais interdite pour un indicateur certifié si elle change de grain. Une réparation proposée après erreur repasse tous les contrôles. Le modèle ne gagne pas davantage de droits ou une durée illimitée pour trouver une formulation qui s’exécute.

Limiter le coût même lorsque la sortie est petite

Le banc des garde-fous SQL avant exécution sépare refus syntaxiques et protections PostgreSQL. Quatorze propositions et sept sondes vérifient vue bornée, rôle lecteur, annulation par délai et export ; elles montrent pourquoi lecture seule et LIMIT ne suffisent pas à décrire toute la capacité autorisée.

Un résultat de dix lignes peut nécessiter un scan considérable. Les budgets portent sur délai, ressources, nombre de tentatives et volume de sortie ; un LIMIT seul ne règle pas le coût d’une agrégation. L’exécuteur peut examiner un plan sans exécution avant une requête plus libre. Les contrôles de ressources restent nécessaires même lorsque les objets sont autorisés.

La supervision distingue latence de compréhension, validation et exécution SQL. Le plafond de durée et le budget de tentatives sont décidés selon la charge admissible et appliqués par le serveur. L’entrée du contrat conserve question et paramètres ; sa sortie conserve résultat, refus ou erreur. La journalisation relie ces états à une trace sans exposer les secrets. Après dépassement, le repli oriente vers le reporting disponible plutôt que de relancer sans limite.

Une transaction PostgreSQL READ ONLY bloque notamment les mutations des tables non temporaires, sans représenter une interdiction de toute écriture disque. Elle ne limite pas les données lisibles et ne remplace ni les privilèges ni le contrôle des fonctions. Pour plusieurs calculs liés, le choix d’isolation détermine également la cohérence des lectures ; il doit être décidé avant de comparer les résultats.

Présenter le résultat avec sa définition et ses limites

Garder le contrat de réponse près du chiffre

La réponse affiche indicateur, unité, population, période, fuseau, date d’observation et couverture des sources. Exemple concret : « 275 € HT de montant commandé ajusté, commandes confirmées A de septembre, remboursements acceptés avant le 11 octobre ». Une phrase « ventes de septembre : 275 € » ferait disparaître précisément les choix qui permettent d’interpréter le résultat. La validation métier doit donc refuser cette restitution raccourcie pour une décision exigeant la définition complète.

Le SQL, ses paramètres et la version du dictionnaire restent consultables par les personnes habilitées. La restitution conserve aussi refus, erreur, résultat vide et réponse partielle comme états distincts. Un timeout ne produit pas zéro. Une sortie tronquée ne devient pas une liste exhaustive. Le produit indique ce qui a été réellement calculé plutôt que seulement ce qui a été demandé.

Expliquer une variation sans inventer sa cause

Une baisse par canal peut décrire la contribution observée de chaque segment au total. Elle ne prouve pas que le canal a causé la baisse. L’assistant sépare les décompositions calculées des hypothèses métier. Une campagne marketing, un retard de collecte ou un changement de catalogue demandent d’autres preuves avant d’être présentés comme explication causale.

Le journal conserve les références utiles au contrôle : question, indicateur choisi, paramètres, version, identité de périmètre, issue d’exécution et validation. Il ne doit pas créer une copie incontrôlée de données sensibles. Les exports et partages possèdent leurs propres droits ; pouvoir consulter un agrégat ne donne pas automatiquement le droit d’exporter toutes les lignes sources.

Matrice de recette : huit questions qui changent le verdict

La recette des résultats SQL valides mais faux approfondit le contrôle des contributions : montants égaux, commandes perdues et erreurs qui se compensent. Sept variantes exécutées et quatre mutations du jeu fictif montrent pourquoi un total proche, un nombre d’objets correct ou une préagrégation ne suffisent pas à établir la justesse du résultat.

Comparer un résultat et un comportement attendus

Le jeu de recette possède résultats indépendants du modèle et issues attendues. Les exemples exécutés établissent ici une référence de calcul et des refus de base. Les autres cas ci-dessous décrivent les essais à construire pour un assistant complet ; ils n’ont pas été exécutés sur un modèle. La recette vérifie autant la clarification et le refus que l’agrégation finale.

Ajouter des invariants qui résistent à la reformulation

Deux formulations synonymes doivent sélectionner la même définition et le même périmètre. Ajouter une deuxième ligne à une commande sans changer son montant ne doit pas changer le montant commandé. Ajouter une commande B ne doit pas modifier le résultat A. Ces invariants détectent des erreurs que des exemples heureux isolés peuvent manquer.

Les limites temporelles méritent des cas dédiés : une commande exactement au début de période est incluse, celle au début de la période suivante est exclue. Le calendrier traite les changements de décalage horaire pour d’autres mois. Les critères sont recalculés après modification de vue, d’indicateur ou de validation, au-delà du seul changement de modèle.

Erreurs fréquentes des assistants NL-to-SQL

Confondre résultat plausible et définition partagée

Les erreurs typiques sont la somme après une jointure multiplicative, le comptage de lignes à la place des commandes et le mélange des dates de commande, facture et remboursement. La moyenne des moyennes peut également changer la pondération attendue. Une requête rapide et un graphique propre ne corrigent pas ces différences de définition.

Autre piège : laisser la conversation modifier implicitement le sens d’un indicateur. « Et sans les retours ? » doit désigner un contrat défini ou demander une précision. L’assistant ne transforme pas un montant commandé en montant facturé sans l’annoncer. La conversation garde les paramètres retenus et permet à l’utilisateur de les corriger explicitement.

Confondre limitation de requête et protection des données

Lecture seule, contrôle de syntaxe et nombre maximal de lignes traitent des risques différents. Aucun ne remplace le périmètre de données. Un agrégat peut encore divulguer une information interdite, notamment à travers des groupes très petits ou plusieurs demandes rapprochées. Les règles de restitution doivent être examinées avec les usages et les personnes habilitées.

Tester exclusivement avec un administrateur, oublier les droits d’une vue ou réutiliser une connexion avec un rôle précédent sont des défauts d’intégration. Le contexte d’exécution doit être contrôlé à chaque demande et nettoyé entre usages. L’ouverture attend des preuves sur ce chemin réel ; un prompt demandant au modèle de respecter A ne suffit pas.

Plan d’action : du premier indicateur au périmètre ouvert

Construire la référence avant la conversation

Commencez par une question dont le propriétaire peut valider le résultat sans IA. Écrivez grain, événements, statuts, période, fuseau, unité et règles d’absence. Préparez un petit jeu synthétique qui contient au moins les cardinalités et frontières de ce calcul. Faites vérifier le SQL de référence, puis conservez ses résultats et sa version comme base de recette.

Définissez ensuite les vues et colonnes utiles ainsi que les questions ouvertes. Une équipe métier valide le vocabulaire ; une équipe data valide le calcul ; l’intégration valide l’identité et les droits. Si une règle reste indécise, le catalogue exclut la question ou prévoit une clarification. Cette décision doit être compréhensible dans le produit, sans demander à l’utilisateur de lire le schéma SQL.

Ouvrir après contrôle du chemin d’exécution complet

Ajoutez compréhension de demande, sélection du contrat, validation, exécution bornée et restitution. Testez avec le rôle réellement utilisé, y compris les accès étrangers, les objets fermés, les erreurs et les réparations. Vérifiez que chaque sortie expose la définition choisie et que les résultats de référence restent reproductibles après une évolution du dictionnaire.

Attribuez la responsabilité de chaque entrée du catalogue à un propriétaire métier et celle de l’exécution à l’équipe SI. Le contrat fixe la sortie attendue et les raisons de refus ; la journalisation permet de retrouver la version utilisée. Le repli nomme le rapport disponible et son responsable. Une question reste fermée si ces éléments ne peuvent pas être rapprochés, même lorsque la démonstration paraît convaincante.

Le premier lancement peut rester limité à quelques utilisateurs et indicateurs. Observez questions clarifiées, refus, corrections et charge de validation avant d’étendre. Une demande hors catalogue devient une opportunité de définition, pas une permission immédiate. L’extension ajoute ses propres tests et peut exiger une autre stratégie de requêtes, d’agrégats ou de confidentialité.

Guides complémentaires pour les preuves et le lancement

Mesurer le comportement de l’assistant sur des cas conservés

Le protocole d’évaluation d’un POC IA métier distingue référence, résultat observé, cas difficiles et décision. Il complète le calcul SQL : des résultats de référence corrects ne disent pas encore si l’assistant sélectionne la bonne définition, clarifie les ambiguïtés et restitue les limites à chaque demande.

La recette sépare alors erreurs de compréhension, erreurs de construction, refus d’exécution et défauts de restitution. Cette distinction rend les corrections utiles. Changer de modèle pour une permission mal configurée ne traite pas le problème ; améliorer une vue ne suffit pas à faire expliquer un choix de période que le produit garde invisible.

Garder les conditions de retrait de l’indicateur

Le dossier de lancement IA avec critères d’arrêt relie les preuves à la version exposée, aux responsables et au repli. Pour le NL-to-SQL, le retrait d’un indicateur ou d’une source doit pouvoir fermer les questions concernées et orienter vers le reporting disponible.

Une source devenue incomplète ne doit pas continuer à alimenter une réponse certifiée au seul motif que la connexion fonctionne. La reprise attend le rapprochement des données et la validation du contrat concerné. Les requêtes déjà exportées gardent leur date d’observation ; les nouvelles ne doivent pas reprendre silencieusement les anciennes garanties.

Conclusion : autoriser une réponse, pas seulement une requête

Un assistant NL-to-SQL utile associe une définition métier, un calcul vérifiable et un périmètre imposé par l’exécution. La syntaxe valide est une condition technique. Le grain, les événements, les dates et les unités décident de la justesse ; les droits décident de ce qui peut être consulté.

L’exemple synthétique montre comment une jointure admissible au moteur produit 550 € au lieu de 275 €. Une référence indépendante, un dictionnaire explicite et des cas de refus permettent de détecter ce défaut et de bloquer sa restitution comme indicateur certifié. Ils ne remplacent pas les essais du modèle ni les contrôles de la passerelle réelle, qui doivent être évalués séparément.

L’agent IA SQL relié à une couche métier rend ces contrats utilisables dans une conversation : questions ouvertes, clarifications, requêtes contrôlées et résultats avec leurs limites. L’extension garde les mêmes exigences de preuve que le premier indicateur.

Dans ce projet d’IA sur mesure intégrée à vos données et à vos opérations, Dawap accompagne le propriétaire du reporting sur une question, son calcul de référence et les rôles qui peuvent le consulter. Le premier livrable comprend la définition, la requête et les cas qui doivent modifier ou refuser la réponse. Le pilote pourra alors mesurer si la conversation réduit le travail de recherche sans déplacer sur l’utilisateur la vérification du chiffre.