i

Description

Rivage d’un grand lac agité sous un ciel chargé, avec des arbres nus et des enrochements.

Source

SAF1999 · 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 : difficultés et pièges

Vous saurez anticiper les difficultés structurelles : capacité (CU), throttling, quotas d'API, fraîcheur, identité, qualité terrain, multi-locataire, coûts cachés, gouvernance, verrouillage…

En bref

• Vous saurez anticiper les difficultés structurelles : capacité (CU), throttling, quotas d'API, fraîcheur, identité, qualité terrain, multi-locataire, coûts cachés, gouvernance, verrouillage, compétences.
• Vous disposez d'un catalogue de 36 pièges au format symptôme / cause / remède, numérotés P01 à P36, à recopier dans votre checklist (checklist de projet).
• Vous saurez diagnostiquer un incident de capacité et un écart de chiffres sans accuser le mauvais maillon.
• Contexte : vue d'ensemble et architecture. Faits volatils vérifiés en octobre 2026 (état 2026-10) ; les seuils exacts sont à revérifier dans la documentation avant tout dimensionnement.

Sur cette page

1. 1. Capacité et CU
2. 2. Throttling et smoothing
3. 3. Direct Lake : repli et garde-fous
4. 4. Quotas et contraintes des API SaaS
5. 5. Latence et fraîcheur
6. 6. Identités et consentements
7. 7. Qualité des données de terrain
8. 8. Multi-locataire et multi-clients
9. 9. Coûts cachés
10. 10. Gouvernance et verrouillage
11. 11. Compétences et organisation
12. 12. Catalogue des pièges
    1. 12.1 Capacité et exploitation
    2. 12.2 Direct Lake et modèle
    3. 12.3 Ingestion SaaS
    4. 12.4 Qualité, sécurité et conformité
    5. 12.5 Organisation et stratégie
13. 13. Diagnostic en situation
14. 14. Notes de synthèse
15. 15. Voir aussi

Niveau : 🟢→🔴

1. Capacité et CU#

🟢 Novice.

Fabric ne se facture pas à la requête mais à la capacité : une SKU « F » (F2, F4, F8… F8192) fournit un nombre de Capacity Units (CU) par seconde, partagé entre toutes les charges de l'espace : pipelines, Spark, dataflows, requêtes SQL, rafraîchissements, rapports, Copilot. Une F64 offre 64 CU.

Ordres de grandeur de tarification publics (état 2026-10, à revérifier dans votre région et votre devise) : environ 0,18 USD par CU et par heure en paiement à l'usage dans une région américaine de référence, facturation à la seconde avec minute minimale, soit environ 263 USD par mois pour une F2 en 24 h/24 ; une réservation d'un an abaisse le coût d'environ 40 %. Les capacités peuvent être suspendues (on ne paie pas le calcul pendant la pause, mais la consommation lissée déjà accumulée est facturée à la mise en pause, et le stockage reste facturé) ou redimensionnées (changement de SKU) quand la charge varie.

Autres repères :

• Le seuil F64 a une signification de licence : à partir de F64 (ex-P1), les lecteurs d'un contenu partagé n'ont pas besoin de licence Power BI Pro ; en dessous, chaque lecteur doit en avoir une (état 2026-10, à vérifier avec la politique de licences en vigueur — voir coût, licences et capacité).
• Les garde-fous Direct Lake dépendent de la SKU (mémoire maximale, nombre de fichiers, lignes par table) : F2–F32 : 300 millions de lignes par table ; F64 : 1,5 milliard (état 2026-10).
• Copilot et les agents de données sont utilisables à partir de F2 (disponibilité étendue à toutes les SKU payantes depuis le 30 avril 2025 ; état 2026-10) et consomment des CU.

2. Throttling et smoothing#

🟡 Praticien.

Smoothing : Fabric lisse la consommation dans le temps. Les opérations d'arrière-plan (rafraîchissements, pipelines, Spark planifié) sont lissées sur 24 heures ; les opérations interactives (requêtes de rapport) sur une fenêtre plus courte (de quelques minutes à une heure, selon la charge). On peut donc dépasser temporairement sa capacité sans conséquence immédiate, en « empruntant » du futur.

Throttling : quand la dette de consommation dépasse certains seuils, la plateforme retarde puis rejette des opérations. Ordre de grandeur de l'escalade (à revérifier dans la documentation « Throttling » de Fabric) : dépassement jusqu'à 10 minutes de capacité future : aucune sanction ; 10 à 60 minutes : les opérations interactives sont retardées ; au-delà, elles sont rejetées ; si la dette dépasse 24 heures, les opérations d'arrière-plan sont rejetées elles aussi.

Conséquences concrètes :

• Un gros notebook lancé à 8 h peut dégrader les rapports à 11 h : la facture arrive après.
• Une boucle de rafraîchissement défaillante (relances automatiques) peut consommer tout le crédit.
• Les rapports « lents le lundi matin » sont souvent un symptôme de dette héritée du week-end.

