Comment auditer une requête SQL générée par l’IA avant de l’utiliser

Pourquoi une requête qui s’exécute peut être erronée

Une requête SQL générée par l’IA peut être analysée, exécutée et renvoyer des lignes sans pour autant répondre correctement à la question métier. La base de données exécute les opérations demandées ; elle ne sait pas si une somme correspond à l’indicateur que l’équipe appelle « chiffre d’affaires », si la période retenue est la bonne ou si une jointure a dupliqué des enregistrements. Une syntaxe correcte permet l’exécution, mais ne prouve pas que la logique est juste.

Le risque tient souvent à des choix plausibles qui passent inaperçus : joindre des tables avec une mauvaise clé, appliquer un filtre qui n’a pas été demandé, agréger des valeurs après avoir multiplié les lignes ou traiter les valeurs NULL de façon inattendue. Avant l’exécution, il faut pouvoir expliquer ce que représente chaque ligne et pourquoi chaque condition figure dans la requête. Ensuite, il faut comparer le résultat à une référence qui ne dépend pas de la même génération par IA.

Ce protocole porte sur les requêtes analytiques appliquées aux bases relationnelles. Il ne remplace ni la définition des règles métier ni un examen complet de la sécurité. Il propose une démarche pratique : préciser la question, inspecter statiquement le SQL, effectuer un test de portée limitée et valider la sortie. Un accès en lecture seule réduit les dommages possibles, mais ne garantit pas à lui seul l’exactitude des résultats.

Étape 1 : convertir la question métier en critères vérifiables

Avant d’examiner le SQL, précisez le sens de la demande. « Ventes du trimestre par client » laisse plusieurs points en suspens : s’agit-il des ventes brutes ou nettes ? Des commandes créées ou terminées ? Quelles dates délimitent le trimestre ? Les retours sont-ils déduits ? Quel fuseau horaire faut-il appliquer ? Si ces choix ne sont pas documentés, une requête apparemment raisonnable risque de répondre à une autre interprétation.

Rédigez une spécification courte qui indique l’indicateur, l’unité d’analyse, la période, les filtres et le niveau de regroupement. Identifiez aussi la source faisant autorité pour chaque donnée. Par exemple, si le montant total se trouve dans l’en-tête de commande et les produits dans une table de détail, indiquez explicitement que l’indicateur doit conserver une ligne logique par commande avant la somme. L’IA ne doit pas compléter silencieusement des règles que l’équipe n’a pas encore définies.

Clarifiez le schéma réel et le dialecte SQL. Vérifiez les tables, les colonnes, les types, les clés et les relations documentées dans la base de données ou le dictionnaire des données ; ne vous fiez pas à des noms qui semblent plausibles. Dans une intégration de langage naturel vers SQL, le schéma et les règles fournis au modèle constituent un contexte utile, mais sa sortie doit encore être contrôlée dans le code et sur le moteur cible. Microsoft Learn présente, par exemple, une génération de SQL avec des valeurs paramétrées ainsi qu’un contrôle ultérieur des requêtes interdites ; la documentation précise également que les instructions données au modèle ne remplacent pas la planification des mesures de sécurité.

Si une définition indispensable manque, suspendez l’examen et demandez des précisions à la personne responsable de l’indicateur. Ajouter une condition inventée pour « faire fonctionner » la requête ne résout pas l’ambiguïté : cela la transforme en décision difficile à repérer par la suite.

Étape 2 : inspection statique avant l’exécution

Lisez la requête de l’extérieur vers l’intérieur et repérez chaque table, JOIN, filtre, agrégation, sous-requête et fonction de fenêtre. Comparez les objets au schéma réel. Suivez ensuite le parcours des lignes : quelle relation chaque JOIN introduit-il ? Quelles conditions éliminent des enregistrements ? À quel moment la granularité change-t-elle ? Ne validez pas une condition simplement parce que son nom vous semble familier.

