Question NL‑to‑SQL ambiguë : préciser marge, période et devise avant la requête

« Quelle est notre marge de septembre ? » L’assistant trouve une table de ventes, écrit un SQL valide et affiche un pourcentage. Le risque commence avant cette requête : personne n’a choisi entre date de commande et date de facture, montant et ratio, euros et devises d’origine. La friction apparaît lorsque deux équipes comparent des chiffres incompatibles et passent leur réunion à reconstituer les hypothèses.

En pratique, une question ambiguë doit sélectionner une définition autorisée avant de produire un calcul. Une conversation utile présente les choix qui changent la décision, conserve ce qui a été confirmé et demande seulement les précisions encore nécessaires. Le modèle peut interpréter la formulation ; il ne possède pas l’autorité pour inventer le sens officiel d’un indicateur.

Un exemple fictif de quatre ventes permet de vérifier ces différences. Les calculs ont été exécutés localement sur PostgreSQL 18.6, avec un taux de conversion de démonstration. Le dialogue et son contrat sont des propositions de conception, sans assistant IA exécuté ni résultat client revendiqué. La contribution définie ici est un indicateur interne simplifié, pas un bénéfice comptable.

Pour intégrer cette IA sur mesure à votre reporting, commencez par une question que le responsable de l’indicateur sait calculer sans assistance. Sur « quelle marge en septembre ? », il doit préciser l’événement qui rattache une vente au mois, le dénominateur du ratio et le traitement des devises. Le parcours d’un agent IA SQL fait choisir ces éléments avant de proposer une requête ; il garde une attente explicite quand la définition reste indécidable.

Pour qui une clarification vaut mieux qu’un chiffre immédiat

Identifier le désaccord qui rend la réponse inutilisable

Responsables commerciaux, équipes data, produit et contrôle de gestion rencontrent des mots partagés dont les définitions diffèrent. « Ventes », « activité », « retard » ou « marge » peuvent désigner plusieurs populations et événements. Avant de choisir les synonymes du modèle, examinez les demandes qui produisent des corrections : quel filtre manque, quel dénominateur change et quelle décision doit attendre ?

La clarification est pertinente lorsque plusieurs définitions disponibles répondent réellement à la formulation. Si le besoin consiste simplement à ouvrir un rapport certifié connu, un raccourci vers ce rapport suffit parfois. Si aucun coût fiable n’existe, un dialogue plus fluide ne rend pas la marge calculable. Le produit doit distinguer un choix de sens d’une lacune des sources.

Faire valider les options avant de les présenter

Le propriétaire de l’indicateur définit les variantes ouvertes et leur usage. L’équipe data décrit les calculs correspondants. L’utilisateur choisit parmi ces contrats selon sa question, dans le périmètre auquel il est habilité. Une option « rentabilité complète » ne doit pas être proposée si seules ventes et coûts affectés sont disponibles ; elle promettrait une couverture absente du système.

Les valeurs par défaut peuvent réduire les échanges lorsque le contexte est établi. Elles restent visibles et corrigeables : établissement courant, calendrier commercial ou devise de restitution. Leur existence ne dispense pas de clarifier une formule concurrente. L’ordre de priorité entre contexte de page, profil et demande explicite doit être défini, afin que le même mot ne change pas de sens selon un état invisible.

Séparer montant, taux sur ventes et taux sur coûts

Nommer le dénominateur au lieu de deviner « marge »

Dans notre contrat fictif, la contribution HT vaut montant de vente HT moins coût affecté à la vente. Elle peut être restituée comme montant, comme ratio sur les ventes ou comme ratio sur les coûts. Le mot « marge » ne sélectionne pas seul l’une de ces trois sorties. Le libellé affiché nomme la formule, sans supposer que les conventions locales des équipes sont identiques.

Exemple concret : une vente de 1 000 € avec un coût de 600 € produit une contribution de 400 €. La contribution divisée par la vente donne 40 % ; divisée par le coût, elle donne environ 66,67 %. Les deux divisions sont arithmétiquement valides. Une clarification doit révéler le choix, plutôt que laisser une explication après coup rationaliser le premier résultat obtenu.

