Azure SQL | The .NET Blog

NL2SQL est l'injection SQL de l'ère agentique

Emiliano Montesdeoca — Wed, 03 Jun 2026 00:00:00 +0000

Il existe une version du discours NL2SQL qui semble parfaite : les utilisateurs posent des questions en langage naturel, les agents génèrent du SQL, les données reviennent. Moins d’écrans, moins de requêtes, moins de code. Simple.

Puis vous y réfléchissez cinq minutes de plus.

Les problèmes dont personne ne parle dans la démo

Les schémas n’ont pas été conçus pour expliquer les choses. Noms de tables cryptiques, noms de colonnes incohérents, relations techniquement valides mais sémantiquement invalides sans prédicats supplémentaires — c’est normal dans les bases de données d’entreprise. Ce ne sont pas des bugs, c’est simplement l’histoire accumulée des changements métier. Mais quand vous demandez à un modèle d’inférer l’intention d’un schéma qui n’a pas été conçu pour communiquer l’intention, le modèle essaiera quand même. Il ne s’arrêtera pas. Il générera sa meilleure requête et retournera des résultats avec assurance.

Les modèles ne sont pas déterministes. Posez la même question sur la même base de données deux fois et vous pourriez obtenir du SQL différent. Le modèle calcule des probabilités, et de légères variations de contexte produisent des sorties différentes. Vous ne pouvez pas tester votre chemin vers une garantie que l’agent génère toujours la bonne requête.

La révision par l’utilisateur ne passe pas à l’échelle. “Vérifiez simplement chaque requête avant l’exécution” semble sûr. Mais cela suppose que les utilisateurs sont des experts à la fois dans le modèle de données et en SQL — exactement les personnes qui n’avaient pas besoin de l’interface en langage naturel. Cela introduit également une surcharge cognitive et une nouvelle classe de biais de confirmation, où les utilisateurs submergés par la complexité des requêtes approuvent des requêtes invalides plutôt que de les investiguer.

Et puis il y a l’injection. Dans le développement SQL traditionnel, la paramétrisation a résolu l’injection parce que la saisie utilisateur remplissait des paramètres, pas la structure SQL. Avec NL2SQL, le modèle génère le SQL lui-même. Le prompt, le contexte du schéma, l’historique de conversation et les données récupérées influencent tous ce qui est exécuté. Si quelqu’un élabore un prompt qui change ce que le modèle génère, c’est de l’injection — pas au niveau des paramètres, mais au niveau de la génération des requêtes. Et contrairement à la suppression d’une table (évident, récupérable), l’injection NL2SQL produit des requêtes qui retournent des résultats incorrects sans aucune erreur visible. Des décisions métier sont prises sur de mauvaises données.

Ce que SQL MCP Server résout réellement

C’est là que l’article fait son point pratique le plus utile. Plutôt que de donner à un agent un accès arbitraire au schéma et d’espérer le meilleur, SQL MCP Server expose une surface API organisée construite sur Data API builder.

La différence est importante : l’agent ne génère pas de SQL. Il appelle des endpoints nommés qui retournent des formes de résultat prédéfinies. Le SQL est écrit une fois, par un développeur, et est déterministe. Le non-déterminisme de l’agent se limite à choisir quel endpoint appeler, pas à construire des requêtes arbitraires.

C’est analogue à ce que la paramétrisation a fait pour l’injection SQL dans le modèle d’application traditionnel — vous supprimez la capacité de construire des requêtes arbitraires à partir d’entrées non fiables.

La bonne question

L’article ne dit pas “n’utilisez jamais NL2SQL.” Il dit : soyez délibéré sur où vous l’appliquez et ce que vous exposez. Pour une analyse exploratoire dans un environnement contrôlé, avec un schéma limité et un accès en lecture seule, NL2SQL pourrait convenir. Pour les systèmes de production où les décisions métier dépendent des résultats, une couche API organisée est significativement plus sûre.

Honnêteté : certains problèmes sont vraiment mieux résolus avec des requêtes structurées derrière des endpoints nommés qu’avec du langage naturel vers SQL. SQL MCP Server vous donne cette option sans abandonner entièrement l’interface agentique.

Publication originale : Considering NL2SQL? Should your database really be the prompt? How can SQL MCP Server help?

