i

Description

Retenue d’eau bordée de montagnes, vue depuis le parapet d’un barrage.

Source

Daizy John · 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.

OneLake + applications mobiles en SaaS : architecture

Vous saurez dessiner une architecture OneLake alimentée par un SaaS mobile : ingestion, médaillon bronze/silver/gold, modèle sémantique, rapports.

En bref

• Vous saurez dessiner une architecture OneLake alimentée par un SaaS mobile : ingestion, médaillon bronze/silver/gold, modèle sémantique, rapports.
• Vous saurez choisir entre lakehouse et warehouse, entre pipeline, dataflow gen2, notebook et eventstream, entre Direct Lake, Import et DirectQuery.
• Vous saurez traiter les cas durs d'une source terrain : suppressions, schéma qui dérive, hors-ligne, doublons, horodatage.
• Vous saurez sécuriser (RLS, OneLake security, rôles) et industrialiser (workspaces, Git, déploiement).
• Interprétation du sujet : voir la vue d'ensemble. Faits volatils vérifiés en octobre 2026 (état 2026-10).

Sur cette page

1. 1. Vue d'ensemble de l'architecture
2. 2. Les bases OneLake
   1. 2.1 Delta et Parquet
   2. 2.2 Shortcuts
   3. 2.3 Mirroring
3. 3. Les items Fabric et leurs usages
   1. 3.1 Lakehouse ou warehouse ?
   2. 3.2 Quel outil pour quoi ?
4. 4. Ingestion depuis un SaaS mobile
   1. 4.1 Chargement incrémental : le motif watermark
5. 5. Le médaillon bronze silver gold
   1. 5.1 Idempotence et rejeu
6. 6. Cas durs de la donnée terrain
   1. 6.1 Gestion des suppressions
   2. 6.2 Schéma qui dérive
   3. 6.3 Hors-ligne, synchronisation et horodatage
   4. 6.4 Doublons et identité des clients terrain
   5. 6.5 Photos, signatures et fichiers
7. 7. Le modèle sémantique et les modes de stockage
   1. 7.1 Direct Lake, Import, DirectQuery
   2. 7.2 Règles de modélisation spécifiques
8. 8. SQL analytics endpoint
9. 9. Sécurité
10. 10. Workspaces et capacités
11. 11. Déploiement et Git
12. 12. Notes de synthèse
13. 13. Voir aussi

Niveau : 🟢→🔴

1. Vue d'ensemble de l'architecture#

🟢 Novice.

Trois principes dirigent le reste :

1. Découpler le SaaS (qui change) du modèle de reporting (qui doit être stable) par au moins une couche intermédiaire.
2. Rejouer : tout ce qui est en bronze doit permettre de reconstruire silver et gold ; un pipeline qu'on ne peut pas rejouer est un pipeline qu'on ne peut pas corriger.
3. Mesurer : chaque étape journalise volumes, durées, lignes rejetées (supervision).

2. Les bases OneLake#

🟢 Novice.

2.1 Delta et Parquet#

• Parquet : format de fichier colonnaire compressé, immuable.
• Delta Lake : couche transactionnelle posée au-dessus de fichiers Parquet : un journal (_delta_log) enregistre les versions de la table. On obtient des transactions ACID, la lecture d'une version passée (time travel), les MERGE (upsert), et l'évolution de schéma contrôlée.
• Dans Fabric, toutes les tables des lakehouses et des warehouses sont stockées en Delta dans OneLake.

2.2 Shortcuts#

Un shortcut (raccourci) expose dans un lakehouse un dossier ou une table située dans un autre lakehouse, ADLS Gen2, Amazon S3, Google Cloud Storage, Dataverse… (liste évolutive, à vérifier). Intérêt : pas de copie, lecture à jour. Limites : la performance dépend de la source distante ; la sécurité doit être pensée de bout en bout ; un shortcut vers une structure d'éditeur importe sa dérive de schéma. Les shortcuts à identité déléguée (OneLake vers OneLake, y compris inter-tenant) permettent de séparer la gestion des droits du producteur et du consommateur ; leur statut (preview ou GA) est à vérifier dans la documentation Microsoft Learn.

2.3 Mirroring#