Définir le ratio du total et le coût retenu

Pour une population, notre ratio sur ventes divise la contribution totale par les ventes totales. Ce n’est pas la moyenne simple des ratios de chaque vente. Les petites et grandes ventes n’ont pas le même poids dans ces deux calculs. Une demande de « taux moyen » exige donc une définition supplémentaire si les deux options sont ouvertes.

Le coût affecté est déjà établi par le jeu fictif, dans la même devise que sa vente. Il ne comprend aucune charge générale ni composante supplémentaire implicite. Dans une entreprise, le responsable métier précise la source du coût, son état provisoire ou final et les éléments inclus. L’assistant ne complète pas les coûts manquants à partir d’une marge habituelle ou d’un prix de catalogue.

Choisir événement, calendrier et date d’observation

Associer le mois à une date métier explicite

Septembre peut désigner les ventes commandées pendant septembre ou les ventes facturées pendant septembre. Une commande d’août facturée en septembre appartient seulement à la seconde population. Une commande de septembre facturée en octobre appartient seulement à la première. La question de clarification nomme ces événements ; elle ne demande pas à l’utilisateur de choisir entre deux colonnes techniques.

Le calendrier de l’exemple est Europe/Paris, avec le 1er septembre inclus et le 1er octobre exclu. Une vente enregistrée le 31 août à 22 h 30 UTC a une date locale du 1er septembre à 0 h 30. La documentation PostgreSQL des dates et heures distingue les types avec et sans fuseau ; le contrat doit préciser comment les instants deviennent des bornes métier.

Résoudre les périodes relatives sans perdre leur référence

« Le mois dernier » dépend de la date de la demande et du calendrier choisi. Le produit transforme cette expression en dates absolues affichées, puis les conserve avec le résultat. Une conversation reprise en novembre ne doit pas recalculer silencieusement octobre si son résultat précédent portait sur septembre. L’utilisateur peut demander une nouvelle période, avec une nouvelle confirmation du contrat.

La date d’observation indique aussi quand les données sont arrêtées. Notre jeu est figé au 10 octobre ; il ne contient aucun avoir ni coût révisé. En usage réel, l’événement de sélection et la disponibilité des données restent distincts. Une facture de septembre ajoutée après une première réponse peut changer le résultat, sans changer la définition. Le produit garde ces deux versions d’observation.

Décider la conversion avant de sommer les montants

Séparer devise d’origine et devise de restitution

Un montant de 1 000 EUR et un montant de 1 000 USD ne forment pas un total de 2 000 € sans conversion définie. L’utilisateur peut demander une sortie par devise d’origine ou un total dans une devise commune. « En euros » choisit la restitution ; cela ne signifie pas forcément « seulement les ventes dont la devise d’origine est EUR ».

FX-DEMO-1 fixe, pour notre seule vente USD, 1 USD = 0,90 EUR. Vente et coût sont convertis avec ce même taux fictif ; 1 000 USD deviennent 900 €, et 800 USD deviennent 720 €. Il ne s’agit pas d’un cours historique. En production, le propriétaire du calcul définit source des taux, date de référence, méthode et traitement des taux manquants.

Arrondir après le calcul défini

Le contrat précise si l’arrondi se fait par ligne, par document ou après agrégation. Ces méthodes peuvent diverger ; la conversation ne doit pas modifier la convention pour obtenir un affichage plus agréable. Notre exemple conserve les décimales des montants convertis puis arrondit seulement les pourcentages présentés à deux décimales.

PostgreSQL documente les nombres décimaux exacts de type numeric, avec les effets de précision et d’échelle. Le choix de ce type aide à reproduire les calculs ; il ne choisit ni la politique de change ni la formule commerciale. Ces décisions restent dans le contrat validé, avec la version du référentiel utilisée.

Quatre ventes fictives et des résultats différents

Conserver des frontières visibles dans le jeu de référence

