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

Le SQL est la première chose à contrôler, et il ne suffit pas à lui seul. Si vous vous demandez comment vérifier qu’un chiffre généré par IA est juste, la réponse tient dans un passage court et reproductible. Avant qu’un chiffre n’arrive dans une présentation au conseil, confirmez huit points : l’interprétation correspond à votre intention, la métrique correspond à votre définition métier, les bonnes tables ont été lues, les jointures n’ont pas multiplié les lignes, les filtres ont exclu les bonnes lignes, fuseaux horaires et devises concordent, le résultat passe un contrôle de vraisemblance, et les avertissements ont été lus.

Qui valide le chiffre

Les dirigeants qui présentent des chiffres qu’ils n’ont pas calculés eux-mêmes et veulent une réponse défendable à « d’où vient ce chiffre ? ». Les équipes finance qui rapprochent des métriques générées par IA du grand livre avant toute diffusion externe. Les analystes à qui l’on demande de valider une réponse d’analytique conversationnelle et qui ont besoin d’une liste de contrôle plus rapide que de refaire le travail de zéro — mais tout aussi rigoureuse.

Pourquoi lire la requête est nécessaire mais pas suffisant

Une réponse vérifiable est une réponse livrée avec ses preuves — la requête exacte qui s’est exécutée, les tables qu’elle a lues et ce qui est revenu. C’est la propriété de base, et ce que signifie l’analytique conversationnelle vérifiable en défend le principe. Mais les preuves ne servent que si vous savez quoi contrôler. Une requête peut être syntaxiquement parfaite, s’exécuter sans erreur et calculer malgré tout la mauvaise chose : elle peut lire une question ambiguë autrement que vous ne l’entendiez, retenir une définition de métrique défendable mais fausse, ou multiplier discrètement les lignes par une jointure. Comment un texte devient du SQL explique pourquoi une même question peut honnêtement produire des requêtes différentes ; ce guide porte sur une autre décision : la requête que vous avez obtenue est-elle celle sur laquelle votre chiffre pour le conseil doit reposer ?

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

Déroulez-les dans l’ordre. Les étapes un à six lisent la requête et ses sources ; les étapes sept et huit lisent le résultat et l’enregistrement de l’exécution.

1. 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.

2. 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.

3. 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.

4. 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 que le nombre de lignes n’explose pas au passage d’une jointure.

5. 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.

6. 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.

7. 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 table clients dont vous savez qu’elle contient des milliers de lignes ne doit pas en renvoyer douze, 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.

8. 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, considérez le résultat comme tronqué : 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.

Un exemple concret : le piège des remboursements

L’exemple ci-dessous utilise le schéma de démonstration d’un distributeur fictif — customers, orders, order_items — et chaque chiffre qu’il contient est inventé à titre d’illustration, ce n’est pas la sortie d’un système réel.

La question est : « Quel a été notre chiffre d’affaires au T2 2026 ? » Voici deux requêtes qu’un modèle pourrait raisonnablement générer. Les deux sont du SQL valide, les deux sont des lectures, les deux s’exécutent sans erreur — et elles répondent à des questions différentes.

La variante A somme toutes les commandes du trimestre, quel que soit leur statut :

SELECT SUM(oi.quantity * oi.unit_price) AS revenue_q2
FROM orders AS o
JOIN order_items AS oi ON oi.order_id = o.order_id
WHERE o.ordered_at >= DATE '2026-04-01'
  AND o.ordered_at < DATE '2026-07-01';

La variante B ne compte que les commandes honorées, en excluant les commandes remboursées et annulées :

SELECT SUM(oi.quantity * oi.unit_price) AS revenue_q2
FROM orders AS o
JOIN order_items AS oi ON oi.order_id = o.order_id
WHERE o.status = 'completed'
  AND o.ordered_at >= DATE '2026-04-01'
  AND o.ordered_at < DATE '2026-07-01';

Sur les données de démonstration, la variante A renvoie 1 284 650 et la variante B renvoie 1 209 410 — un écart de 75 240, qui correspond exactement aux commandes remboursées et annulées. Aucune des deux requêtes n’est cassée ; la différence est définitionnelle. Si la finance définit le chiffre d’affaires comme les commandes honorées nettes des remboursements et que la présentation porte le chiffre de la variante A, le chiffre est faux d’une manière qu’aucun validateur ne peut détecter — seule l’étape deux du processus l’attrape, et seulement si quelqu’un l’exécute.

Le même schéma, avec une jointure qui gonfle le total

L’étape quatre est plus difficile à repérer que l’étape deux, parce que la requête se lit toujours correctement. La variante C pose la même question, mais somme une colonne qui vit sur orders plutôt que sur order_items :

SELECT SUM(o.order_total) AS revenue_q2
FROM orders AS o
JOIN order_items AS oi ON oi.order_id = o.order_id
WHERE o.status = 'completed'
  AND o.ordered_at >= DATE '2026-04-01'
  AND o.ordered_at < DATE '2026-07-01';

La jointure produit une ligne par article, donc une commande de quatre lignes contribue quatre fois pour son total. Sur les données de démonstration, la variante C renvoie 4 031 180 — plus du triple de la variante B — et le nombre de lignes dit pourquoi : l’agrégat est construit sur 7 190 lignes d’articles pour 2 180 commandes, soit une moyenne de 3,3 lignes chacune. Dès qu’une somme porte sur une colonne dont la granularité est plus grossière que celle produite par la jointure, le chiffre est gonflé à peu près de cette moyenne.

