Microsoft Fabric : Limiter les dépassements avec Surge Protection (+ démo)
Comment protéger ta capacité contre les workspaces qui surconsomment ?
Bonjour à tous, je suis Antoine Wang.
J’aide les profils techniques à maîtriser l’architecture de Microsoft Fabric, et j’aide les décideurs à comprendre l’impact réel de cette technologie.
Mon objectif ? Vulgariser le complexe et vous donner les clés pour maîtriser Microsoft Fabric, une plateforme de données SaaS unifiée et alimentée par l’IA pour simplifier la gestion des données et l’analyse.
🆕 Nouveauté pour les lecteurs : j’ai créé Ask Fabric Mastery, un assistant IA qui répond à vos questions sur Microsoft Fabric & Power BI en s’appuyant uniquement sur les 31 éditions de cette newsletter. Réponses sourcées, sans hallucination, avec un lien direct vers l’édition d’origine.
👉 Testez-le maintenant : ask-fabric-mastery
🔑 Code d’accès (ce code est réservé aux abonnés Fabric Mastery) :
Cette newsletter est 100% gratuite. En vous abonnant maintenant, vous recevrez en exclusivité mon “One-Pager” pour cartographier l’ensemble de la solution Fabric en un coup d’œil.
Merci à celles et ceux qui me suivent depuis le début. Sans plus attendre, entrons dans le vif du sujet !
Avez-vous déjà vécu ce genre de scénario sur Microsoft Fabric ? On lance un premier cas d'usage, ça fonctionne, tout tourne parfaitement, cool. Puis on en ajoute un deuxième, un troisième, … et on se pose la question de savoir quels sont les outils qui me permettent de surveiller la consommations des Capacity Units (CUs) de l’ensemble de mes workspaces.
On installe la Capacity Metrics App et la réalité saute aux yeux : un seul espace de travail monopolise toutes les Capacity Units (CUs). On se demande alors, que faire si :
la capacity Fabric est throttlée par un workspace en particulier ?
Comment prioriser les tâches interactives plutôt que les tâches en arrière-plan ?
Certains pipelines sont rejetés dûs à un workspace de DEV ?
C’est la réalité du terrain quand on gère une capacité mutualisée avec 10, 20 ou 50 workspaces différents. Un seul projet de DEV ou un pipeline mal calibré prend en otage l’ensemble de votre production, sans que vous puissiez isoler chirurgicalement le coupable.
C’est pour cela que mon post se tourne vers une fonctionnalité précise pour gérer la capacité : le Surge Protection.
L’objectif : limiter la consommation de CUs au niveau de la capacity entière. Soit tout le monde trinquait, soit personne.
Et Microsoft vient de changer la donne avec le workspace-level surge protection (janvier 2026).
Voici ce que tu dois comprendre avant de l’activer en prod.
C’est quoi la Surge Protection ?
La Surge Protection limite la quantité de compute consommée par les background jobs, pour éviter que la capacity entre en état de throttling profond.
Le principe de base :
Tu définis un seuil de rejet (rejection threshold) : au-delà, les nouvelles opérations background sont refusées.
Tu définis un seuil de récupération (recovery threshold) : en dessous, la capacity recommence à accepter des jobs.
Ce mécanisme protège en priorité les opérations interactives (consultation de rapports Power BI, requêtes SQL...) face aux workloads lourds en arrière-plan (actualisations, notebooks, pipelines).
Cette nouveauté de février 2026 : Workspace-level surge protection
Jusqu’ici, la Surge Protection s’appliquait uniquement au niveau de la capacity, tous les workspaces partageaient les mêmes règles.
Maintenant, tu peux aller beaucoup plus fin.
Voici comment configurer concrètement le workspace-level surge protection :
Naviguez vers le portail d’administration : Connectez-vous et allez dans Admin Portal → Capacity settings → sélectionnez votre Fabric Capacity.
Activez la détection automatique : Sous la section Surge protection, activez l’option pour monitorer tous les espaces de travail et bloquer ceux qui surconsomment.
Paramétrez le contrôle par workspace : Activez le bouton Workspace consumption. C’est ici que la gouvernance granulaire se définit. Deux nouveaux champs vont s’afficher :
Le seuil de rejet (Rejection Threshold) : Vous définissez le quota maximum de CUs de la capacité totale qu’un seul workspace peut monopoliser sur 24 heures glissantes. Pour un SKU F2 par exemple, un plafond de 5 % équivaut à 2,4 CU-heures par jour.
Le blocage (Block) : C’est le disjoncteur chirurgical. Dès que le quota est atteint, paf, le workspace est bloqué. C’est à vous de choisir la durée de la punition : indéfinie pour forcer une discussion d’optimisation ou temporaire (un nombre d’heures spécifique).
L'automatisation c'est bien, mais la réalité du terrain exige parfois des interventions manuelles, vous avez des workspaces qui sont prioritaires par rapport à d’autres et c’est normal. Voici comment reprendre le contrôle manuel sur un workspace spécifique :
Dans le portail d’administration, sous “Capacity Settings”, sélectionnez la Capacité Fabric.
Dans le tableau “Workspace assigned to this capacity” en bas, cliquez sur l’icône d’engrenage dans la colonne Actions pour accéder aux paramètres de l’espace de travail.
Chaque workspace peut se voir attribuer l’un de ces 3 états :
🟢 Available : état par défaut, soumis aux règles de surge protection
🔴 Blocked : toutes les opérations (background ET interactives) sont rejetées — manuellement ou automatiquement
⭐ Mission Critical : exempté des limites de CU au niveau workspace — mais pas exempté du throttling si la capacity globale est saturée
La réalité du terrain
✅ Bénéfices réels
Évite les états de throttling profond avec des temps de récupération longs, en déclenchant le rejet plus tôt
Permet d’exclure les workspaces critiques (Mission Critical) de tout mécanisme de blocage automatique
Permet de bloquer manuellement un workspace problématique pour une durée définie
Active des bannières de notification directement dans le workspace bloqué, pour alerter les équipes concernées
⚠️ Limites
La Surge Protection n’arrête pas les jobs en cours — seules les nouvelles opérations sont rejetées. Le 24h background % peut donc dépasser le seuil configuré le temps que les jobs actifs terminent.
La Surge Protection ne garantit pas que les requêtes interactives ne seront pas ralenties ou rejetées. Si la capacity atteint ses limites absolues, tout est throttlé, protection active ou pas.
La Surge Protection ne bloque pas les opérations facturées via Autoscale pour Spark.
Matrice de décision
Q1 : Est-ce que tu partages une capacity entre des workspaces de production et de développement ?
Oui → Active la protection workspace-level et tague tes workspaces prod en Mission Critical.
Q2 : Est-ce que tu as régulièrement des alertes de throttling ou des rejections en heures ouvrées ?
Oui → Commence par analyser le Background rejection chart dans le Fabric Capacity Metrics App. Identifie les pics avant de configurer les seuils.
Q3 : Est-ce que tu as des pipelines critiques qui ne peuvent pas être interrompus sous aucun prétexte ?
Oui → Passe ces workspaces en Mission Critical. Et pense à les isoler dans une capacity dédiée pour une vraie garantie de service.
Q4 : Est-ce que 80% ou plus de ta capacity est consommée par des background operations ?
Oui → La Surge Protection seule ne sera pas suffisante. La priorité est de réarchitecturer ta capacity ou de scaler.
Mon conseil
L’erreur classique sur le terrain : activer la Surge Protection avec les seuils par défaut sans avoir analysé les patterns réels de consommation.
Résultat : tu bloques des jobs légitimes, tu génères des alertes incompréhensibles pour les équipes data, et tu passes 2 heures à expliquer pourquoi le pipeline du matin n’est pas parti.
Commence par observer, ouvre le Fabric Capacity Metrics App, analyse les charts Background rejection, Interactive rejection et Utilization sur 2-3 semaines, avant de toucher aux seuils.
La bonne configuration, c’est une configuration que tu ajustes empiriquement, pas un réglage qu’on copie d’un blog.
Règle d’Or
Si tu dois retenir une chose : la Surge Protection workspace-level, c’est un gouverneur de ressources. Elle te donne enfin la granularité pour isoler un workspace déviant sans pénaliser toute ta capacity. Mais elle ne remplace pas une architecture propre : workspaces dev/test séparés des workspaces prod, seuils calibrés sur tes vrais patterns de charge, et workspaces critiques tagués Mission Critical dès le départ.
Le gain concret : fini le scénario où un notebook qui tourne en boucle le dimanche soir provoque des rejections en cascade le lundi matin sur tous tes rapports Power BI.
Et vous, pensez-vous que cette fonctionnalité va vous servir ? Répondez simplement à cet email ou ce post, je lis tous vos messages.
À la semaine prochaine pour continuer à explorer ensemble les entrailles de Fabric !
🔗 À lire dans Fabric Mastery
Microsoft Fabric : Comment surveiller votre capacité comme un Pro ?
Fabric Copilot Capacity (FCC) : le guide 2026 pour activer Copilot sans throttling
📚 Ressources pour aller plus loin
Pour approfondir le sujet, je vous recommande ces lectures essentielles :
La documentation technique Microsoft Learn : Surge protection - Microsoft Fabric
L’annonce détaillée sur le blog Fabric : Surge protection gets smarter: Introducing workspace-level controls (Preview)