Les quatre ventes sont confirmées, sans remise ni avoir, dans un unique établissement fictif A. Chaque ligne porte une vente et son coût affecté, avec une devise commune à ces deux montants. Les dates ci-dessous sont locales, en Europe/Paris. Le jeu ne comporte aucun client réel ; il sert à vérifier les conséquences des choix, pas la performance d’un agent.

Les factures de septembre retiennent S-01, S-02 et S-03. Après conversion, les ventes totalisent 2 400 €, les coûts 1 520 € et la contribution 880 €. Les commandes de septembre retiennent S-01, S-03 et S-04 : ventes 1 900 €, coûts 1 100 €, contribution 800 €. Les deux populations ont trois lignes ; leur taille identique ne prouve pas qu’elles représentent la même activité. La recette doit contrôler les identifiants retenus avant les totaux ; accepter trois lignes ne vérifie pas l’événement demandé.

Comparer les réponses que la même question pourrait recevoir

Paradoxalement, plusieurs réponses exactes peuvent donc être incompatibles avec la décision attendue. Ce n’est pas nécessairement une hallucination de calcul : le système a pu choisir le mauvais contrat. Une recette qui contrôle seulement la syntaxe ou la proximité d’un chiffre ne détecte pas cette substitution de sens.

Le test du calendrier ajoute une autre différence : sélectionner les commandes de septembre en UTC retire S-01, située en août UTC mais en septembre à Paris. Restent S-03 et S-04, pour 400 € de contribution. Ce contre-exemple a également été exécuté. Il illustre une frontière de période ; il ne justifie pas de convertir toutes les dates métier en UTC sans examiner leur signification.

Dialogue de clarification : des options à la confirmation

Poser une question qui modifie réellement la réponse

La demande initiale arrive dans l’établissement A avec un calendrier Paris déjà affiché : « Quelle est notre marge de septembre ? » Le produit connaît ce périmètre ; il ne le redemande pas. Il propose : « Souhaitez-vous le montant de contribution, le ratio sur les ventes ou le ratio sur les coûts ? » Chaque option décrit son dénominateur dans un libellé compréhensible.

L’utilisateur répond : « Le taux sur nos ventes facturées, en euros. » Cela sélectionne le ratio sur ventes et l’événement facture. Le produit garde une précision restante : « Toutes les devises converties en EUR selon le référentiel approuvé, ou uniquement les ventes d’origine EUR ? » Le mot « euros » ne doit pas éliminer silencieusement S-02.

Confirmer le contrat avant la remise au calcul

La réponse « toutes les devises converties » complète le choix. Le produit reformule : contribution HT divisée par ventes HT, factures de septembre 2026, établissement A, calendrier Paris, conversion FX-DEMO-1, données figées au 10 octobre. Dans cet exemple, la confirmation autorise la sélection du calcul de référence ; elle n’élargit aucun droit d’accès.

Le résultat attendu est 36,67 %, accompagné de 880 € de contribution pour 2 400 € de ventes et 1 520 € de coûts. Le dialogue est écrit à la main pour préparer la recette. Il faudra tester si l’assistant réel conserve chaque choix et ne pose pas une question déjà résolue. Aucune capacité de compréhension du modèle n’est déduite de cet échange illustratif.

Figer un contrat de réponse versionné

Séparer les choix interprétés des valeurs imposées

Le service assemble une définition et des paramètres autorisés. La session authentifiée impose l’établissement ; le catalogue fournit formule et objets de données ; le dialogue confirme période, événement et restitution. L’assistant ne peut pas faire passer un établissement demandé librement pour une habilitation. Une clarification réussie ne prouve pas non plus que la requête construite respecte ensuite ce contrat.

Le contrat ci-dessous est un objet de conception fictif, pas un format standard ni un appel d’API exécuté. Sa révision relie la confirmation à la définition choisie. Les identifiants nomment un catalogue interne à construire ; ils ne correspondent pas à des fonctionnalités PostgreSQL. Le résultat doit garder cette révision pour pouvoir être rapproché de la demande confirmée.

