i

Description

Passerelle de nuit, dont les cadres lumineux décalés forment un tunnel au-dessus d’une vallée enneigée.

Source

Tony Webster tonywebster · page d’origine

Licence

CC0 Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

Comparatif — OneLake / Fabric contre SQL Server managé pour le reporting Power BI

Vous saurez situer, sur neuf aspects d'architecture, une plateforme Fabric / OneLake (alimentée par des applications mobiles SaaS) face à une base SQL Server managée (Azure SQL Database…

En bref

• Vous saurez situer, sur neuf aspects d'architecture, une plateforme Fabric / OneLake (alimentée par des applications mobiles SaaS) face à une base SQL Server managée (Azure SQL Database, Managed Instance, SQL database in Fabric) comme source Power BI.
• Vous disposerez d'une heatmap notée /5, d'un arbre de décision et de scénarios types pour trancher en réunion, sans dogme.
• Vous saurez chiffrer en ordres de grandeur (signalés comme tels) ce que coûte chaque option, et ce qui fait basculer de l'une à l'autre.
• Vous connaîtrez les trajectoires de coexistence : le plus souvent, la bonne réponse n'est ni l'un ni l'autre, mais SQL managé + mirroring vers Fabric.
• Vous repartirez avec les liens vers les dossiers détaillés (OneLake 01 à 04, SQL Server 05 à 08).

Sur cette page

1. 1. Cadre, interprétation et nuance PaaS contre SaaS
2. 2. Les options comparées
   1. 🟢 Novice — Quatre architectures de référence
   2. 🟡 Pratique — Ce qui distingue vraiment A de B/C
3. 3. Grille de notation et lecture des notes
4. 4. Comparatif aspect par aspect
   1. 4.1 Fraîcheur
   2. 4.2 Performance
   3. 4.3 Coût
   4. 4.4 Complexité
   5. 4.5 Gouvernance et sécurité
   6. 4.6 Scalabilité
   7. 4.7 Compétences requises
   8. 4.8 Maturité de la technologie
   9. 4.9 Risque de verrouillage
5. 5. Heatmap de synthèse
6. 6. Coûts comparés en ordres de grandeur
   1. 🟡 Pratique — Les postes de coût
   2. 🟡 Pratique — Raisonnements chiffrés (illustratifs)
   3. 🔴 Expert — Les coûts cachés
7. 7. Arbre de décision
   1. 🟢 Novice — Cinq questions dans l'ordre
   2. 🟡 Pratique — Les contraintes dures qui court-circuitent l'arbre
   3. 🔴 Expert — Rendre la décision réversible
8. 8. Scénarios types
   1. 8.1 Scénario 1 — Force de vente terrain, 150 utilisateurs, datamart SQL existant (le fil rouge)
   2. 8.2 Scénario 2 — Multi-SaaS (CRM + SFA + support), schémas mouvants, équipe data engineering
   3. 8.3 Scénario 3 — Grande diffusion (2 000 lecteurs), peu de développeurs
   4. 8.4 Scénario 4 — Temps réel opérationnel (suivi de tournée, alertes)
   5. 8.5 Scénario 5 — Petite structure, 15 utilisateurs, budget serré
   6. 8.6 Scénario 6 — Conformité stricte (secteur régulé)
9. 9. Trajectoires de migration et de coexistence
   1. 🟡 Pratique — Trajectoire « mirroring d'abord » (la plus prudente)
   2. 🟡 Pratique — Trajectoire « extraction SaaS vers OneLake »
   3. 🔴 Expert — Coexistence durable et gouvernance de la double source
10. 10. Ce qui fait basculer
    1. 🟡 Pratique — Seuils de bascule (ordres de grandeur, à calibrer)
    2. 🔴 Expert — Les raisons de ne pas basculer
11. 11. Pièges de la décision
12. 12. Contribution de l'IA à la décision
13. 13. Voir aussi

Niveau : 🟢→🔴

1. Cadre, interprétation et nuance PaaS contre SaaS#

Ce document reprend les interprétations retenues pour le dossier (détail dans le README du dossier).

