2) Ai-je encore besoin de CAL utilisateur/appareil avec la licence de base ?

Non. L'accès au serveur SQL n'est plus lié à des utilisateurs ou à des appareils individuels, mais uniquement aux cœurs de CPU correctement licenciés. Cela signifie qu'il n'est pas nécessaire de savoir si l'accès est direct ou indirect, si des services supplémentaires sont ajoutés ou si le nombre d'utilisateurs internes ou externes change. Le seul facteur décisif est que le matériel ou la machine virtuelle utilisé(e) dispose d'une licence complète conformément aux spécifications des cœurs.

3) SQL Server Enterprise est-il "illimité en termes d'utilisateurs" ?

Avec SQL Server Enterprise, les licences sont basées sur les cœurs de CPU. Cela signifie que si tous les cœurs requis sont correctement concédés, un nombre illimité d'utilisateurs et d'appareils peuvent accéder au serveur. Dans ce modèle, il n'y a pas de CAL d'utilisateur ou d'appareil et donc pas de limite supérieure fixe d'utilisateurs. Le seul facteur décisif est que le matériel ou la machine virtuelle utilisé(e) soit entièrement concédé(e) sous licence en fonction des cœurs. Cela signifie que les utilisateurs ne doivent pas compter les utilisateurs ou acheter des CAL supplémentaires tant que la licence par cœur est correcte.

4) SQL Server Standard peut-il également être exploité sans CAL ?

Oui, mais uniquement si SQL Server Standard est concédé sous licence par cœur. La nécessité de disposer de CAL dépend uniquement du modèle de licence choisi. Si SQL Server Standard est utilisé dans le modèle "Server + CAL", des CAL d'utilisateur ou d'appareil doivent également être disponibles pour tous les accès. En revanche, si SQL Server Standard est concédé sous licence par cœur, aucune CAL n'est nécessaire, car l'accès est entièrement couvert par les cœurs de CPU concédés sous licence.

5) Peut-on mélanger les User CALs et les Device CALs dans le même environnement ?

Oui. Dans les environnements mixtes, il est courant et autorisé d'utiliser les User CALs et les Device CALs en parallèle. Il est important que chaque accès fasse l'objet d'une licence unique et complète. Par exemple, vous pouvez couvrir les utilisateurs du bureau, de l'informatique ou de l'administration via des User CAL, tandis que les postes de travail partagés ou les terminaux dans l'entrepôt sont concédés via des Device CAL. Cette combinaison est souvent la solution la plus économiquement viable, car elle reflète de manière réaliste le comportement d'utilisation réel et évite les coûts de licence inutiles.

6) L'accès indirect par le biais d'applications, d'API, de frontaux web ou de logiciels intermédiaires est-il également considéré comme nécessitant une CAL ?

Oui. L'accès indirect est également considéré comme un accès nécessitant une licence. Par exemple, si des employés accèdent à des données de SQL Server via un système ERP, une application web ou un logiciel intermédiaire, ces personnes sont toujours considérées comme des utilisateurs accédant. Peu importe que la connexion soit techniquement groupée ou établie via une application intermédiaire. Le facteur décisif est que les personnes ou les appareils accèdent en fin de compte aux données de SQL Server - et cet accès doit être couvert par des CAL d'utilisateurs ou d'appareils correspondants dans le modèle serveur + CAL.

7) Que signifie "multiplexage" et pourquoi est-ce pertinent pour les clients CAL ?

Le multiplexage se réfère à des mécanismes techniques qui regroupent ou réduisent les connexions directes à SQL Server, par exemple par le biais de la mise en commun de connexions, d'intergiciels, de serveurs de terminaux, de serveurs d'applications centraux ou de services de reporting. Cela donne souvent l'impression que seul le système intermédiaire doit faire l'objet d'une licence. Or, cela n'est pas correct du point de vue de la législation sur les licences. Si les utilisateurs finaux ou les appareils finaux accèdent effectivement aux données du serveur SQL via cette couche intermédiaire, ils sont toujours considérés comme accédant aux utilisateurs ou aux appareils. Dans le modèle Serveur+CAL, ces accès restent donc entièrement soumis à la licence, quel que soit le nombre de connexions techniques existant réellement avec le serveur SQL.

8) Avec Serveur+CAL, une CAL par serveur ou par base de données est-elle suffisante ?

Non. Les CAL sont des licences d'accès, pas des "modules d'extension de serveur". Une CAL s'applique soit à un utilisateur, soit à un appareil. Le serveur fait l'objet d'une licence distincte. Si une entreprise exploite plusieurs serveurs SQL, l'approche "une CAL par serveur" est fondamentalement erronée, car les CAL ne sont pas "consommées" serveur par serveur, mais représentent des droits d'accès. Pour la communication avec les clients, il est préférable d'expliquer cela strictement comme "accès par utilisateur/appareil" et non en unités de serveur.

9) Si j'exécute SQL Server dans une VM : cela change-t-il quelque chose à propos des CAL ou du modèle de licence ?

10) Quel est le problème typique avec les utilisateurs externes (clients, partenaires, extranet) ?

Le problème central avec les utilisateurs externes est la mise à l'échelle et la comptabilisation propre de l'accès. Le nombre d'utilisateurs externes fluctue souvent, est difficile à enregistrer clairement ou augmente considérablement avec l'utilisation d'un portail, d'un espace client ou d'un extranet. Dans de tels scénarios, le modèle "serveur plus CAL" devient rapidement source de confusion et d'erreurs, car chaque accès doit être pris en compte dans le cadre de la législation sur les licences. La licence de base est souvent la solution la plus robuste dans ce cas, car l'accès ne doit pas faire l'objet d'une nouvelle licence par personne externe et reste clair et traçable même si le nombre d'utilisateurs augmente ou change.

11) Quel rôle jouent les "cœurs minimums" et pourquoi cela conduit-il à de fausses attentes ?

En ce qui concerne les machines virtuelles, on s'attend souvent à ce qu'une très petite VM puisse également être couverte par une licence de taille correspondante, par exemple avec deux vCores. Toutefois, dans la pratique des licences, il existe des exigences minimales et des paquets de noyaux fixes qui s'appliquent indépendamment de l'allocation technique réelle. Cela signifie que la plus petite unité conforme à la licence est souvent plus grande que la VM elle-même. Cette différence entre la configuration technique et la taille minimale prévue par le droit des licences est souvent source de surprises. Le facteur décisif n'est donc pas seulement le nombre de cœurs attribués à une VM, mais aussi le nombre minimum de cœurs qui doivent être concédés sous licence conformément aux règles d'octroi de licences.

Disclaimer
Cet article est destiné à des fins d'information générale uniquement et ne constitue pas une recommandation de vente ou d'octroi de licence. Toutes les informations ont été compilées au mieux de nos connaissances, mais sont fournies sans garantie d'exhaustivité ou d'exactitude. Les conditions de licence sont susceptibles d'être modifiées et peuvent être interprétées différemment selon les cas. Le contenu ne remplace pas les conseils juridiques individuels ou les conseils en matière de licence.