Il ne s’agit pas simplement d’apprendre à faire écrire du SQL par un LLM. Vous apprenez à produire du code SQL fiable pour la mise en production de charges de travail BI récurrentes ; vous assumez la responsabilité des défaillances en aval si la requête est erronée, lente ou non reproductible. L’IA accélère la rédaction, la formulation d’hypothèses de débogage et la synthèse des compromis. C’est à vous de vérifier la sémantique, de définir les seuils et de décider de la mise en production.
Ce cours permet d’acquérir une compétence transférable. Vous apprendrez à définir précisément la demande, à fournir le contexte minimal requis, à générer des propositions de requêtes SQL et à effectuer des vérifications avant tout partage ou toute planification. Chaque leçon enrichit cette méthodologie de production, afin que l’assistance de l’IA vous fasse gagner du temps sans compromettre vos exigences de fiabilité.
Avant d’utiliser une technique spécifique, concentrez-vous sur le livrable. Ce livrable se compose d’une requête SQL accompagnée d’éléments de vérification permettant à un autre analyste de réexécuter le code, de l’examiner et de s’y fier.
Le périmètre opérationnel concerne les requêtes récurrentes qui alimentent des tableaux de bord, des systèmes d’alerte et des extractions planifiées. Le code SQL doit donc être correct au niveau de granularité souhaité, stable face à la croissance des données et explicable aux relecteurs. L’IA peut suggérer des jointures, des fonctions de fenêtrage et des refactorisations. Vous seul pouvez certifier que la requête respecte les définitions métier et qu’elle ne dépassera pas les budgets alloués en termes de coûts et de latence.
Examinez l’architecture de production dans laquelle vous évoluez, notamment la provenance des éléments servant à la vérification.
Considérez chaque requête générée par l’IA comme une proposition, et non comme une réponse définitive. Si elle est mise en production et perturbe le tableau de bord, la responsabilité de l’incident incombe à l’analyste et à l’équipe qui l’ont validée, et non au modèle.
La qualité des résultats de l’IA dépend du contexte que vous lui fournissez. Pour le SQL, le jeu minimal d’informations ne se résume pas à une description métier textuelle ; il s’agit d’un ensemble de contraintes que le modèle peut traduire en clés de jointure, filtres et agrégations sans avoir à inventer une structure.
Incluez le schéma et les chemins de jointure, le grain de chaque table, les contraintes de clés, les filtres obligatoires, le dialecte SQL de votre entrepôt de données ainsi que les contraintes opérationnelles (telles que les SLA et les impératifs de coût). Précisez également les approximations acceptables, par exemple si les événements arrivant avec du retard peuvent être ignorés ou si les décomptes de valeurs distinctes peuvent être approximatifs.
Élaborez un jeu de contexte pour un entrepôt de données e-commerce et observez comment chaque détail manquant peut devenir une source de défaillance.
Un bon prompt constitue un contrat. Il précise l’intention et fige les éléments susceptibles de dériver, tels que la logique de jointure, le traitement des valeurs nulles et les cardinalités attendues. L’IA peut se charger de la syntaxe ; à vous de définir ce que la requête est autorisée à signifier.
Définissez explicitement la granularité du résultat (par exemple, le chiffre d’affaires hebdomadaire par canal). Précisez les exclusions, comme les retours et les commandes annulées. Définissez le traitement des valeurs nulles (par exemple, si un canal inconnu doit être libellé '(unknown)' ou exclu). Indiquez le nombre de lignes attendu (par exemple, 52 semaines multipliées par 8 canaux) afin de détecter immédiatement toute explosion du volume de données liée à une jointure.
Rédigez un prompt structuré qui impose ces contraintes avant la génération du code SQL.