Vérifier une requête SQL générée par l'IA

Une requête SQL (langage de requête structuré) écrite par une IA se vérifie en quatre temps : l'afficher, la relire avec votre question en tête, la tester sur une réponse que vous connaissez, recouper le résultat par un autre chemin. Une requête qui s'exécute sans erreur n'est pas pour autant une requête juste. Google le dit sans détour dans la documentation de Data Studio (anciennement Looker Studio) : l'outil peut produire des résultats plausibles mais factuellement inexacts, et toutes les sorties doivent être validées.

1. Afficher la requête

Ne vous contentez pas du tableau ou du graphique. Selon leur documentation, lue le 15/11/2026 :

Un outil qui ne montre ni la requête ni le détail du calcul ne se vérifie que par recoupement. Gardez-le pour des questions à faible enjeu.

2. Relire : la liste de contrôle

Reprenez votre question mot à mot et cherchez chaque mot dans la requête.

1. La table (FROM) : est-ce la table des factures, des commandes ou des devis ? Elles ne donnent pas le même chiffre d'affaires.
2. La période (WHERE … date …) : bonne colonne de date, bonnes bornes. « Octobre » doit aller du 01/10 inclus au 01/11 exclu.
3. Le statut : les commandes annulées, les devis refusés, les avoirs sont-ils exclus ? Un mot de votre question absent de la requête est un signal d'alerte.
4. La valeur exacte des filtres : si la base écrit ENVOYE et que la requête cherche 'envoyé', elle ne trouvera rien et répondra zéro.
5. La jointure (JOIN) : la documentation de PostgreSQL rappelle qu'une jointure simple ne garde que les lignes qui ont une correspondance des deux côtés. Pour « les clients sans commande », il faut une jointure externe (LEFT JOIN).
6. Le doublement : relier une table à une autre peut multiplier les lignes. Un total qui paraît deux ou trois fois trop haut vient souvent de là.
7. Le calcul (sum, count, avg) : additionne-t-on des montants hors taxes ? Compte-t-on des clients (avec DISTINCT) ou des commandes ?
8. Le tri et la limite : PostgreSQL prévient qu'un LIMIT sans ORDER BY renvoie un sous-ensemble imprévisible. « Top 10 » sans tri ne veut rien dire.
9. Le type de requête : elle doit commencer par SELECT (ou WITH). Un UPDATE, DELETE, INSERT ou DROP modifie la base : arrêtez-vous et lisez cette page.

Si l'un de ces mots vous est étranger, comprendre une requête SQL les traduit un par un.

3. Tester sur une réponse connue

Avant de poser une question nouvelle, posez-en une dont vous avez la réponse :

• le chiffre d'affaires d'un mois clos, que votre comptable vous a donné ;
• le nombre de clients actifs affiché par votre logiciel ;
• le nombre de commandes d'une journée que vous avez comptée.

Si l'outil retrouve ces chiffres, ses requêtes sur ces tables méritent un début de confiance. Sinon, la requête vous montre où il se trompe : souvent une colonne mal comprise, que vous corrigerez dans votre dictionnaire de données.

4. Recouper le résultat

• Comptez les lignes : l'outil annonce 42 clients inactifs ? Un filtre manuel dans votre logiciel doit en trouver à peu près autant.
• Ouvrez trois ou quatre lignes du résultat et vérifiez-les une par une dans le logiciel.
• Regardez les extrêmes : le plus gros client, le mois le plus faible. Une erreur de période ou de jointure s'y voit souvent.
• Reposez la question autrement : deux formulations, deux requêtes, deux résultats. S'ils diffèrent, comparez les requêtes.

Les erreurs typiques et leur signe

Adapter l'effort à l'enjeu

Une question de curiosité mérite une relecture rapide. Un chiffre transmis à un client, une banque ou un associé mérite la liste complète, un recoupement, et une deuxième paire d'yeux. Microsoft le rappelle à propos de Copilot dans Power BI : le comportement de l'IA n'est pas déterministe, la même entrée ne donne pas toujours la même réponse.

Pour la méthode générale, valable aussi pour les documents, voyez comment vérifier une réponse de l'IA sur NL-Q.