Le mirroring réplique en continu une base opérationnelle vers des tables Delta dans OneLake, sans pipeline à écrire. Sources en disponibilité générale (état 2026-10) : notamment Azure SQL Database, Cosmos DB, Snowflake, PostgreSQL, Oracle ; autres sources en preview (Azure Database for MySQL, catalogue Dremio, SharePoint List…). Intérêt dans notre sujet : si le SaaS expose sa base (rare) ou si votre couche intermédiaire est une base relationnelle (cf. SQL Server en SaaS). Un SaaS pur ne se « mirror » en général pas : on passe par ses API.

3. Les items Fabric et leurs usages#

🟡 Praticien.

3.1 Lakehouse ou warehouse ?#

3.2 Quel outil pour quoi ?#

Règle d'or : orchestrer avec un pipeline, calculer avec un notebook ou du SQL, laisser Power Query aux transformations légères et aux profils analystes.

4. Ingestion depuis un SaaS mobile#

🟡 Praticien.

Un SaaS SFA offre rarement l'accès à sa base. Il propose un ou plusieurs mécanismes, aux propriétés très différentes.

4.1 Chargement incrémental : le motif watermark#

# Notebook Fabric (PySpark) — motif watermark + upsert Delta (exemple simplifié)
from delta.tables import DeltaTable
from pyspark.sql import functions as F

from datetime import timedelta
dernier = spark.sql("SELECT max(modifie_le) AS m FROM silver.visite").first()["m"]
# fenêtre de recouvrement de 2 h pour absorber les synchronisations tardives
debut = dernier - timedelta(hours=2)
lot = appeler_api_visites(modifie_apres=debut)       # pagination + reprise, hors périmètre ici
df = spark.createDataFrame(lot).withColumn("ingere_le", F.current_timestamp())

cible = DeltaTable.forName(spark, "silver.visite")
(cible.alias("t")
   .merge(df.alias("s"), "t.visite_id = s.visite_id")
   .whenMatchedUpdateAll(condition="s.modifie_le >= t.modifie_le")
   .whenNotMatchedInsertAll()
   .execute())

Points à retenir : le recouvrement de la fenêtre (on relit un peu en arrière), la clé naturelle unique, la condition modifie_le >= qui rend l'opération idempotente (rejouable sans doublons), et la colonne ingere_le qui trace la réception.

5. Le médaillon bronze silver gold#

🟡 Praticien.

Le gold est le contrat avec le rapport. Tout ce qui change côté SaaS doit être absorbé en silver, pas répercuté dans le gold (modèle sémantique, couche données et ETL).

5.1 Idempotence et rejeu#

Un lot rejoué doit produire le même état. Moyens : clé naturelle + MERGE, partition de bronze par date d'ingestion (on peut recalculer une journée), table de journal d'exécution (lot_id, statut, volumes). Voir aussi recette et validation métier.

6. Cas durs de la donnée terrain#

🔴 Expert.

6.1 Gestion des suppressions#

Trois familles de situations :

1. Soft delete exposé (champ est_supprime, deleted_at) : simple, on propage le drapeau.
2. Flux ou table de suppressions (événements, $deltatoken) : à rejouer comme un MERGE WHEN MATCHED AND s.suppr THEN DELETE ou marquage.
3. Aucune information : la seule méthode est la réconciliation : à intervalle régulier, extraire les clés actuelles de la source et marquer en silver les clés absentes (NOT MATCHED BY SOURCE).

-- Spark SQL : marquage des disparus après extraction complète des clés
MERGE INTO silver.visite t
USING clefs_source s
ON t.visite_id = s.visite_id
WHEN NOT MATCHED BY SOURCE AND t.supprime = false THEN
  UPDATE SET t.supprime = true, t.supprime_detecte_le = current_timestamp()

6.2 Schéma qui dérive#

Un éditeur SaaS ajoute des champs, renomme, change un type, décline des champs personnalisés par client. Défenses :

• bronze en schéma souple (JSON ou mergeSchema contrôlé), jamais de SELECT * vers le gold ;
• projection explicite en silver (liste de colonnes attendues) ;
• test de contrat à chaque ingestion : colonnes attendues présentes, types compatibles, taux de nuls ; en cas d'écart, alerter sans casser (quarantaine du champ nouveau, échec franc pour un champ requis disparu) ;
• versionnement des définitions (Git) et du numéro de version d'API appelé.

attendues = {"visite_id":"string","commercial_id":"string","debut":"timestamp","statut":"string"}
manquantes = [c for c in attendues if c not in df.columns]
if manquantes:
    raise Exception(f"Contrat rompu, colonnes absentes : {manquantes}")