Outils : Fabric Capacity Metrics app (consommation par item, opération, utilisateur, dépassements), alertes de capacité, journaux de pipelines et Spark. Pas de supervision, pas de maîtrise (exploitation, supervision et capacité).

3. Direct Lake : repli et garde-fous#

🟡 Praticien.

Deux variantes coexistent (état 2026-10) : Direct Lake on OneLake, qui ne se replie jamais en DirectQuery et échoue franchement si un garde-fou est dépassé, et Direct Lake on SQL analytics endpoint, qui se replie en DirectQuery si la source est une vue SQL, si l'endpoint applique une RLS SQL, ou si un garde-fou de la SKU est dépassé (paramètre « Direct Lake behavior »). Le repli est silencieux pour l'utilisateur : le rapport devient simplement lent et charge la source SQL.

Causes typiques de lenteur ou d'échec : trop de petits fichiers Parquet (dépassement du nombre de fichiers), tables non optimisées (pas de V-Order, row groups mal dimensionnés), colonnes trop larges (chaînes très longues, limite de 32 764 caractères), mémoire maximale de la SKU dépassée (pagination excessive), types non supportés.

4. Quotas et contraintes des API SaaS#

🟡 Praticien.

Le goulet d'étranglement d'un projet SaaS n'est souvent pas Fabric mais l'éditeur :

• Quotas d'appels par jour/heure/minute, par organisation ou par utilisateur d'intégration ; erreurs 429/503 à gérer avec backoff exponentiel et reprise.
• Pagination : curseurs expirants, pages de 200 enregistrements, décalage entre pages si la donnée change pendant l'extraction.
• Fenêtres de maintenance et dégradation des API en journée de forte charge (début de mois, clôtures).
• Limites de volume par export, par requête, par objet ; champs calculés non filtrables côté serveur.
• Coûts d'API facturés par certains éditeurs au-delà d'un forfait.
• Dépréciation d'API : versions retirées, nouveaux jetons obligatoires ; lire le calendrier de fin de vie.
• Contrat d'interface : l'éditeur ne s'engage pas sur votre usage analytique ; clarifier le support contractuel.

5. Latence et fraîcheur#

🟡 Praticien.

La fraîcheur est une somme de latences, et la plus longue décide :

Saisie terrain -> synchro mobile -> back-end SaaS -> API/export -> ingestion Fabric
   (min…jours)     (min…h)          (s)           (min…h)         (min)
-> transformation silver/gold -> reframing du modèle -> cache de rapport
          (min)                      (s…min)             (min si tuiles)

Que faire : mesurer de bout en bout (un enregistrement test dont on suit chaque horodatage), afficher la date de dernière donnée dans le rapport, négocier le besoin réel (un directeur régional a-t-il besoin du temps réel ?), et réserver l'eventstream aux cas à valeur démontrée.

6. Identités et consentements#

🟡 Praticien.

• Compte de service : l'intégration SaaS ne doit pas dépendre du compte d'une personne (départ, rotation de mot de passe, MFA). Préférer un principal de service ou une identité d'espace de travail, avec secrets dans Key Vault.
• Consentement administrateur (OAuth) : les connexions à Dynamics, Salesforce ou Graph exigent des consentements d'application qui relèvent de l'administrateur du locataire ; prévoir le délai.
• Jetons expirants : refresh tokens révoqués si le compte change de statut ou si l'éditeur resserre sa politique.
• Identité de l'utilisateur final : le RLS repose sur l'adresse (UPN) de l'utilisateur ; or l'identité dans la SFA (code commercial) diffère de l'identité Entra : table de correspondance à maintenir.
• Invités externes (agents de distributeurs, prestataires) : licence, sécurité, partage inter-locataire, délégation (shortcuts délégués en preview, état 2026-10).
• Accès conditionnel / MFA : peut bloquer les appels automatisés si mal configuré.

7. Qualité des données de terrain#

🟡 Praticien.