• « OneLake + applications mobiles en SaaS » désigne un reporting Power BI dont la source analytique est Microsoft Fabric / OneLake (lakehouse, warehouse, Direct Lake, mirroring, shortcuts, pipelines, dataflows Gen2, eventstream), alimenté par des applications mobiles SaaS (SFA/CRM terrain, Dynamics 365, Salesforce, Power Apps, applications de collecte). Cela implique des quotas d'API, des schémas qui dérivent, des données synchronisées après un passage hors ligne, de la latence et des questions d'identité.
• « SQL Server en SaaS » désigne une base relationnelle managée en cloud — Azure SQL Database, Azure SQL Managed Instance, SQL database in Fabric ; SQL Server sur machine virtuelle sert de contraste — utilisée comme source Power BI (Import, DirectQuery, composite, ou Direct Lake via mirroring), le service Power BI étant lui-même en SaaS.

Les deux options ne sont pas exclusives : le mirroring Fabric de SQL managé (voir § 9) est précisément le pont. Le comparatif sert à choisir un centre de gravité, pas à bannir une brique.

Fil rouge illustratif (anonyme) : un datamart SQL Server alimenté par une application de force de vente terrain, avec des rapports Power BI multilingues, versionné en TFVC et livré en kits d'installation. Il est typiquement le point de départ d'une réflexion « faut-il passer à OneLake ? ».

2. Les options comparées#

🟢 Novice — Quatre architectures de référence#

Pour contraste, E — SQL Server sur VM : mêmes principes que B/C mais vous exploitez l'OS, les correctifs, la haute disponibilité et les sauvegardes. À ne garder que pour une raison de compatibilité (fonctionnalités non disponibles en PaaS, licences existantes) : voir 06 — architecture SQL Server.

🟡 Pratique — Ce qui distingue vraiment A de B/C#

1. Où se fait la transformation. En A, dans Spark/SQL de Fabric, dans des notebooks, pipelines et dataflows ; en B/C, en T-SQL dans des procédures, avec le moteur relationnel pour contrainte d'intégrité (clés, contraintes, transactions).
2. Quel moteur sert les requêtes du rapport. En A (Direct Lake), le moteur VertiPaq lit des fichiers Delta/Parquet sans copie ; en B, il lit sa propre copie importée ; en C, c'est le moteur SQL qui répond, requête après requête.
3. Quelle unité de facturation. A repose sur une capacité Fabric (unités de capacité, partagées par tous les workloads) ; B/C sur une base dimensionnée (DTU ou vCore) plus des licences Power BI ; D cumule les deux.
4. Quelle relation avec la source SaaS. Ni A ni B ne retirent le problème de l'extraction SaaS : quotas d'API, pagination, schémas évolutifs. Le choix change où on le traite. Voir 03 — difficultés et pièges (OneLake) et 07 — difficultés et pièges (SQL Server).

3. Grille de notation et lecture des notes#

Les neuf aspects sont ceux du brief « architectures de reporting ». Une note 5/5 est toujours favorable (y compris pour « coût » et « complexité » : 5 = peu coûteux, peu complexe). Les notes sont des appréciations d'expert, contextuelles, pas des mesures (voir NOTATION).

4. Comparatif aspect par aspect#

4.1 Fraîcheur#

Option A. La fraîcheur dépend du maillon le plus lent de la chaîne : l'API SaaS (quotas, pagination), l'orchestration, puis le « framing » Direct Lake qui rafraîchit les métadonnées du modèle. Avec le mirroring d'une source supportée, la réplication est quasi continue ; avec des pipelines sur API SaaS, comptez le quart d'heure à l'heure. Un eventstream peut descendre à quelques secondes pour des flux d'événements, au prix d'une autre complexité.

