SQL valide, résultat faux : tester jointures, doubles comptes et dates

Le tableau de bord affiche 440 € et la base n’a signalé aucune erreur. La commande SQL est lisible, les noms de colonnes existent et le résultat semble proche du contrôle manuel de 450 €. Pourtant la perte de deux commandes est masquée par la contribution doublée d’une autre. Un agent IA peut restituer ce chiffre avec assurance ; le responsable doit alors reprendre le rapprochement avant de pouvoir utiliser l’indicateur.

En pratique, un résultat NL-to-SQL ne devient acceptable qu’en rapprochant la population retenue, le grain de calcul et le montant avec une référence indépendante. Cette recette vient après la confirmation de la question métier. Pour concevoir un agent IA SQL et données métier, il faut rendre ces contrôles reproductibles, puis décider comment l’application suspend la restitution lorsqu’ils révèlent une incohérence.

Nous construisons ici six commandes entièrement fictives, sept lignes et cinq expéditions. Sept variantes SQL et quatre mutations du jeu ont été exécutées dans PostgreSQL 18.6. Le but est de reconnaître des défauts qui échappent à un simple test de syntaxe, pas de mesurer un modèle. Avant d’ouvrir ce reporting à une IA sur mesure, le responsable métier doit pouvoir retrouver les cinq commandes attendues et leurs contributions aux 450 €. Un total voisin, calculé sur une autre population, reste à expliquer avant toute restitution.

Pour qui tester un résultat avant sa restitution

Reconnaître une réponse plausible mais inutilisable

Cette démarche concerne un responsable métier qui compare des périodes, une équipe data qui ouvre des questions en langage naturel ou une DSI qui doit expliquer un écart avec un reporting maintenu. Le symptôme n’est pas forcément un montant spectaculaire. Une petite différence répétée peut suffire à déplacer une priorité commerciale, à rendre deux équipes incapables de rapprocher leurs chiffres ou à déclencher une correction sur la mauvaise population.

Le défaut apparaît souvent quand le calcul rencontre une relation multiple, un objet sans événement enfant ou une frontière temporelle. Un exemple pris au milieu du mois, avec une seule ligne et une seule expédition par commande, peut tout laisser passer. La recette choisit au contraire des données qui obligent la requête à respecter son contrat. Elle ne se contente pas d’une capture de réponse obtenue sur une journée commode.

Séparer justesse, compréhension et permission

Le dialogue de clarification d’une question NL-to-SQL ambiguë fixe formule, événement, calendrier et devise avant le calcul. Ici ces choix sont déjà décidés. Une réponse qui utilise le mauvais événement constitue un défaut différent d’une réponse qui applique mal une jointure à l’événement convenu. Les deux essais doivent produire des motifs lisibles plutôt qu’un verdict unique qui empêche de retrouver la cause.

Une requête peut être correcte et interdite, ou autorisée et fausse. Le présent jeu n’éprouve pas la sécurité de l’exécuteur : il calcule sur des tables de démonstration dans un périmètre figé. Les essais de justesse restent distincts de ceux des droits d’accès. Dans un service complet, la restitution attend les preuves pertinentes pour chacun de ces axes et ne transforme pas un succès de calcul en permission d’explorer davantage.

Figer population, grain et montant attendu

Décider ce qui contribue une seule fois

Le contrat de démonstration porte sur le montant commandé HT des commandes créées en septembre 2026 selon le calendrier Europe/Paris. Les six objets représentent des commandes confirmées d’un seul périmètre fictif. Les montants de leurs lignes sont déjà définis en EUR ; ils doivent être additionnés par commande. Une expédition ne crée pas de montant commandé supplémentaire et son absence n’exclut pas une commande de cette population.

Ce montant n’est ni un encaissement ni un chiffre d’affaires comptable. Les remboursements, taxes, conversions et changements de statut ne figurent pas dans ce petit jeu. Dans votre système, le propriétaire doit préciser comment ses vues sélectionnent les objets admissibles et produisent les montants de ligne. Le contrat conservé pour la recette indique les exclusions afin qu’un chiffre testé dans cette démonstration ne soit pas réutilisé pour une autre mesure sous un libellé plus large.

Conserver une attente indépendante de la requête candidate

Avant de regarder les variantes, le registre attendu retient A, B, C, E et F. Leurs montants valent respectivement 100, 120, 80, 120 et 30 €, soit 450 €. D appartient à octobre dans le calendrier choisi. Cette liste manuscrite permet de contrôler le total sans utiliser la requête que l’on cherche à valider. Si la référence et le candidat partagent la même jointure fautive, leur accord ne détecte rien.

