Connecter SQL Server à n8n : le node Microsoft SQL de bout en bout

Une part importante des logiciels métier installés en France stocke ses données dans Microsoft SQL Server : gestion commerciale, GPAO, WMS, modules Sage ou Cegid on-premise, applications internes toujours en production après dix ans. Ces données sont propres et structurées, mais inaccessibles au reste de la stack. Le node Microsoft SQL de n8n (n8n-nodes-base.microsoftSql) ouvre ce verrou : un client SQL natif, quatre opérations, et un mécanisme de requêtes paramétrées à comprendre avant la première ligne de code.

Quand brancher n8n directement sur SQL Server

Trois situations justifient l'accès SQL direct.

• Le logiciel n'a pas d'API exploitable. Cas fréquent avec les ERP on-premise : l'éditeur propose parfois un connecteur payant, parfois rien, et la base reste le seul point d'entrée réaliste. Quand une API documentée existe — c'est le cas des offres cloud, comme dans notre guide de connexion à Sage Business Cloud —, elle reste préférable pour l'écriture.
• Le besoin est du reporting transverse. Croiser un stock WMS avec un carnet de commandes, calculer un délai moyen de livraison : des jointures et des GROUP BY qu'aucune API applicative ne rendra aussi simplement.
• Il faut alimenter un autre système. Sortir les clients d'un ERP vers un CRM — la mécanique de notre article sur la synchronisation HubSpot ↔ Pipedrive — ou pousser des indicateurs vers un tableau de bord.

La règle qui vaut pour MySQL vaut ici mot pour mot : lecture directe légitime, écriture directe risquée. Un UPDATE sur une table d'ERP contourne toute la logique métier — recalculs, triggers, journaux internes. Notre guide du node MySQL développe cet arbitrage.

Créer le credential Microsoft SQL

Le credential demande les champs suivants :

• Server — le nom d'hôte ou l'IP du serveur SQL. Pour une instance nommée, la valeur ressemble à SRV-ERP\SQLEXPRESS.
• Database — le nom de la base (master par défaut, ce qui n'est presque jamais ce que vous voulez).
• User et Password — les identifiants du compte SQL Server.
• Port — 1433 par défaut. Une instance nommée peut écouter sur un port dynamique : fixez-le explicitement côté serveur plutôt que d'espérer que SQL Server Browser fonctionne à travers un pare-feu.
• Domain — à renseigner uniquement pour une authentification de domaine Windows (NTLM). Laissé vide, la connexion utilise l'authentification SQL Server classique.
• TLS — activé par défaut. Laissez-le activé, y compris sur un réseau interne.
• Ignore SSL Issues (Insecure) — désactivé par défaut. À activer quand SQL Server présente un certificat auto-signé, cas de la majorité des installations internes : le certificat est accepté sans être validé, le trafic reste chiffré mais l'authenticité du serveur n'est plus vérifiée. Acceptable sur un LAN maîtrisé, à proscrire dès que la connexion traverse internet.
• Connect Timeout et Request Timeout — 15 000 ms chacun par défaut. Le second est celui qui vous rattrapera sur une requête lourde (voir plus bas).
• TDS Version — 7_4 par défaut, avec 7_3_B, 7_3_A, 7_2 et 7_1 pour les serveurs anciens. N'y touchez qu'en cas d'échec de connexion.

Créez un compte SQL dédié à n8n, jamais sa. Un compte limité au droit SELECT sur les tables ou vues réellement nécessaires couvre la plupart des usages et transforme une erreur de requête en message d'erreur plutôt qu'en incident de production — le prolongement de l'hygiène décrite dans notre guide de sécurisation des credentials.

Les quatre opérations du node

Le node Microsoft SQL est plus sobre que ses cousins MySQL et Postgres : quatre opérations, pas six.

• Execute Query — un champ SQL libre, avec un éditeur en dialecte MSSQL. C'est l'opération centrale.
• Insert — une Table et une liste de Columns séparées par des virgules ; les valeurs viennent des champs du même nom sur les items entrants.
• Update — même logique, plus une Update Key (id par défaut) qui désigne la propriété servant à identifier les lignes à modifier.
• Delete — une Table et une Delete Key (id par défaut).

Pas d'opération Select ni d'upsert intégré : toute lecture passe par Execute Query, et un MERGE s'écrit à la main. La majorité des workflows SQL Server dans n8n n'utilisent d'ailleurs qu'Execute Query, en lecture.

Requêtes paramétrées : $1, $2 et rien d'autre

Le réflexe à éliminer immédiatement : écrire WHERE client = '{{ $json.client }}' dans le champ Query. La valeur est concaténée telle quelle dans le texte SQL — un nom contenant une apostrophe casse la requête, une valeur forgée par un tiers en détourne la logique. Dans les Options de l'opération Execute Query, activez Query Parameters : marqueurs numérotés dans la requête, valeurs fournies à part, séparées par des virgules.

SELECT c.numero, c.date_commande, c.montant_ht, t.raison_sociale
FROM dbo.commandes c
JOIN dbo.tiers t ON t.code_tiers = c.code_tiers
WHERE c.date_commande >= $1 AND c.statut = $2
ORDER BY c.date_commande DESC

avec {{ $json.dateDebut }}, {{ $json.statut }} dans Query Parameters. La syntaxe est celle du node Postgres ($1, $2) et non celle du node MySQL (? positionnels) — un détail qui coûte une demi-heure à qui bascule d'un node à l'autre. Notre guide du node Postgres détaille le même mécanisme côté PostgreSQL.

Pourquoi ce n'est pas négociable : séparer le canal de la requête de celui des données est la contre-mesure structurelle contre l'injection SQL, là où les filtrages de chaînes se contournent. Les travaux de Boyd et Keromytis, SQLrand: Preventing SQL Injection Attacks (ACNS 2004 — voir sur Google Scholar), l'illustrent par l'absurde : leur défense rend la grammaire SQL imprévisible pour l'attaquant, précisément parce que toute valeur atteignant l'analyseur par le même canal que la requête est potentiellement exécutable. Attention : les paramètres portent sur des valeurs, jamais sur un nom de table ou de colonne — un nom dynamique se valide contre une liste blanche dans un node Code en amont.

Cas d'usage : sortir les données de l'ERP vers un CRM et un tableau de bord

Un pipeline typique, en lecture seule :

1. Schedule Trigger, chaque nuit à 3 h.
2. Microsoft SQL (Execute Query) lit les clients modifiés depuis la dernière exécution, types convertis explicitement :

SELECT LOWER(CAST(t.guid AS varchar(36)))         AS id_externe,
       t.raison_sociale,
       t.email,
       CONVERT(varchar(33), t.date_modif, 126)    AS modifie_le
FROM dbo.tiers t
WHERE t.date_modif >= $1 AND t.email IS NOT NULL
ORDER BY t.date_modif
OFFSET $2 ROWS FETCH NEXT 500 ROWS ONLY

3. Un node Loop Over Items incrémente $2 de 500 tant que la requête renvoie des lignes.
4. Un node HubSpot (ou Pipedrive) fait l'upsert côté CRM sur id_externe.
5. En parallèle, une requête d'agrégation alimente un tableau de bord — le node Power BI, décrit dans notre guide Power BI, prend le relais.

Le pattern clé est la fenêtre incrémentale : date_modif >= $1, avec $1 égal à l'horodatage de la dernière exécution réussie, stocké dans une Data Table. Relire toute la table chaque nuit tient un mois, puis devient ingérable.

Brancher un LLM sur la base SQL Server

Le résumé quotidien. Une requête d'agrégation cadrée (chiffre d'affaires du jour, commandes en retard, ruptures de stock), le résultat passé à un node LLM avec un prompt demandant une synthèse de cinq lignes, envoi sur Slack ou par email. Le modèle ne touche jamais la base : il met en forme un résultat calculé en SQL. Le montage le plus fiable, et le plus simple à maintenir.