La saisie mobile engendre des défauts spécifiques : doublons de client, formats libres (téléphone, adresse), dates fausses (horloge de l'appareil), coordonnées GPS à zéro, champs obligatoires contournés (« xxx »), produits saisis hors référentiel, photos illisibles, visites « fantômes » créées par erreur.

Principes : mesurer avant de corriger (taux de nuls, doublons, hors référentiel, par commercial et par jour), ne pas corriger silencieusement (journaliser et rendre visible), remonter à la source (le retour vers le terrain vaut plus que tout nettoyage en aval) et séparer erreur technique (pipeline) et erreur métier (saisie). Voir qualité des données et tests et fiabilité des chiffres.

8. Multi-locataire et multi-clients#

🔴 Expert.

Deux dimensions de « multi » se superposent : celle du SaaS (l'éditeur est multi-locataire ; vous êtes un locataire parmi d'autres) et celle de votre produit (un seul socle Fabric pour plusieurs clients ou filiales).

• Isolation : espaces distincts par client, ou un espace avec RLS par client ; l'isolation par RLS exige une rigueur irréprochable (une table de sécurité erronée = fuite). L'espace séparé coûte plus cher en gouvernance mais simplifie l'audit.
• Paramétrage par client : champs personnalisés propres à chaque tenant SaaS → schéma silver commun avec table « clé/valeur » ou colonnes dynamiques ; le gold conserve les colonnes standard.
• Capacité partagée : un client lourd peut en priver d'autres ; envisager capacités par segment ou quotas internes.
• Régions et conformité : données dans la région du locataire, ou région contractuelle du client ; Direct Lake exige la même région pour la source et le modèle.
• Releases : un éditeur déploie sur tous ses clients ; le comportement de votre intégration peut changer un lundi sans que vous n'ayez rien fait.

9. Coûts cachés#

🟡 Praticien.

10. Gouvernance et verrouillage#

🔴 Expert.

Gouvernance : sans règles, un tenant Fabric devient un « libre-service sans responsable » ; chaque item a un propriétaire, un statut (certifié, promu, essai), une durée de vie. Voir gouvernance, catalogue et self-service et gouvernance des données. Les fonctions de lignage, de catalogue (OneLake catalog) et de gouvernance (Purview) aident mais ne remplacent pas la discipline ; certaines fonctions de découverte (API de recherche, outils MCP) sont en preview (état 2026-10).

Verrouillage : le format de stockage (Delta/Parquet) est ouvert ; ce qui enferme, c'est l'assemblage : pipelines Fabric, dataflows gen2, modèle sémantique Direct Lake, sécurité OneLake, capacités. Mesure de réversibilité : « si on quitte Fabric dans 18 mois, que garde-t-on tel quel ? » (données Delta, notebooks Spark, SQL de transformation ; à réécrire : orchestration, modèle de sécurité, semantic model). Plus le logiciel est « no-code », plus la sortie coûte. Comparez dans le comparatif OneLake vs SQL Server.

Cadence d'évolution : Fabric livre en continu ; une fonction « preview » peut changer ou disparaître. Règle : pas de dépendance critique à une fonction preview sans plan de repli et sans accord explicite de l'équipe.

11. Compétences et organisation#

🟡 Praticien.

Un projet OneLake + SaaS demande, pour une équipe de 3 à 6 personnes, quatre familles de compétences : ingestion/API (REST, OAuth, pagination), Delta/Spark/SQL (MERGE, optimisation), modélisation et DAX, exploitation de capacité (métriques, coûts). Une équipe issue du monde SQL Server maîtrise souvent le deuxième et le troisième par analogie, mais pas l'ingestion API ni la capacité.

Pistes : binôme senior/junior sur chaque brique, un référent capacité nommé, runbook d'incident, revue de code des notebooks, kata sur un petit périmètre avant le grand. Évitez le « héros » unique : le facteur camion de l'intégration API est très souvent égal à 1.

12. Catalogue des pièges#

🔴 Expert. Chaque piège : symptôme, cause, remède.

12.1 Capacité et exploitation#

12.2 Direct Lake et modèle#

12.3 Ingestion SaaS#

12.4 Qualité, sécurité et conformité#

12.5 Organisation et stratégie#

13. Diagnostic en situation#

🔴 Expert.

Arbre de décision pour « le chiffre est faux ou le rapport est lent » :

1. Faux ou absent ? Comparez à la source (requête directe sur l'API ou export). Si la source diffère : problème d'ingestion (P15–P24). Si la source est identique : problème de modèle/mesure (P09, P12, P13).
2. Lent ? Le rapport est-il en repli (P07), la capacité en throttling (P01) ou le modèle dépasse-t-il les garde-fous (P08) ?
3. Récent ou ancien ? Changement d'éditeur (P17), déploiement (P14), dépassement de quota (P18), jeton (P21).
4. Reproductible ? Pour un utilisateur seulement : RLS (P12–P13) ; pour tous : source ou capacité.

14. Notes de synthèse#

Appréciations d'expert, contextuelles (cf. NOTATION). Note de gravité typique et de probabilité par famille ; contexte : équipe de 3 à 6 personnes, SFA SaaS, 100–500 utilisateurs.

15. Voir aussi#

• Dossier : Vue d'ensemble · Architecture · IA · Pièges SQL Server en SaaS · Comparatif · Bonnes pratiques transverses · Checklist de projet
• Matrices : Développement BI · Performance et volumétrie · Sources et contrats de données · Exploitation et support
• Conduite de projet : Pièges et bonnes pratiques
• Termes : Glossaire

✻ Rédigé par Claude Sonnet 5.5