Le registre précise aussi le grain : cinq commandes distinctes, six lignes contributives et aucune dépendance à l’existence d’une expédition. Les identités constituent des attentes, pas des détails facultatifs. En changeant de version de source ou de définition, l’équipe doit réexaminer ce registre avec le métier. Recalculer automatiquement un « attendu » à partir du SQL modifié ferait disparaître la possibilité de découvrir que le changement a altéré la décision servie.

Six commandes choisies pour révéler les défauts

Associer chaque objet à une raison de présence

A possède deux lignes de 60 et 40 € et deux expéditions. B et E valent chacune 120 € avec des identités différentes. C et F n’ont aucune expédition. F se situe exactement au début de septembre et D exactement au début d’octobre, dans le calendrier Paris. Ces choix exposent les cas qui resteraient invisibles avec des valeurs toutes différentes, des relations strictement uniques et des dates éloignées des frontières.

Le schéma comporte une identité unique par commande, ligne et expédition ; les tables enfants référencent leur commande. Les montants sont de type numérique exact et non nuls dans le jeu initial. Les dates sont des instants avec fuseau. Les noms demo_orders, demo_lines et demo_shipments désignent uniquement cette simulation. Aucun connecteur ERP, flux logistique ou historique de client n’alimente les résultats présentés.

Garder le jeu petit sans le rendre complaisant

Six objets ne représentent pas la diversité d’un système commercial. Ils suffisent ici à réfuter plusieurs calculs précis parce que leurs attentes sont inspectables à la main. Cette petite référence complète une recette plus large ; elle ne démontre aucun taux de fiabilité en production. Si un modèle réel est ajouté, il faudra varier les formulations et vérifier quel contrat il sélectionne avant d’évaluer le SQL effectivement proposé.

Le fichier de recette conserve données, variantes, assertions et restauration après mutation. Une autre personne peut retrouver quel objet devait contribuer et pourquoi le total change. Pour votre famille de questions, ajoutez les situations que le schéma autorise réellement : plusieurs corrections d’une ligne, statut retiré, source incomplète ou événement tardif. Chaque ajout doit posséder une attente décidée ; accumuler des enregistrements aléatoires sans verdict ne crée pas une meilleure preuve.

Observer les lignes multipliées et perdues

Voir la multiplication avant de calculer la somme

Exemple concret : joindre commandes, lignes et expéditions fait rencontrer les deux lignes de A avec ses deux expéditions. Quatre lignes intermédiaires portent 60, 60, 40 et 40 €. Il faut rejeter cette contribution de 200 € au lieu des 100 € attendus. Avec une relation externe vers les expéditions, C et F restent présentes, mais le total devient 550 €. Huit lignes jointes représentent cinq commandes ; ces deux nombres ne sont pas interchangeables.

La documentation PostgreSQL des expressions de table décrit la construction des lignes par les jointures. Le contrôle opérationnel consiste ici à l’observer au grain de chaque commande : nombre de lignes avant agrégation, contribution attendue et contribution obtenue. Un nom de clé correctement utilisé ne suffit pas à garantir une cardinalité compatible avec une somme. La relation peut être valide tout en produisant une mesure fausse.

Détecter deux erreurs qui se compensent

Second cas concret : si la relation avec les expéditions devient une jointure interne, C et F disparaissent. Le calcul garde seulement A, B et E ; il additionne toujours deux fois le montant de A. Le total vaut 440 €. L’excédent de 100 € lié à A compense presque les 110 € perdus avec C et F. Cette variante doit être refusée pour la population attendue, même si le moteur exécute sa commande sans erreur.

Paradoxalement, le montant le plus proche de la référence vient donc ici d’une requête qui cumule deux défauts. L’écart de 10 € représente environ 2,22 % des 450 € attendus. Il faut refuser ce résultat malgré cette proximité : trois commandes sont retenues au lieu de cinq. Une tolérance globale choisie sans contrôle des identités pourrait laisser passer la perte de population. Le rapprochement par objet découvre la cause que le seul total masque.

Pourquoi DISTINCT et préagrégation peuvent échouer

Distinguer une valeur égale d’une identité répétée

