Vous hébergez l’infrastructure d’un client et hésitez entre des CAL RDS « classiques » (paiement unique) et un abonnement SPLA/SAL (mensuel) ? Voici un guide concret, orienté conformité et coûts, pour choisir sans risque entre modèle perpétuel et modèle par abonnement.
Nature de la question
Un partenaire Microsoft qui exploite un environnement Windows Server pour le compte d’un client doit décider s’il convient d’acheter des Remote Desktop Services Client Access Licenses (RDS CALs) en mode « Per User » ou « Per Device », ou de passer par un abonnement mensuel de type Subscriber Access License (SAL) dans le cadre d’un contrat SPLA (Services Provider License Agreement). L’enjeu : payer une fois lorsque l’infrastructure est dédiée au client, ou payer au mois et par utilisateur autorisé lorsque le service est mutualisé (multi‑tenant) et fourni par l’hébergeur comme un service.
Points clés de la réponse
| Aspect | CAL RDS « classique » (Per User / Per Device) | SAL RDS (Service Provider) |
|---|---|---|
| Type de contrat | Licences en volume (Open Value, CSP, MPSA, etc.) | SPLA (Services Provider License Agreement) |
| Facturation | Paiement unique par licence ; aucun coût mensuel direct† | Paiement mensuel par utilisateur unique autorisé |
| Durée | Perpétuelle (droit d’usage illimité sur la version achetée) | Abonnement mensuel, accord SPLA avec engagement contractuel (3 ans) |
| Mise à niveau | Non incluse ; nécessite Software Assurance (SA) pour bénéficier des futures versions | Incluse nativement : l’abonnement couvre la version la plus récente |
| Contexte d’usage | Environnement on‑premises ou hébergement dédié à un seul client | Hébergement multi‑tenant (DaaS, RDS mutualisé, applications publiées multi‑clients) |
† Des frais indirects peuvent exister : mise en place d’un serveur de licences RDS, tenue des preuves d’attribution des CALs, et éventuellement Software Assurance si le client souhaite les droits de nouvelle version ou la mobilité via des programmes spécifiques.
Avantages / limites à garder en tête
| Option | Avantages | Limites / Risques | Idéal quand… |
|---|---|---|---|
| CAL RDS Per User / Per Device | Investissement unique (CAPEX) ; simplicité de suivi par utilisateur ou par poste ; excellent pour des effectifs stables. | Pas d’upgrade inclus sans SA ; gestion administrative des attributions ; moins flexible si le nombre d’utilisateurs fluctue fortement. | L’environnement est mono‑client (dédié), l’effectif est plutôt stable, horizon d’usage > 24‑36 mois. |
| SAL RDS via SPLA | OPEX pur ; montée/descente mensuelle ; droits toujours à jour (dernière version) ; conforme au multi‑tenant. | Coût récurrent ; obligation de déclarer chaque mois les utilisateurs autorisés ; gestion contractuelle SPLA. | Service multi‑tenant (DaaS/applications) avec effectifs variables ou démarrage sans CAPEX. |
Recommandations pratiques
Environnement dédié à un seul client
- Achetez des CAL RDS « Per User » ou « Per Device » selon votre mode d’usage.
- Il s’agit d’un paiement unique, valable pour la version de Windows Server en cours au moment de l’achat.
- Ajoutez la Software Assurance si le client veut des droits de nouvelle version (et, le cas échéant, des scénarios de mobilité autorisés par les programmes concernés).
Service mutualisé fourni par l’hébergeur
- Souscrivez un contrat SPLA et déclarez mensuellement le nombre d’utilisateurs via des SAL RDS.
- Profitez du modèle pay‑as‑you‑go : pas de CAPEX, ajustement au réel, conformité avec les règles d’hébergement multi‑tenant.
Gestion technique (indispensable)
- Installez et activez un serveur de licences RDS (RD Licensing).
- Approvisionnez les CALs (ou déclarez les SALs côté SPLA) et configurez le mode (Per User / Per Device) dans les paramètres RDS ou via GPO.
- Conservez un registre d’attribution (utilisateur, UID, date d’affectation, motif) pour prouver la conformité en cas d’audit.
Points d’attention juridiques
- Les CALs RDS standard ne sont pas destinées à être recommercialisées en mode service multi‑clients.
- Les SALs SPLA impliquent une déclaration mensuelle tant que l’accord n’est pas résilié, y compris si l’activité est faible.
Informations complémentaires utiles
- Mixité interdite : sur un même serveur RDS, on ne mélange pas CALs standard et SALs.
- Compatibilité descendante : une CAL RDS de version N autorise l’accès à des serveurs Windows Server ≤ N (l’inverse n’est pas vrai).
- Audit SPLA : conservez les journaux de connexion, exports usuels (Event Logs, RDS Usage), feuilles de calcul d’allocation pour justifier le comptage des « utilisateurs autorisés ».
- License Mobility / QMTH : avec Software Assurance, certains scénarios de mobilité vers un Qualified Multitenant Host (QMTH) peuvent être éligibles selon les termes en vigueur.
Comparer les modèles : coûts, risques et horizon d’usage
Au‑delà des aspects réglementaires, le choix « CAL perpétuel » vs « SAL mensuel » se décide souvent sur trois axes : stabilité des effectifs, horizon d’usage et qualité du multi‑tenant.
CAPEX vs OPEX : le point d’équilibre
| Paramètre | Symbole | Définition |
|---|---|---|
| Nombre d’utilisateurs | N | Utilisateurs accédant à RDS (ou appareils, si Per Device) |
| Coût unitaire d’une CAL RDS | PCAL | Prix d’acquisition (hors SA) |
| Coût SA annuel par CAL (facultatif) | PSA | Si le client veut les droits de nouvelle version |
| Coût SAL mensuel par utilisateur | PSAL | Déclaré chaque mois dans le SPLA |
| Horizon en mois | H | Durée prévisionnelle du service |
Coût CAL sur H mois ≈ N × PCAL + (H/12) × N × PSA (si SA sélectionnée).
Coût SAL sur H mois ≈ H × N × PSAL.
Règle pratique : plus H est long et N stable, plus le modèle CAL (CAPEX) devient économiquement favorable. À l’inverse, si N varie (saisonnalité, projets), la flexibilité SAL (OPEX) peut l’emporter, surtout en début d’activité.
Exemple illustratif (valeurs indicatives, non contractuelles)
Supposons N=50, H=36 mois, PCAL=X €, PSA=Y € par an, PSAL=Z € par mois :
- CAL ≈
50×X + 3×50×Y - SAL ≈
36×50×Z
Calculez les deux montants ; choisissez le plus bas sous la contrainte réglementaire (dédié → CAL ; multi‑tenant → SPLA/SAL).
Architecture et cas d’usage
Environnement dédié (mono‑client)
- Serveurs (physiques/virtuels) réservés à un seul client.
- RDS CAL « Per User » privilégiées quand les utilisateurs se connectent depuis plusieurs appareils.
- RDS CAL « Per Device » pertinentes pour des postes partagés ou des salles.
Service multi‑tenant (DaaS / applications publiées)
- Infrastructures mutualisées entre plusieurs entreprises.
- SPLA + SAL requis pour fournir la capacité comme un service.
- Comptez les « utilisateurs autorisés » (licence par personne nommée) et déclarez‑les mensuellement.
Cas frontaliers
- Hébergement dédié chez l’hébergeur : si les ressources sont réellement dédiées à un seul client (sans mutualisation), les CALs classiques peuvent être appropriées.
- Mobilité de licences : si le client possède des CALs avec SA, vérifiez les programmes en vigueur (p. ex. QMTH) applicables au scénario visé.
Mise en œuvre pas‑à‑pas (côté technique)
Installer et activer le serveur de licences RDS
- Ajouter le rôle Remote Desktop Licensing sur un serveur Windows Server.
- Ouvrir RD Licensing Manager et activer le serveur de licences.
- Installer les CALs RDS (ou enregistrer l’usage côté SPLA/SAL).
- Dans Remote Desktop Services → Deployments, définir le mode de licences (Per User / Per Device) et le ou les serveurs de licences.
Configurer via GPO (recommandé)
- GPO : Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → RD Session Host → Licensing.
- Activer : Use the specified Remote Desktop licensing servers et Set the Remote Desktop licensing mode.
Tenue des preuves
- Journaliser les connexions (Event Logs, Security, RDS Connections).
- Maintenir une liste nominative des utilisateurs (ou des appareils) titulaires d’une CAL ou autorisés en SAL.
- Conserver les contrats, bons de commande, certificats de licence et captures d’écran de configuration.
Erreurs fréquentes (et comment les éviter)
- Mélanger CAL et SAL sur un même serveur : interdit. Créez des fermes séparées si vous devez opérer les deux modèles.
- Confondre « utilisateur autorisé » et « utilisateur connecté » en SPLA : le comptage se fait sur l’habilitation, pas seulement sur la connexion effective.
- Oublier la SA et perdre le droit aux versions futures alors qu’une mise à niveau est prévue.
- Mauvais mode (Per Device vs Per User) : choisissez selon le profil d’accès, pas par habitude.
- Absence de registre : sans registres d’attribution, la conformité devient difficile à démontrer lors d’un audit.
Migration et coexistence
Passer de CAL vers SPLA/SAL
- Monter une nouvelle ferme RDS sous SPLA (isoler le multi‑tenant).
- Définir la date de bascule, migrer les collections et rediriger progressivement les utilisateurs.
- Mettre à jour la documentation conformité (listes nominatives, journaux, contrats).
Passer de SPLA/SAL vers CAL
- Valider que la cible est dédiée à un seul client.
- Acquérir et déployer les CALs, désigner le nouveau serveur de licences.
- Mettre fin à la déclaration SAL correspondante une fois la bascule achevée.
FAQ (les questions les plus posées)
Les CAL RDS « Per User » ou « Per Device » sont‑elles un paiement unique ?
Oui. Les CALs classiques sont perpétuelles pour la version achetée. Il n’y a pas de coût mensuel direct, hors frais indirects (serveur de licences, tenue des registres, etc.).
Quand utiliser un abonnement mensuel (SAL via SPLA) ?
Dès que vous fournissez un service multi‑tenant (DaaS, applications RDS pour plusieurs entreprises) ou que vous souhaitez une flexibilité mensuelle sans CAPEX.
Peut‑on combiner CALs et SALs sur un même serveur ?
Non. Pas de mixité sur un serveur RDS. En pratique, on sépare les fermes (ou les collections) selon le modèle retenu.
Les CALs couvrent‑elles les futures versions de Windows Server ?
Non, sauf si vous ajoutez la Software Assurance, qui ouvre les droits de nouvelle version selon les conditions applicables.
Comment compter en SPLA : par utilisateur connecté ou autorisé ?
Par utilisateur unique autorisé (nominatif). Le comptage ne se limite pas aux connexions effectives.
Et si l’environnement est hébergé chez un partenaire mais reste dédié à un seul client ?
Le modèle CAL reste pertinent si l’infrastructure est réellement dédiée au client et non mutualisée.
Que se passe‑t‑il en cas d’audit ?
On doit prouver la conformité : journaux de connexion, liste nominative d’attribution, certificats de licences, paramètres de configuration, et rapports mensuels SPLA le cas échéant.
Quid de la compatibilité de version des CALs ?
Une CAL de version N autorise l’accès à des serveurs de version ≤ N. L’inverse n’est pas valable.
La SA est‑elle obligatoire ?
Non. Elle est facultative mais recommandée si vous prévoyez des migrations de version ou des scénarios de mobilité.
Peut‑on transférer des CALs d’un client à un autre ?
En règle générale, non. Les CALs standard ne sont pas destinées à être transférées entre clients en dehors du cadre contractuel complet.
Check‑list décisionnelle (rapide)
- Votre environnement est‑il dédié à un seul client ? → Oui : CAL. Non : SPLA/SAL.
- Vos effectifs varient fortement ? → SAL (flexibilité). Non : CAL (investissement unique).
- Vous voulez toujours la dernière version sans gestion de SA ? → SAL.
- Vous visez un horizon d’usage long (≥ 36 mois) et stable ? → CAL.
Modèle simple de registre d’attribution
| Utilisateur / Appareil | Type (Per User / Per Device / SAL) | Identifiant (UPN / Asset) | Date d’attribution | Serveur / Collection | Notes (révocation, remplacement) |
|---|---|---|---|---|---|
| jdupont | Per User | jdupont@entreprise.fr | 2025‑03‑12 | RDS‑FARM‑PROD / COL‑APPS | Attribuée projet ERP |
| PC‑AGENCE‑01 | Per Device | INV‑PC‑000234 | 2025‑04‑02 | RDS‑FARM‑SITE‑LYON / COL‑VDI | Poste partagé accueil |
| msanchez | SAL | msanchez@client‑b.com | 2025‑07‑01 | RDS‑SPLA‑POOL / COL‑SaaS‑FIN | Ajouté juin → déclaré juillet |
Conseils de gouvernance et conformité
- Standardisez la procédure d’attribution (création, validation, révocation) et auditez‑la trimestriellement.
- Segmentez les fermes selon le modèle (CAL vs SPLA) pour éviter toute contamination réglementaire.
- Documentez vos hypothèses (définition d’« utilisateur autorisé », périmètre, exclusions).
- Réexaminez le modèle économique au moins annuellement (variation des effectifs, roadmap de versions).
Synthèse opérationnelle
Les CAL RDS « classiques » constituent bien un paiement unique (perpétuel pour la version achetée) et conviennent parfaitement aux environnements dédiés avec effectifs relativement stables. Les SAL via SPLA offrent, elles, un abonnement mensuel adapté aux services multi‑tenants et aux besoins de flexibilité (montée/descente d’utilisateurs), avec l’avantage d’être toujours alignées sur la version la plus récente.
Le bon choix découle d’un double filtre : topologie (dédiée vs mutualisée) et préférence financière (CAPEX vs OPEX). Appliquez la check‑list, calculez votre point d’équilibre, segmentez vos fermes, et gardez des preuves : vous serez conforme, lisible et rentable.
Avertissement : cet article fournit un cadre de décision et des bonnes pratiques. Les conditions des programmes Microsoft évoluent ; vérifiez toujours les termes contractuels applicables à votre situation et à votre région avant de vous engager.