La dépense SQL Server ne vient pas seulement du prix d’une licence. Elle résulte du parc réellement déployé, des éditions, de la virtualisation, des droits contractuels, de la capacité et des choix de haute disponibilité.
À retenir
- L’inventaire doit relier technique, propriété, criticité et droits.
- Le modèle de licence dépend de l’architecture et des contrats applicables.
- La haute disponibilité doit être conçue avec la résilience et les droits en même temps.
- Le right-sizing commence par la performance et la capacité, pas par une réduction arbitraire.
1. Construire un inventaire défendable
Le point de départ est un inventaire rapprochant hôtes physiques, clusters, machines virtuelles, instances, éditions, versions, bases, propriétaires, usages et criticité. Les outils de découverte doivent être complétés par la connaissance applicative : une instance “inactive” peut porter un traitement mensuel critique.
Les environnements de développement, test, recette, secours et reprise doivent être identifiés séparément, avec leur mode d’utilisation réel.
2. Cartographier les droits, pas seulement les clés installées
Les droits dépendent du programme de licence, de l’édition, du modèle choisi, de la Software Assurance, des dates et des termes applicables. Le produit installé ne suffit pas à déterminer la conformité.
La DSI, les achats et le spécialiste licence doivent partager une source commune : contrats, Product Terms, preuves d’achat, affectations et historique des changements.
3. Choisir le modèle de licence en fonction des accès et de l’architecture
SQL Server est proposé selon plusieurs modèles, notamment par cœur et, dans certains cas, serveur plus CAL. Le bon choix dépend du nombre et de la nature des utilisateurs ou appareils, de l’exposition des applications, de la virtualisation et des droits contractuels.
Une application accessible à une population large ou indirecte se prête rarement à une estimation simpliste des utilisateurs. L’accès multiplexé ne supprime pas nécessairement les obligations de licence.
4. Vérifier que l’édition correspond aux fonctions utilisées
Enterprise et Standard n’offrent pas les mêmes limites ni les mêmes fonctions. Une édition supérieure peut être justifiée par la performance, la disponibilité ou la virtualisation ; elle peut aussi rester installée par héritage alors que le besoin a évolué.
Le downgrade ne se décide pas sur une liste de fonctions. Il nécessite tests de performance, capacité, disponibilité et exploitation.
5. Relier virtualisation, mobilité et droits de licence
Le placement des VM, la mobilité, les clusters et l’affectation des licences ont un impact majeur. Une architecture techniquement flexible peut devenir coûteuse si les mouvements ne sont pas cohérents avec les droits de réaffectation ou les avantages de Software Assurance.
La gouvernance doit inclure les règles de placement et empêcher la création incontrôlée d’instances sur des hôtes non couverts.
6. Intégrer la haute disponibilité dans le modèle économique
Les réplicas passifs, les droits de secours et les usages en lecture dépendent des termes applicables. Un secondaire utilisé pour reporting, sauvegarde ou contrôles peut ne plus être considéré comme strictement passif selon le contexte contractuel.
L’architecture de résilience doit donc être conçue avec les achats et le spécialiste licence, sans réduire la sécurité pour économiser.
7. Right-sizer le moteur et l’infrastructure
Des cœurs surdimensionnés, des VM anciennes, une mémoire mal réglée ou une consolidation mal pensée augmentent simultanément coût et risque. La baseline doit distinguer besoin de capacité, inefficacité SQL et marge de résilience.
Une réduction de cœurs n’est pertinente que si les temps de réponse, pics, maintenance et reprise restent conformes.
8. Intégrer le cycle de vie dans le coût total
Une version hors support peut maintenir une application, mais elle augmente les risques, la complexité de sécurité et le coût des options de support étendu. SQL Server 2022 bénéficie d’un cycle de support défini ; SQL Server 2025 est la version majeure actuelle documentée par Microsoft.
La trajectoire doit tenir compte de la compatibilité applicative, des tests, du système d’exploitation, des drivers et de la capacité d’exploitation, pas seulement de la date de fin de support.
9. Installer une gouvernance FinOps SQL Server
Le tableau de bord rapproche coûts, droits, capacité, criticité, versions, incidents et actions. Les décisions doivent être prises avec architecture, exploitation, achats, finance et métiers.
Les indicateurs utiles incluent instances sans propriétaire, éditions Enterprise non justifiées, cœurs alloués et utilisés, versions à risque, secondaires actifs, environnements non-productifs et taux de consolidation.
Sources et références
Les choix d’architecture, de sécurité et de licence doivent être validés au regard de la version, de l’édition, du contrat et des exigences propres à l’organisation.