Sur les lignes contributives, les valeurs distinctes sont 60, 40, 120, 80 et 30 €. Leur somme vaut 330 €. SUM(DISTINCT amount_ht) élimine l’un des deux montants de 120 €, alors que B et E doivent chacune contribuer. Il ne reconnaît pas les commandes : il déduplique des valeurs. La correction peut sembler fonctionner sur un jeu où tous les montants diffèrent, puis supprimer une activité légitime dès que deux objets ont le même prix.

COUNT(DISTINCT o.id) retrouve cinq commandes dans la variante externe, mais ne corrige pas sa somme de 550 €. Le comptage et le montant sont deux mesures à contrôler séparément. La référence PostgreSQL des agrégats aide à examiner les opérations utilisées ; la recette décide quelles identités et contributions doivent rester présentes dans votre indicateur. Un mot-clé ajouté à un agrégat ne certifie pas les autres colonnes de sa réponse.

Revérifier le grain après chaque relation ajoutée

Préagréger les lignes par commande constitue une étape utile : A revient à une seule ligne de 100 €. Mais si cette ligne est ensuite jointe aux deux expéditions brutes, ses 100 € sont de nouveau répétés. La variante exécutée retrouve 550 €. La preuve doit donc porter sur la chaîne entière jusqu’à l’agrégation finale, pas sur la présence rassurante d’un CTE ou d’un GROUP BY au début de la requête.

Pour notre contrat, les expéditions sont inutiles au montant commandé : la référence ne les joint pas. Si un autre indicateur exige une propriété logistique, l’équipe définit d’abord si cette propriété filtre des commandes ou produit une mesure par expédition. Elle choisit ensuite une relation compatible avec ce grain. Ajouter une table seulement parce que la question mentionne la logistique peut faire glisser silencieusement une somme de commandes vers une somme d’occurrences d’expédition.

Éprouver les frontières du calendrier choisi

Tester le début inclus et la fin exclue

Le calendrier convenu retient les instants à partir du 1er septembre à 0 h inclus et avant le 1er octobre à 0 h. F contribue donc 30 €, tandis que D ne contribue pas. La variante utilisant BETWEEN sur ces mêmes bornes inclut aussi D et renvoie 540 €. Le défaut concerne la borne supérieure ; il ne vient pas d’une formule de montant ou d’un changement d’événement métier.

Les opérateurs de comparaison PostgreSQL définissent notamment le caractère inclusif de BETWEEN. La recette conserve un objet exactement sur chaque frontière pour éprouver la règle retenue. Les bornes adjacentes ne doivent ni compter deux fois le même instant ni créer un trou entre périodes. Une date de fin affichée sans son caractère inclus ou exclu ne permet pas de reconstruire ce contrôle.

Vérifier les instants derrière les dates affichées

Dans ce jeu de septembre, minuit à Paris est représenté avec le décalage +02. F correspond au 31 août à 22 h UTC et D au 30 septembre à 22 h UTC. Une sélection de septembre avec des bornes UTC retire F et ajoute D. Elle retient A, B, C, D et E pour 510 €. Le nombre de commandes reste cinq, mais leurs identités changent : contrôler seulement la taille de la population ne suffit toujours pas.

La documentation PostgreSQL des types temporels précise le traitement des instants avec fuseau. Les décalages littéraux de cette démonstration correspondent à ses dates ; ce +02 ne constitue pas une règle à appliquer à toute l’année. Dans le service, les bornes viennent du calendrier approuvé et sont injectées comme paramètres typés. La preuve garde les instants effectifs afin de comparer un résultat malgré un affichage dans un autre fuseau.

Une requête de référence au grain commande

Conserver les commandes et leurs contributions attendues

La référence agrège les lignes par commande, puis conserve toutes les commandes du calendrier choisi avec une jointure externe vers ces montants. Elle ne rencontre aucune expédition. L’identité de chaque commande reste disponible dans la réponse de recette, avec le nombre d’objets et un compteur d’absence de montant. Le SQL ci-dessous a été exécuté sur les tables fictives ; il donne cinq identités, zéro absence et 450 € certifiés dans ce jeu.

WITH amounts AS (
  SELECT order_id, SUM(amount_ht) AS amount_ht
  FROM demo_lines
  GROUP BY order_id
)
SELECT COUNT(*) AS orders,
       ARRAY_AGG(o.id ORDER BY o.id) AS retained_ids,
       COUNT(*) FILTER (WHERE a.order_id IS NULL) AS without_amount,
       CASE WHEN COUNT(*) FILTER (WHERE a.order_id IS NULL) > 0
            THEN NULL ELSE SUM(a.amount_ht) END AS certified_ht