Azure SQL Peut Maintenant Générer des Embeddings — En T-SQL Pur, Sans Couche Applicative

Emiliano Montesdeoca — Fri, 22 May 2026 00:00:00 +0000

Si vous avez déjà construit un pipeline RAG, vous connaissez la taxe pipeline : vos données vivent dans SQL, mais pour générer des embeddings vous devez les extraire, appeler une API d’embeddings, gérer le traitement par lots et les limites de débit, et stocker les résultats quelque part avec une recherche vectorielle. Souvent dans une base de données entièrement différente.

Azure SQL vient d’éliminer la majeure partie de cela avec deux fonctionnalités désormais généralement disponibles : CREATE EXTERNAL MODEL et AI_GENERATE_EMBEDDINGS.

Ce Qu’elles Font

Ces deux fonctionnalités T-SQL fonctionnent comme un pipeline intégré :

CREATE EXTERNAL MODEL — enregistre un endpoint de modèle d’IA externe comme un objet de base de données nommé. Vous définissez l’emplacement, le format d’API, le type de modèle et les identifiants une seule fois. Réutilisez-les partout.

AI_GENERATE_EMBEDDINGS — une fonction T-SQL scalaire qui appelle le modèle enregistré et renvoie un tableau JSON de valeurs vectorielles. Fonctionne dans les instructions SELECT, INSERT, UPDATE et MERGE.

Ensemble, ils forment un pipeline d’embeddings de bout en bout sans quitter le moteur SQL.

Le Flux de Travail Complet

-- Étape 1 : Enregistrez votre fournisseur d'embeddings une fois
CREATE EXTERNAL MODEL MyEmbeddingModel
WITH (
 LOCATION = 'https://your-aoai-resource.openai.azure.com/',
 API_FORMAT = 'Azure OpenAI',
 MODEL_TYPE = EMBEDDINGS,
 MODEL = 'text-embedding-ada-002'
);

-- Étape 2 : Générez des embeddings en ligne en T-SQL
UPDATE docs
SET embedding = AI_GENERATE_EMBEDDINGS(content USE MODEL MyEmbeddingModel)
FROM documents AS docs;

-- Étape 3 : Recherche avec la distance vectorielle
SELECT TOP 10 id, content
FROM documents
ORDER BY VECTOR_DISTANCE('cosine', embedding,
 AI_GENERATE_EMBEDDINGS(@query USE MODEL MyEmbeddingModel));

C’est tout le pipeline : données dans SQL, embeddings générés dans SQL, recherche de similarité dans SQL. Pas de couche d’orchestration, pas d’ETL, pas de base de données vectorielle séparée.

Formats d’API et Options Supportés

En GA, API_FORMAT supporte Azure OpenAI et OpenAI. MODEL_TYPE est verrouillé sur EMBEDDINGS pour l’instant. Le JSON PARAMETERS vous permet de définir des valeurs par défaut au niveau du modèle, notamment le nombre de tentatives :

PARAMETERS = '{"sql_rest_options":{"retry_count":3}}'

L’authentification utilise les identifiants de la base de données, donc les secrets restent hors de votre code applicatif.

Ce Que Cela Permet pour les Applications .NET

Pour les développeurs .NET qui construisent des fonctionnalités d’IA sur des données SQL existantes, c’est significatif. Vous n’avez pas besoin de :

Extraire des données vers un magasin intermédiaire pour les embeddings
Gérer un pipeline d’embeddings externe
Configurer une base de données vectorielle séparée (bien que vous puissiez utiliser Azure AI Search si vous voulez un magasin vectoriel complet)
Modifier la couche d’accès aux données de votre application

Vous pouvez ajouter la recherche sémantique aux applications SQL existantes de manière incrémentale, en utilisant les mêmes outils T-SQL que vous avez déjà.

Conclusion

Les patterns RAG sur les données SQL sont devenus dramatiquement plus simples. AI_GENERATE_EMBEDDINGS + CREATE EXTERNAL MODEL signifie que votre application SQL existante peut acquérir des capacités de recherche vectorielle sans ajouter de nouvelle infrastructure.

Les deux fonctionnalités sont en GA dans Azure SQL Database et Azure SQL Managed Instance aujourd’hui.

Post original : Generate Embeddings Function and External Model Object Support Are Now Generally Available in Azure SQL