{
  "requestId": "Q-MARGE-01",
  "revision": 3,
  "state": "confirmed",
  "metricId": "contribution_ratio_on_sales",
  "metricVersion": "DEMO-1",
  "scopeFromSession": "A",
  "selectionEvent": "invoiced_at",
  "periodStartLocal": "2026-09-01T00:00:00",
  "periodEndExclusiveLocal": "2026-10-01T00:00:00",
  "calendarZone": "Europe/Paris",
  "originCurrencyFilter": null,
  "outputCurrency": "EUR",
  "conversionReference": "FX-DEMO-1",
  "dataSnapshot": "DEMO-2026-10-10",
  "confirmationForRevision": 3
}

Bloquer un contrat incomplet ou devenu différent

Un champ manquant peut laisser l’état à « clarification requise ». Un choix hors catalogue peut conduire à « définition indisponible ». Un retrait de droits produit un refus distinct. La passerelle reçoit seulement une révision confirmée et valide le catalogue, les paramètres et l’accès au moment de l’exécution. Ces contrôles appartiennent à l’application ; une phrase rassurante du modèle ne les remplace pas.

Si l’événement devient date de commande après confirmation, la révision change et le résultat précédent ne décrit plus la nouvelle demande. Le produit invalide la sélection en attente et demande une confirmation adaptée. Il conserve le résultat antérieur avec son ancien contrat, plutôt que de le réétiqueter. Les réponses tardives sont rapprochées de leur révision avant affichage.

Cas concret : Q-MARGE-01 révision 3 part au calcul, puis une nouvelle sélection crée la révision 4 avant son retour. L’entrée du validateur conserve identifiant, révision et paramètres ; sa sortie rattache le résultat à la révision 3 et interdit son affichage sous la 4. La responsabilité de ce contrôle revient au service applicatif. La trace distingue validation du contrat, permissions et issue d’exécution ; elle ne contient pas de secret de connexion.

Traiter une relance sans changer le sens en silence

Décrire ce que la nouvelle phrase modifie

Après le résultat confirmé, l’utilisateur demande : « Et sur les commandes ? » La proposition change seulement l’événement de sélection, si le contexte reste clair : septembre, ratio sur ventes, Paris, conversion EUR et établissement A sont conservés. Le produit présente cette différence puis confirme la nouvelle révision. Le résultat attendu devient 42,11 %, avec une contribution de 800 €.

Une relance « sans les dollars » demande une autre précision si plusieurs interprétations restent possibles : exclure les ventes d’origine USD, ou afficher seulement le détail EUR ? Le produit ne supprime pas la conversion et ne transforme pas les montants USD en euros par simple changement de symbole. La différence entre filtre de population et unité de sortie reste visible entre les tours.

Réduire la clarification lorsque le contexte est suffisant

« Même calcul, pour octobre » peut garder formule et événement si la révision de référence est identifiable et le catalogue toujours compatible. La reformulation affiche les nouvelles bornes avant calcul. Si plusieurs tableaux sont présents ou si le fil a été repris après un changement de catalogue, le produit demande à quel résultat la relance se rapporte.

La conversation conserve les choix structurés séparément de son historique libre. Une fenêtre de contexte plus longue ne suffit pas à protéger le sens : un résumé peut supprimer une exclusion ou une réponse tardive peut se rattacher au mauvais tour. Le journal permet de retrouver question, choix confirmés, révision et résultat associé, avec une conservation adaptée aux données traitées.

Le parcours de correction d’un copilote dans un écran métier complète cette gestion des versions. Une correction locale, une confirmation serveur et une réponse ancienne portent des états différents. Dans la conversation analytique, ces états déterminent quel contrat peut encore être confirmé et quel résultat reste visible dans son contexte d’origine.

Distinguer ambiguïté, absence de données et refus

Ne pas demander à l’utilisateur de réparer une source

Une ambiguïté laisse plusieurs définitions admissibles ; l’utilisateur peut la lever. Un coût absent est un défaut de données ; choisir une formule ne le remplit pas. Dans une variante indépendante, une cinquième facture de 200 € EUR est ajoutée sans coût. La somme des contributions connues reste 880 €, mais elle ne décrit plus les quatre factures de la population sélectionnée.