FROM demo_orders o
LEFT JOIN amounts a ON a.order_id = o.id
WHERE o.created_at >= TIMESTAMPTZ '2026-09-01 00:00:00+02'
  AND o.created_at < TIMESTAMPTZ '2026-10-01 00:00:00+02';

Les identités servent au rapprochement du jeu, pas à ouvrir un export sans limite sur votre base. Les permissions d’export doivent être décidées séparément de la consultation du montant. Pour une population importante, le service peut rapprocher des contributions à un niveau autorisé et conserver une référence de contrôle. La restitution garde ainsi une explication de l’anomalie sans exposer systématiquement tous les identifiants dans l’écran ; cacher le détail ne doit pas rendre l’écart inexplicable.

Suspendre le montant quand une contribution manque

Une commande sans ligne dans ce schéma ne possède pas de montant connu. Le seuil de complétude fixé pour cette recette est zéro commande sans montant : la référence garde l’identité de la commande et suspend le total certifié. Elle ne supprime pas l’objet et ne convertit pas son absence en zéro. Cette règle doit être enrichie si une source réelle peut transmettre des lignes incomplètes, des quantités inconnues ou des corrections encore non rapprochées.

Ce garde-fou précise une limite de la preuve. Le jeu initial ne manque d’aucune ligne, mais une mutation ci-dessous supprime la ligne de C pour vérifier que le total est réellement suspendu. Le moteur ne peut pas deviner si une collecte est exhaustive à partir des seules tables reçues. L’application doit porter les autres critères de complétude, leurs responsables et leur état de validation avant de qualifier un montant de certifié pour une décision réelle.

Quatre mutations réellement exécutées

Faire varier une propriété à la fois

Un test de mutation modifie ici une seule situation du jeu puis compare la réponse à une attente écrite. Chaque mutation est exécutée dans sa propre transaction et annulée ensuite. Les commandes ne s’accumulent pas entre les quatre essais. La référence finale revient aux six commandes, sept lignes, cinq expéditions et 450 € de départ. Cette restauration a été contrôlée afin qu’un résultat de mutation ne soit pas attribué à une modification précédente.

M1 affirme une invariance métier : ajouter une expédition ne crée pas de montant commandé. M2 affirme au contraire une variation : une nouvelle commande ajoute sa contribution même lorsqu’elle a le même montant qu’une autre. Ces deux attentes évitent de demander simplement que toutes les modifications changent le résultat. La propriété attendue dépend de l’indicateur, pas d’une idée générale selon laquelle un bon calcul serait sensible à chaque événement disponible.

Éprouver une frontière et une absence

M3 déplace D de la borne exclue vers l’instant immédiatement précédent, puis vérifie l’ajout de 90 €. Il ne simule ni retard de transport ni changement de calendrier : seule la date source change. M4 conserve C dans la population mais retire son unique ligne ; cinq identités subsistent, une absence est signalée et aucun montant n’est certifié. Les deux essais isolent des causes qui exigent des issues différentes dans la restitution.

Ces quatre passages prouvent le comportement des requêtes écrites pour ce schéma et ces données. Ils ne démontrent pas que l’agent réel produit la bonne requête sur une nouvelle formulation, résiste à une instruction malveillante ou reste juste sur tous vos schémas. Les résultats restent des références de recette. La construction d’un jeu d’évaluation IA couvrant les cas rares permet ensuite de relier ces défauts à des questions et à des issues attendues sans les transformer en benchmark imaginaire.

Accepter un résultat avec ses identités et ses preuves

Comparer les variantes sans confondre les verdicts

La matrice conserve ce que chacune des sept variantes a effectivement calculé sur le jeu initial. « SQL exécuté » signifie seulement que le moteur a accepté et évalué la commande. Le verdict de recette examine ensuite les identités, les contributions et la période fixées. Les erreurs sont nommées pour que le développeur puisse corriger la transformation responsable sans demander au métier de modifier son attendu afin de rejoindre un chiffre techniquement obtenu.

Le journal peut conserver le résultat attendu et obtenu sans porter l’étiquette vague de « réponse incorrecte ». Sur R2, le motif associe A à un excès de 100 €, C à une perte de 80 € et F à une perte de 30 €. Sur R6, les contributions sont justes pour les objets sélectionnés mais les bornes ont choisi la mauvaise population. Le correctif recherché et le cas de non-régression ne sont donc pas les mêmes.