Azure Data Studio est retraité : migrez votre flux Azure SQL vers VS Code

Emiliano Montesdeoca — Sat, 09 May 2026 00:00:00 +0000

Ce post a été traduit automatiquement. Pour la version originale, cliquez ici.

Azure Data Studio a été retraité le 6 février 2025, le support se termine le 28 février 2026 — le remplacement recommandé est VS Code avec l’extension MSSQL.

Ce qu’il faut installer

Trois éléments pour commencer :

Extension MSSQL — cherchez « SQL Server (mssql) » dans le Marketplace VS Code
Extension SQL Database Projects — schéma en tant que code, validation de build, publication guidée
.NET 8 SDK — requis par le système de build ; SDK manquant est le problème le plus fréquent au premier démarrage

Migrer vos connexions et paramètres ADS

L’extension MSSQL inclut l’ADS Migration Toolkit, qui gère la migration unique dans un flux guidé : connexions enregistrées, groupes de connexions, paramètres et raccourcis clavier sont tous importés automatiquement.

Retrouver le réflexe F5

Les utilisateurs d’ADS utilisent F5 pour exécuter des requêtes. Installez l’extension MSSQL Database Management Keymap pour retrouver les raccourcis clavier de type ADS, y compris F5.

SQL Database Projects : schéma en tant que code

Clic droit sur un projet → Publier → configurer la cible → examiner le script T-SQL généré → déployer. La prévisualisation du script avant le déploiement est la fonctionnalité de sécurité clé. Les modèles d’éléments génèrent des stubs pour les tables, procédures stockées et vues — le même flux de travail que SSDT.

Problème courant : une incompatibilité de plateforme cible dans le fichier .sqlproj provoquera des erreurs de build si le projet a été créé pour une version différente de SQL Server.

Schema Compare et Schema Designer

L’extension inclut également Schema Compare (diff entre votre projet et la base de données déployée) et Schema Designer (édition visuelle du schéma sans écrire du DDL à la main).

Développeurs Microsoft Fabric

La configuration est identique, mais commencez depuis le portail Fabric et connectez la base de données à Git avant de l’ouvrir dans VS Code. Microsoft dispose d’un guide dédié : Azure Data Studio to VS Code — What it means for SQL database in Fabric developers.

En résumé

La migration est un flux guidé en une seule fois, pas une reconstruction manuelle. Installez les trois outils, exécutez l’ADS Migration Toolkit, restaurez vos raccourcis clavier, et vous êtes de retour à la normale en moins de 10 minutes.

Consultez l’article complet pour les captures d’écran étape par étape et le tutoriel spécifique à Fabric.

SQL MCP Server sur Azure App Service — Sans Conteneurs

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Soyons honnêtes : chaque fois que je lis “nécessite un conteneur” dans un tutoriel, une petite partie de moi soupire. Les conteneurs sont formidables — jusqu’à ce que ton équipe n’ait pas de stratégie de conteneurs, et soudain une fonctionnalité qui semblait simple se retrouve bloquée par une complexité d’orchestration que personne n’avait anticipée.

C’est pourquoi celui-ci a retenu mon attention. Le SQL MCP Server peut désormais s’exécuter sur Azure App Service — sans Docker, sans Kubernetes, juste avec la même configuration Data API Builder (DAB) qui expose ta base de données SQL via MCP, REST et GraphQL.

Qu’est-ce que le SQL MCP Server ?

Contexte rapide si tu ne le connais pas encore. Le SQL MCP Server se place entre ton agent IA et ta base de données SQL. Au lieu de donner à ton agent un accès direct à la base de données (une très mauvaise idée), il expose tes tables et vues comme une couche d’abstraction — des entités avec des permissions définies.

Il est construit sur Data API Builder, ce qui signifie qu’un seul fichier de configuration gère MCP et REST et GraphQL simultanément. Ton agent parle à l’endpoint MCP. Ton application traditionnelle parle à REST ou GraphQL. Même config, même runtime, surfaces différentes.

C’est vraiment utile. Tu ne maintiens pas deux couches d’API séparées.

Le Problème des Conteneurs (et la Solution)