Ce défaut a été reproduit dans le test SQL : quatre factures, trois coûts connus, contribution certifiée suspendue. Les agrégats PostgreSQL ignorent les valeurs NULL dans une somme. Un résultat numérique peut donc sortir malgré une composante inconnue. Remplacer ce coût par zéro augmenterait artificiellement la contribution ; supprimer la facture masquerait la couverture incomplète.

Restituer une issue qui correspond au problème rencontré

Le produit peut afficher un résultat partiel explicitement autorisé, avec sa population couverte, ou suspendre l’indicateur selon la politique. Il ne présente pas le sous-ensemble comme le total confirmé. Si aucun événement ne tombe dans la période, le nombre de ventes vaut zéro, mais le ratio est non applicable. Ce cas vide a été vérifié séparément dans notre jeu synthétique.

Une permission insuffisante produit un refus d’accès, pas une nouvelle question sur le sens de « marge ». Un taux manquant produit une indisponibilité de conversion ; un délai d’exécution dépassé produit une erreur ou une reprise prévue. Ces issues doivent rester distinguées dans l’interface et les mesures. Aucun échec ne doit recevoir un chiffre zéro pour donner l’impression que la conversation s’est terminée normalement.

Recette : vérifier la sélection avant l’arithmétique

Tester un dialogue et sa sortie structurée

La référence de recette contient la question, le contexte autorisé, les réponses humaines possibles et le contrat attendu. L’essai observe les questions effectivement posées puis compare les champs sélectionnés. Le correcteur ne doit pas donner le contrat final au modèle avant de lui demander de comprendre la phrase : cela supprimerait précisément l’ambiguïté à tester.

Préparez au moins les variantes montant contre ratio, ventes contre coûts, facture contre commande, devise d’origine contre conversion et mois relatif contre dates absolues. Ajoutez une réponse qui ne tranche pas : « comme d’habitude » ne confirme rien si aucune convention n’est disponible. Le seuil d’ouverture dépend des erreurs jugées critiques et de la capacité de revue, pas d’un taux universel emprunté à une démonstration.

Séparer preuve de calcul et comportement de l’assistant

Les calculs de référence exécutés ici vérifient les montants et ratios des données synthétiques. Ils ne vérifient ni la sélection d’un contrat par un modèle ni l’application de droits dans une passerelle réelle. Le dictionnaire et catalogue de questions NL-to-SQL couvrent le grain, les accès et l’exécution ; la clarification ajoute sa propre recette de compréhension.

Le protocole d’évaluation d’un POC IA aide à conserver ces résultats séparés. Pour la conversation, mesurez les définitions incorrectement choisies, les précisions inutiles, les réponses ambiguës acceptées et les changements non confirmés. Pour le calcul, comparez les résultats au contrat retenu. Un bon calcul sous une mauvaise définition reste un échec du service rendu.

Erreurs fréquentes des conversations analytiques

Transformer les habitudes en défauts invisibles

La première erreur consiste à sélectionner le sens le plus fréquent du corpus sans vérifier celui de la question. Le modèle peut connaître une convention générale et ignorer celle de votre établissement. La seconde consiste à demander systématiquement toutes les dimensions, alors que le contexte en confirme déjà certaines. L’utilisateur finit par cliquer vite ; la confirmation perd sa fonction.

Une troisième erreur consiste à multiplier les alternatives inventées. Le catalogue doit fournir des options réellement calculables et nommées par le métier. Il ne faut pas demander quel coût complet utiliser si aucun référentiel ne permet ce calcul. Une demande hors définition ouverte est transmise pour cadrage, avec son besoin, plutôt que convertie en SQL improvisé.

Valider seulement le pourcentage affiché

Un pourcentage proche de la référence peut cacher deux erreurs qui se compensent. La recette compare population, sommes, dénominateur, période et conversion avant l’arrondi final. Une restitution de 36,67 % sans contrat lisible ne suffit pas à certifier qu’elle représente les factures sélectionnées. Des mêmes valeurs sur deux populations différentes peuvent même rendre un test numérique aveugle au défaut.