Organiser la sortie du contrôle dans l’application

L’entrée du contrôle associe contrat, version des données, paramètres temporels effectifs et requête candidate. Le rapprochement produit ses écarts avant la restitution d’un indicateur validé. Une modification du schéma ou du contrat invalide les preuves concernées. Le repli est une suspension explicable ou un retour vers le reporting approuvé, avec une trace reliant l’écart à sa commande et à son contrat. Relancer le calcul jusqu’à obtenir un chiffre proche ne constitue pas une correction.

La sortie distingue montant accepté sur la recette, contribution absente, population différente et calcul non rapproché. La responsabilité métier porte sur la définition et les attentes ; la responsabilité technique porte sur la transformation et ses traces. Le contrat séparant appel d’outil, autorisation et exécution aide à éviter qu’une explication correcte du modèle soit confondue avec la preuve du résultat réellement produit par le service de données.

Erreurs fréquentes dans la recette des indicateurs

Accepter une preuve trop proche du calcul testé

Une première erreur consiste à faire écrire l’attendu par le même générateur qui a proposé le SQL. Une deuxième consiste à réutiliser la même jointure dans une requête dite de contrôle. Une troisième consiste à ne garder que la réussite technique et le montant final. Dans ces trois cas, la recette peut reproduire le défaut ou perdre les informations qui permettent de le diagnostiquer, même si son compte rendu annonce que tous les essais sont verts.

Le jeu comporte volontairement des montants égaux, une relation multiple et des objets sans expédition. Retirer ces situations pour faciliter la comparaison rendrait la recette plus confortable mais moins discriminante. Si une donnée est impossible dans votre contrat, documentez pourquoi elle est exclue ; si elle est seulement rare, gardez un cas qui l’éprouve. Sa présence ne doit pas dépendre de son apparition fortuite dans un extrait récent de production.

Corriger le chiffre sans corriger sa population

Ajouter DISTINCT, changer la borne de fin ou filtrer les lignes nulles après avoir vu l’écart peut faire coïncider un total sans restaurer l’indicateur. Le correctif doit décrire quelle transformation est erronée et quels objets retrouvent leur contribution. Une note « écart corrigé » ne suffit pas lorsque le même SQL doit répondre sur une autre période. Les mutations doivent rester vertes après la correction, y compris celles qui modifient une propriété indépendante du montant.

Une autre erreur serait de présenter les sept variantes comme sept réponses d’un modèle ou de déduire une précision statistique des refus. Elles sont écrites à la main pour éprouver des calculs précis. La recette d’un assistant ajoute des formulations, du contexte autorisé et les commandes qu’il produit réellement. Les conclusions conservées doivent rester proportionnées à ce qui a été exécuté ; l’expertise vient de cette distinction autant que de la présence d’un résultat chiffré.

Plan d’action pour une première famille de questions

Construire une référence qui permet de décider

Commencez par un indicateur que le métier sait expliquer et qui possède une source accessible au périmètre choisi. Il est plus utile de qualifier une famille de questions avec ses cas difficiles que de multiplier les formulations sans référence. Le responsable valide le nom de la mesure, le grain, les exclusions et l’issue attendue lorsqu’une contribution manque. L’équipe technique conserve ensuite les relations utilisées et les conditions qui rendent une version de recette applicable.

1. Documenter le contrat, les bornes effectives et les identités contributives d’un petit jeu. Rapprocher l’attendu avec un calcul manuel ou un reporting approuvé, puis conserver l’origine de cette référence.
2. Associer chaque défaut possible à un cas discriminant : objet enfant multiple, valeur égale, enfant absent, début inclus ou fin exclue. Choisir la transformation qui doit rester stable ou changer pour chacun.
3. Rapprocher le résultat candidat au grain métier avant son total. Refuser un montant qui masque des identités perdues, et garder le motif ainsi que la commande réellement exécutée.
4. Conserver les mutations et vérifier leur restauration. Réexécuter les cas concernés après changement de vue, clé, calendrier ou définition ; identifier les preuves rendues obsolètes.
5. Soumettre le dossier de recette au propriétaire de l’indicateur avant ouverture dans l’assistant. La décision précise périmètre admis, limites de preuve, responsabilité des exceptions et reprise manuelle.