Deux contrôles l’attrapent. Comparez le nombre de lignes à la granularité attendue : 7 190 lignes pour 2 180 commandes, c’est que chaque commande a été comptée plusieurs fois. Et contrôlez l’ordre de grandeur — un trimestre qui triple d’une année sur l’autre est bien plus souvent un bug de requête qu’un résultat commercial.

Signaux d’alerte qui doivent arrêter un chiffre à la porte

Signal d’alerte	Ce qu’il suggère
Une réponse sans requête visible	Vous ne pouvez exécuter aucune des étapes un à six ; le chiffre est invérifiable par construction
Un nombre de lignes très éloigné de l’attendu	Mauvaise table, filtre trop agressif, ou jointure qui a supprimé ou multiplié des lignes
Un nom de métrique sans définition	« Chiffre d’affaires » ou « utilisateurs actifs » sans que le brut ou le net, les statuts ou les fenêtres soient explicités — l’étape deux n’a jamais eu lieu
Un nombre suspectement rond	Troncature possible par une limite de lignes, un résultat plafonné, ou un agrégat sur des données partielles
Une jointure qui multiplie les lignes	Des montants au niveau de la commande sommés par ligne d’article — le gonflement classique par fan-out de l’étape quatre

L’un d’eux suffit à marquer une pause ; deux ou plus, c’est une raison de reposer la question et de tout revérifier depuis le début.

D’où viennent les preuves

Le processus paraît long, mais avec les bonnes preuves attachées à la réponse, la plupart des étapes sont une courte lecture plutôt qu’une enquête.

Preuve livrée avec la réponse	Étapes qu’elle traite
La requête exacte qui s’est exécutée	1, 2, 4, 5, 6 — interprétation, définition, jointures, filtres et gestion du temps sont tous visibles dans le texte SQL
Les tables sources	3 — vous voyez immédiatement si les tables canoniques ont été lues
Le nombre de lignes	4 et 7 — un fan-out se voit à un nombre invraisemblable ; un résultat trop filtré aussi
Le temps d’exécution	7 — un signal d’appui indiquant que la requête a parcouru à peu près les données attendues
L’exécution enregistrée, étape par étape	8 — reprises, troncature par limite de lignes et avertissements figurent dans l’enregistrement de l’exécution, avec la possibilité de rouvrir et de revérifier le tout plus tard

Le schéma mérite d’être nommé : les étapes un à sept se traitent en une seule fois à partir de quatre éléments de preuve, à condition que l’outil les livre avec chaque réponse plutôt que sur demande.

Quel niveau de vérification un chiffre exige

Tous les chiffres ne méritent pas la même attention. Pour une question opérationnelle — « combien de commandes sont arrivées hier ? » — un coup d’œil à la requête et un contrôle d’ordre de grandeur (étapes un et sept) constituent une revue proportionnée. Pour un chiffre destiné à une présentation au conseil, à une communication aux investisseurs ou à un dépôt réglementaire, déroulez les huit étapes, et faites relire la requête et les preuves par une deuxième personne, de façon indépendante, avant que le chiffre parte. Le jugement d’escalade — quels chiffres sont sensibles, quelles sont les définitions canoniques, quand un chiffre demande un second regard — reste humain. L’outillage de vérification raccourcit le contrôle ; il ne remplace pas les analystes et les responsables financiers qui décident de ce que veut dire « juste ».

Lire le panneau de preuves

Datarelix attache par défaut à chaque réponse les entrées du processus ci-dessus : la requête exécutée, les tables sources, le nombre de lignes et le temps d’exécution — ce que chacun des quatre vous apprend. Chaque exécution est enregistrée étape par étape et réouvrable depuis l’historique, de sorte que l’étape huit et toute revérification ultérieure travaillent sur l’enregistrement plutôt que sur la mémoire. Quand une réponse vérifiée devient un tableau de bord, il se rafraîchit à partir de la même logique de requête : la définition que vous avez vérifiée est celle qui continue de tourner. Le fonctionnement de la lecture d’un résultat et de ses preuves est détaillé dans le guide des requêtes.

Ce que les huit étapes ne détectent pas

Ce processus vérifie ce qui a été mesuré, pas si les données sous-jacentes sont justes — si les remboursements arrivent dans l’entrepôt avec trois jours de retard, une requête parfaitement vérifiée rapporte quand même un chiffre qui dérivera. Il ne peut pas non plus fournir vos définitions : savoir si le chiffre d’affaires est net des remboursements est une décision de la finance, et le processus contrôle seulement que la requête est d’accord avec une définition que quelqu’un a déjà arrêtée. L’étape du second relecteur demande une réserve pratique : le relecteur travaille à partir de la requête et des preuves que vous lui transmettez, collées dans des notes de revue ou un ticket, parce que les comptes sont isolés (isolation des comptes). Et pour une analyse réellement inédite, à fort enjeu, reposant sur de lourdes hypothèses de modélisation, vérifier une seule requête ne suffit pas ; ce travail revient à un analyste de bout en bout, les outils conversationnels n’en étant qu’une des entrées.

À propos de l’exemple concret

Les affirmations produit de ce guide décrivent Datarelix tel que livré ; la page sécurité fait foi pour les frontières de validation, de gestion des identifiants, d’isolation et d’enregistrement des exécutions évoquées ici. Tous les exemples SQL et tous les chiffres utilisent le schéma de démonstration d’un distributeur fictif (customers, orders, order_items) et sont des inventions illustratives, pas des sorties capturées sur un système réel. Aucune citation externe, aucun benchmark et aucun exemple client ne sont utilisés.

En faire une habitude durable

Faites des huit étapes une habitude d’évaluation permanente : la checklist sécurité de l’analytique IA prolonge ce processus par réponse en une série de questions à poser à n’importe quel outil avant de le connecter à une vraie base de données.