Comment se connecter à SQL Server depuis macOS et Linux en 2026

SQL Server a longtemps été synonyme de Windows, d'ODBC et de Management Studio. Depuis SQL Server 2017 et l'arrivée du moteur sur Linux, la donne a changé : le protocole TDS est public, plusieurs implémentations natives existent en dehors de l'écosystème Microsoft, et il est aujourd'hui possible de se connecter à une instance SQL Server depuis macOS ou Linux sans installer le moindre composant Windows.

Cet article fait le tour des options disponibles en 2026, du terminal aux clients graphiques, et explique comment chacune gère les modes d'authentification typiques d'un environnement SQL Server : SQL auth, Windows Auth (NTLM ou Kerberos) et Azure Active Directory.

Les modes d'authentification à connaître

Avant de choisir un client, il faut savoir comment l'instance SQL Server attend ses identifiants. Quatre modes sont courants. SQL Authentication est le mode le plus simple : un login et un mot de passe stockés dans l'instance, exactement comme un utilisateur PostgreSQL. C'est le mode privilégié quand on se connecte depuis un OS non-Windows, parce qu'il ne dépend pas d'Active Directory.

Windows NTLM permet d'utiliser un compte de domaine au format DOMAIN\\user ou user@DOMAIN. Le client envoie un challenge NTLM à l'instance, qui le valide auprès du contrôleur de domaine. La plupart des implémentations TDS modernes supportent NTLM en cross-platform, à condition que le poste client puisse joindre le DC.

Windows Integrated réutilise la session Windows courante via SSPI. Hors Windows, on parle plutôt de Kerberos : un ticket obtenu via kinit peut être utilisé par certaines bibliothèques pour s'authentifier sans mot de passe. Le setup est plus exigeant car il demande une configuration Kerberos correcte (fichier krb5.conf, SPN du serveur, DNS).

Azure Active Directory concerne surtout Azure SQL Database et Azure SQL Managed Instance. L'authentification se fait par token OAuth2 (avec ou sans MFA). Le support varie d'un client à l'autre : Azure Data Studio l'intègre nativement, certains drivers JDBC nécessitent l'extension Microsoft, et les drivers TDS purement open source ne couvrent souvent que le flux par mot de passe.

sqlcmd via Docker, l'option terminal

Microsoft publie l'outil sqlcmd dans une image Docker officielle (mcr.microsoft.com/mssql-tools). C'est la voie la plus rapide pour se connecter depuis un poste macOS ou Linux sans installer la moindre dépendance native.

Une session typique tient en une commande : docker run -it --rm mcr.microsoft.com/mssql-tools /opt/mssql-tools/bin/sqlcmd -S serveur,1433 -U sa -P motdepasse -d ma_base. L'outil supporte SQL auth et Windows Auth (via Kerberos si l'image est configurée pour). Il ne gère pas AAD interactif, et son ergonomie reste minimaliste : pas d'historique persistant, pas d'autocomplétion, sortie tabulaire brute. C'est exactement le bon outil pour scripter ou diagnostiquer rapidement, mais pas pour explorer un schéma.

Azure Data Studio, le client officiel cross-platform

Azure Data Studio est l'héritier multi-plateforme de SQL Server Management Studio. Construit sur Electron et basé sur la même architecture que VS Code, il fonctionne nativement sur Windows, macOS et Linux. Côté authentification, il couvre l'ensemble du spectre : SQL auth, Windows Integrated, Windows NTLM et Azure AD avec MFA. Il sait aussi se connecter à Azure SQL via l'identité cloud signée dans l'OS.

Son point fort est la prise en charge complète des spécificités SQL Server : T-SQL, plans d'exécution graphiques, dashboards de monitoring, notebooks SQL, extensions PostgreSQL. Le revers est qu'il reste centré sur l'écosystème Microsoft. Pour qui jongle entre SQL Server, PostgreSQL et MongoDB, il devient un client de plus à ouvrir en parallèle.

DBeaver et DataGrip, les généralistes JDBC

