i

Description

Calculatrice mécanique ancienne à leviers, à curseurs et à rangées de touches, exposée dans une vitrine.

Source

Daderot · page d’origine

Licence

CC0 Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

SQL Server en SaaS — contribution de l'IA

Vous saurez où l'IA aide réellement dans une chaîne Azure SQL → Power BI : écriture et optimisation de T-SQL, DAX, analyse de plans, diagnostic, documentation, détection d'anomalies, réglage…

En bref

• Vous saurez où l'IA aide réellement dans une chaîne Azure SQL → Power BI : écriture et optimisation de T-SQL, DAX, analyse de plans, diagnostic, documentation, détection d'anomalies, réglage automatique du moteur.
• Vous disposerez de notes /5 (gain, risque, maturité) par cas d'usage, avec prérequis et garde-fous.
• Vous aurez des prompts types, et la liste de ce que l'IA ne remplace pas.
• Les noms de produits et leur statut (aperçu, disponibilité générale) évoluent vite : chaque point volatil est marqué « état 2026-10 » ou « à vérifier ». Cadre : vue d'ensemble.

Sur cette page

1. Deux familles d'IA à ne pas confondre
   1. 🟢 Novice — Assistant ou moteur ?
2. Copilot dans les outils SQL
   1. 🟡 Pratique — Où on le trouve (état 2026-10)
3. Copilot dans Power BI
   1. 🟡 Pratique — Ce qui est proposé (état 2026-10, à vérifier)
4. T-SQL et DAX : génération et optimisation
   1. 🟡 Pratique — Cas d'usage
5. Plans d'exécution et diagnostic
   1. 🟡 Pratique — L'IA lit les plans
   2. 🔴 Expert — Boucle d'amélioration sûre
6. Intelligence intégrée au moteur
   1. 🟡 Pratique — Réglage automatique et détection
7. Documentation et métadonnées automatiques
   1. 🟡 Pratique — Documenter à moindre coût
8. Tableau gain, risque, maturité
9. Garde-fous
   1. 🔴 Expert — Cadre d'usage recommandé
10. Prompts d'exemple
11. Ce que l'IA ne remplace pas
12. Voir aussi

Niveau : 🟢→🔴

Deux familles d'IA à ne pas confondre#

🟢 Novice — Assistant ou moteur ?#

1. L'IA assistante : vous écrivez une consigne en langage naturel, un modèle de langage (Copilot, un agent) produit du texte (SQL, DAX, explication). Vous relisez et décidez. Risque principal : l'hallucination plausible.
2. L'IA embarquée dans le moteur : le service Azure SQL observe sa charge et agit (créer/supprimer un index, forcer un plan, détecter une anomalie de performance). Ce sont des algorithmes d'apprentissage automatique appliqués à la télémétrie, avec un cycle de validation (essai, mesure, annulation). Risque principal : une action automatique non comprise.

La première demande de la vigilance de relecture, la seconde de la supervision. Le reste du dossier distingue ces deux régimes.

Copilot dans les outils SQL#

🟡 Pratique — Où on le trouve (état 2026-10)#

