Plus loin que Power BI, plus puissant que Power Apps : Fabric Apps & Rayfin, le guide pas à pas pour créer une app Microsoft Fabric (backend, SDK, agent de code)

Imaginez : votre tableau de bord Power BI vous signale qu'un produit sera en rupture de stock dans trois jours. Que faites-vous ? Aujourd'hui, il faut quitter le rapport, ouvrir un autre outil (un e-mail, un fichier Excel, une application Power Apps…), ressaisir l'information et espérer que quelqu'un agisse. Power BI sert à voir les problèmes, pas à les traiter.

Microsoft a changé la donne en juin 2026, lors de Build, sa grande conférence annuelle pour les développeurs (developers). Avec Fabric Apps, vous créez une vraie application web, branchée directement sur les données que vous utilisez déjà dans vos rapports. Vos équipes y voient les alertes et agissent en un clic : commander, transférer, commenter. Chaque action est enregistrée dans Fabric, puis remonte dans vos rapports.

Pas de serveur à installer ni à entretenir : c'est du SaaS, un logiciel en ligne géré par Microsoft. Pas de nouveau mot de passe non plus : vos collègues se connectent avec leur compte Microsoft 365 habituel. Une seule réserve : la fonctionnalité est encore en préversion, c'est-à-dire disponible pour tester, mais pas encore définitive.

Cet article explique pourquoi cette approche mérite votre attention, ce qu'il faut préparer, puis déroule pas à pas la création et le déploiement d'une application complète, avant un bilan honnête des avantages et des limites.

Fabric Apps, c'est quoi ?

Fabric Apps permet de créer une application web (un site interne où vos collègues consultent et saisissent des informations) et de la faire tourner directement dans Microsoft Fabric, là où se trouvent déjà vos données et vos rapports.

Deux noms reviennent sans cesse, et une image suffit à les distinguer.

Fabric Apps, c'est l'immeuble. C'est le service de Microsoft qui héberge votre application et la fait fonctionner. Microsoft fournit les murs, l'électricité et le gardien à l'entrée, c'est-à-dire la sécurité et la connexion des utilisateurs.

Rayfin, c'est la boîte à outils. C'est l'outil de Microsoft (on parle aussi de Microsoft Rayfin) qui sert à construire l'application, puis à l'installer dans l'immeuble.

Autrement dit, on construit avec Rayfin et on habite dans Fabric.

Comment ça marche

1. Vous décrivez les informations que votre application doit retenir, par exemple « une action avec un commentaire et une quantité ».
2. Vous tapez une seule commande : npx rayfin up.
3. Fabric construit tout le reste pour vous : l'endroit où ranger les données (une database), le guichet pour y accéder (une API), la porte d'entrée sécurisée (la connexion avec le compte Microsoft de chacun) et l'adresse web de l'application.

Votre application peut aussi lire les données que vous utilisez déjà dans vos rapports. C'est tout l'intérêt pour un développeur Power BI : les chiffres de vos rapports alimentent directement une vraie application.

Les mots à connaître

TypeScript : la langue dans laquelle l'application est écrite. Elle repère certaines erreurs avant même que l'application ne tourne, comme un traitement de texte qui souligne les fautes pendant qu'on écrit.

SDK : des morceaux de code déjà prêts, qu'on assemble au lieu de tout écrire soi-même, comme un meuble en kit.

CLI : un outil qu'on pilote en tapant des commandes. npx rayfin up veut dire « publie mon application ». C'est une télécommande qui fonctionne avec des mots.

Décorateur : une étiquette commençant par @, placée au-dessus d'une ligne de code pour dire à Rayfin quoi en faire. @text() signifie par exemple « cette colonne contient du texte ». Comme l'étiquette « fragile » sur un carton.

API : l'intermédiaire entre l'écran et les données. L'écran demande, l'API va chercher et rapporte, comme un serveur au restaurant.

GraphQL : une façon de demander à l'API exactement ce dont on a besoin, sans plus, comme commander à la carte plutôt qu'un menu imposé. Rayfin s'en occupe pour vous.

Connecteur : le lien entre l'application et des données déjà présentes dans Fabric, comme le modèle d'un rapport. Une sorte de rallonge électrique.

Backend : tout ce qui tourne « derrière » l'écran (base de données, API, connexion). C'est précisément ce que Fabric génère pour vous.

Fabric Apps face à Power BI et Power Apps

Avant d'entrer dans le détail, voici où se situe cette nouvelle brique par rapport aux outils que vous connaissez.

