Détecter des opérations spécifiques sur une capacité Microsoft Fabric

« Nous avons créé une capacité Copilot dédiée. Mais comment savoir que Copilot s’exécute réellement dessus, et nulle part ailleurs ? »

C’est une question qu’un administrateur Fabric m’a récemment posée, quelques semaines après le déploiement de Copilot.

Et c’est une excellente question.

Car la configuration était correcte. La Fabric Copilot Capacity (FCC) était configurée, les utilisateurs assignés, les paramètres du tenant correctement délégués. Sur le papier, tout était en place.

Mais personne n’était capable de répondre à une question opérationnelle pourtant simple :

Quelqu’un utilise-t-il Copilot ailleurs en ce moment ?

L’écart entre « configuré » et « vérifié » est précisément l’endroit où l’observabilité devient essentielle.

Pourquoi est-ce important ?

Dans Fabric, Copilot est facturé comme une opération d’arrière-plan (background operation), basée sur la consommation de tokens.

Les opérations d’arrière-plan sont lissées sur une période de 24 heures. C’est excellent pour la stabilité de la plateforme, mais beaucoup moins pour la visibilité. La consommation arrive discrètement, répartie sur une longue période, sur la capacité qui héberge le contenu de l’utilisateur.

Une Fabric Copilot Capacity résout l’aspect facturation. Vous désignez une capacité dédiée (une F2 suffit pour commencer), vous y affectez un groupe d’utilisateurs, et leur consommation Copilot est regroupée et facturée sur cette capacité plutôt que dispersée dans vos capacités de production.

Mais une FCC n’est pas un mur de séparation. C’est une règle comptable soumise à plusieurs conditions :

• Elle ne s’applique qu’aux utilisateurs assignés. Un utilisateur oublié continuera à consommer sur sa propre capacité.
• Un seul FCC est pris en charge par utilisateur. Si un utilisateur est affecté à plusieurs FCC, la plus récemment créée est prioritaire.
• Les Data Agents suivent la même logique, ce qui surprend souvent les équipes ayant déployé des agents avant l’arrivée du FCC.

Ainsi, la configuration peut être parfaite sur le papier, tandis que le comportement réel dérive progressivement.

Et lorsque cette dérive se produit sur une capacité de production déjà utilisée pour des workloads Power BI critiques, vous la découvrez généralement au travers du throttling, pas dans un rapport.

👉 Ce dont l’administrateur avait réellement besoin n’était pas un tableau de bord. Il avait besoin d’une alerte.

Le scénario

Prenons un exemple concret :

• Un administrateur Fabric a créé une Fabric Copilot Capacity et affecté un groupe d’utilisateurs maîtrisé
• Copilot est censé s’exécuter uniquement sur cette capacité
• Toute exécution de Copilot sur une autre capacité n’est pas forcément une erreur, mais elle doit être connue et validée
• Lorsqu’un tel événement se produit, l’équipe plateforme souhaite recevoir un message dans un canal Microsoft Teams en quelques minutes, avec suffisamment de contexte pour déterminer si le comportement est attendu ou non

Voilà tout. Pas besoin d’un framework sophistiqué de gouvernance IA. Une règle, un signal, une action.

La solution

Jusqu’à récemment, répondre à cette problématique impliquait :

• Capacity Metrics App
• Filtre d’opération « Copilot in Fabric »
• Un humain se souvenant d’aller vérifier régulièrement

J’avais décrit cette approche il y a deux ans dans mon article sur le suivi de l’adoption de Copilot dans Fabric.

Cela fonctionne, mais :

• L’approche est rétrospective
• Elle dépend de la période de rétention du modèle sémantique de Capacity Metrics
• L’application peut évoluer ou changer

➡️ Le véritable changement vient de Fabric Capacity Operation Events, désormais disponible en préversion dans le Real-Time Hub.

📖 Documentation : Explorer les événements d’opérations de capacité Fabric

Fabric émet désormais un événement pour chaque opération consommant de la capacité.

Pas un agrégat. Pas un regroupement toutes les 30 minutes. Une ligne = une opération.

L’ensemble de la solution tient sur un seul écran : Une source, un stream, un filtre, une alerte, une destination. Sans code.

Étapes 1 et 2 : S’abonner aux événements

Dans le Real-Time Hub, ouvrez : Fabric Events → Fabric Capacity Operation Events

Puis sélectionnez la capacité à surveiller.

Vous devez disposer de l’autorisation Subscribe sur cette capacité. Vérifiez ce point : Subscribe permission for Azure and Fabric events.

Le paramètre important ici est : Event Scope = By Capacity

Le flux est alors lié à la capacité sélectionnée. Surveiller cinq capacités nécessite cinq sources dans le même Eventstream. C’est un peu répétitif, mais très simple à mettre en place.

Étape 3 : Filtrer les activités

Dans ce scénario, seuls les usages Copilot m’intéressent.

J’applique donc le filtre : OperationName = « Copilot In Fabric »

Étape 4 : Envoyer une notification Teams