Les JOIN méritent une attention particulière. Vérifiez que les clés utilisées représentent la bonne relation et déterminez sa cardinalité : un-à-un, un-à-plusieurs ou plusieurs-à-plusieurs. Si une table contient une ligne par commande et une autre une ligne par article, les joindre peut répéter le montant de l’en-tête pour chaque article. Additionner ensuite le montant de la commande peut gonfler le total sans générer d’erreur de syntaxe. Ajouter DISTINCT après coup ne prouve pas que la logique est corrigée.

Comparez chaque filtre à la spécification. Vérifiez les états, les dates, les limites inclusives ou exclusives ainsi que les conditions portant sur NULL. Demandez-vous si la requête écarte des enregistrements qui devraient compter ou en inclut d’autres qui ne devraient pas l’être. Dans une condition telle que `colonne = valeur`, NULL ne se comporte pas comme une valeur ordinaire : son traitement doit être défini, et non supposé.

Examinez les agrégations et les fonctions de fenêtre en vous posant une question précise : sur quel ensemble de lignes chaque valeur est-elle calculée ? Vérifiez que les colonnes sélectionnées et regroupées correspondent au niveau attendu. Pour les sous-requêtes imbriquées, notez quelles lignes chaque niveau renvoie et comment il se relie au suivant. Enfin, confirmez que les fonctions et la syntaxe correspondent au dialecte du moteur cible.

Étape 3 : limiter la portée et exécuter dans un environnement contrôlé

La première exécution doit avoir lieu hors production, dans la mesure du possible : dans une base de test isolée contenant des données synthétiques ou dans une copie anonymisée, actualisée conformément aux règles de l’organisation. Les données synthétiques permettent de construire des cas délibérés — y compris des doublons, des valeurs NULL et des dates limites — sans exposer de vrais enregistrements. Une copie anonymisée peut mieux reproduire la distribution des données, mais il faut vérifier que l’anonymisation est appropriée et que la copie ne dispose pas de droits d’écriture sur la production.

Configurez la connexion avec le principe du moindre privilège. Pour un test de requête, utilisez une identité en lecture seule et limitez l’accès aux tables ou vues nécessaires. Vérifiez aussi les contraintes de ressources : durée maximale, nombre de lignes et possibilité d’annuler l’exécution. Une requête en lecture seule peut tout de même consommer trop de ressources ou renvoyer des données auxquelles l’utilisateur ne devrait pas accéder ; sécurité et exactitude sont liées, mais restent deux contrôles distincts.

N’exécutez pas du SQL généré par l’IA sans validation côté application. Les instructions du prompt peuvent orienter le modèle, mais ne constituent pas une limite de sécurité. N’autorisez que les opérations et objets prévus, validez les paramètres et utilisez des requêtes paramétrées pour les valeurs. Microsoft Learn décrit un exemple dans lequel le serveur passe les chaînes comme paramètres et vérifie la requête avant de l’exécuter ; la liste des mots interdits présentée à titre d’exemple n’est pas une défense complète que l’on pourrait appliquer sans l’adapter.

Commencez par la portée minimale permettant de tester la logique : une entité connue, une période courte ou un petit échantillon. Si vous devez examiner un plan d’exécution, faites-le dans un environnement autorisé et tenez compte du coût. L’objectif n’est pas de prouver que la requête peut s’exécuter sur toute la base, mais de vérifier les hypothèses pertinentes sans risque avant d’élargir la portée.

Étape 4 : tester sur des cas connus et comparer les résultats

Un résultat plausible ne constitue pas une référence. La validation doit utiliser des cas dont le résultat peut être anticipé sans demander au même modèle de confirmer sa propre requête. Préparez de petits exemples aux résultats calculables, des enregistrements situés aux limites de la période, des entités avec ou sans relation et des lignes contenant des valeurs NULL lorsque cela est pertinent. Avec des données synthétiques, ces conditions peuvent être définies précisément.

