Génération de requêtes SQL
Produire en quelques minutes des requêtes SQL complexes (jointures multiples, CTE, fonctions analytiques) qui prendraient 30-60 min en écriture manuelle.
Les data scientists et analysts passent 30 à 50 % de leur temps à écrire du SQL : exploration, agrégations, jointures, fenêtres analytiques. L'IA générative peut produire en quelques secondes des requêtes que vous auriez mis 30-60 minutes à écrire et à débugger. Le piège : le SQL généré peut être syntaxiquement correct mais sémantiquement faux (mauvaise jointure, doubles comptages, NULL mal gérés). Ce guide présente le workflow rigoureux qui maximise la productivité tout en évitant les erreurs invisibles qui faussent les résultats business.
Workflow étape par étape
Décrire le schéma à l'IA
Fournir les tables impliquées avec leurs colonnes principales, types et relations (PK/FK). Sans schéma, l'IA invente des noms de colonnes plausibles mais inexistants. Idéalement coller un DDL ou un dictionnaire de tables.
Formuler la question business clairement
Pas « écris-moi un SELECT », mais « pour chaque client actif depuis plus de 6 mois, calcule le revenu cumulé sur les 12 derniers mois et le pourcentage de croissance vs les 12 mois précédents ». Plus la question est claire, meilleure est la requête.
Préciser la BDD cible et ses spécificités
Postgres, BigQuery, Snowflake, Redshift, MySQL : les fonctions analytiques et la syntaxe diffèrent. Préciser permet d'avoir une requête optimisée pour votre dialecte.
Tester sur un échantillon avant production
Limiter à WHERE date >= '2025-01-01' AND id < 1000 pour valider rapidement. Comparer avec un cas connu (compté à la main) pour vérifier la cohérence des résultats.
Itérer pour optimiser
Si la requête est lente : faire suggérer par l'IA des optimisations (indexes manquants, CTE matérialisées, JOIN order). Toujours vérifier le plan d'exécution (EXPLAIN) avant de mettre en prod.
Prompts copiables
5 prompts testés et optimisés. Adaptez les variables entre crochets [VARIABLE] à votre contexte.
Génération de requête SQL business
Tu es expert SQL en [POSTGRES / BIGQUERY / SNOWFLAKE / REDSHIFT / MYSQL]. Voici mon schéma : [TABLES + COLONNES + RELATIONS] Question business : [QUESTION DÉTAILLÉE] Écris une requête qui : - Utilise les bons JOIN (en étant explicite sur INNER vs LEFT) - Gère les NULL correctement - Évite les doubles comptages - Utilise des CTE nommées pour la lisibilité - Inclut des commentaires sur les choix non triviaux Fournis : (1) la requête, (2) une explication en 3-5 lignes des choix, (3) un résultat attendu sur quelques lignes pour validation.
Debug d'une requête lente
Cette requête tourne en [DURÉE] sur [VOLUME] de données : [REQUÊTE] Schéma : [TABLES + INDEXES EXISTANTS] Plan d'exécution : [EXPLAIN ANALYZE OUTPUT] Propose : 1. **Diagnostic** : où sont les goulots (full scan, mauvais JOIN order, manque d'index) ? 2. **3 optimisations** par ordre d'impact attendu, avec la requête modifiée pour chacune 3. **Indexes à créer** si pertinent (avec syntaxe CREATE INDEX) 4. **Risques** : impact sur écritures, espace disque, locks Cible : passer sous [SLA SOUHAITÉ].
Conversion entre dialectes SQL
Convertis cette requête de [DIALECTE_SOURCE] vers [DIALECTE_CIBLE] : [REQUÊTE SOURCE] Garde la même logique business mais adapte : - Fonctions de date (DATE_TRUNC, EXTRACT, etc.) - Fonctions analytiques (window functions) - Syntaxe des CTE - Gestion des types (TIMESTAMP, JSON, ARRAY) - Particularités du dialecte cible (LATERAL, QUALIFY, etc.) Fournis la requête convertie + les 3 différences principales que tu as dû gérer.
Détection d'erreurs sémantiques
Audite cette requête SQL pour des erreurs SÉMANTIQUES (pas juste syntaxiques) : [REQUÊTE] Schéma : [TABLES + COLONNES + CARDINALITÉS APPROX] Question business attendue : [QUESTION] Vérifie : 1. **Cardinalité des JOIN** : risque de doubles comptages ? 2. **Gestion des NULL** : COUNT(col) vs COUNT(*), AVG sur NULL, etc. 3. **Filtres** : WHERE vs ON dans LEFT JOIN, ordre des conditions 4. **Agrégations** : GROUP BY cohérent, HAVING vs WHERE 5. **Edge cases** : que se passe-t-il si une dimension n'a aucune fact ? si plusieurs facts par dimension ? Pour chaque problème : (a) ligne concernée, (b) explication, (c) correction.
Génération de requête analytique avec window functions
Pour [QUESTION ANALYTIQUE — ex : top 3 produits par catégorie en revenu, classement utilisateurs par mois, etc.] Schéma : [TABLES] Écris une requête utilisant des __window functions__ (ROW_NUMBER, RANK, DENSE_RANK, LAG, LEAD, SUM OVER...) optimale pour [DIALECTE]. Explique en 3 points : (1) pourquoi window plutôt que sous-requête corrélée, (2) le PARTITION BY et ORDER BY choisis, (3) les performances attendues. Inclus un exemple de résultat.
Top outils pour ce cas d'usage
Sélection commentée des 3 meilleurs outils IA pour génération de requêtes sql.
Pourquoi pour ce cas d'usage : Excellence sur le SQL complexe et les fonctions analytiques. Comprend les subtilités sémantiques mieux que les concurrents.
Pourquoi pour ce cas d'usage : Solide sur tous les dialectes courants, particulièrement bon pour la conversion entre BDD.
Pourquoi pour ce cas d'usage : Si vous travaillez sur des fichiers SQL versionnés (dbt, scripts de migration), Cursor donne du contexte projet à l'IA.
ROI estimé
Temps gagné
60-70% sur la rédaction de requêtes complexes
Gain qualité
Détection d'erreurs sémantiques en pré-prod
Coût stack
Inclus dans abonnement Claude Pro / ChatGPT Plus (20-30€/mois)
Estimations basées sur des benchmarks 2026 et retours d'utilisateurs. Le ROI réel dépend de votre contexte.
Questions fréquentes
L'IA gère-t-elle bien tous les dialectes SQL ?
Postgres, MySQL, BigQuery, Snowflake, Redshift : très bien. SQL Server (T-SQL) : bien, avec parfois des oublis sur des syntaxes propriétaires. Oracle (PL/SQL) : correct mais demande plus de vérification. DuckDB, SQLite : bien sur le SQL standard, parfois confus sur les extensions.
Peut-on faire du SQL sur des données sensibles avec ChatGPT ?
Le code SQL en lui-même n'est pas sensible — c'est la donnée qui l'est. Donc oui, vous pouvez générer des requêtes SQL via tout LLM tant que vous ne lui envoyez pas de vraies données client. Ne coller que des schémas et exemples factices dans les prompts.
L'IA peut-elle remplacer un DBA ?
Pour l'écriture de requêtes courantes, l'aide à l'optimisation, la documentation : largement. Pour l'architecture de BDD, le tuning fin du SGBD, la haute disponibilité, la sauvegarde, la sécurité : non, le DBA reste indispensable. L'IA est un excellent SQL writer, pas un DBA.
Faut-il documenter qu'une requête a été générée par IA ?
Bonne pratique en environnement collaboratif (dbt, Airflow, scripts versionnés) : oui, en commentaire avec la requête + le prompt utilisé. Cela permet aux relecteurs de comprendre la logique et de re-générer si besoin avec des améliorations.