Pourquoi Fabric Apps et Rayfin changent le app development sur Microsoft Fabric

Fabric Apps répond à un besoin que tout développeur Power BI connaît : aller au-delà du canevas de rapport sans sortir du périmètre gouverné de Fabric.

1. Un backend complet, cohérent, en une seule commande

Aujourd'hui, une application métier qui touche à la donnée se répartit souvent entre plusieurs services : une Web App Azure pour le front, une base Azure SQL, un modèle sémantique publié dans Fabric, une inscription d'application Entra pour l'authentification. Chaque brique a son cycle de vie, son déploiement et sa gouvernance.

Avec Fabric Apps, tout tient dans un seul élément de l'espace de travail (le fabric workspace), déployé par une seule commande et exposé derrière une seule URL de back-end (https://<votre-app>-app.rayfin.windows.net/).

2. Lire et écrire, pas seulement afficher

Un rapport lit. Une Fabric App lit et écrit : la base SQL database in Fabric fournie avec l'application accepte les créations, mises à jour et suppressions via GraphQL. Les connecteurs étendent cette capacité aux autres éléments de votre data estate, au plus près de vos « Fabric data » : le modèle sémantique en lecture (via des requêtes DAX) et les bases SQL de l'espace de travail en lecture et en écriture.

C'est exactement ce que fera notre exemple : lire en DAX les niveaux de stock et les seuils dans le modèle sémantique, puis enregistrer les actions correctives (réapprovisionnement, transfert, alerte fournisseur) dans la base de l'application.

3. Une gouvernance héritée de la platform

Dans la documentation Microsoft Learn, les mots qui reviennent sont « security », « governance » et « compliance » : l'application hérite de ceux de Fabric au lieu de les réinventer.

Concrètement, l'authentification (authentication) déployée repose exclusivement sur le SSO Microsoft Entra ID de Fabric. Les connecteurs utilisent une authentification déléguée : une requête DAX s'exécute avec les droits de l'utilisateur connecté, qui doit disposer des autorisations Build et Read sur le modèle. Dans la base de l'application, le décorateur @role définit des règles d'accès au niveau ligne directement dans le code. La RLS du modèle sémantique est préservée.

Les données écrites par l'application restent dans le tenant, dans une SQL database in Fabric, donc exploitables ensuite dans vos rapports comme n'importe quelle autre source Fabric. Côté privacy, rien ne sort du périmètre de l'organisation : pas de service tiers, pas de copie des données ailleurs.

4. Du TypeScript standard, pensé pour les agents de code

Le front est une vraie application web en TypeScript, pas un rapport PBIR. GitHub Copilot, Claude Code ou Cursor travaillent dessus nativement : c'est du développement agentic, où l'agent lit la documentation, lance les commandes et corrige ses erreurs. Le template Data App embarque même des instructions et des skills pour agents, avec des composants de visualisation, une grille de données et une validation navigateur Playwright.

Concrètement, un développeur Power BI qui maîtrise son modèle et son DAX peut livrer une application métier brandée en décrivant l'interface à un agent, sans devenir développeur full-stack. Si le sujet vous intéresse, nous avons comparé le vibe coding et Power BI dans un article dédié.

5. Des visuels sans limite

Dans Power BI, vous composez avec un catalogue : les visuels natifs, ceux de l'AppSource, ou un visuel personnalisé à développer avec ses propres contraintes. Dans une Fabric App, l'interface est une vraie page web : tout ce qu'un site web peut afficher, votre application peut l'afficher.

• un plan d'entrepôt ou d'usine en 3D, que l'on fait pivoter à la souris et sur lequel on clique pour agir ;
• un plan de vos sites, un planning en glisser-déposer, un organigramme, un configurateur produit ;
• des animations, votre charte graphique au pixel près, une version mobile soignée ;
• les grandes bibliothèques de visualisation du web, pour la 3D comme pour les graphiques, que l'agent de code sait manier.

Le template Data App fournit déjà les graphiques classiques (barres, courbes, cartes KPI, waterfall, heatmap…). Au-delà, Microsoft le dit lui-même : une Fabric App est une application web standard, on peut donc y construire n'importe quel visuel. La contrepartie : un visuel hors template demande plus de code et de tests qu'un glisser-déposer dans Power BI.

Prérequis

Côté Fabric