Le modèle de déploiement original du SQL MCP Server utilisait des conteneurs. Cela fonctionne bien dans beaucoup d’équipes — mais pas toutes. De nombreuses équipes .NET standardisent sur Azure App Service ou des VMs. Exiger un runtime de conteneur juste pour exposer un endpoint SQL ajoute de la friction que personne n’a demandée.

Le nouveau guide montre comment contourner entièrement le conteneur. Tout fonctionne avec une commande dab start, hébergé sur App Service comme un processus web .NET 8 standard.

# Installer Data API Builder
dotnet tool install microsoft.dataapibuilder --prerelease -g

# Initialiser la configuration
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# Ajouter une entité
dab add products --source dbo.products --permissions "authenticated:*"

# Configurer le fournisseur d'auth App Service
dab configure --runtime.host.authentication.provider AppService

# Démarrer le serveur
dab start

À ce stade, tu as MCP à /mcp, REST et GraphQL depuis le même processus, et rien qui tourne dans un conteneur.

Authentification Sans Clés d’API Partagées

C’est la partie que j’apprécie le plus. Quand tu déploies sur App Service, tu configures Microsoft Entra ID comme fournisseur d’authentification. Pas de secrets partagés dans les fichiers de configuration, pas de clés d’API à faire tourner.

La chaîne de connexion reste dans une variable d’environnement App Service (pas dans dab-config.json), et l’endpoint MCP est protégé par l’authentification de la plateforme. Si tu es déjà aligné sur Entra ID pour tes charges de travail Azure, cela s’intègre naturellement.

Pour le développement local, tu passes en mode Simulator et transport STDIO. Tu reviens en mode AppService avant le déploiement. Propre et explicite.

Déploiement sur App Service

az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

az webapp config set \
 --name <app-name> \
 --resource-group <resource-group> \
 --startup-file "dab start"

Ensuite tu déploies ton projet DAB en utilisant la méthode de déploiement de code que ton équipe utilise déjà. Le détail clé : c’est un déploiement de code, pas de conteneur.

Pourquoi C’est Important pour les Développeurs .NET

Si tu construis des agents IA en .NET, ton agent devra tôt ou tard communiquer avec une base de données. Le SQL MCP Server te donne une façon structurée de le faire sans exposer des chaînes de connexion brutes.

Consulte le guide complet dans le billet original et le dépôt d’exemple sur GitHub.

Conclusion

Le SQL MCP Server sur App Service est une option pragmatique solide pour les équipes .NET qui souhaitent donner à leurs agents un accès structuré aux données SQL sans stratégie de conteneurs. Essaie-le — tes agents apprécieront la surface d’API propre.

SQL Server 2025 comme Base de Données Prête pour les Agents : Sécurité, Backup et MCP dans un Seul Moteur

Emiliano Montesdeoca — Sun, 26 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

J’ai suivi la série Polyglot Tax d’Aditya Badramraju avec beaucoup d’intérêt. La partie 4 clôt la série avec les parties qui déterminent vraiment si vous feriez confiance à cette architecture en production.

Un Modèle de Sécurité pour Tous les Modèles de Données

Une seule politique Row-Level Security couvre toutes les tables — relationnelles, JSON, graphes, vecteurs. Une politique, une preuve pour l’auditeur.

Backup Unifié = Récupération Atomique

Dans un stack polyglottes, la récupération point-in-time sur cinq bases de données est un cauchemar de cohérence. Avec une seule base de données, c’est atomique par définition.

Intégration MCP : Agents Sans Middleware

SQL Server 2025 supporte directement le SQL MCP Server. Les agents appellent des outils, le moteur impose l’isolation tenant et le masquage des colonnes automatiquement.

Conclusion

Pour les développeurs .NET qui construisent des applications agent-first sur Azure SQL, cette architecture mérite une sérieuse considération. Post original d’Aditya Badramraju : The Polyglot Tax – Part 4.

SQL MCP Server — La bonne façon de donner accès aux bases de données aux agents IA

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Soyons honnêtes : la plupart des serveurs MCP de bases de données disponibles aujourd’hui sont effrayants. Ils prennent une requête en langage naturel, génèrent du SQL à la volée et l’exécutent contre vos données de production. Qu’est-ce qui pourrait mal tourner ? (Tout. Absolument tout.)