DBeaver et DataGrip se connectent à SQL Server via JDBC. Tous deux embarquent le driver Microsoft mssql-jdbc, qui parle TDS et supporte SQL auth, NTLM, Kerberos et AAD (avec ou sans MFA selon la version du driver). L'avantage de l'approche JDBC est l'uniformité : ce sont les mêmes outils qui gèrent PostgreSQL, MySQL, Oracle et SQL Server.

L'inconvénient est la dépendance à une JVM. DBeaver embarque sa propre JRE depuis quelques versions, mais l'empreinte mémoire reste élevée et le démarrage à froid se sent. Le driver mssql-jdbc évolue rapidement côté AAD ; il faut souvent maintenir une version récente pour bénéficier des flux d'authentification les plus modernes (device code, managed identity).

QoreDB, driver Tiberius natif sans JVM

QoreDB embarque un driver SQL Server écrit en Rust et basé sur Tiberius, la bibliothèque TDS de référence de l'écosystème Rust, couplée au pool de connexions asynchrone bb8. Aucune JVM, aucun composant ODBC, aucun installateur Microsoft à déployer sur le poste. Le binaire de l'application contient tout ce qu'il faut pour ouvrir une connexion TDS sur le port 1433.

Côté authentification, le driver gère trois modes via une enum dédiée (MssqlAuthMode) : SqlAuth pour le login/password classique, WindowsNtlm pour les comptes de domaine au format DOMAIN\\user, et WindowsIntegrated pour réutiliser la session OS via SSPI sur Windows ou un ticket Kerberos sur Unix. La validation est faite avant la connexion : si on tente de configurer WindowsNtlm depuis macOS ou Linux sans format de domaine correct, l'erreur est renvoyée immédiatement avec un message explicite plutôt qu'un échec opaque côté serveur.

Le chiffrement suit la configuration de l'instance. Quand la connexion exige TLS, EncryptionLevel passe à Required et la négociation se fait avant l'envoi des identifiants. Les certificats du serveur sont vérifiés via les CA système, et il est possible de fournir un certificat personnalisé pour les instances avec PKI interne. Cette mécanique est la même que celle des autres drivers SQL de QoreDB, ce qui évite d'avoir à apprendre une configuration spécifique par moteur.

En pratique, depuis macOS ou Linux

Pour une instance accessible directement, SQL Auth reste le chemin le plus simple : un hostname, un port, un login, un mot de passe. Tous les clients cités fonctionnent dans ce cas, et les différences se jouent surtout sur l'ergonomie et l'empreinte mémoire.

Pour une instance derrière un domaine Active Directory, NTLM est généralement le mode qui fonctionne en cross-platform avec le moins de configuration. Il faut juste s'assurer que le poste résout le contrôleur de domaine et que le compte est au format attendu. Kerberos est plus propre conceptuellement mais demande un setup complet (krb5.conf, SPN, DNS reverse).

Pour une instance Azure SQL avec AAD interactif et MFA, Azure Data Studio reste la voie la plus directe. Les clients généralistes peuvent s'y connecter via le flux par mot de passe ou device code selon le driver, mais l'expérience est moins fluide.

Quand l'instance est derrière un bastion, le tunnel SSH est souvent inévitable. La plupart des clients desktop le supportent, mais avec des implémentations variables : DBeaver et DataGrip s'appuient sur JSch, QoreDB utilise une implémentation OpenSSH native intégrée à Tauri, sqlcmd dépend du tunnel de l'OS. Le scénario typique est : ssh -L 1433:sqlserver-interne:1433 bastion, puis connexion locale sur 127.0.0.1.

Conclusion

Se connecter à SQL Server depuis macOS ou Linux est devenu un cas d'usage banal en 2026. sqlcmd via Docker couvre le besoin terminal, Azure Data Studio reste la référence pour qui vit dans l'écosystème Microsoft, et les clients généralistes comme DBeaver, DataGrip ou QoreDB permettent de garder une interface unique pour toutes ses bases. Le choix dépend surtout du contexte : un poste qui jongle entre SQL Server et d'autres moteurs gagne à utiliser un client multi-bases, idéalement sans JVM pour réduire le coût mémoire. C'est le raisonnement qui a guidé l'intégration de Tiberius dans QoreDB : un driver TDS pur Rust, validé à la compilation, qui partage le même modèle d'authentification, de chiffrement et de tunneling que les autres drivers de l'application.