La réponse doit également préciser les unités sans exposer toute la mécanique de stockage. Les fonctions temporelles PostgreSQL permettent les conversions de calendrier, mais le produit doit garder la décision métier dans ses bornes et ses libellés. Déplacer la date selon le fuseau du navigateur sans décision explicite ferait varier le périmètre entre utilisateurs.

Plan d’action : ouvrir une famille de questions maîtrisée

Préparer les choix avant d’améliorer la formulation

Commencez par une famille de questions qui suscite des désaccords observables. Faites nommer les définitions par leur propriétaire, relevez les données nécessaires et éliminez les options non calculables. Construisez un jeu de référence avec une différence de période, de devise et de dénominateur. Les résultats concurrents doivent être vérifiables avant de tester la conversation.

1. Écrire les formules et leurs usages autorisés.
2. Définir les contextes imposés, les valeurs par défaut visibles et les choix humains.
3. Préparer les dialogues courts, les réponses incomplètes et les changements entre tours.
4. Relier chaque confirmation à une révision de contrat et à son résultat.
5. Tester ensuite le chemin complet jusqu’à la restitution, avec accès et sources réels.

La priorité va aux ambiguïtés qui changent une décision, une population ou une unité. Le délai de réponse est mesuré en incluant la clarification et les corrections, pas seulement l’exécution SQL. Les exemples fictifs préparent le contrôle ; le lancement attend des essais sur le service effectivement construit.

Attribuer la responsabilité des évolutions

Le propriétaire métier approuve une nouvelle variante, l’équipe data vérifie le calcul et le produit précise comment elle est présentée. Une version de catalogue retirée ne doit plus accepter de nouvelle exécution. Les conversations existantes gardent leur contrat historique et demandent une reconfirmation lorsque leur choix n’est plus disponible.

La supervision relie corrections humaines et versions concernées. Si une formule change, les tests de sélection et de calcul sont rejoués avant ouverture. Si le service ne sait pas établir le contrat ou si les données restent incomplètes, le repli nomme le rapport ou l’équipe qui peut traiter la demande. Cette issue possède un responsable ; elle ne disparaît pas dans une catégorie générique « question non comprise ».

En entrée de supervision, conservez les événements de clarification et les révisions, puis distinguez en sortie contrat confirmé, abandonné, refusé ou indisponible. Le responsable produit examine aussi la latence entre demande et définition confirmée, avec le délai des reprises humaines. Le dossier de lancement IA et ses conditions de retrait fixe la conduite lorsque cette chaîne ne tient plus : suspendre les questions concernées et orienter vers le reporting de repli.

Conclusion : confirmer la définition que le chiffre représente

Clarifier une question NL-to-SQL consiste à choisir une définition parmi des options métier autorisées. Formule, événement, calendrier et devise se combinent pour produire le contrat. Une requête qui respecte seulement la syntaxe peut répondre correctement à une autre question que celle de l’utilisateur.

Les quatre ventes fictives rendent le désaccord visible : 36,67 % sur les ventes facturées, 57,89 % sur leurs coûts, 42,11 % sur les ventes commandées. Ces calculs sont vérifiés ; la compréhension et la confirmation du dialogue restent à tester dans l’assistant réel. La preuve doit suivre ces deux étapes séparément.

La conception d’un agent IA SQL avec définitions et requêtes contrôlées relie le choix humain à un calcul identifiable. Chaque relance conserve ce qui reste valable, expose ce qui change et empêche un résultat ancien d’hériter d’un nouveau sens.

Dawap accompagne votre responsable reporting dans le cadrage de cette IA sur mesure reliée aux données métier. Nous partons d’une question de marge, de son calcul de référence et des choix que l’utilisateur doit confirmer. La recette inclut une vente à cheval sur deux mois et une devise différente, puis vérifie que le résultat conserve la définition choisie et qu’une nouvelle demande ne réétiquette pas un ancien chiffre.