inconnues = [c for c in df.columns if c not in attendues]
if inconnues:
    journaliser_alerte("colonnes nouvelles non projetées", inconnues)   # on avance, on informe

6.3 Hors-ligne, synchronisation et horodatage#

Une visite saisie lundi à 10 h sans réseau, synchronisée mardi à 18 h, arrive en retard. Conséquences :

• Faits tardifs : les chiffres du lundi changent mardi soir. Le rapport doit afficher une date de dernière synchronisation ou de dernière mise à jour, et l'équipe métier doit savoir qu'un « jour J » n'est stable qu'à J+N.
• Trois horodatages à conserver : evenement_le (appareil, peut être faux), synchro_le (serveur éditeur), ingere_le (votre pipeline).
• Fuseaux horaires : stocker en UTC, convertir à l'affichage (colonne de décalage par pays ou fuseau du commercial). Les changements d'heure produisent des durées négatives ou des doublons d'une heure.
• Conflits de synchronisation : deux appareils modifient la même fiche ; l'éditeur arbitre (dernier gagnant ?). Vous recevez la version arbitrée : sans historique éditeur, des modifications se perdent. Garder en bronze chaque version reçue.

6.4 Doublons et identité des clients terrain#

Le même client saisi deux fois par deux commerciaux, la même visite créée par une double synchronisation. Chaîne type : clé technique éditeur → clé fonctionnelle (code client ERP si existant) → règles de rapprochement approximatif (nom normalisé + adresse + géocode) → table de correspondance xref_client maintenue par un humain pour les cas ambigus. L'IA peut aider à proposer des rapprochements (fichier IA).

6.5 Photos, signatures et fichiers#

Les pièces jointes ne vont pas dans les tables : fichiers dans Files du lakehouse (ou ADLS via shortcut), table de métadonnées (chemin, hash, taille, visite associée). Les photos de rayon sont un volume important et soumis au RGPD si des personnes y figurent.

7. Le modèle sémantique et les modes de stockage#

🟡 Praticien.

7.1 Direct Lake, Import, DirectQuery#

Principe de Direct Lake : le modèle lit directement les fichiers Parquet des tables Delta, charge en mémoire (VertiPaq) uniquement les colonnes nécessaires à une requête, et un « refresh » ne fait que re-cadrer (framing) les références vers la dernière version des tables.

Deux variantes (état 2026-10, d'après la documentation Microsoft Learn mise à jour en septembre 2026) :

Garde-fous par SKU (extraits de la doc, état 2026-10) : F2 à F8 : 1 000 fichiers Parquet, 300 millions de lignes par table, 10 Go de modèle sur disque ; F64 : 5 000 fichiers, 1,5 milliard de lignes, taille de modèle illimitée ; F512 : 10 000 fichiers, 12 milliards de lignes.

7.2 Règles de modélisation spécifiques#

• Étoile (Kimball) : faits visite, commande, releve ; dimensions date, client, produit, commercial, secteur. Pas de tables « à plat » de 300 colonnes.
• Types : Direct Lake n'accepte pas les types Delta complexes ni GUID/binaire ; convertir en chaîne en silver/gold.
• Clés : colonnes du côté « un » d'une relation uniques, sinon les requêtes échouent (état 2026-10) ; valider en gold par un test.
• Mesures : DAX centralisé (mesures et calculs DAX), avec traductions pour le multilingue (accessibilité et multilingue).
• Dates : une table de dates marquée ; calendriers de période commerciale spécifiques.

8. SQL analytics endpoint#

🟡 Praticien.

Chaque lakehouse et chaque warehouse expose un SQL analytics endpoint : une interface T-SQL (lecture seule pour le lakehouse) utilisable par SSMS, des clients ODBC, d'autres outils. Usages : exploration, vues, rapports SQL, ancien rapport DirectQuery, validation de chiffres.

Points d'attention :

• Latence de synchronisation des métadonnées : après une écriture Delta, l'endpoint peut mettre un certain temps à voir les nouvelles tables/colonnes (à surveiller ; l'API de resynchronisation existe, à vérifier selon l'état 2026-10).
• Les vues sur l'endpoint déclenchent le repli DirectQuery d'un modèle « Direct Lake on SQL » ; en « on OneLake », on privilégie des tables matérialisées.
• La sécurité de l'endpoint (RLS/CLS SQL) ne s'applique pas à un Direct Lake on OneLake : la sécurité se règle côté OneLake security ou côté modèle.

9. Sécurité#

🔴 Expert.

Quatre niveaux, à ne pas confondre (sécurité RLS et accès) :

1. Rôles d'espace de travail (Admin, Member, Contributor, Viewer) : droits sur l'ensemble des items. Un Viewer d'espace n'est pas un consommateur de rapport anodin : il peut lire les données selon le contexte.
2. Permissions d'item (partage d'un rapport, d'un modèle, d'un lakehouse) : granularité plus fine, à documenter.
3. OneLake security : contrôle d'accès fin natif au stockage (dossier, table, ligne, colonne), appliqué par tous les moteurs ; en disponibilité générale depuis le printemps 2026 (date exacte non confirmée par une source primaire), activé par défaut pour les nouveaux items (état 2026-10). Le principal intérêt est la cohérence : la règle suit la donnée, que l'on y accède par Spark, SQL ou Power BI.
4. RLS du modèle sémantique : rôles DAX (ex. [Commercial_Email] = USERPRINCIPALNAME() via une table de hiérarchie commerciale). Avec Direct Lake, la documentation recommande une identité fixe (connexion cloud à identité fixe) avec RLS de modèle.