Ce plan produit une décision d’ouverture documentée pour la famille étudiée. Il ne donne pas automatiquement le même statut à une nouvelle dimension ou à une requête qui introduit une autre table. Si le service ajoute un regroupement par produit, il devra préciser ce qui arrive aux lignes réparties, aux montants déjà agrégés et aux objets non attribués. La preuve acquise au grain commande doit être réexaminée lorsqu’un nouveau grain change la contribution attendue.

Garder la recette exploitable après l’ouverture

En exploitation, un écart confirmé rejoint les cas de référence avec le contrat, les versions et les objets nécessaires à sa reproduction. Le support doit pouvoir orienter l’incident vers définition, source, cardinalité ou restitution. Conserver seulement la réponse finale crée une charge support : l’équipe doit rechercher les bornes, les objets perdus et la transformation fautive. Des références de preuve adaptées aux droits et à la rétention permettent ce travail sans copier systématiquement toutes les données interrogées.

La supervision regarde les résultats suspendus pour contribution absente, les requêtes modifiées après changement de schéma et les écarts expliqués par population. Elle aide à décider si l’automatisation d’une famille de questions peut rester ouverte ou doit revenir à un calcul préparé. Un seuil d’écart autorisé dépend du contrat et des données ; les essais synthétiques ne fournissent aucune tolérance universelle ni estimation du coût d’exploitation d’un assistant.

Guides complémentaires pour le contrat et le dialogue

Relier le contrôle à un catalogue d’indicateurs

NL-to-SQL métier : indicateurs justes et requêtes autorisées organise dictionnaire, catalogue et périmètre d’exécution. Le calcul ajusté par remboursements montre pourquoi événement et date d’observation doivent être explicites. Ces définitions permettent de décider quelles questions deviennent accessibles et quels résultats de référence appartiennent réellement à la mission de l’assistant.

La recette détaillée ici approfondit cette chaîne avec une population inspectable, des valeurs égales et des mutations ciblées. Elle peut compléter une vue maintenue sans ouvrir de génération SQL libre. Le choix entre requêtes préparées et exploration plus large dépend du besoin, de la diversité des questions et des validations que votre équipe peut maintenir.

Éviter de tester une interprétation non confirmée

La clarification des questions NL-to-SQL traite les choix qui précèdent cette recette : formule, événement, calendrier et devise. Plusieurs calculs exacts peuvent correspondre à des demandes différentes. La validation de ces choix empêche de qualifier un SQL mécaniquement juste pour une mesure que l’utilisateur n’a pas retenue.

En reliant confirmation et résultat exécuté par une version de contrat, le produit peut expliquer ce qu’il a vérifié. Une reformulation qui change le périmètre ou le calendrier doit ouvrir une nouvelle vérification pertinente. Elle ne doit pas conserver le statut de preuve d’une réponse précédente au seul motif que les noms des tables restent identiques.

Conclusion : contrôler le calcul que la décision utilise

Une syntaxe valide ne prouve ni la population ni la contribution de chaque objet. Dans notre exemple, le résultat de 440 € paraît proche des 450 € attendus alors que deux commandes disparaissent et qu’une autre est doublée. Les identités, le grain et les frontières du calendrier révèlent ce défaut. La recette doit conserver ces dimensions plutôt que réduire la justesse à un écart global entre deux nombres.

Sept variantes et quatre mutations ont été exécutées sur six commandes synthétiques, avec annulation de chaque mutation et restauration finale vérifiée. La référence distingue cinq commandes, 450 € et zéro absence dans le jeu initial ; lorsqu’une ligne manque, elle conserve la population et suspend le montant. Cette preuve concerne les requêtes et les données présentées. Aucun comportement de modèle, connecteur distant ou historique client n’est évalué par ces essais.

La conception d’un agent SQL avec des réponses métier vérifiables relie définition, transformations, restitution et exceptions. Une nouvelle table, dimension ou version de source doit pouvoir déclencher la revue de ses preuves. Le produit reste alors capable d’expliquer pourquoi un résultat est admis, suspendu ou renvoyé à un calcul approuvé.

Dawap accompagne la recette d’une IA sur mesure pour votre reporting à partir d’un indicateur dont les objets et contributions sont vérifiables séparément. Avec son responsable métier, nous fixons la population attendue, puis provoquons une expédition supplémentaire, un montant identique et une donnée manquante. La décision de restituer le chiffre porte ainsi sur les écarts observés dans vos vues, avant d’élargir les questions accessibles aux utilisateurs.