Option B. Le rafraîchissement Import est planifié (8 actualisations planifiées par jour en capacité partagée, jusqu'à 48 sur une capacité Premium, PPU ou Fabric, selon la documentation Microsoft ; état 2026-10) et déclenchable par API en fin de chargement. La fraîcheur réaliste se compte en heures, au mieux quelques dizaines de minutes sur des petits modèles ou avec actualisation incrémentale.

Option C. La fraîcheur est celle de la base : excellente (temps réel) mais obtenue en reportant la charge sur la base à chaque interaction utilisateur.

Option D. Le mirroring SQL → OneLake est conçu pour une latence faible (de l'ordre de quelques secondes à minutes en régime normal ; ordre de grandeur, à vérifier selon la charge), mais la fraîcheur de votre datamart reste celle de ses propres chargements.

4.2 Performance#

Option A. Direct Lake combine la vitesse d'Import (colonnes en mémoire VertiPaq) et l'absence de copie. Les performances dépendent de l'hygiène des fichiers Delta : trop de petits fichiers, absence d'optimisation V-Order ou de compactage, row groups mal dimensionnés. Au-delà des limites de la capacité (taille de modèle par SKU, garde-fous Direct Lake), le comportement peut basculer en repli DirectQuery : la performance chute alors sans que le rapport ne change. Voir 02 — architecture OneLake.

Option B. Import offre la meilleure performance de requête à volumétrie moyenne, avec un modèle bien conçu (étoile, colonnes à faible cardinalité, mesures efficaces). Le plafond est la taille du modèle importable selon la licence/capacité.

Option C. DirectQuery rend la performance dépendante du moteur SQL et de l'indexation : index columnstore, statistiques, plans de requête. Bien conçu (agrégations, tables agrégées en mode Import dans un modèle composite), il convient aux grandes tables de faits ; mal conçu, il produit des visuels à 10 secondes et une base saturée.

Option D. Direct Lake sur la réplique donne la performance de A sans migrer le traitement : l'équipe garde T-SQL et ses procédures.

4.3 Coût#

Voir le détail en § 6. En synthèse : B est la plus économique pour un petit périmètre (une base de quelques centaines de dollars par mois et des licences Pro) ; A impose un ticket d'entrée de capacité mais mutualise Power BI et analytique ; C cumule coût de base élevé (le dimensionnement doit absorber les requêtes interactives) ; D additionne les deux, en partie compensé par l'absence d'ETL de réplication.

4.4 Complexité#

• B est la plus simple : peu de pièces, compétences standard, diagnostic connu.
• C ajoute le diagnostic de requêtes générées par DAX → SQL, source d'opacité.
• A multiplie les composants (lakehouse, warehouse, notebooks, pipelines, dataflows, capacité, workspaces, domaines) et un modèle de capacité à surveiller (lissage, throttling).
• D combine B + une couche A mince : plus de composants que B, mais sans réécrire les traitements.

4.5 Gouvernance et sécurité#

• A : OneLake offre un point de stockage unique, du lignage, des étiquettes de sensibilité (Microsoft Purview), une sécurité « OneLake security » (rôles de données avec RLS/CLS, documentée sans mention de préversion ; seule l'intégration de moteurs tiers autorisés reste en préversion, état 2026-10). Le risque est la dispersion de la sécurité : droits d'espace de travail, droits sur l'élément, RLS dans le modèle, sécurité côté SQL endpoint, côté Direct Lake. Une règle RLS mal alignée entre couches fuit ou bloque.
• B/C : le modèle est connu — authentification Entra ID, rôles de base, RLS native SQL (DirectQuery) et RLS Power BI (Import). En DirectQuery avec identité SSO, la RLS SQL s'applique à l'utilisateur final ; sans SSO, c'est un compte de service qui voit tout et la RLS Power BI porte seule la sécurité.
• D hérite des deux : veillez à ce que la réplique OneLake ne contourne pas les protections de la source (une donnée masquée en SQL ne doit pas être lisible en clair dans OneLake).

4.6 Scalabilité#

• A : conçue pour de très grandes volumétries et la montée en capacité par SKU, avec la contrainte de partage de la capacité entre rapports interactifs et traitements batch (noisy neighbour).
• B/C : montée en puissance verticale (vCore/DTU), hyperscale pour les très grosses bases ; la limite de B est la taille de modèle importable, celle de C est le moteur relationnel sous charge interactive.
• D : l'analytique monte à l'échelle côté Fabric, l'écriture transactionnelle côté SQL.

4.7 Compétences requises#

4.8 Maturité de la technologie#

SQL managé et Power BI Import/DirectQuery sont très matures. Fabric est GA mais évolue vite : certaines fonctionnalités passent de preview à GA en quelques mois et l'écosystème de pratiques (CI/CD, tests, observabilité) se consolide. Le mirroring d'Azure SQL Database est GA depuis novembre 2024 et celui d'Azure SQL Managed Instance l'est aussi ; des extensions (passerelle pour une instance non publique, tables sans clé primaire) sont arrivées par paliers depuis 2025 — vérifier l'état exact pour votre cas dans la documentation à jour (état 2026-10).

4.9 Risque de verrouillage#

OneLake stocke du Delta/Parquet, format ouvert, ce qui réduit le verrouillage des données ; mais le verrouillage se déplace vers l'orchestration, les modèles sémantiques, les droits et le modèle de capacité. SQL managé est verrouillé sur T-SQL (mais portable vers SQL Server sur site ou VM) ; Power BI reste le verrou côté restitution dans les deux cas.

5. Heatmap de synthèse#

Légende : 🟥 1–2 · 🟧 3 · 🟨 3,5–4 · 🟩 4,5–5. Notes /5, plus c'est haut, plus c'est favorable.

Lecture honnête :

• B l'emporte à périmètre modeste. C'est la moyenne la plus haute : ce n'est pas un hasard, c'est la combinaison la moins sophistiquée.
• La moyenne ne décide pas. Pondérez selon votre contexte : si la scalabilité et l'IA pèsent trois fois plus que la complexité, A et D remontent nettement. Refaites le calcul avec vos poids.
• C est rarement un choix de destination. C'est un outil ponctuel (très grosse table de faits, exigence de temps réel, contrainte de non-copie), jamais un défaut.
• D vaut surtout pour son optionnalité : il achète la possibilité de Direct Lake, de notebooks et d'IA sans réécriture, au prix de coûts additionnels.

6. Coûts comparés en ordres de grandeur#

🟡 Pratique — Les postes de coût#

🟡 Pratique — Raisonnements chiffrés (illustratifs)#

🔴 Expert — Les coûts cachés#

1. Le lissage et le throttling (Fabric) : une capacité sous-dimensionnée ralentit tout le monde ; la parade (monter de SKU, séparer les capacités par criticité) a un coût. Prévoir un monitoring de l'utilisation de capacité (application Capacity Metrics).
2. Les ré-exécutions : un chargement SaaS qui échoue sur quota d'API consomme du calcul pour rien ; l'idempotence et le rejeu sont un poste de coût et de conception.
3. Le mirroring : inclut un stockage OneLake jusqu'à un quota proportionnel à la capacité, au-delà duquel il est facturé comme du stockage ; le calcul de réplication est, selon la documentation, gratuit au titre de la capacité (à vérifier pour votre configuration). La source supporte une charge supplémentaire de lecture du journal de transactions.
4. Le DirectQuery : chaque interaction d'utilisateur génère des requêtes ; sur une base facturée à la taille de calcul, l'usage interactif impose de dimensionner pour le pic.
5. La dette de compétence : sans compétences Spark/Delta en interne, A se transforme en prestation externe récurrente.
6. Le coût de l'indécision : maintenir deux plateformes sans cible claire coûte souvent plus que de choisir la « mauvaise » option raisonnée.

7. Arbre de décision#

🟢 Novice — Cinq questions dans l'ordre#

Q1. Avez-vous déjà un datamart SQL qui fonctionne et que l'équipe maîtrise ?
    ├─ Oui → Q2
    └─ Non (projet neuf, sources SaaS dominantes) → Q4

Q2. Quelque chose empêche-t-il de rester en SQL managé + Import ?
    (volumétrie hors limites du modèle importé, besoin d'IA/notebooks, besoin de
     lecteurs nombreux sans licence individuelle, exigence de fraîcheur < 15 min)
    ├─ Non → OPTION B  (SQL managé + Import) — ne changez rien d'inutile
    └─ Oui → Q3

Q3. Pouvez-vous garder les traitements T-SQL tels quels ?
    ├─ Oui → OPTION D  (SQL managé + mirroring + Direct Lake)
    └─ Non, il faut aussi sortir du T-SQL → OPTION A, migration par étapes (§ 9)

Q4. Les données arrivent-elles surtout par API/exports SaaS, avec schémas mouvants ?
    ├─ Oui, et vous avez/embauchez des compétences Spark/Delta → OPTION A
    └─ Oui, mais l'équipe est T-SQL → OPTION D ou B (atterrissage en base SQL,
       extraction par pipeline léger), A plus tard

Q5. Besoin de temps réel strict sur une grosse table de faits, sans copie ?
    └─ Ajoutez ponctuellement une table en DirectQuery (modèle composite),
       jamais le modèle entier — OPTION C en complément, pas en défaut.

🟡 Pratique — Les contraintes dures qui court-circuitent l'arbre#

🔴 Expert — Rendre la décision réversible#

Choisissez toujours la variante dont la sortie coûte le moins : atterrir les données SaaS brutes dans un stockage ouvert (OneLake ou stockage objet), conserver les traitements dans un langage portable, versionner modèles (PBIP/TMDL) et schémas, et masquer la source derrière une couche sémantique que les rapports référencent. La section 7 du dossier 06 et le dossier 02 détaillent la couche sémantique de chaque côté.

8. Scénarios types#

8.1 Scénario 1 — Force de vente terrain, 150 utilisateurs, datamart SQL existant (le fil rouge)#

• Contexte : application SFA alimentant un datamart SQL, rapports multilingues, livraison par kits.
• Recommandation : B maintenant (rien ne casse), D si un besoin d'analytique avancée ou d'IA apparaît. Surveiller le temps de rafraîchissement du modèle importé.
• Ce qui change la donne : une demande de données quasi temps réel sur les visites, ou une croissance qui fait dépasser la taille de modèle importable.

8.2 Scénario 2 — Multi-SaaS (CRM + SFA + support), schémas mouvants, équipe data engineering#

• Contexte : trois SaaS, API à quotas, historisation exigée, analystes en notebooks.
• Recommandation : A : lakehouse en médaillon (bronze brut, silver nettoyé, gold sémantique), Direct Lake. Le brut conservé absorbe les dérives de schéma.
• Garde-fous : idempotence des pipelines, gestion des quotas, contrat de données. Voir 03 — difficultés et pièges (OneLake).

8.3 Scénario 3 — Grande diffusion (2 000 lecteurs), peu de développeurs#

• Recommandation : modèle importé ou Direct Lake sur capacité (lecteurs sans licence individuelle si le seuil de capacité est atteint), D si la base reste en SQL. Le calcul de licences domine (voir § 6).

8.4 Scénario 4 — Temps réel opérationnel (suivi de tournée, alertes)#

• Recommandation : A avec eventstream (ou Real-Time Intelligence) pour le flux ; rapports Power BI en mode DirectQuery/streaming sur ce périmètre seulement ; le reste du reporting en B/D. Un seul modèle « temps réel de bout en bout » est un anti-modèle.

8.5 Scénario 5 — Petite structure, 15 utilisateurs, budget serré#

• Recommandation : B, sans hésiter. La plateforme la plus simple qui satisfait le besoin est la meilleure. Réévaluer annuellement.

8.6 Scénario 6 — Conformité stricte (secteur régulé)#

• Recommandation : celle que votre équipe sécurité sait auditer. B/C offrent des pratiques d'audit anciennes ; A impose de maîtriser la sécurité multicouche (workspace, élément, OneLake security, RLS). Une preuve de conformité qui n'existe pas n'est pas un argument technique.

9. Trajectoires de migration et de coexistence#

🟡 Pratique — Trajectoire « mirroring d'abord » (la plus prudente)#

1. Étape 0 — Cadrer : inventorier tables, volumétrie, consommateurs, exigences de fraîcheur et de sécurité. Choisir un périmètre pilote (3 à 5 tables de faits, 1 rapport).
2. Étape 1 — Mirroring de la base SQL vers un élément « base de données mise en miroir » ; vérifier prérequis, limites de types de données, tables non répliquées et particularités (clé primaire, DDL supportés), qui évoluent : vérifier la documentation à jour (état 2026-10).
3. Étape 2 — Modèle sémantique en Direct Lake sur la réplique (ou sur un lakehouse via raccourci), rapport pilote en parallèle de l'existant.
4. Étape 3 — Comparaison de chiffres : recette « rapport ancien contre rapport nouveau » sur un jeu de KPI figé (voir 11 — checklist).
5. Étape 4 — Bascule des rapports un par un, en conservant l'ancien modèle Import en secours une période définie.
6. Étape 5 — Décommissionnement de ce qui est redondant seulement une fois la période de coexistence validée.

🟡 Pratique — Trajectoire « extraction SaaS vers OneLake »#

Quand la nouveauté est la source SaaS (pas la base SQL) :

1. Atterrir les extractions SaaS brutes, horodatées, immuables dans OneLake (zone bronze).
2. Normaliser en silver (types, clés, déduplication, gestion des suppressions logiques).
3. Publier gold en warehouse ou lakehouse (modèle en étoile) ; le datamart SQL peut rester la source de référentiels (raccourcis ou mirroring).
4. Laisser le datamart SQL consommer gold, ou le retirer progressivement.

🔴 Expert — Coexistence durable et gouvernance de la double source#

Exemple de réconciliation côté SQL (à comparer au résultat équivalent sur le SQL endpoint de la réplique) :

-- Empreinte quotidienne d'une table de faits, comparable entre source et réplique
SELECT CAST([DateVisite] AS date)         AS [Jour],
       COUNT_BIG(*)                       AS [NbLignes],
       SUM(CAST([Montant] AS decimal(19,4))) AS [SommeMontant],
       CHECKSUM_AGG(CHECKSUM([ID_Visite])) AS [Empreinte]
FROM   [dbo].[FACT_Visite] WITH (NOLOCK)
WHERE  [DateVisite] >= DATEADD(day, -30, CAST(GETDATE() AS date))
GROUP BY CAST([DateVisite] AS date)
ORDER BY [Jour];

10. Ce qui fait basculer#

🟡 Pratique — Seuils de bascule (ordres de grandeur, à calibrer)#

🔴 Expert — Les raisons de ne pas basculer#

• Le besoin est satisfait et l'équipe n'a pas de temps libre : un changement d'architecture sans douleur ressentie est une dépense, pas un investissement.
• Les données sont petites et les rapports peu nombreux.
• La gouvernance Fabric n'est pas prête (domaines, droits, cycle de vie des espaces de travail) : migrer le désordre vers un lac donne un marécage de données.
• Les rapports clients ou tiers sont liés à des modèles existants (identifiants de mesures, liens) : l'impact d'un changement de modèle dépasse l'équipe. Voir 10 — mesures et lineageTag.

11. Pièges de la décision#

12. Contribution de l'IA à la décision#

Exemple de prompt : « Voici nos cinq exigences mesurables et le schéma du datamart ci-joint. Propose trois architectures, avec pour chacune les risques, le coût de sortie, et les points que je dois vérifier dans la documentation officielle — sans inventer de tarif. »

13. Voir aussi#

• Dossier OneLake : 01 — vue d'ensemble · 02 — architecture · 03 — difficultés et pièges · 04 — IA
• Dossier SQL Server : 05 — vue d'ensemble · 06 — architecture · 07 — difficultés et pièges · 08 — IA
• Suite du dossier : 10 — bonnes pratiques transverses · 11 — checklist de projet
• Matrices : Développement BI (coût, licences, capacité : 12 — coût, licences et capacité ; performance : 03 — performance et volumétrie) · Conduite de projet data
• Méthodes et outils : CI/CD pour la data · GDS et données SQL/BI
• Glossaire : GLOSSAIRE · Notation : NOTATION

✻ Rédigé par Claude Sonnet 5.5