Dans Activator, ajoutez une action Microsoft Teams à votre règle.

Le champ Context permet de déterminer quelles informations seront intégrées à la carte Teams.

Dans mon cas, j’envoie :

• data.capacityName
• data.capacitySku
• data.workspaceId
• data.workspaceName
• data.itemName
• data.itemKind

Cela permet de répondre immédiatement à la question : Où cette opération s’est-elle exécutée, et sur quel objet ?

L’horodatage est automatiquement fourni. Ce que ces informations ne permettent pas de savoir, c’est : Qui ? Combien ?

Pour cela, il faut ajouter : data.identityValue et data.capacityUnitMs.

Je les avais omis dans ma première version, puis ajoutés après la première question évidente reçue de la part des utilisateurs.

Étape 5 : Conserver les données dans un Eventhouse

La branche non filtrée est envoyée vers un Eventhouse, l’objectif n’est pas l’alerte. L’objectif est de ne pas perdre les données.

Cela permet :

• Une rétention supérieure à celle de Capacity Metrics App
• Des investigations via KQL
• La création éventuelle d’un Real-Time Dashboard

Trois points à connaître avant de commencer

1. Un événement par opération génère beaucoup d’événements. Une session Copilot n’est pas une seule opération. Ma première implémentation envoyait une alerte pour chacune d’entre elles. Le canal Teams a été mis en sourdine en moins d’une journée. Privilégiez plutôt une alerte sur la première occurrence quotidienne par capacité ou un agrégat dans l’Eventstream suivi d’une alerte agrégée.
2. Le système de surveillance consomme lui aussi des CUs. L’Eventstream, l’Eventhouse et l’Activator s’exécutent quelque part. Ne les déployez pas sur la capacité que vous essayez justement de protéger.
3. La fonctionnalité est encore en préversion. Le schéma peut évoluer. Gardez votre logique suffisamment simple pour qu’un ajustement se fasse en dix minutes plutôt qu’en projet complet.

Au-delà de Copilot

C’est probablement la partie la plus importante. Copilot n’était qu’un exemple. Le mécanisme est générique. Une fois que vous disposez d’une télémétrie opérationnelle détaillée en temps réel, « détecter Copilot sur la mauvaise capacité » n’est plus qu’une règle parmi beaucoup d’autres :

• Un notebook Spark exécuté sur une capacité de production en dehors de la fenêtre de changement autorisée.
• Toute opération présentant throttlingDelayMs > 0 sur une capacité critique, avant même que les utilisateurs ne s’en plaignent.
• Une opération consommant plus de X CU afin d’ouvrir la discussion le jour même plutôt qu’en fin de mois.
• Un workspace provenant du mauvais domaine et utilisant une capacité qu’il n’aurait jamais dû toucher.
• Des opérations identifiées avec releaseType = Preview, gratuites aujourd’hui mais potentiellement facturables demain.
• Un service principal exécutant des traitements sur une capacité où seuls des utilisateurs interactifs sont attendus.
• Une modification du SKU d’une capacité dont personne ne vous a informé.

Et les actions ne doivent pas nécessairement se limiter à Teams.

Un Activator peut également :

• Déclencher un flux Power Automate
• Ouvrir un ticket ServiceNow
• Créer un ticket Azure DevOps
• Appeler une API REST Fabric
• Déclencher une action sur l’API Azure pour mettre à l’échelle ou suspendre une capacité

C’est là que se produit le véritable changement : La télémétrie de capacité cesse d’être quelque chose que l’on consulte pour devenir quelque chose que l’on exploite.

Si vous n’avez pas besoin de temps réel. Si votre objectif est d’analyser des tendances plutôt que de gérer des incidents :

• Coût Copilot mensuel
• Coût par capacité
• Coût par business unit
• Chargeback
• Validation de l’impact réel du FCC sur la consommation de production

alors une approche quasi temps réel est probablement excessive.

Fabric Cost Analysis (FCA) couvre déjà parfaitement ce besoin, avec l’avantage de disposer de tout l’historique sans infrastructure de streaming à maintenir.

🔗 Fabric Cost Analysis : https://aka.ms/FabricCostAnalysis

La règle que j’utilise est simple : Si personne ne modifierait son comportement dans l’heure qui suit l’alerte, alors il vous faut probablement un rapport et non une alerte.

Conclusion

La majorité des efforts d’observabilité se concentrent sur les performances et les coûts. Ces deux sujets sont importants. Mais aucun ne permet de savoir si les règles de gouvernance que vous avez définies sont réellement respectées.

L’intérêt de la télémétrie de capacité est justement de permettre de vérifier que vos décisions de gouvernance sont effectivement appliquées, et pas simplement configurées un jour dans une page de paramètres par une personne qui a depuis changé d’équipe.

Une FCC sans détection n’est qu’une intention. Une FCC avec une alerte Teams est un contrôle.

Et une fois cette première règle en place, vous trouverez probablement cinq autres cas d’usage utiles  🚀