Vous exploitez un serveur SQL Server réservé au rôle de base de données ? La réponse courte est : cela dépend du modèle de licence choisi. Voici un guide complet, concret et à jour pour décider quand acheter des CAL et quand s’en passer.
Vue d’ensemble de la question
Un administrateur prépare un serveur dédié à SQL Server et s’interroge : faut‑il acheter des Client Access Licenses (CAL) pour chaque PC qui s’y connectera ? La confusion vient du fait que SQL Server propose deux modèles de licence très différents, avec des impacts budgétaires, techniques et organisationnels notables.
La règle de base est simple : si vous licenciez SQL Server « Per Core », aucune CAL n’est requise. Si vous licenciez « Serveur + CAL », chaque utilisateur ou appareil accédant au serveur (directement ou indirectement) doit être couvert. Toute la décision consiste donc à choisir, en connaissance de cause, le modèle le mieux adapté à votre contexte.
Réponses & solutions
| Modèle | Ce qu’il faut acheter | Quand l’utiliser | CAL nécessaires ? |
|---|---|---|---|
| Per Core | Une licence par cœur physique (ou par vCore attribué à la VM/conteneur) pour SQL Server Standard ou Enterprise | Grand nombre d’utilisateurs/appareils Difficulté à dénombrer les accès Scénarios publics, B2C, extranets, SaaS | Aucune |
| Serveur + CAL | 1 licence « SQL Server Standard (Server) » + 1 CAL par utilisateur ou par appareil | Population d’utilisateurs limitée et stable Accès internes bien identifiés | Oui : chaque accès direct ou indirect doit être couvert |
Avantages et limites de chaque modèle
| Modèle | Avantages | Points de vigilance |
|---|---|---|
| Per Core | Pas de CAL à gérer : simplifie l’audit Idéal pour les accès externes, anonymes ou fluctuants Prévisible côté capacité : on dimensionne par cœurs/vCores | Coût initial potentiellement plus élevé pour de petits effectifs Minimum de cœurs à licencier par serveur/VM |
| Serveur + CAL | Souvent le moins cher avec peu d’utilisateurs/appareils Simple à comprendre en contexte purement interne | Inventaire des utilisateurs/appareils à maintenir Accès indirects non dispensés de CAL (multiplexage) Peut devenir plus coûteux en cas de croissance |
Points clés à retenir
User CAL vs Device CAL
Une User CAL couvre un utilisateur, quel que soit l’appareil qu’il utilise (PC, mobile, poste en télétravail). Une Device CAL couvre un appareil partagé par plusieurs personnes (ex. : poste d’atelier, caisse, borne). Le bon choix dépend de vos habitudes d’accès :
| Profil d’usage | Exemples | CAL conseillé | Pourquoi |
|---|---|---|---|
| Utilisateurs nomades/multi‑devices | Commerciaux, cadres, télétravail | User CAL | Un seul droit pour tous les appareils de la personne |
| Postes partagés en équipes | Atelier, entrepôt, kiosques | Device CAL | Évite d’acheter une CAL par employé |
| Mix complexe | Bureaux + ateliers + mobilité | Mix User/Device | Optimise au cas par cas |
Accès indirects inclus
Tout accès via une application, un service web, un ETL, un cache ou une file d’attente compte comme un accès au sens des CAL. Le « multiplexage » (pooling de connexions, comptes de service, API intermédiaires) ne réduit pas la quantité de CAL requises : on compte les utilisateurs/appareils finaux qui consultent, saisissent ou extraient des données.
Éditions gratuites
Developer (usage Dev/Test) et Express (taille de base limitée, ressources restreintes) n’exigent pas de CAL, mais ne sont pas destinées à la production. Elles sont utiles pour les environnements de développement, d’intégration continue et de formation.
Virtualisation et conteneurs
- Per Core : licenciez les vCores affectés à chaque VM ou conteneur (avec un minimum par VM/conteneur). Pour des hôtes virtualisés, licencier tous les cœurs physiques (souvent avec Enterprise + Software Assurance) simplifie la mobilité des workloads.
- Serveur + CAL : chaque VM a besoin de sa propre licence « Server » ; les CAL restent valides pour accéder à toutes les instances couvertes. Ce modèle est rarement optimal dans de gros environnements virtualisés.
Bonnes pratiques
- Modélisez la croissance attendue : au‑delà d’un certain seuil d’utilisateurs ou de terminaux, Per Core devient plus économique et moins risqué en audit.
- Tenez un inventaire vivant des utilisateurs/appareils couverts (sources RH, MDM, IAM).
- Examinez les options Software Assurance (SA) : mobilité de licences, droits de basculement/failover, avantages hybrides avec le cloud.
- Avant achat, confrontez votre design (physique/virtuel, clusters, DR) aux règles en vigueur. Les termes peuvent évoluer.
Comment décider rapidement ?
Utilisez cette grille de lecture :
- Accès externes (clients, partenaires, grand public) ou volumes changeants : privilégiez Per Core.
- Accès strictement internes, stables et en nombre limité : Serveur + CAL peut réduire la facture.
- Virtualisation massive ou conteneurs en densité : Per Core est généralement plus simple et prévisible.
- Applications intermédiaires (ERP, CRM, portail) masquant la base : les utilisateurs finaux comptent en modèle CAL.
Calculer le point d’équilibre économique
Sans même connaître les tarifs exacts de votre contrat, vous pouvez comparer les modèles avec une formule simple :
Coût_total_Serveur+CAL = Prix_Licence_Server + (Nombre_CAL × Prix_CAL) Coût_total_PerCore = Nombre_cœurs_licenciés × Prix_par_cœur
Définissez trois scénarios (conservateur, nominal, ambitieux) en faisant varier le nombre d’utilisateurs/devices et la capacité CPU prévisionnelle (cœurs/vCores). Ajoutez :
- Le coût de la Software Assurance si vous la retenez (pour la mobilité, le failover, etc.).
- Les coûts d’administration : inventaire et gestion des CAL vs gouvernance de la capacité CPU.
Exemple fictif : si le coût marginal d’une CAL multiplié par vos utilisateurs réels + la licence Server dépasse le coût d’un petit paquet de cœurs, basculez vers Per Core. À l’inverse, si vous n’avez que quelques dizaines d’utilisateurs connus et peu d’évolutions prévues, Serveur + CAL restera gagnant pendant plusieurs années.
Cas d’usage concrets et recommandations
| Contexte | Symptômes | Recommandation | Raison |
|---|---|---|---|
| Intranet analytique pour 35 employés | Accès BI/rapports internes, peu de mobilité | Serveur + CAL (Device CAL si postes partagés) | Population stable et limitée |
| Portail clients B2C | Accès variables, grand public | Per Core | Impossible de compter les CAL, conformité simplifiée |
| Entrepôt avec 20 scanners partagés | Équipes en rotation, mêmes terminaux | Serveur + Device CAL | Un droit par terminal suffit |
| Force de vente de 80 commerciaux | Multi‑devices, mobilité forte | Serveur + User CAL ou Per Core si forte croissance | User CAL pratique ; bascule possible vers Per Core si effectif grimpe |
| Application interne + API pour partenaires | Accès internes et externes | Per Core | Les partenaires comptent dans le total des CAL en modèle CAL |
| Fermes de VM SQL | Haute densité, mobilité de charges | Per Core (Enterprise + SA souvent pertinent) | Souplesse de mobilité/failover, gestion centralisée des cœurs |
Spécificités techniques qui influencent la licence
Haute disponibilité et basculement
Les droits de basculement (failover) dépendent souvent de la présence de Software Assurance. En pratique, un nœud passif de secours exclusivement dédié au basculement peut bénéficier de droits allégés ; vérifiez que vos contrats couvrent votre topologie (Always On, réplication, log‑shipping, etc.).
Instances multiples et OSE
En Per Core, le périmètre de licence est le serveur/VM/conteneur (cœurs) ; vous pouvez exécuter plusieurs instances tant que le conteneur d’exécution couvert reste le même. En Serveur + CAL, la licence « Server » est par système d’exploitation invité (OSE) : plusieurs instances dans la même VM restent couvertes par la même licence Server, mais une seconde VM nécessitera une autre licence Server.
Accès en lecture seule, caches et exports
Une requête de lecture seule est un accès ; elle requiert donc une CAL en modèle CAL. L’export périodique (ETL) depuis SQL vers un data mart ne « masque » pas les besoins de CAL : les utilisateurs du data mart sont comptés s’ils accèdent aux données issues de SQL Server via des processus intermédiaires.
Confusions fréquentes
- CAL Windows Server ≠ CAL SQL Server : elles sont distinctes.
- CAL RDS ≠ CAL SQL Server : l’une porte sur l’accès à la session distante, l’autre à la base de données.
- Concurrents simultanés : il n’existe pas de notion de « n utilisateurs concurrents » pour réduire le volume de CAL.
- Comptes de service : on ne leur achète pas de CAL ; on couvre les utilisateurs/devices finaux.
Check‑list décisionnelle express
- Cartographiez qui accède à quoi : humains, robots, partenaires, public.
- Déterminez si les accès externes sont significatifs : si oui, orientez‑vous vers Per Core.
- Comptez les utilisateurs ou les appareils ; choisissez User vs Device CAL selon les usages.
- Évaluez la croissance à 12–36 mois (embauches, nouveaux usages, fusion/acquisition).
- Décidez si la virtualisation ou les conteneurs seront la norme.
- Examinez vos exigences de HA/DR et les droits offerts par la SA.
- Simulez le coût total Serveur+CAL vs Per Core (3 scénarios).
- Ajoutez les coûts d’administration/compliance (inventaire des CAL vs gestion de capacité CPU).
- Sélectionnez un modèle, puis documentez explicitement les hypothèses (populations couvertes, limites d’usage).
- Préparez le dossier d’audit : preuves d’achat, relevés d’instances, décompte utilisateurs/appareils, diagrammes d’architecture.
Gouvernance et conformité
La conformité n’est pas un exercice ponctuel. Mettez en place :
- Un registre des instances SQL Server (physiques, VM, conteneurs), avec cœurs/vCores alloués et éditions installées.
- Un référentiel des accès : sources applicatives, utilisateurs, partenaires, flux ETL, automatisations.
- Une procédure d’onboarding/offboarding qui synchronise IAM/MDM/HR avec l’inventaire des CAL.
- Des rapports périodiques (SQL Audit, connexion AD, journaux d’application) pour valider vos hypothèses.
- Un plan de bascule : quand passer de Serveur+CAL à Per Core (ou l’inverse) en cas de changement de périmètre.
FAQ rapide
Un serveur « back‑end » uniquement base de données dispense‑t‑il de CAL ?
Non. Si vous êtes en modèle Serveur+CAL, les utilisateurs/appareils accédant à l’application qui interroge SQL Server doivent être couverts, même si personne ne « se connecte » directement à la base.
Dois‑je couvrir les comptes techniques ?
Non, on couvre les utilisateurs ou appareils finaux derrière ces comptes, pas les comptes eux‑mêmes.
Un rapport automatisé par e‑mail évite‑t‑il une CAL ?
Non, car le destinataire « consomme » des données issues de SQL Server via un mécanisme indirect.
Que se passe‑t‑il si des partenaires accèdent à mon application ?
En Serveur+CAL, ils doivent être comptés. En pratique, quand les partenaires sont nombreux ou variables, le modèle Per Core est plus adapté.
Et si je copie mes données dans un data lake ?
Le fait d’extraire les données ne supprime pas les droits d’accès : si les utilisateurs exploitent ces données au travers d’un service qui interroge SQL Server, ils restent concernés par les CAL en modèle CAL.
Express ou Developer en production ?
Non : Developer est strictement réservé au Dev/Test, Express est limité techniquement et non prévu pour des charges de production significatives.
Dois‑je acheter une CAL par base de données ?
Non, les CAL couvrent l’accès à l’instance/serveur, pas à une base spécifique.
La lecture seule via réplica secondaire nécessite‑t‑elle des CAL ?
En modèle CAL, oui : l’accès reste un accès. En Per Core, non.
Faut‑il des RDS CAL pour SQL Server ?
Uniquement si vos utilisateurs se connectent via Services Bureau à distance ; ces CAL sont distinctes des CAL SQL Server.
Quand Enterprise s’impose‑t‑il ?
Fonctionnalités haut de gamme (haute dispo avancée, compression/partitionnement avancés, virtualisation à grande échelle) ou besoin d’unlimited virtualization sous conditions de licence et SA.
Résumé opérationnel
- Per Core : pas de CAL ; on paie la puissance CPU (physique ou virtuelle). Convient aux accès nombreux, externes ou imprévisibles, et aux environnements virtualisés à forte densité.
- Serveur + CAL : économique si le nombre d’utilisateurs/appareils est réduit, stable et bien identifié. Exige un inventaire rigoureux et n’exonère pas les accès indirects.
- Software Assurance : souvent déterminante pour le failover, la mobilité de licences et certains scénarios hybrides.
- Décision : basez‑la sur un modèle de coûts, votre trajectoire d’usage et la simplicité de conformité à long terme.
Modèle de décision prêt à l’emploi
Copiez/collez cette matrice dans votre dossier projet :
| Question | Oui | Non |
|---|---|---|
| Avez‑vous des accès externes ou publics ? | Per Core | Poursuivez l’évaluation |
| Le nombre d’utilisateurs/appareils est‑il < 100 et stable ? | Serveur + CAL (User ou Device) | Penchez vers Per Core |
| Virtualisation/containers à grande échelle ? | Per Core (Enterprise + SA à étudier) | Les deux modèles restent possibles |
| Besoin de failover/DR formalisé ? | Inclure SA dans la simulation | SA optionnelle (mais recommandée) |
| Inventaire des utilisateurs/devices simple à maintenir ? | Serveur + CAL viable | Per Core pour réduire le risque d’audit |
Conseils de mise en œuvre
- Établir l’inventaire : serveurs/VM/conteneurs, éditions, affectations CPU, cartes d’accès.
- Cartographier les flux : qui consomme quelles données, par quel chemin.
- Choisir le modèle et documenter les hypothèses (périmètre couvert, exclusions).
- Acquérir les droits en cohérence avec votre contrat (Open, CSP, EA) et vos besoins de SA.
- Automatiser les preuves : scripts d’inventaire, rapports d’audit SQL, exports IAM.
- Former les équipes (IT, achats, sécurité) aux règles de base pour éviter les erreurs coûteuses.
- Revoir annuellement : aligner licences et réalité opérationnelle (embauches, nouveaux projets, cloud).
Conclusion
Pour un serveur dédié à SQL Server, la question des CAL n’est pas liée au rôle « base de données » mais au modèle de licence : Per Core (zéro CAL) vs Serveur + CAL (une CAL par utilisateur ou appareil, y compris les accès indirects). Prenez votre décision à partir d’un modèle de coûts, de votre stratégie de virtualisation et de la cartographie réelle des accès. En cas de doute, simulez la croissance et privilégiez le modèle le plus simple à maintenir et à auditer.
En résumé : Per Core = pas de CAL, dimensionnement sur les cœurs. Serveur + CAL = moins cher pour peu d’utilisateurs, mais nécessite une couverture stricte de chaque connexion, même via des applications intermédiaires. Les éditions Express/Developer ne conviennent pas à la production. La Software Assurance peut changer la donne sur la mobilité et le basculement.