(Azure Data Studio est retiré depuis le 28 février 2026 ; l'extension mssql de VS Code et SSMS reprennent ses usages.)

Copilot dans Power BI#

🟡 Pratique — Ce qui est proposé (état 2026-10, à vérifier)#

• Copilot dans les rapports : résumé d'un rapport, création de pages et de visuels à partir d'une consigne, requêtes en langage naturel sur le modèle, explication des visuels. Nécessite une capacité payante Fabric/Premium d'une taille minimale et l'activation par l'administrateur du locataire (la liste des références éligibles évolue ; à vérifier).
• Copilot dans la création de mesures DAX : suggestion de mesures, explication d'une mesure existante, rédaction de descriptions.
• Préparation du modèle pour l'IA : description du modèle, synonymes, exemples de questions, « schéma IA » indiquant à l'assistant quelles tables et champs utiliser (les noms et fonctionnalités changent ; à vérifier). C'est le levier de qualité n° 1 : un modèle propre, nommé et documenté donne de bonnes réponses.
• Questions-réponses en langage naturel et agents de données sur un modèle/lakehouse : intéressants pour l'exploration, rarement acceptables pour des chiffres engageants sans validation.

T-SQL et DAX : génération et optimisation#

🟡 Pratique — Cas d'usage#

-- Contrôle d'équivalence entre l'ancienne et la nouvelle requête
SELECT * FROM (ancienne) a EXCEPT SELECT * FROM (nouvelle) n;
SELECT * FROM (nouvelle) n EXCEPT SELECT * FROM (ancienne) a;
-- Les deux résultats doivent être vides (à lancer sur un jeu de données représentatif)

Voir aussi la matrice BI sur les mesures et calculs DAX.

Plans d'exécution et diagnostic#

🟡 Pratique — L'IA lit les plans#

Coller un plan d'exécution XML (ou son texte) dans un assistant permet d'obtenir une explication opérateur par opérateur, un repérage des anomalies (estimation de lignes très éloignée du réel, key lookup massif, spill dans tempdb, scan alors qu'une recherche est possible, conversion implicite) et une liste d'hypothèses. C'est un excellent accélérateur pour juniors et un gain de temps pour les experts, à condition de vérifier chaque hypothèse sur le plan réel (SET STATISTICS XML ON ou Query Store).

Diagnostic des attentes : coller le résultat de sys.dm_exec_session_wait_stats/sys.dm_db_wait_stats et le profil de ressources aide à classer le goulot (CPU, IO, journal, verrou).

🔴 Expert — Boucle d'amélioration sûre#

1. Capturer la requête et son plan dans Query Store (référence).
2. Soumettre le plan à l'assistant ; obtenir 2–3 hypothèses.
3. Tester chaque hypothèse séparément, en alternance, sur environnement dédié, en CPU et lectures logiques (protocole de mesure).
4. Contrôler l'équivalence des résultats.
5. Déployer via le kit/pipeline habituel avec revue ; consigner le gain dans le suivi des changements.

Intelligence intégrée au moteur#

🟡 Pratique — Réglage automatique et détection#

• Réglage automatique (Automatic Tuning) d'Azure SQL Database : FORCE_LAST_GOOD_PLAN (annule une régression de plan détectée par Query Store), recommandations et (selon activation) application automatique de création/suppression d'index (CREATE_INDEX, DROP_INDEX) avec validation et retour arrière si la charge se dégrade. Activation par base ; le forçage de plan est généralement sûr, la gestion automatique d'index demande davantage de prudence (index créés non versionnés dans votre code → écart entre environnements ; coût de maintenance).
• Recommandations de performance du portail (index manquants/inutiles, requêtes coûteuses) : issues de la télémétrie, à traiter comme des suggestions.
• Intelligent Insights / détection d'anomalies de performance et alertes basées sur des métriques (CPU, IO, workers) : en aperçu ou en évolution, à vérifier ; utile pour passer d'une supervision par seuil fixe à une détection d'écarts.
• Microsoft Defender for SQL : évaluation de vulnérabilités et détection d'activités anormales (injection, accès inhabituels), un autre cas d'IA embarquée, côté sécurité.
• Traitement de requêtes intelligent (famille IQP) : feedback d'allocation de mémoire, optimisation de plan sensible aux paramètres, jointures adaptatives, selon le niveau de compatibilité. Pas de « magie » : ce sont des mécanismes d'apprentissage dans l'optimiseur, qui exigent un niveau de compatibilité suffisant (voir piège 27).

Documentation et métadonnées automatiques#

🟡 Pratique — Documenter à moindre coût#

L'IA génère de bons premiers jets de descriptions pour des tables et colonnes à partir du schéma, des noms et d'échantillons : descriptions de mesures DAX, commentaires de colonnes, dictionnaires de données, synonymes pour Copilot, traductions de libellés (anglais, espagnol…). Dans un datamart dont les métadonnées sont portées par des propriétés étendues SQL (description, source, libellé), un script peut produire des propositions, qu'un humain valide avant écriture.

Cas d'usage voisins : génération de schémas Mermaid de lignage à partir des dépendances (sys.sql_expression_dependencies), résumé de changements entre deux versions du datamart, notes de version à partir des différences de schéma.

Tableau gain, risque, maturité#

Appréciations d'expert, contextuelles (équipe de 3 à 8 personnes, projet de reporting d'entreprise sur Azure SQL + Power BI ; voir NOTATION). Risque : 5 = risque élevé ; maturité : 5 = pratique éprouvée.

Garde-fous#

🔴 Expert — Cadre d'usage recommandé#

1. Périmètre de données : liste des environnements autorisés (développement seulement, jamais de données personnelles réelles envoyées à un service externe sans accord).
2. Lecture seule d'abord : les assistants se connectent avec un compte en lecture seule (rôle db_datareader, ou même schéma restreint) ; l'écriture passe toujours par le pipeline.
3. Revue humaine obligatoire de tout code généré avant fusion, comme pour du code d'un nouveau collègue ; la revue regarde la sémantique (NULL, doublons, fuseaux, accents), pas la syntaxe.
4. Tests d'équivalence et de non-régression : requêtes de contrôle, totaux par périmètre et par rôle RLS ; voir tests et fiabilité des chiffres.
5. Traçabilité : indiquer dans la description du changement qu'un élément a été généré/assisté par IA (cohérent avec la politique de signature des contenus rédactionnels ; pas besoin de signer chaque ligne de code).
6. Pas de secret dans les prompts : chaînes de connexion, mots de passe, clés ; utiliser des coffres de secrets.
7. Mesure plutôt que confiance : toute assertion de performance est confirmée par mesure ; toute limite de licence/tarif par documentation officielle.
8. Veille et gouvernance : les fonctions Copilot et Fabric évoluent (changements de nom, de statut, de licence) ; une personne désignée tient à jour l'inventaire des usages autorisés.

Prompts d'exemple#

Contexte : Azure SQL Database, niveau de compatibilité 160, collation sensible aux accents.
Schéma (DDL joint) : dbo.FaitVisite, dbo.DimClient, dbo.DimDate.
Tâche : écris une requête qui donne, par mois et par région, le nombre de visites distinctes
et le taux de visites avec relevé. Contraintes : n'utilise que les colonnes du DDL ; aucune fonction
sur les colonnes de filtre ; gère les NULL de [DateRelevé] comme « pas de relevé » ; commente les hypothèses.
Réponds avec : la requête, les hypothèses, 3 cas limites à tester.

Voici le plan d'exécution réel (XML) d'une requête DirectQuery lente et les statistiques IO/TIME.
Liste les 3 causes les plus probables, classées, et pour chacune la mesure ou la requête qui la confirmerait.
Ne propose pas de réécriture avant confirmation.

Voici une mesure DAX et la description du modèle (tables, relations, cardinalités).
Explique-la en français simple, signale les risques de contexte (filtre/ligne), les itérateurs coûteux
et propose une version avec variables. Indique ce qui pourrait changer le résultat selon un rôle RLS.

Voici le DDL de la table dbo.DimProduit. Propose une description métier de chaque colonne (une phrase),
marque [incertain] ce qui n'est pas déductible du nom, et propose un libellé court en anglais (glossaire joint).

Ce que l'IA ne remplace pas#

• Le jugement d'architecture : choisir Import/DirectQuery/mirroring, dimensionner, arbitrer coût et fraîcheur reste une décision d'expert, avec compromis assumés (06).
• La responsabilité : le code généré est votre code ; un chiffre faux publié engage l'équipe, pas l'assistant.
• La recette métier : seule la confrontation à une référence validée par les utilisateurs prouve qu'un chiffre est juste.
• La confidentialité : aucune garantie n'est donnée par l'assistant ; elle vient de la configuration, du contrat et de la discipline.
• La mémoire du projet : l'assistant ignore les décisions antérieures, les règles non écrites et l'historique des erreurs ; la documentation vivante reste indispensable.
• La dette cachée : du code généré en masse, non compris, devient une dette de maintenance (personne ne sait pourquoi cette requête existe). Règle simple : si l'équipe ne peut pas expliquer un script, il n'entre pas.

Voir aussi#

• Vue d'ensemble · Architecture · Difficultés et pièges
• Comparatif OneLake vs SQL Server · Bonnes pratiques transverses · Checklist de projet
• Matrice BI : mesures et calculs DAX · modèle sémantique
• Matrice PD : qualité des données
• Bibliographie et ressources · Glossaire

✻ Rédigé par Claude Sonnet 5.5