- Description
- Salle d’ordinateurs anciens, garnie d’unités de disques et de bandes magnétiques alignées.
- Source
- BadgersCP · page d’origine
- Licence
- CC0 Domaine public
SQL Server en SaaS — vue d'ensemble
Vous saurez situer précisément ce que recouvre « SQL Server en SaaS » : Azure SQL Database, Azure SQL Managed Instance, SQL database in Fabric, et SQL Server sur machine virtuelle comme…
En bref
- Vous saurez situer précisément ce que recouvre « SQL Server en SaaS » : Azure SQL Database, Azure SQL Managed Instance, SQL database in Fabric, et SQL Server sur machine virtuelle comme contraste.
- Vous saurez énoncer la nuance PaaS vs SaaS en une phrase, et ne plus vous laisser piéger par le vocabulaire commercial.
- Vous connaîtrez la promesse de ce choix d'architecture pour un reporting Power BI, ses limites, et les situations où c'est le bon choix (ou pas).
- Vous disposerez d'une grille de notes /5 (contexte explicite) pour comparer cette option à la voie OneLake décrite dans 01-onelake-mobile-saas-vue-d-ensemble.md.
- Vous saurez où poursuivre : architecture, pièges, IA.
Niveau : 🟢→🔴
Interprétation retenue du sujet#
Sujet 4b — « SQL Server en SaaS ». Il s'agit d'une base relationnelle managée dans le cloud (Azure SQL Database, Azure SQL Managed Instance, SQL database in Fabric ; SQL Server sur VM seulement pour contraste) servant de source à Power BI (Import, DirectQuery, composite, ou Direct Lake via mirroring), le service Power BI étant lui-même consommé en SaaS. Le fil rouge reste anonyme : un datamart SQL Server alimenté par une application de force de vente (SFA) terrain, avec des rapports Power BI multilingues, versionné en TFVC, livré en kits d'installation.
La question que pose ce dossier n'est pas « SQL Server est-il bon ? » (oui, depuis trente ans), mais : que change le fait de confier le moteur relationnel à un fournisseur cloud, et quel impact sur la chaîne de reporting ? Le dossier frère 01-onelake-mobile-saas-vue-d-ensemble.md traite l'autre voie (lakehouse/OneLake) ; le comparatif les met face à face.
Les bases : de quoi parle-t-on ?#
🟢 Novice — Les quatre formes de « SQL Server dans le cloud »#
Un moteur SQL Server peut être consommé de quatre manières, du plus « bricolé par soi » au plus « fourni clé en main » :
| Forme | Ce que vous gérez | Ce que le fournisseur gère | Parenté avec SQL Server « boîte » |
|---|---|---|---|
| SQL Server sur VM (IaaS) | Système, instance, sauvegardes, correctifs, haute disponibilité | Matériel, hyperviseur | Identique à 100 % |
| Azure SQL Managed Instance (PaaS) | Bases, logins, configuration d'instance (partielle) | Correctifs, sauvegardes, haute disponibilité, système | Quasi totale (SQL Agent, liens inter-bases, CLR, Service Broker…) |
| Azure SQL Database (PaaS) | Une base (ou un pool de bases), son schéma, ses performances | Serveur logique, correctifs, sauvegardes, HA, tuning optionnel | Forte, mais pas d'instance : pas de SQL Agent natif, pas de requêtes inter-bases classiques |
| SQL database in Fabric (SaaS, disponibilité générale depuis novembre 2025 ; état 2026-10) | Le schéma et les requêtes | Presque tout, y compris la capacité (partagée avec Fabric) | Moteur Azure SQL Database, miroir automatique vers OneLake |
Le point à retenir pour un novice : plus on descend dans le tableau, moins on administre et moins on a de contrôle. Ce n'est ni bon ni mauvais : c'est un curseur.
🟢 Novice — Pourquoi Power BI aime SQL Server#
Power BI sait lire une base relationnelle de trois façons (détaillées dans 06-sqlserver-saas-architecture.md) :
- Import : Power BI copie les données dans son moteur en mémoire (VertiPaq) à chaque actualisation ; les requêtes d'affichage ne touchent plus la base.
- DirectQuery : Power BI laisse les données en base et traduit chaque visuel en requête SQL.
- Direct Lake (via mirroring ou lakehouse) : le moteur lit directement des fichiers Delta dans OneLake ; la base SQL n'est alors plus interrogée à l'affichage.
Un datamart en étoile (tables de faits et de dimensions, voir le Kimball Toolkit) est la forme de données que ces trois modes digèrent le mieux. C'est exactement ce que produit un bon datamart : le modèle sémantique Power BI en devient presque un miroir.
PaaS ou SaaS : la nuance en une phrase#
En une phrase. Azure SQL Database et Managed Instance sont du PaaS (plateforme managée : vous livrez un schéma et du code, pas un serveur) ; seul Power BI — et, depuis son arrivée, SQL database in Fabric — relèvent du SaaS (vous consommez un service fini, sans choisir de machine ni de version) ; l'appellation « SQL Server en SaaS » est donc un raccourci commercial : la base est PaaS, le rapport est SaaS.
Pourquoi la nuance compte (voir ../GLOSSAIRE.md pour PaaS/SaaS/IaaS) :
- En PaaS, vous choisissez le niveau de service, la région, le niveau de compatibilité, la fenêtre de maintenance (limitée), et vous payez à la ressource réservée (DTU/vCore) même si la base dort, sauf serverless.
- En SaaS, la capacité est mutualisée : le coût et la performance se jouent sur une capacité Fabric/Power BI partagée entre tous les artefacts, et la « base » devient un artefact parmi d'autres.
- La responsabilité reste chez vous dans les deux cas : la qualité des données, le modèle, la sécurité des accès, la recette métier. Aucun niveau de service ne corrige un datamart mal conçu.
La promesse#
🟡 Pratique — Ce que le choix promet#
| Promesse | Contenu concret | Réserve honnête |
|---|---|---|
| Disparition de l'infrastructure | Plus de serveur à patcher, de disque à dimensionner, de sauvegarde à scripter | Il reste le dimensionnement logique (niveau de service) et la supervision |
| Haute disponibilité intégrée | SLA contractuel (de l'ordre de 99,99 % sur les niveaux Usage général/Standard, jusqu'à 99,995 % sur les niveaux critiques avec redondance de zone — à vérifier selon niveau et offre) | Un SLA n'est pas un RTO/RPO de votre métier ; une erreur humaine (DROP) n'est pas couverte, seulement la restauration à un instant (point-in-time) |
| Élasticité | Monter/descendre en puissance en quelques minutes, serverless avec pause automatique | La variabilité des performances complique la mesure (voir 07) |
| Évolution continue | Fonctionnalités SQL récentes disponibles sans migration | Le comportement change sous vos pieds : un plan d'exécution peut évoluer entre deux semaines |
| Intégration native Power BI | Connecteur SQL Server, SSO Entra, mirroring vers Fabric | Les limites du service Power BI (actualisations, taille de modèle) s'appliquent en aval |
| Sécurité d'entreprise | Entra ID, chiffrement au repos et en transit, audit, Defender, masquage dynamique, RLS | Le réseau privé impose passerelle ou endpoints privés : de la complexité réelle |
🟡 Pratique — Ce que le choix ne promet PAS#
- La fraîcheur temps réel : en Import, elle est celle de la dernière actualisation (au mieux quelques dizaines de fois par jour) ; en DirectQuery elle est instantanée, mais au prix de la performance.
- La vitesse : un modèle étoile bien indexé ou en Import est rapide ; un DirectQuery sur des vues compliquées est lent, cloud ou pas.
- Le faible coût : le cloud transforme le CAPEX en OPEX, il ne diminue pas mécaniquement la facture (cf. le thème coût de la matrice BI).
- La fin du travail de DBA : il change de nature (FinOps, tuning, gouvernance des accès) mais ne disparaît pas.
Un datamart SFA de 40 tables de faits/dimensions, ~150 millions de lignes de faits au total, consolidé la nuit. Sur SQL Server sur VM, l'équipe gérait 3 sauvegardes, 2 fenêtres de patch par an et un incident disque par an. Sur Azure SQL Database vCore, ces tâches disparaissent ; en échange, le coût mensuel devient une ligne de budget visible, et les temps de consolidation varient de ±30 à 100 % selon le voisinage de la ressource (ordre de grandeur observé sur des environnements de développement partagés, non généralisable).
Le cas pratique : un datamart SFA vu du cloud#
Trois remarques de lecture :
- La consolidation (T-SQL dans la base) reste le cœur de valeur : c'est la même qu'en local, mais exécutée sur une ressource élastique, d'où l'importance de la mesurer en CPU et non en temps horloge.
- Le mirroring (pointillés) est une option, pas une obligation : il ouvre la voie Direct Lake et rapproche les deux dossiers (OneLake et SQL).
- La livraison en kits d'installation (scripts rejoués sur chaque environnement) s'accommode bien du cloud, à condition d'avoir des comptes de déploiement avec les droits adéquats (cf. 06 — ALM).
Quand c'est le bon choix, quand ça ne l'est pas#
🟡 Pratique — Grille de décision#
| Situation | Verdict | Pourquoi |
|---|---|---|
| Datamart relationnel existant, équipe T-SQL, volumétrie < quelques To | Très bon choix | Compétences déjà là, migration quasi directe, Import suffit presque toujours |
| Besoin de requêtes inter-bases, SQL Agent, CLR, Service Broker | Managed Instance (pas SQL Database) | Surface de compatibilité d'instance |
| Charges très variables (pics mensuels, dev/test) | Bon choix si serverless ou pools élastiques | Paiement à l'usage, pause automatique |
| Données volumineuses semi-structurées, data science, multiples consommateurs | Plutôt OneLake | Lakehouse + Spark + Direct Lake (01) |
| Contrainte de souveraineté ou de réseau fermé strict | À étudier au cas par cas | Régions, endpoints privés, passerelle : faisable mais coûteux en complexité |
| Application tierce certifiée sur une version précise de SQL Server | VM | Compatibilité contractuelle |
| Latence quasi temps réel sur milliards de lignes | Autre architecture (eventstream, KQL, Real-Time Intelligence) | Hors du domaine fort du relationnel + Import |
Décidez par charge de travail, pas par « stratégie cloud » : consolidation nocturne lourde ≠ lecture interactive de 200 utilisateurs ≠ API d'écriture. Chacune peut justifier un niveau de service, voire une base distincte.
Symptôme : on choisit « le plus gros niveau » pour être tranquille. Cause : peur de la performance, absence de mesure. Remède : mesurer le profil de charge (CPU, IO, log) sur une semaine représentative et dimensionner au 90e centile, avec une marge de montée en charge documentée.
Notes /5 de l'option#
Appréciations d'expert, contextuelles (voir ../00_Lire-en-premier/NOTATION.md). Contexte : équipe de 3 à 8 personnes maîtrisant T-SQL et Power BI, datamart de 10 à 500 Go, 50 à 500 utilisateurs de rapports, projet de reporting d'entreprise (pas d'IoT temps réel).
| Critère | Note | Justification |
|---|---|---|
| Fraîcheur | 3/5 | Import limité en fréquence ; DirectQuery rend la fraîcheur au détriment de la performance |
| Performance | 4/5 | Excellente en Import sur étoile ; dégrade vite en DirectQuery mal indexé |
| Coût | 3/5 | Prévisible mais continu ; serverless/pools aident, la capacité Power BI s'ajoute |
| Complexité | 4/5 | Faible pour une équipe T-SQL ; hausse sensible dès qu'on ajoute réseau privé et mirroring |
| Gouvernance / sécurité | 4/5 | Entra, RLS, audit, masquage : très complet ; la discipline d'équipe reste décisive |
| Scalabilité | 3/5 | Verticale très bonne (Hyperscale), horizontale limitée en lecture sans réplicas ni mirroring |
| Compétences requises | 4/5 | Compétences courantes sur le marché ; peu de nouveauté pour un profil BI classique |
| Maturité de la techno | 5/5 | Moteur mûr, outils (SSMS, Query Store, Copilot) abondants ; seuls les nouveaux services Fabric sont jeunes |
| Risque de verrouillage | 3/5 | T-SQL portable vers SQL Server ; l'écosystème Azure/Entra/Fabric, lui, l'est moins |
Comparez toujours sur les mêmes critères et le même contexte que la voie OneLake. Si vous changez de contexte (volumétrie × 100, flux temps réel), les notes basculent : le comparatif explicite ces bascules.
Expert : ce que la promesse ne dit pas#
🔴 Expert — Cinq angles morts récurrents#
- Le couplage fort entre base et modèle. Un modèle sémantique en Import dépend des noms et types de colonnes de la source. Renommer une colonne du datamart casse silencieusement un rapport (voir 04-developpement-bi : modèle sémantique). Le cloud n'y change rien ; l'élasticité rend juste l'erreur plus coûteuse à diagnostiquer.
- La double facturation de capacité. La base consomme ses vCore/DTU ; l'actualisation du modèle consomme de la capacité Power BI/Fabric ; une actualisation fréquente consomme les deux. Un chantier d'optimisation sérieux traite les deux ensemble.
- La dette de compatibilité. Les niveaux de compatibilité (ex. 130 vs 160) conditionnent des optimisations du moteur (UDF scalaires en ligne, traitement par lots en mode ligne…). Rester sur un niveau ancien « pour ne rien casser » prive de gains substantiels ; migrer sans test peut régresser des plans.
- La séparation lecture/écriture. Une base unique sert à la fois la consolidation nocturne (écritures massives) et la lecture DirectQuery : sans réplica en lecture, mirroring ou fenêtrage, l'un pénalise l'autre.
- Le transfert de responsabilité sur l'identité. La sécurité ne repose plus sur des comptes SQL mais sur Entra ID : groupes, jetons, expiration, comptes de service/principaux de service. C'est un nouveau domaine de pannes (voir 07).
À cet endroit, l'IA aide surtout à comparer des niveaux de service et à estimer des coûts ; elle se trompe vite sur les tarifs (qui changent) et sur les limites : vérifiez toujours dans la documentation officielle. Détails dans 08-sqlserver-saas-ia.md.
Voir aussi#
- Architecture détaillée · Difficultés et pièges · IA
- Comparatif OneLake vs SQL Server · Bonnes pratiques transverses · Checklist de projet de reporting
- Matrice BI : performance et volumétrie · coût, licences et capacité
- Matrice PD : modélisation et architecture
- Outils : GDS et données SQL/BI
- Conduite de projet : CI/CD pour la data
- Glossaire
✻ Rédigé par Claude Sonnet 5.5
