i

Description

Lac d’un bleu turquoise au pied d’un massif rocheux de montagne.

Source

Riddles42 · 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 : vue d'ensemble

Vous saurez délimiter le sujet : un reporting Power BI dont la source analytique est Microsoft Fabric / OneLake, alimenté par des applications mobiles SaaS (SFA/CRM terrain, Dynamics 365…

En bref

• Vous saurez délimiter le sujet : un reporting Power BI dont la source analytique est Microsoft Fabric / OneLake, alimenté par des applications mobiles SaaS (SFA/CRM terrain, Dynamics 365, Salesforce, Power Apps, apps de collecte).
• Vous saurez formuler la promesse de cette architecture et ses contreparties (capacité, quotas d'API, latence, schémas qui dérivent).
• Vous saurez dire quand c'est le bon choix — et quand un simple datamart SQL ou un Import suffit — avec une grille de décision et des notes /5.
• Vous aurez la carte des 3 autres fichiers du dossier : architecture, difficultés et pièges, IA.
• Faits volatils vérifiés en octobre 2026 ; ils sont signalés « (état 2026-10) ».

Sur cette page

1. 1. Interprétation du sujet
2. 2. Les bases : ce qu'est OneLake
3. 3. Les bases : ce qu'est une application mobile SaaS en terrain
4. 4. La promesse de l'architecture
5. 5. Cas métier SFA et terrain
6. 6. Pratique : à quoi ressemble un projet type
7. 7. Quand c'est le bon choix, et quand ça ne l'est pas
   1. C'est le bon choix si…
   2. Ce n'est pas le bon choix si…
8. 8. Expert : les arbitrages structurants
9. 9. Notes de synthèse
10. 10. Voir aussi

Niveau : 🟢→🔴

1. Interprétation du sujet#

Le sujet « OneLake + applications mobiles en SaaS » est ambigu ; voici l'interprétation retenue pour tout le dossier, afin que les quatre fichiers parlent de la même chose.

• OneLake désigne le stockage logique unique de Microsoft Fabric : un « OneDrive pour la donnée » par tenant, qui stocke les tables au format ouvert Delta/Parquet et que tous les moteurs Fabric (Spark, SQL, KQL, Power BI) lisent sans copie.
• Applications mobiles en SaaS désigne les applications de force de vente / CRM / collecte terrain exploitées en SaaS : une appli mobile (souvent hors-ligne) saisit des visites, commandes, relevés, photos, signatures ; un back-end géré par l'éditeur les synchronise vers un cloud que l'on ne contrôle pas (Dynamics 365, Salesforce, une solution SFA verticale, une Power App, un outil de formulaires).
• Le reporting est du Power BI (modèle sémantique + rapports), éventuellement multilingue, qui lit OneLake plutôt que l'application elle-même.

Autrement dit : « Comment transformer la donnée d'une application mobile SaaS que je ne maîtrise pas en un reporting fiable, frais et gouverné, en passant par OneLake ? »

Pour la variante « base relationnelle managée comme source » (Azure SQL, SQL Managed Instance, SQL database in Fabric), voir le dossier jumeau : SQL Server en SaaS — vue d'ensemble, et leur confrontation dans le comparatif.

2. Les bases : ce qu'est OneLake#

🟢 Novice.

OneLake est le lac de données unique, fourni avec chaque tenant Fabric. Quatre idées suffisent pour commencer :

1. Une seule copie. Les données sont stockées une fois, au format Delta Lake (fichiers Parquet + un journal de transactions). Le moteur SQL, Spark et Power BI lisent les mêmes fichiers.
2. Des items. On range ces données dans des items Fabric, eux-mêmes dans des workspaces : un lakehouse (tables Delta + fichiers, manipulé surtout par Spark), un warehouse (entrepôt T-SQL transactionnel), un eventhouse (séries temporelles / événements).
3. Des raccourcis (shortcuts) : une référence vers des données situées ailleurs (autre lakehouse, ADLS Gen2, Amazon S3, Dataverse…), consultée comme si elle était locale, sans la copier.
4. Le mirroring : réplication continue, gérée par Fabric, d'une base opérationnelle (Azure SQL, Cosmos DB, Snowflake, PostgreSQL, Oracle… (état 2026-10)) vers des tables Delta dans OneLake.

Power BI se branche dessus de trois façons : Import (copie dans le modèle), DirectQuery (requêtes vers la source) et Direct Lake (le moteur VertiPaq charge directement les colonnes Delta en mémoire ; refresh = simple « reframing » des métadonnées). Détails au fichier architecture.

3. Les bases : ce qu'est une application mobile SaaS en terrain#

🟢 Novice.

Une application SFA terrain a quatre particularités qui conditionnent tout le reporting :

Un signal faible mais déterminant : la fraîcheur ressentie dépend davantage de la synchronisation mobile (parfois quotidienne !) que de votre pipeline. Un tableau de bord « temps réel » alimenté par des tablettes qui synchronisent le soir n'est pas temps réel.

4. La promesse de l'architecture#

🟡 Praticien.

Combiner OneLake et un SaaS mobile promet :

• Une copie analytique que vous contrôlez : historisée, requêtable en SQL, Spark ou DAX, indépendante des quotas d'interrogation de l'appli.
• Une seule plateforme pour l'ingestion, la transformation, le stockage, le modèle sémantique et le reporting : moins de maillons à supervisionner, une gouvernance et une sécurité communes (OneLake security, disponible en GA depuis le printemps 2026 (état 2026-10)).
• Du volume à coût maîtrisé : Direct Lake permet d'interroger des volumes qu'on n'importerait pas, avec des performances proches de l'Import.
• Une fraîcheur ajustable : du batch quotidien au quasi-temps réel (eventstream, mirroring, webhooks) selon la valeur métier.
• Un socle pour l'IA : Copilot, agents de données et notebooks lisent la même donnée gouvernée (fichier IA).

Ce que la promesse ne couvre pas : la qualité de saisie, la définition des indicateurs (voir modèle sémantique), la stabilité du schéma SaaS, l'adoption par les commerciaux.

5. Cas métier SFA et terrain#

🟡 Praticien.

6. Pratique : à quoi ressemble un projet type#

🟡 Praticien.

Les étapes d'un projet raisonnable :

1. Cadrer la valeur : 3 à 5 questions métier, pas « tout répliquer ».
2. Inventorier la source : objets, volumes, API disponibles, quotas, mode de suppression, horodatages, schéma documenté ou non.
3. Choisir le mode d'ingestion (voir la matrice du fichier architecture).
4. Poser le médaillon et les règles de qualité.
5. Modéliser en étoile (Kimball) : faits de visite/commande/relevé, dimensions client, produit, date, utilisateur terrain.
6. Sécuriser : RLS (hiérarchie commerciale), OneLake security, rôles d'espace de travail.
7. Industrialiser : Git, pipelines de déploiement, supervision de la capacité (CI/CD pour la data).
8. Recetter sur des chiffres connus du métier, puis ouvrir.

7. Quand c'est le bon choix, et quand ça ne l'est pas#

🟡 Praticien.

C'est le bon choix si…#

• plusieurs sources (SFA, ERP, référentiels, fichiers de panel) doivent être croisées ;
• le volume ou l'historique dépasse ce qu'un Import confortable supporte, ou l'on veut des temps de rafraîchissement courts ;
• on veut Spark/Python (nettoyage avancé, ML) à côté du SQL et de DAX ;
• l'organisation est déjà sur Microsoft 365/Entra/Power BI et prête à piloter une capacité ;
• on prévoit plusieurs rapports s'appuyant sur le même socle (un modèle, plusieurs usages) ;
• l'IA (agents de données, Copilot) fait partie de la trajectoire.

Ce n'est pas le bon choix si…#

• une seule source de volume modeste alimente 2 rapports : un Import depuis le connecteur de la SFA, ou un datamart SQL existant, est plus simple et moins cher ;
• l'équipe n'a aucune compétence Spark/Delta et aucun budget de montée en compétence : la complexité cachée l'emporte ;
• la latence exigée est de l'ordre de la seconde et dépend d'un SaaS qui n'offre que du batch ;
• la contrainte de souveraineté ou de région ne cadre pas avec le tenant Fabric disponible ;
• la capacité ne peut pas être dimensionnée ni supervisée (pas de propriétaire).

8. Expert : les arbitrages structurants#

🔴 Expert.

1. Copier ou ne pas copier. Les raccourcis et le mirroring évitent la copie physique mais pas la dépendance : un shortcut vers un SaaS qui expose des fichiers (ex. Dataverse via Link to Fabric) vous donne la structure de l'éditeur, qui bouge. Le médaillon réintroduit une copie volontaire pour découpler. Règle : ne jamais brancher un rapport sur la structure brute d'un SaaS.

2. Capacité partagée ou dédiée. Le coût de Fabric est un coût de capacité (CU), pas de requête. Une capacité mutualisée entre ETL nocturne, Spark interactif, Copilot et rapports finit par se faire sentir : le « voisin bruyant » est interne (difficultés).

3. Horodatage et vérité. Dans une SFA hors-ligne, la vérité métier est la date de l'événement, la vérité technique la date de réception. Les faits doivent porter les deux ; les agrégats « du jour » se calculent sur l'événement, les contrôles de fraîcheur sur la réception.

4. Suppressions. La plupart des API SaaS n'exposent pas proprement les suppressions. Sans stratégie (soft delete, flux de suppression, réconciliation périodique), le lac accumule des fantômes. C'est le piège n° 1 des projets de ce type.

5. Verrouillage. Delta/Parquet sont ouverts, donc les données sont portables ; en revanche le modèle sémantique Direct Lake, les dataflows gen2, la sécurité OneLake et les pipelines sont propres à Fabric. Mesurez votre niveau de dépendance dans le comparatif.

6. Niveau de gouvernance. Plus il y a de self-service, plus il faut de contrats, de certification et de lignage (gouvernance et self-service).

9. Notes de synthèse#

Appréciations d'expert, contextuelles (cf. NOTATION). Contexte : équipe BI de 3 à 6 personnes, une SFA terrain SaaS + 2 à 3 sources complémentaires, 100 à 500 utilisateurs de rapports, tenant Microsoft 365 existant.

10. Voir aussi#

• Suite du dossier : Architecture · Difficultés et pièges · IA
• Variante relationnelle : SQL Server en SaaS · Comparatif OneLake vs SQL Server
• Transverse : Bonnes pratiques Power BI · Checklist de projet de reporting
• Mesurer votre pratique : Matrice développement BI · Exploitation, supervision et capacité · Coût, licences et capacité · Qualité des données
• Outils : Git et données SQL/BI
• Termes : Glossaire

✻ Rédigé par Claude Sonnet 5.5