À suivreGuide suivant
Comment écrire des scripts et des macros de feuille de calcul avec l'IA
Technique
GUIDE Technique
Comment écrire des requêtes SQL avec l'IA
Écrire des requêtes SQL avec l'IA signifie décrire la question à laquelle vous souhaitez répondre dans un anglais simple, donner au modèle les définitions de vos tables et colonnes, et lui faire rédiger, expliquer ou optimiser le SQL pour vous.
Sur cette page4 minutes de lecture
Aperçu
C'est important parce que les analystes, les spécialistes du marketing et les développeurs peuvent obtenir des réponses beaucoup plus rapidement à partir des bases de données, à condition qu'ils vérifient les résultats par rapport aux données réelles avant de leur faire confiance.
Plongée profonde
Les grands modèles de langage ont appris SQL à partir d'énormes quantités de code public, de documentation et de forums de questions-réponses, ils sont donc efficaces pour produire des requêtes syntaxiquement valides. Ce qu'ils ne peuvent pas connaître, c'est votre base de données. Sans votre schéma, un modèle devine les noms de tables comme « utilisateurs » ou « commandes » et les noms de colonnes comme « created_at », et la requête peut échouer ou, pire encore, s'exécuter et renvoyer la mauvaise réponse. La plus grande amélioration que vous puissiez apporter est de coller le schéma : les instructions CREATE TABLE, ou une liste de tables, de colonnes, de types de données et la manière dont les tables sont liées via des clés étrangères. L'ajout de quelques exemples de lignes et de notes sur les règles métier, telles que « les commandes annulées ont un statut = 'X' » ou « les montants sont stockés en centimes », évite de nombreuses erreurs silencieuses. Indiquez également le dialecte SQL. PostgreSQL, MySQL, SQL Server, SQLite, BigQuery et Snowflake diffèrent par les fonctions de date, la concaténation de chaînes, LIMIT par rapport à TOP et d'autres détails. Une requête écrite pour l’un peut échouer ou se comporter différemment sur un autre. Un flux de travail fiable comporte quatre étapes : donner le contexte, poser la question dans un anglais simple, demander au modèle d'expliquer sa requête avec des mots, puis tester. L'étape d'explication est importante car elle révèle des malentendus, tels que le comptage des lignes au lieu de clients distincts, ou l'utilisation d'un INNER JOIN qui supprime silencieusement les clients qui n'ont aucune commande. Les idées fausses courantes incluent la croyance qu'une requête qui s'exécute est correcte (une mauvaise jointure peut compter deux fois les sommes), que la sortie de l'IA peut être exécutée en toute sécurité en production (une UPDATE ou DELETE sans clause WHERE modifie chaque ligne) et que vous devez partager des données réelles. Habituellement, le schéma seul suffit, ce qui permet également d'exclure les informations client du chat. Les assistants généraux tels que ChatGPT, Claude et Gemini, les outils de codage tels que GitHub Copilot et les assistants IA intégrés à de nombreux éditeurs de bases de données fonctionnent tous mieux avec ce même modèle.
Impact stratégique
Coût et budget
Les décisions en matière d'architecture déterminent les performances et les coûts d'exploitation pendant des années.
Décisions plus claires
La formation technique aide les équipes à choisir la bonne pile, pas seulement la plus récente.
Contrôle qualité
De meilleurs choix d’ingénierie réduisent les incidents de fiabilité en production.
L'avenir de la façon d'écrire des requêtes SQL avec l'IA
Text-to-SQL est un domaine de recherche actif, et les fournisseurs de bases de données et d'analyses intègrent de plus en plus d'assistants en langage naturel dans les éditeurs de requêtes et les outils de BI. Ces assistants fonctionnent mieux lorsqu'ils peuvent lire les métadonnées du schéma, les descriptions de colonnes et une couche sémantique qui définit des termes tels que « client actif » une fois pour tout le monde. La précision des bases de données désordonnées du monde réel reste à la traîne par rapport aux résultats de références propres, car les définitions commerciales ambiguës sont un problème humain et non un problème de syntaxe. La compétence qui restera précieuse est de savoir exactement quelle question vous posez et comment vérifier qu'une réponse est correcte, même si la rédaction du code SQL lui-même devient de plus en plus automatisée.
Mise en œuvre dans le monde réel
Un petit propriétaire de boutique en ligne colle les instructions CREATE TABLE pour les tables de commandes et de clients, demande « Quels sont les 10 clients qui ont dépensé le plus au cours des 90 derniers jours ? » et exécute la requête renvoyée sur une copie de la base de données avant d'utiliser les chiffres.
Un analyste de données colle une requête de rapport lente de 60 lignes avec sa sortie EXPLAIN ANALYZE et demande à l'IA de suggérer un index et de réécrire une sous-requête corrélée sous forme de jointure.
Une nouvelle recrue qui hérite d'un ancien rapport mensuel demande à l'IA d'expliquer une requête existante ligne par ligne, y compris ce que font chaque JOIN et GROUP BY, avant de modifier quoi que ce soit.
Un développeur déplaçant un rapport de MySQL vers PostgreSQL demande à l'IA de traduire des fonctions telles que DATE_FORMAT en to_char de PostgreSQL et de répertorier toutes les différences de comportement méritant d'être testées.
Risques et garde-fous
L’optimisation d’un benchmark peut masquer des faiblesses plus larges du système.
Les coûts d’infrastructure et de maintenance sont souvent sous-estimés.
Les lacunes en matière de sécurité et d’observabilité peuvent se creuser à mesure que les systèmes deviennent plus complexes.
Feuille de route de mise en œuvre
Définissez les objectifs de latence, de qualité et de coût avant la mise en œuvre.
Benchmark dans des conditions de charge et de données réalistes.
Surveillance des instruments pour détecter les erreurs, la dérive et l'impact sur l'utilisateur.
Préparez les chemins de restauration et de réponse aux incidents avant la mise à l’échelle.
Continuez à explorer
Free newsletter
Get the daily AI briefing
Three verified AI stories every weekday morning, written in plain English. Free forever, no ads.
One email each weekday. Unsubscribe in one click. We never sell or share your address.
Test yourself
Take the How to Write SQL Queries with AI quiz
Instant feedback on every answer, and a shareable certificate with a verifiable ID once you pass a course.
Support free AI education. AI Understanding is a 501(c)(3) nonprofit — no ads, no paywall, ever. Make a donation
Questions fréquemment posées
Qu'est-ce que Comment écrire des requêtes SQL avec l'IA ?
Écrire des requêtes SQL avec l'IA signifie décrire la question à laquelle vous souhaitez répondre dans un anglais simple, donner au modèle les définitions de vos tables et colonnes, et lui faire rédiger, expliquer ou optimiser le SQL pour vous. C'est important parce que les analystes, les spécialistes du marketing et les développeurs peuvent obtenir des réponses beaucoup plus rapidement à partir des bases de données, à condition qu'ils vérifient les résultats par rapport aux données réelles avant de leur faire confiance.
Selon le guide, quelle étape améliore le plus la précision du SQL généré par l'IA ?
Sans votre schéma, le modèle doit deviner les noms des tables et des colonnes. En lui donnant la véritable structure, ainsi que les règles métier, vous éliminez la plupart de ces incertitudes.
Pourquoi devriez-vous indiquer à l’IA quel dialecte SQL vous utilisez ?
PostgreSQL, MySQL, SQL Server, SQLite, BigQuery et Snowflake gèrent les dates, la concaténation de chaînes et les limites de lignes différemment, de sorte qu'une requête pour l'un peut s'interrompre sur une autre.
Vous joignez les commandes à order_items, puis calculez SUM (orders.total). Quel est le problème probable ?
Il s'agit d'une distribution de jointure : rejoindre une table avec plusieurs lignes par commande duplique le total de chaque commande. Agrégez au bon grain, souvent dans un CTE, avant de joindre.
Pourquoi le guide recommande-t-il de demander à l’IA d’expliquer sa requête avec des mots simples ?
Une explication en langage simple vous permet de comparer ce que fait réellement la requête avec ce que vous vouliez dire, en détectant les erreurs logiques qui s'exécutent toujours sans plainte.
Quelle affirmation concernant COUNT(column) et COUNT(*) est correcte ?
COUNT(*) compte les lignes quel que soit leur contenu, tandis que COUNT(column) ignore les lignes où cette colonne est NULL. Les mélanger change les résultats en silence.
Continuez à apprendre
Guides associés
Plus de guides sélectionnés pour ce sujet