Cas SFA : un commercial voit son portefeuille, son manager voit l'équipe, un directeur voit la région. La hiérarchie doit être historisée et mise à jour sans intervention (changements d'affectation), et l'effet de bord classique est le rétro-filtrage : une mesure qui compte les clients varie selon le rôle (comportement attendu, à expliquer).

Données personnelles : minimisation (pseudonymisation des identités d'agents au-delà de ce qu'exige l'usage), durées de rétention par table, droit à l'effacement (propager la suppression jusqu'au bronze) — voir sécurité, confidentialité, conformité.

10. Workspaces et capacités#

🟡 Praticien.

• Un workspace est un conteneur d'items, rattaché à une capacité (F-SKU, voir difficultés).
• Découpage recommandé : espaces par étape de cycle de vie (Dev / Test / Prod) et, pour les gros projets, par couche (ingestion, transformation, sémantique/rapports) afin d'isoler les droits et la consommation.
• Séparer le modèle sémantique (équipe BI) des rapports (utilisateurs avancés) autorise le « rapport mince » (thin report) connecté à un modèle certifié.
• Capacités multiples : une capacité de production protégée, une capacité de développement/ad hoc plus petite : le bruit des essais n'impacte pas les utilisateurs.
• Régions : Direct Lake impose que l'espace du modèle et la source soient dans la même région (contournement par shortcuts documenté pour la variante SQL analytics endpoint, état 2026-10).
• Copilot et IA consomment des CU de la capacité (fichier IA).

11. Déploiement et Git#

🔴 Expert.

Fabric propose deux mécanismes complémentaires :

• Intégration Git (Azure DevOps ou GitHub) : le contenu de l'espace est sérialisé (TMDL pour les modèles, format PBIR pour les rapports, définitions d'items pour notebooks, pipelines, lakehouse…). Un espace = une branche. Le commit au niveau fichier est en preview, et le changement de branche par un Contributor suppose qu'un administrateur ait activé le paramètre d'espace correspondant (état 2026-10).
• Pipelines de déploiement : Dev → Test → Prod avec règles de paramètres (changer la source, la connexion) ; attention : certaines règles de re-liaison de source ne sont pas supportées pour Direct Lake on OneLake (état 2026-10) — prévoir un paramétrage par variables ou un auto-binding.
• Azure DevOps Server (on-prem) : l'intégration Git de Fabric cible Azure DevOps Services et GitHub ; avec un serveur interne il faut un dépôt Git cloud ou un script via API (à vérifier selon votre contexte) — voir GDS et données SQL/BI et stratégies de branches.

Espace Dev  <--branche feature/xyz--  Git (Azure DevOps / GitHub)
Espace Test <--branche main (PR)--    Git
Espace Prod <-- pipeline de déploiement (Test -> Prod) avec règles de paramètres

12. Notes de synthèse#

Appréciations d'expert, contextuelles (cf. NOTATION). Contexte : équipe BI de 3 à 6 personnes, SFA SaaS + sources complémentaires, 100–500 utilisateurs.

13. Voir aussi#

• Dossier : Vue d'ensemble · Difficultés et pièges · IA · Architecture SQL Server en SaaS · Comparatif · Bonnes pratiques transverses · Checklist
• Matrices : Développement BI · Performance et volumétrie · Modélisation et architecture
• Termes : Glossaire

✻ Rédigé par Claude Sonnet 5.5