• Une capacité Fabric attribuée à l'espace de travail. Une petite capacité F2 a suffi pour notre exemple.
• Un espace de travail dans lequel vous avez le droit de créer des éléments.
• Une source de données, ici un modèle sémantique, sur laquelle vous avez au moins un droit de lecture.
• L'accord de votre administrateur Fabric si la fonctionnalité n'est pas encore ouverte dans votre organisation.

Côté poste du créateur

• Node.js, l'environnement d'exécution JavaScript, gratuit.
• Visual Studio Code, pour lancer les commandes de création et de publication. L'outil s'installe avec le projet.
• Un compte Microsoft qui sert à se connecter à Fabric.
• Facultatif mais recommandé : un assistant IA de développement, comme GitHub Copilot ou Claude Code, pour créer et faire évoluer l'application en langage naturel.

Côté compétences

• Des notions de développement web (React, TypeScript), ou un assistant IA pour s'en charger.
• Des notions de DAX pour interroger le modèle sémantique.

Côté utilisateurs

• Un compte de l'organisation, l'accès à l'espace de travail et au modèle sémantique, et un navigateur (Microsoft Edge, Chrome…). L'application s'ouvre depuis le portail Fabric.

Pas à pas : du modèle sémantique à l'entrepôt en 3D

Le scénario est simple. J'ai un modèle sémantique de stocks. Je veux une application où mes gestionnaires voient l'entrepôt en 3D, repèrent les ruptures d'un coup d'œil et agissent en un clic. Et je ne vais pas coder : je vais vibe coder, c'est-à-dire décrire l'application en français à une IA qui écrit le code à ma place. Mon rôle : relire, tester, demander des ajustements.

Étape 1 – Le point de départ : le modèle sémantique

Tout part du modèle sémantique (semantic model) Stocks : un distributeur fictif de robots, drones et jouets, avec 3 entrepôts, 60 produits et 90 jours de stocks et de ventes.

L'application va se baser sur notre modèle de données : les tables, les relations entre elles, les mesures… bref, la partie data des rapports en général.

Il s'agit d'un schéma en constellation : 2 tables de faits et 4 tables de dimension.

Étape 2 – Coder ou vibe coder l'application

C'est le cœur de la démo, et vous n'avez aucune commande à taper. Ouvrez VS Code, activez GitHub Copilot en mode agent (ou lancez Claude Code). Vous pouvez installer l'extension Claude Code dans le panneau latéral à gauche si vous avez un abonnement Claude, pareil pour GitHub Copilot.

Ensuite, collez le prompt. L'agent crée le projet, le branche sur le modèle, écrit l'application et la publie dans Fabric.

Il vous demandera seulement de vous connecter à votre compte Microsoft et de valider certaines actions. Vous pouvez lui faire valider toutes les actions automatiquement avec l'option présente dans la capture ci-dessous, cela vous permettra d'aller vous chercher un café.

Voici le prompt appliqué dans la capture ci-dessus :

Crée une application Fabric "Pilotage des stocks" dans l'espace de travail "MYPE_Fabric_F2"
avec le template Data App de Rayfin, branchée sur le modèle sémantique "Stocks" du même espace.
Lis d'abord https://rayfin.ai/docs/reference/agent-rules.md et lance toi-même les commandes nécessaires.
 
Je veux :
- l'entrepôt en plan et en 3D, chaque emplacement coloré selon son niveau de stock
(rupture, sous seuil, normal, surstock), avec une infobulle au survol ;
- un bouton "Agir" pour demander un réappro, un transfert ou alerter le fournisseur,
enregistré dans l'application avec un suivi des statuts ; chacun ne modifie que ses propres actions ;
- en haut, quelques indicateurs : ruptures, produits sous seuil, actions en cours.
 
Utilise uniquement les vraies données du modèle, puis publie l'application et donne-moi son adresse.

Étape 3 – Le résultat dans l'espace de travail

L'application est créée et on a 3 nouveaux éléments : l'application, une base de données SQL pour enregistrer les actions effectuées par l'utilisateur dans l'application, et un point de terminaison SQL pour interroger la base.

Voici à quoi ressemble la base de données.

Et voilà le rendu final. On a une sorte de Power BI qui va plus loin en termes de visuels. C'est aussi une application Power Apps beaucoup plus puissante, avec la possibilité de saisir de la donnée, et même de déclencher des actions si on connecte ça à un pipeline et à Activator pour faire du Power Automate.

On peut effectivement faire des actions, comme le montre la capture.

Étape 4 – Et ensuite ? Brancher les actions dans un flux de travail

