Prompt pour écrire une requête SQL

Pourquoi le SQL généré par IA casse souvent à la première exécution

Une IA peut écrire du SQL syntaxiquement parfait et te livrer quand même une requête qui échoue ou, pire, qui renvoie des chiffres silencieusement faux. La raison est presque toujours le contexte, pas la compétence. Quand tu demandes une requête sans décrire tes tables, le modèle invente un schéma plausible : il suppose que ta table d’utilisateurs a un id et un created_at, que les commandes se relient par user_id, et qu’une colonne de statut existe. Parfois il a raison. Souvent la colonne est en réalité customer_id, ou la date est stockée comme du texte, ou il n’y a aucune colonne de statut. Le prompt ci-dessus règle ça à la source en t’imposant de coller ton schéma réel ou tes instructions CREATE TABLE. Une fois que le modèle peut voir les vrais noms et types de colonnes, il arrête de deviner et commence à faire correspondre la requête à ta base de données.

Le dialecte n’est pas un détail

SQL est une famille de langages, pas un seul langage. Une requête qui fonctionne sur PostgreSQL peut échouer sur MySQL parce que les fonctions diffèrent. La concaténation de chaînes utilise || sur Postgres mais CONCAT() sur MySQL. L’arithmétique des dates, LIMIT face à TOP, le support des fonctions de fenêtrage, et ILIKE pour les correspondances insensibles à la casse, tout varie selon le moteur. C’est pourquoi le prompt te demande d’indiquer le dialecte dès le début. Dire au modèle « c’est BigQuery » ou « c’est SQL Server » change les fonctions vers lesquelles il se tourne et évite la frustrante boucle de coller une erreur, recevoir un correctif et tomber sur le problème spécifique au dialecte suivant. Si tu n’es pas sûr de ton moteur, ça vaut la peine de vérifier avant de générer quoi que ce soit, parce que ça façonne chaque choix de fonction dans le résultat.

Les JOIN explicites et la gestion des NULL séparent le correct du plausible

L’instruction d’utiliser des JOIN explicites avec des alias clairs vise à la fois la correction et la lisibilité. Les jointures de style virgule avec une clause WHERE gigantesque cachent la logique de jointure et facilitent la production involontaire d’un produit cartésien. Les mots-clés explicites INNER JOIN et LEFT JOIN forcent à énoncer la relation clairement, et choisir entre eux compte : un inner join écarte silencieusement les lignes sans correspondance, donc un rapport « clients et leurs commandes » écrit avec le mauvais type de jointure exclura silencieusement les clients qui n’ont jamais commandé. L’exigence de gérer les NULL de façon sûre attrape l’autre piège classique : les comparaisons et agrégations se comportent de façon inattendue autour de NULL. Un filtre comme WHERE status != 'closed' exclura les lignes où status est NULL, ce qui est rarement ce que tu veux. Nommer ces préoccupations dans le prompt fait que le modèle raisonne dessus au lieu de prendre le chemin facile par défaut.

La note d’hypothèses est ton filet de sécurité

L’exigence finale — une explication d’une ligne plus toute hypothèse — est ce qui transforme une réponse de boîte noire en quelque chose à quoi tu peux te fier. Quand le modèle écrit « en supposant que chaque commande appartient à exactement un client et que les remboursements sont exclus », tu peux confirmer ou corriger cette logique immédiatement avant d’exécuter quoi que ce soit. L’ambiguïté est d’où viennent les rapports erronés, et la faire remonter en langage simple est bien moins cher que de déboguer une requête qui s’est exécutée avec succès mais a compté la mauvaise chose. Lis toujours cette note, et teste toujours la requête sur un petit échantillon avant de la pointer vers des données de production.

Pourquoi ce prompt fonctionne

Le SQL de l’IA échoue quand il devine ton schéma ou ton dialecte. Ce prompt apporte les deux plus l’objectif exact, pour que la requête corresponde à tes vraies tables et fonctionne sur ton moteur, et la note d’hypothèses attrape les ambiguïtés avant qu’elles ne causent des résultats erronés.

Comment le personnaliser

• Colle ton schéma réel pour que les noms de colonnes soient corrects.
• Indique le dialecte ; les fonctions diffèrent entre bases de données.
• Teste sur un échantillon avant d’exécuter sur des données de production.

Variantes de prompt à essayer

Optimiser une requête lente existante

Tu es ingénieur de performance de bases de données senior. Voici une requête SQL lente sur [base de données : PostgreSQL/MySQL/etc] :
[colle la requête]
Schéma et comptages approximatifs de lignes :
[colle tables, colonnes, index et comptages de lignes]
Réécris-la pour qu’elle s’exécute plus vite. Explique ce qui était lent (p. ex. index manquant, fonction sur une colonne indexée, sous-requête inutile), suggère tout index à ajouter, et confirme que la réécriture renvoie des résultats identiques. Garde le dialecte correct.

Expliquer ce que fait une requête

Tu es tuteur SQL. Explique cette requête [dialecte de base de données] en langage simple, étape par étape :
[colle la requête]
Décris ce que fait chaque JOIN, filtre et agrégation, à quoi ressemble l’ensemble de résultats, et signale tout cas limite ou bug que tu remarques (comme la gestion des NULL ou une jointure qui pourrait écarter des lignes). Suppose que je suis à l’aise avec le SQL de base mais pas avec cette requête.

Convertir une requête entre dialectes

Convertis cette requête SQL du [dialecte source] au [dialecte cible] :
[colle la requête]
Remplace toute fonction spécifique au dialecte, gestion de dates, opérations de chaînes et syntaxe (comme LIMIT face à TOP) par les équivalents corrects. Énumère chaque changement que tu as fait et pourquoi, et signale tout ce qui n’a pas d’équivalent direct et nécessite une solution de contournement.

Erreurs courantes à éviter

• Ne pas coller le schéma réel. Sans tes vrais noms de table et colonne, l’IA les invente et la requête échoue ou référence des colonnes inexistantes. Colle toujours les instructions CREATE TABLE ou une liste de colonnes.
• Sauter le dialecte. Les fonctions diffèrent entre moteurs, donc une requête pour une base peut donner une erreur sur une autre. Indique MySQL, PostgreSQL, SQL Server, ou ce que tu utilises vraiment.
• Utiliser un INNER JOIN quand tu voulais conserver les lignes sans correspondance. Un inner join écarte silencieusement les enregistrements sans correspondance ; utilise un LEFT JOIN et COALESCE quand tu as besoin de chaque ligne de la table principale.
• Ignorer les NULL dans les filtres. Une condition comme status != 'closed' exclut les lignes où status est NULL. Décide explicitement avec IS NULL / IS NOT NULL ou COALESCE.
• Se fier à la requête sans la tester. Même le SQL d’apparence correcte peut compter la mauvaise chose. Lis la note d’hypothèses, puis exécute-la sur un petit échantillon avant de toucher les données de production.

Questions fréquentes

Ai-je vraiment besoin de coller tout mon schéma ?

Pourquoi la même requête échoue sur MySQL mais fonctionne sur PostgreSQL ?

Est-il sûr d’exécuter du SQL généré par IA en production ?

L’IA peut-elle m’aider à accélérer une requête lente ?

Astuce : remplace les parties entre [crochets] par tes propres informations avant d’envoyer. Plus tu es précis — public, ton, objectif, contraintes — meilleur sera le résultat de l’IA.