L'interrogation en langage naturel. Le node Microsoft SQL est ici attaché comme outil à un node AI Agent, qui écrit lui-même la requête — plus puissant, nettement plus risqué. Notre article sur l'interrogation d'une base en langage naturel détaille le montage ; deux garde-fous y sont non négociables : un compte SQL en lecture seule limité à des vues créées pour l'agent, et un schéma restreint dans le prompt système.

Le benchmark BIRD de Li et al., Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs (NeurIPS 2023 — arXiv:2305.03111), donne la mesure de la fiabilité attendue : construit sur 95 bases réelles totalisant plus de 33 Go, avec des contenus « sales » et des noms de colonnes ambigus, il place les meilleurs modèles de l'époque loin derrière la précision d'exécution humaine. Une base d'ERP français, avec ses tables aux noms tronqués et ses codes métier implicites, ressemble bien plus à BIRD qu'à une démo à deux tables. En pratique : gardez l'agent en lecture, faites-lui afficher la requête générée, préférez des vues préparées aux tables brutes. Pour des questions portant sur des documents plutôt que sur des chiffres, une architecture RAG comme celle de notre guide RAG avec Supabase reste le meilleur outil.

Pièges fréquents

• L'instance est sur un réseau privé, injoignable depuis n8n Cloud. Aucun réglage de credential ne corrigera ça : il faut un tunnel, un VPN, ou une instance n8n self-hosted sur le même réseau. Notre comparatif self-hosted vs Cloud pose l'arbitrage — pour un SQL Server on-premise, il penche toujours du même côté.
• ECONNREFUSED depuis Docker. Si SQL Server tourne sur l'hôte et n8n dans un conteneur, localhost désigne le conteneur : utilisez host.docker.internal ou l'IP LAN. Vérifiez aussi que TCP/IP est activé dans SQL Server Configuration Manager. Notre article sur l'erreur ECONNREFUSED en Docker déroule le diagnostic.
• Le Request Timeout à 15 secondes. Une agrégation sur plusieurs années de commandes le dépasse facilement. Augmentez la valeur, mais surtout optimisez : filtrez sur une période, ajoutez l'index qui manque, ou passez par une vue côté SQL Server.
• Charger toute la table en un item. Un SELECT * sur 400 000 lignes fera exploser la mémoire du worker. Paginez avec OFFSET … FETCH NEXT … ROWS ONLY, qui exige un ORDER BY déterministe sous peine de doublons entre deux pages.
• Les types mal sérialisés. datetime et datetime2 peuvent arriver avec un décalage de fuseau inattendu, uniqueidentifier ressort en GUID majuscule, money et decimal perdent parfois en précision en JSON. Convertissez explicitement dans la requête (CONVERT(varchar(33), col, 126), CAST(col AS varchar(36))).
• Le node s'exécute par item. Un Execute Query alimenté par 300 items lance 300 requêtes : agrégez en amont.

Pour aller plus loin

SQL Server est rarement la destination d'un workflow n8n : presque toujours la source, le point de départ d'un flux qui finit dans un CRM, un tableau de bord ou un assistant. Une fois les données sorties proprement, le Pack Assistant RAG (119 €) montre comment les rendre interrogeables — indexation, recherche vectorielle, réponse sourcée — et le Pack Conformité & Audit (149 €) comment tracer chaque accès à une base métier, rarement facultatif quand la source est l'ERP de l'entreprise.