Comparez le résultat à une source de référence autorisée : une requête simplifiée examinée par une personne, un rapport dont la définition correspond à la spécification ou un calcul manuel réalisé sur un petit ensemble. Assurez-vous que les deux méthodes utilisent la même période, les mêmes filtres, les mêmes règles d’exclusion et la même granularité. Deux requêtes qui diffèrent sur ces points ne sont pas comparables, même si elles utilisent le même nom d’indicateur.

Validez à la fois la structure et les valeurs. Vérifiez le nombre de lignes, les clés dupliquées, les totaux par groupe et les cas limites. Si le résultat doit contenir une ligne par client, vérifiez cette unicité ; s’il est regroupé par mois, examinez les mois sans activité et les limites de date. En cas d’écart, réduisez le cas : examinez d’abord les lignes avant le JOIN, puis après chaque jointure, et enfin après les filtres et les agrégations. Vous pourrez ainsi repérer l’étape où le chiffre change.

La validation croisée ne transforme pas un test limité en garantie universelle. Un cas connu peut confirmer que la requête fonctionne dans cette situation, mais pas nécessairement pour toutes les périodes ou combinaisons de données. Transformez en tests de régression les cas qui ont révélé des erreurs, afin de vérifier que de futures modifications ne réintroduisent pas le même problème.

Erreurs, résultats vides et ambiguïtés

Une erreur de syntaxe signifie que le moteur ne peut pas interpréter la requête, mais sa correction ne valide pas la logique. Vérifiez le dialecte, les noms et les types avant de demander une nouvelle génération. Si vous demandez une correction, décrivez l’erreur précise et conservez les conditions métier déjà vérifiées ; ne vous contentez pas de dire « corrige-la », car la réponse peut modifier d’autres parties de la requête.

Un résultat vide peut avoir plusieurs causes : un filtre trop restrictif, des différences de casse ou de format, une date incorrecte, une relation qui exclut certaines lignes ou l’absence réelle de correspondances. Dans l’environnement de test, examinez chaque condition séparément. Ne supprimez pas automatiquement des filtres pour obtenir des résultats : vous risqueriez de remplacer un problème d’interprétation par une requête qui inclut des données hors périmètre.

Si le modèle ne peut pas expliquer l’origine d’une table, d’une relation ou d’une règle, considérez cet élément comme non vérifié. Reformulez la question en ajoutant la définition manquante ou demandez des précisions à la personne responsable de l’indicateur. Les explications du modèle peuvent aider à comprendre la proposition, mais ne constituent pas une preuve indépendante de son exactitude.

En cas d’écart entre le SQL et la référence, conservez la requête, les paramètres, la version du schéma, le cas de test et le résultat observé, dans le respect des protections de confidentialité applicables. Corrigez la cause, et pas seulement la valeur visible. Recommencez ensuite les contrôles concernés et ajoutez un test de régression si le problème risque de se reproduire.

Liste de contrôle finale avant d’intégrer la requête

Avant d’utiliser du SQL généré par l’IA dans une analyse ou un pipeline, vérifiez que la question d’origine est définie de manière vérifiable, que chaque table, colonne et relation existe dans le schéma, et que les JOIN préservent la granularité nécessaire. Examinez les filtres, les agrégations, NULL, les dates, les fonctions et le dialecte. Assurez-vous également que la requête a été testée dans un environnement autorisé, avec des données adaptées et des permissions en lecture seule lorsque le cas le permet.

La sortie doit passer un contrôle indépendant fondé sur des cas connus ou des données de référence comparables. Si le contrôle échoue, ne présentez pas le résultat comme confirmé. Corrigez la requête ou reformulez la demande, répétez les tests et consignez la version approuvée ainsi que son périmètre. Cette liste ne dispense pas d’une expertise spécialisée pour les indicateurs à fort impact, les données sensibles ou les requêtes complexes.

La règle pratique est simple : une requête n’est prête que lorsqu’elle est compréhensible, limitée aux accès autorisés et qu’elle produit des résultats cohérents lors de tests représentatifs de la question métier. Si l’une de ces conditions ne peut pas être démontrée, maintenez l’incertitude et demandez une vérification avant utilisation.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.