Vérifier une réponse générée par IA avant de la présenter au conseil

Pour vérifier une réponse générée par IA, contrôlez d’abord la question, la période et la définition métier, puis faites relire le SQL exécuté lorsque le chiffre compte. Datarelix affiche la requête exécutée, les tables sources, le nombre de lignes et le temps d’exécution avec chaque réponse : la relecture part de ce qui a réellement été exécuté, pas d’une paraphrase. Les sections suivantes répartissent le travail : les contrôles à la portée de tous, une relecture SQL en huit étapes pour les analystes et un exemple de total de commande compté deux fois.

Quels contrôles faire sans écrire de SQL ?

Gardez la question initiale à côté de la réponse. Vérifiez période, devise, unité et définition avant de comparer les totaux. « Chiffre d’affaires du mois dernier » peut désigner commandes enregistrées, factures payées ou ventes après remboursements.

Consultez les tables indiquées pour confirmer la source. Demandez à son responsable quand les données ont été actualisées et si la période est complète. Un chargement incomplet peut expliquer un montant faible même avec une requête correcte.

Contrôle	Point à examiner	Précision à demander
Période	Bornes exactes, période complète ou partielle	« Utilise le dernier mois civil complet. »
Définition	Statuts, remboursements, taxes et remises	« Exclus les annulations et sépare les remboursements. »
Unité	Devise et élément compté	« Affiche les euros et compte les clients distincts. »
Source	Table validée et dernière mise à jour	« Utilise la table de commandes du reporting. »
Cohérence	Rapport comparable ou échantillon connu	« Décompose le total par semaine. »

Ces contrôles orientent la suite. Ils ne démontrent pas que les jointures et calculs sont corrects.

Un résultat annoté

Exemple de rapport commercial :

Élément visible	Exemple	Point à vérifier
Période	1er–31 août 2026	Les données du mois sont-elles complètes ?
Ventes finalisées	2 300 EUR	Le rapport de référence utilise-t-il la même définition ?
Remboursements	200 EUR	Sont-ils datés d’août ou rattachés aux ventes d’août ?
Ventes après remboursements	2 100 EUR	La soustraction est cohérente ; les entrées restent à contrôler.
Lignes renvoyées	1	Il s’agit d’un résumé, pas d’une seule commande.

Le guide de l’analytique vérifiable présente les informations affichées par Datarelix.

Quand faire relire le SQL

Sollicitez une personne connaissant le schéma si les totaux divergent, si plusieurs tables sont jointes ou si le chiffre doit être communiqué à l’extérieur. Transmettez ensemble question, requête, sources et résultat.

Jointures : le total d’une commande répété sur trois articles ne doit pas être additionné trois fois. Regroupez chaque source au niveau prévu avant combinaison.
Filtres et absences : vérifiez annulations, comptes de test, dates nulles et enregistrements exclus faute de correspondance.
Dates et devises : confirmez fuseaux horaires, bornes et règles de conversion.
Limites : une limite placée avant le calcul peut modifier un total. Le nombre de lignes renvoyées ne suffit pas à le détecter.

Le temps d’exécution indique une durée. Il ne prouve ni le volume lu ni l’exactitude du calcul.

Comment vérifier en huit étapes une réponse SQL générée par IA

Utilisez cette séquence pour une revue commune. Les utilisateurs métier établissent définition, période et source attendues. Les analystes vérifient leur traduction en SQL, avec des résultats intermédiaires si nécessaire.

Vérifiez que l’interprétation correspond à votre intention. Lisez votre question d’origine à côté de la requête exécutée et contrôlez qu’elles décrivent la même mesure. « Le chiffre d’affaires du trimestre dernier » peut désigner le trimestre civil précédent ou les quatre-vingt-dix derniers jours, et « les meilleurs clients » peut vouloir dire par chiffre d’affaires ou par nombre de commandes — la requête tranche pour une lecture, et ce doit être la vôtre.
Contrôlez la définition de la métrique. Décidez si le chiffre doit être brut ou net, et si retours, remboursements, remises, taxes et frais de port sont dedans ou dehors — puis vérifiez que l’arithmétique et les filtres de la requête vont dans le même sens. Une requête techniquement correcte peut malgré tout mesurer la mauvaise chose ici.
Contrôlez le périmètre des données. Regardez quelles tables la requête a lues et confirmez que ce sont les tables canoniques, pas une copie de staging ni un _v2 abandonné. Vérifiez ensuite l’exhaustivité et la fraîcheur : la période est-elle entièrement chargée, et le mois en cours est-il partiel — auquel cas il faut l’exclure ou le signaler.
Contrôlez les jointures pour repérer la duplication de lignes (fan-out). Joindre un montant au niveau de la commande aux lignes de commande le multiplie une fois par ligne, ce qui gonfle silencieusement toute somme construite par-dessus. Vérifiez que les montants sont sommés à la granularité où ils vivent, et comparez lignes jointes et identifiants métier distincts avant l’agrégation. Le nombre de lignes final ne suffit pas à détecter ce problème.
Contrôlez les filtres. Cherchez les filtres de statut (honorée, annulée, remboursée), les lignes de test, les comptes internes et les enregistrements supprimés. Les inclure ou les exclure est une décision métier, et c’est dans la clause WHERE de la requête que cette décision est visible.
Contrôlez le fuseau horaire et la devise. Une frontière de journée en UTC n’est pas une frontière de journée dans votre fuseau de reporting, et les chiffres de fin de mois se déplacent quand la coupure bouge. Si les données couvrent plusieurs devises, vérifiez que les montants ont été convertis avant d’être sommés, plutôt qu’additionnés bruts.
Contrôlez la vraisemblance du résultat d’exécution. Comparez le nombre de lignes et l’ordre de grandeur de la réponse à ce que vous attendiez : une demande portant sur tous les clients ne doit pas en renvoyer douze sans filtre ou limite qui l’explique, et un chiffre d’affaires trimestriel doit rester dans le voisinage des trimestres précédents. Un résultat très éloigné invite à reprendre les étapes trois à six ; ce n’est pas une bizarrerie d’arrondi.
Lisez les exceptions et les avertissements. Vérifiez si le résultat a été tronqué par une limite de lignes automatique, si la requête a échoué puis a été corrigée et relancée, et si une étape de l’exécution a signalé des données partielles. Si le nombre de lignes est égal à la limite de lignes, vérifiez une éventuelle troncature : reposez la question sous forme d’agrégat explicite, pour que le total soit calculé dans la base plutôt que sur une tranche plafonnée.