L’équipe Azure SQL vient de présenter SQL MCP Server, et il adopte une approche fondamentalement différente. Construit comme une fonctionnalité de Data API builder (DAB) 2.0, il donne aux agents IA un accès structuré et déterministe aux opérations de base de données — sans NL2SQL, sans exposer votre schéma, et avec un RBAC complet à chaque étape.

Pourquoi pas de NL2SQL ?

C’est la décision de conception la plus intéressante. Les modèles ne sont pas déterministes, et les requêtes complexes sont les plus susceptibles de produire des erreurs subtiles. Les requêtes exactes que les utilisateurs espèrent que l’IA peut générer sont aussi celles qui nécessitent le plus de vérification quand elles sont produites de manière non déterministe.

À la place, SQL MCP Server utilise une approche NL2DAB. L’agent travaille avec la couche d’abstraction d’entités de Data API builder et son constructeur de requêtes intégré pour produire du T-SQL précis et bien formé de manière déterministe. Même résultat pour l’utilisateur, mais sans le risque de JOINs hallucinés ou d’exposition accidentelle de données.

Sept outils, pas sept cents

SQL MCP Server expose exactement sept outils DML, quelle que soit la taille de la base de données :

describe_entities — découvrir les entités et opérations disponibles
create_record — insérer des lignes
read_records — interroger des tables et vues
update_record — modifier des lignes
delete_record — supprimer des lignes
execute_entity — exécuter des procédures stockées
aggregate_records — requêtes d’agrégation

C’est malin, car les fenêtres de contexte sont l’espace de réflexion de l’agent. Les inonder de centaines de définitions d’outils laisse moins de place au raisonnement. Sept outils fixes gardent l’agent concentré sur la réflexion plutôt que la navigation.

Chaque outil peut être activé ou désactivé individuellement :

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

Démarrage en trois commandes

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

Voilà un SQL MCP Server en fonctionnement qui expose votre table Customers. La couche d’abstraction d’entités vous permet de créer des alias pour les noms et colonnes, de limiter les champs par rôle et de contrôler exactement ce que les agents voient — sans exposer les détails internes du schéma.

L’aspect sécurité est solide

C’est là que la maturité de Data API builder porte ses fruits :

RBAC à chaque couche — chaque entité définit quels rôles peuvent lire, créer, mettre à jour ou supprimer, et quels champs sont visibles
Intégration Azure Key Vault — chaînes de connexion et secrets gérés de manière sécurisée
Microsoft Entra + OAuth personnalisé — authentification de niveau production
Content Security Policy — les agents interagissent via un contrat contrôlé, pas du SQL brut

L’abstraction du schéma est particulièrement importante. Vos noms internes de tables et colonnes ne sont jamais exposés à l’agent. Vous définissez des entités, des alias et des descriptions qui ont du sens pour l’interaction IA — pas votre diagramme ERD de base de données.

Multi-bases et multi-protocoles

SQL MCP Server supporte Microsoft SQL, PostgreSQL, Azure Cosmos DB et MySQL. Et comme c’est une fonctionnalité de DAB, vous obtenez des endpoints REST, GraphQL et MCP simultanément depuis la même configuration. Mêmes définitions d’entités, mêmes règles RBAC, même sécurité — sur les trois protocoles.

L’auto-configuration dans DAB 2.0 peut même inspecter votre base de données et construire la configuration dynamiquement, si vous êtes à l’aise avec moins d’abstraction pour du prototypage rapide.

Mon avis

C’est ainsi que l’accès base de données d’entreprise pour les agents IA devrait fonctionner. Pas « hey LLM, écris-moi du SQL et YOLO sur la prod ». À la place : une couche d’entités bien définie, une génération de requêtes déterministe, RBAC à chaque étape, cache, monitoring et télémétrie. C’est ennuyeux de la meilleure façon possible.

Pour les développeurs .NET, l’histoire d’intégration est propre — DAB est un outil .NET, le MCP Server tourne en conteneur, et il fonctionne avec Azure SQL, que la plupart d’entre nous utilisent déjà. Si vous construisez des agents IA qui ont besoin d’accéder aux données, commencez ici.

Pour conclure

SQL MCP Server est gratuit, open-source et tourne partout. C’est l’approche prescriptive de Microsoft pour donner aux agents IA un accès sécurisé aux bases de données. Consultez le post complet et la documentation pour commencer.