Aujourd'hui, dans l'application, le bouton « Agir » enregistre la demande (réappro, transfert ou alerte fournisseur) dans une base SQL Fabric, avec son auteur, sa date et son statut. Chacun suit les demandes de tous et ne modifie que les siennes. Pour l'instant, cela s'arrête là : l'action ne met pas à jour le stock et ne prévient personne.

Mais c'est précisément l'intérêt de Fabric Apps : comme l'action est stockée dans Fabric, elle pourrait s'insérer dans un vrai flux de travail et :

• déclencher un pipeline qui met à jour le Lakehouse une fois la demande validée ;
• envoyer un message Teams ou un e-mail à l'équipe concernée ;
• alimenter vos rapports, par exemple avec un stock projeté.

Rien de tout cela n'est encore branché, mais tout est déjà disponible dans la plateforme. L'application pose la première brique ; le reste est une question d'assemblage.

Maintenir et faire évoluer l'app

Ci-dessus, le dossier contenant le projet de l'application créée, à maintenir.

Une Fabric App, c'est un projet de code web standard, en deux parties :

• Le code source, modifiable, est un dossier de projet qui reste chez vous : sur le poste du développeur, ou mieux dans un espace partagé (un dépôt de code comme GitHub ou Azure DevOps). Fabric ne le conserve pas : c'est ce dossier qu'il faut garder précieusement pour faire évoluer l'application.
• La version publiée est hébergée par Fabric, dans l'espace de travail : l'application elle-même, et la base SQL qui stocke les actions. C'est ce que voient les users.

Pour faire évoluer l'application :

• Modifier : on change le code source, directement ou en le demandant à un assistant IA en langage naturel (« ajoute un filtre par fournisseur »), puis on teste dans le portail Fabric.
• Publier : une commande envoie la nouvelle version dans Fabric, et les utilisateurs gardent le même lien.
• Rester à jour : l'application lit le modèle sémantique en direct. Si une mesure évolue, l'application suit.
• Sécuriser : seules les personnes qui ont accès à l'espace de travail et au modèle peuvent utiliser l'application. Oui, c'est aussi compatible avec la fameuse RLS.

Conclusion : les applications Fabric, pour qui et pour quoi ?

Fabric Apps comble un vide entre le rapport Power BI, qui montre, et l'application métier, qui permet d'agir. Avec « Pilotage des stocks », on passe du constat (cet emplacement est en rupture) à la décision (je demande un réappro), dans le même outil et sur les mêmes données. Pour une équipe operations, c'est la différence entre un reporting et un poste de pilotage.

Les avantages

• Une seule source de vérité : l'application lit le modèle sémantique en direct, sans copie, puis réutilise ses tables et mesures.
• La sécurité de Fabric : chaque utilisateur se connecte avec son compte Microsoft, et la RLS du modèle s'applique.
• Des interfaces sur mesure : en termes de visuels, votre imagination est la seule limite.
• Des actions qui restent dans Fabric : stockées dans une base SQL de l'espace de travail, elles peuvent alimenter des pipelines, des alertes ou des rapports.
• Une publication simple : une commande pour publier, et l'adresse ne change pas d'une version à l'autre.

Les limites

• Ce n'est pas réellement du no-code : il faut coder, soi-même ou avec un assistant IA. Le code source est à conserver de son côté, Fabric n'en garde que la version publiée.
• Une application liée à Fabric : elle s'ouvre depuis le portail Fabric et dépend de la capacité. Si celle-ci est en pause, l'application ne s'affiche plus.
• Une sécurité à penser en deux temps : la RLS du modèle protège les données de stock, mais pas les données propres à l'application, comme les actions. Celles-ci demandent leurs propres règles.
• Des actions à brancher : enregistrer une demande est immédiat ; la faire agir sur les données ou prévenir une équipe demande d'assembler pipelines et notifications. Il faut un bon niveau Fabric.
• Une technologie jeune : le modèle d'application est encore en préversion et peut évoluer.

Fabric Apps ne remplace ni Power BI ni un ERP. Mais pour donner aux équipes un outil d'action branché directement sur leurs données, c'est une brique très prometteuse. C'est très bien pour des prototypes et des démos côté métier ; pour une mise en production réelle à l'échelle de l'enterprise (déploiement, sécurité, exploitation complète dans Fabric), il faudra un profil technique.

Si vous voulez aller plus loin dans la compréhension de Fabric, vous pouvez vous inscrire à notre formation ici ! Et si vous préférez piloter votre modèle sémantique par agent plutôt que par application, jetez un œil à notre article sur le Power BI MCP Server.