Revue SQL : un montant de commande compté deux fois

Prenons trois commandes d’août. Tous les montants sont en EUR, les prix des articles couvrent les mêmes éléments que le total de commande, sans remise ni remboursement dans cet exemple.

Commande	Statut	Total	Lignes d’articles et montants
A	completed	100	60 + 40
B	completed	200	200
C	cancelled	50	20 + 30

On compte cinq lignes d’articles pour trois commandes. La valeur des commandes terminées est de 300. Trois calculs illustrent des problèmes différents :

Calcul	Résultat	Interprétation
Somme de tous les articles sans filtre de statut	350	Inclut la commande annulée
Somme des articles des commandes terminées	300	Correspond à la valeur demandée
Somme des totaux de commandes après jointure avec leurs articles	400	Compte deux fois le total de A, qui a deux articles

Chaque agrégation peut renvoyer une seule ligne. Pour examiner la jointure, l’analyste peut exécuter ce diagnostic :

SELECT COUNT(*) AS joined_rows,
       COUNT(DISTINCT o.order_id) AS distinct_orders,
       SUM(o.total_eur) AS repeated_order_total,
       SUM(i.quantity * i.unit_price_eur) AS item_total
FROM orders AS o
JOIN order_items AS i ON i.order_id = o.order_id
WHERE o.status = 'completed'
  AND o.ordered_at >= DATE '2026-08-01'
  AND o.ordered_at < DATE '2026-09-01';

Le résultat donne joined_rows = 3, distinct_orders = 2, repeated_order_total = 400 et item_total = 300. La différence entre les nombres de lignes révèle la relation un-à-plusieurs ; le montant choisi détermine si elle gonfle la somme.

Pour un total au niveau commande, additionnez les commandes sans joindre les articles. Pour une mesure au niveau article, additionnez les montants une seule fois à ce niveau. Avec des paiements ou remboursements, agrégez chaque entrée au niveau requis avant la jointure. SUM(DISTINCT total_eur) ne constitue pas une correction générale : deux commandes différentes peuvent avoir le même total.

Filtrer les commandes terminées ne calcule pas les ventes après remboursements. Il faut consulter la source des remboursements et décider si on les comptabilise à leur date d’émission ou sur la période de la commande initiale. Le rapport de ventes hebdomadaire détaille cette distinction.

Que conserver avec un chiffre vérifié ?

Conservez la définition, les dates exactes, le fuseau horaire, les sources, le SQL exécuté, le résultat, la date d’exécution et la référence utilisée pour le rapprochement. Signalez les exclusions connues, par exemple un chargement tardif. L’analyste peut ainsi reprendre l’investigation ; l’utilisateur métier comprend pourquoi un rapport défini autrement donne un autre chiffre.

Si une erreur a entraîné une correction, conservez la version exécutée avec succès. Si les données sources changent ensuite, la même requête peut produire un autre résultat. Garder la sortie initiale et la requête permet de distinguer une évolution des données d’une modification du calcul.

Adapter la vérification à l’usage

Pour explorer les données, contrôlez les définitions et un échantillon connu. Pour un rapport de direction ou un chiffre externe, rapprochez le résultat de la source validée et prévoyez une seconde relecture compétente. Cette méthode n’est pas une norme comptable ou réglementaire.

En cas de divergence, conservez les deux requêtes et examinez définitions, fraîcheur et jointures. Le tableau de bord existant peut aussi contenir une erreur.

Conserver les éléments à relire

Rouvrez la conversation Datarelix pour consulter requête et résultat. Les comptes étant privés, exportez le résultat ou copiez le SQL dans vos notes pour un collègue. Un graphique vérifié peut être actualisé à partir de sa requête enregistrée ; consultez les tableaux de bord.

Le guide des questions aide à préciser la demande suivante. Pour l’accès et le traitement des données, utilisez la liste de contrôle sécurité.

Quels contrôles faire sans écrire de SQL ?