Alexandru BADIU, Responsable pôle Data Analytics chez Décilia & MVP Power BI
Tout le monde peut coder une app aujourd’hui. Presque personne ne peut la livrer en production.
L’IA a changé la donne. Vous décrivez ce que vous voulez à un agent, il produit un prototype qui tourne, et vingt minutes plus tard vous avez quelque chose de présentable sur votre poste. Ce n’est plus là que se situe la difficulté. Elle commence au moment de passer de « ça tourne chez moi » à « authentifié, gouverné, déployé et suivi sur le tenant ».
Où vit la base de données ? Qui enregistre l’app Entra ? Comment les données saisies dans l’app reviennent-elles dans l’analytique ? Chaque réponse mobilise un ticket, un budget et plusieurs semaines de développement.
Microsoft a conçu Rayfin pour ce fossé précis, et non pour celui qu’on lui prête généralement. Ce n’est pas un concurrent de Power BI, et ce n’est même pas un constructeur d’applications. Entrons dans le vif du sujet.
Quatre choses différentes s’appellent « app » dans l’écosystème Fabric et Data Platform. Les confondre entretient des malentendus, en réunion comme en cadrage de projet. Autant poser les définitions d’emblée.
| Le nom | Ce que c’est |
|---|---|
| Org app | La distribution de contenu nouvelle génération. Plusieurs apps par workspace. Hors du périmètre de cet article. |
| App Power BI | Le paquet de rapports publié depuis un workspace. Une seule app possible par workspace. |
| Power Apps | Le constructeur d’applications de la Power Platform. Produit distinct, GA, avec son SLA. |
| Fabric App | L’artefact applicatif déployé dans un workspace Fabric, avec sa base et son SQL analytics endpoint. |
Reste la confusion la plus répandue, celle que presque toutes les vidéos communautaires entretiennent. Rayfin est le SDK. La Fabric App est l’artefact.
Sachin Patney (General Manager chez Microsoft, équipe Rayfin) le formule ainsi : Rayfin est d’abord un backend-as-a-service. Vous décrivez votre backend dans le code de l’application, et au déploiement il matérialise ce backend en ressources Fabric. Ce qui est déployé dans le workspace s’appelle Fabric App. Le front peut faire partie du même paquet, et l’hébergement vient avec.
Il va plus loin sur ce que le produit n’est pas :
« Power Apps is an end-to-end app builder and Fabric apps isn’t an app builder. It’s a backend-as-a-service. »
(Power Apps est un constructeur d’applications de bout en bout. Fabric Apps n’en est pas un. C’est un backend-as-a-service.)
Et il s’agit bien de code, le point mérite d’être posé clairement. Le backend se décrit en TypeScript. Le front est un projet React + Vite. Tout passe par la CLI.
Aucun token d’IA n’est obligatoire en théorie. Tout ce que Rayfin sait faire peut s’écrire à la main, et la CLI peut fonctionner sans le moindre agent.
Si vous venez du monde Power BI et vous utilisez TMDL, le modèle de programmation vous sera familier. Quand vous écrivez isHidden: true ou summarizeBy: none sur une colonne, vous ne codez pas un comportement. Vous déclarez une propriété, et le moteur s’occupe du reste.
Un décorateur TypeScript repose sur le même principe. Vous déclarez une classe, vous l’annotez avec une entité et un rôle, et au déploiement Rayfin fabrique le schéma, les tables et l’API. On ne code pas l’API, on décrit les données.
Un rapport Power BI et une Fabric App ne sont pas deux produits concurrents. Ce sont les deux bouts d’un même spectre.
Le rapport est une vue : UI simple, bien gouverné. Il montre l’état des données. L’app est un outil de travail : full code et une flexibilité quasi illimitée.
Quatre choses qu’un rapport Power BI ne sait pas faire aujourd’hui, et qu’une Fabric App fait :
- Écrire dans les données. (Exception : utilisation Translytical Task Flow ou Power Apps embedded)
- Accepter la soumission d’un visiteur externe.
- Utiliser n’importe quelle librairie de visualisation : Vega-Lite, D3.js, Plotly.
- Vivre comme un artefact applicatif, avec sa propre base et son SQL analytics endpoint.
Une cinquième capacité est plausible au vu du modèle de programmation : interroger plusieurs modèles sémantiques sur une même page sans construire de modèle composite. Je ne l’ai pas encore vérifiée, je ne la compte donc pas, mais le use case peut être très intéressant.
Reste à situer le terrain sur lequel chaque option l’emporte. La comparaison n’a vraiment de sens que sur un seul, la diffusion vers l’extérieur. Le tableau qui suit est ma synthèse des sources, pas une grille publiée par Microsoft, et il reflète l’état constaté au 7 septembre 2026.
| Le besoin | Publish to web | Fabric App anonyme | Power BI Embedded |
|---|---|---|---|
| Lecture anonyme de données choisies | oui | oui | oui |
| Écriture anonyme, write-back | non | oui, create et update | non sans câblage UDF |
| Identité par client, comptes nominatifs | non | non, OIDC annoncé | oui |
| Domaine personnalisé, marque blanche | non | non | oui |
| Sécurité au niveau des lignes par utilisateur | non | non, par définition | oui |
| Interactivité complète, drill et export | oui | à recoder | oui |
Ce qui est vraiment nouveau, c’est l’écriture anonyme. Embedded n’est pas détrôné, en tout cas pas les rapports embedded qui concernent un public externe. Ce qui est remplacé, c’est publish to web.
Le repère que j’utilise, et qui a tenu sur tous les cas rencontrés à ce jour : Rayfin comble les manques de Power BI, il ne remplace pas les rapports.
La valeur n’est pas dans la génération de code. Elle est dans ce que vous n’avez plus à construire.
| Vous l’avez d’office | Sinon, vous le construisez |
|---|---|
| L’authentification, dès le départ | Une app Entra séparée à enregistrer et maintenir |
| Une base qui est un artefact Fabric gouverné | Une base à provisionner, sécuriser et gouverner hors du tenant |
| Les données de l’app atterrissent dans Fabric | Des exports à câbler vers l’analytique |
| Backend, front et config dans un seul paquet | Trois déploiements à orchestrer séparément |
| Tout se facture sur les CU Fabric | Un abonnement de plus à faire approuver |
Le point le plus utile pour décider est ailleurs, et il est souvent manqué :
Les deux moitiés sont indépendantes.
Vous pouvez prendre Rayfin uniquement pour le modèle de données et construire le front ailleurs. Vous pouvez prendre uniquement le front au-dessus de données existantes, en interrogeant un modèle sémantique en DAX, sans aucun stockage durable. Ou les deux.
C’est là que se joue la vraie différence avec le vibe coding ordinaire. Coder une app et sa définition d’infrastructure en même temps revient à espérer que l’ensemble tombe juste et que tout est fluide. Rayfin pose un rail étroit, un cadre précis. La valeur n’est pas dans la génération, elle est dans le rail.
La question qui revient à ce stade est toujours la même : concrètement, on en fait quoi. Voici cinq applications que j’ai construites pour répondre à des besoins d’entreprise réels.
Un point commun entre les cinq, et c’est lui qui rend l’exercice intéressant. Elles vivent dans un workspace que vous payez déjà. Le coût marginal d’une application de plus n’est pas une licence supplémentaire, c’est de la capacité que vous consommez de toute façon. Donc plus de valeur ajoutée !
1. Une galerie de visuels Deneb, partageable avec l’équipe. Un catalogue des visuels sur mesure construits en interne, consultable par toute l’équipe. Le problème qu’il règle est banal et coûteux : les bonnes idées de visualisation restent dans le rapport où elles sont nées, et personne ne sait qu’elles existent.
Nous pouvons facilement imaginer d’autres cas d’usage similaires, comme un portail de gouvernance BI, un support d’onboarding pour les nouveaux arrivants, et l’endroit où les conventions maison deviennent consultables plutôt que transmises oralement.
2. L’apprentissage gamifié. Construire un jeu pour faire monter une communauté en compétence sur ce que vous voulez qu’elle maîtrise. Power BI, Fabric, ou la sécurité informatique de votre entreprise.
C’est le cas d’usage qui surprend le plus en réunion, et c’est aussi celui qui produit les meilleurs taux de complétion. Un module de formation se subit. Un jeu, c’est différent : ça motive et engage plus naturellement.
3. Une application métier avec visuels sur mesure et write-back. Le cas où le rapport Power BI s’arrête. L’utilisateur consulte, puis saisit quelque chose : une correction, une validation, un commentaire. Les données saisies repartent dans Fabric, où elles redeviennent analysables.
4. Le monitoring et la gouvernance sur mesure. Microsoft expose toujours plus d’API sur l’écosystème Fabric, et la plupart des organisations n’en exploitent presque rien. Une application dédiée met cet inventaire sous contrôle : qui consomme quoi, quels artefacts dérivent, qui consomme la capacité.
Une précision technique qui mérite d’être mentionnée. Aujourd’hui l’application lit une base alimentée en amont par ces API, via des notebooks et un pipeline.
5. La documentation technico-fonctionnelle de vos rapports. Une application qui documente vos rapports Power BI et qui vit dans le même workspace qu’eux. La documentation cesse d’être un fichier qui vieillit ailleurs pour devenir un artefact à côté de ce qu’elle décrit.
C’est le cas d’usage que je trouve le plus sous-estimé, parce qu’il attaque un problème que tout le monde a et que personne ne traite. J’y consacre un futur article entier, qui montre la chaîne complète depuis le merge jusqu’à l’app.
Aucune de ces cinq applications ne remplace un rapport Power BI. Toutes font quelque chose qu’un rapport ne sait pas faire, et c’est le meilleur test que je connaisse pour décider si votre besoin relève d’une Fabric App.
Voici ce qu’il vous faut avant d’écrire la première ligne.
- Un workspace sur une capacité F2 ou plus. « My workspace » ne convient pas.
- Le réglage Enable Fabric App items, activé par un admin. Il est désactivé par défaut parce que la fonctionnalité est en preview. Il peut être restreint à un groupe de sécurité, ce qui reste la façon recommandée de démarrer.
- L’API REST Execute Queries activée sur les modèles sémantiques, si vous visez une data app.
- Un modèle sémantique sur lequel les lecteurs ont les droits Build et Read. Au 31 août 2026 la documentation exige les deux, et le passage à Read seul pour les consommateurs était annoncé pour début septembre 2026. Vérifiez l’état courant avant de dimensionner vos permissions.
- Node.js LTS, VS Code, Git, et la permission d’installer des paquets npm.
Ensuite, tout le cycle de vie tient en quelques commandes.
Le cycle de vie Rayfin en quatre commandes
Du projet vide à l’app déployée dans votre workspace Fabric.
Crée le dossier du projet à partir du template choisi.
Le scaffold crée le dossier, il ne vous y place pas.
Choix du workspace, URL locale. La base est déjà provisionnée dans Fabric.
Pousse la version locale dans l’app déployée et crée les tables d’écriture.
Syntaxe de scaffold : documentation Microsoft Learn, « Create a Fabric app with the CLI ».
Le cd semble anodin. C’est pourtant l’erreur de démarrage la plus courante, y compris chez des gens qui font la démonstration en public. La commande de scaffold crée un dossier, elle ne vous y place pas.
npm run dev vous demande le workspace cible, puis retourne une URL locale. La base est provisionnée dans Fabric dès le mode dev, et seul le front reste en local. Les tables sur lesquelles reposera l’écriture, en revanche, n’apparaissent qu’au déploiement, ce qui a une conséquence directe sur votre boucle de travail.
npx rayfin up pousse la version locale dans l’app déployée. Avant ce déploiement, ouvrir l’app dans le workspace montre une page vide : le câblage existe, le contenu non.
Le choix du template décide de ce que vous obtenez au départ.
| Template | Ce qu’on obtient | On la choisit si |
|---|---|---|
| Blank app | Connexion et routage, aucune couche de données | On veut juste une page sécurisée dans Fabric |
| To-do app | Connexion, base, créer, lire, modifier, supprimer | On veut de l’écriture de données |
| Data app | Modèle sémantique, DAX, composants de graphiques | On est développeur Power BI |
Le choix n’enferme pas. Chaque app s’étend ensuite : ajouter une base, connecter un modèle, y raccorder d’autres services. Et un template est simplement une app Rayfin à un stade quelconque de développement. Cela peut être un point de départ, ou une app finie que vous instanciez sans écrire une ligne. Choisissez quand même le bon dès le départ, pour une raison que je détaille dans les leçons.
La CLI accepte aussi une URL, donc vos propres templates vivent dans votre repo GitHub. Le repo communautaire s’appelle awesome-rayfin.
Trois fichiers méritent votre attention dans ce que le scaffold produit. Le dossier rayfin, qui tient le schéma de l’application. Le fichier rayfin.yml, où se règlent le dialect de la base, l’hébergement statique et l’authentification. Et src, le front React que vous pouvez remplacer par le framework de votre choix.
💡 Astuce
Essayez le template data app en premier si vous venez de Power BI. Il se branche sur un modèle sémantique existant, l’agent énumère seul tables et champs, et le résultat apparaît en quelques minutes.
Les démonstrations publiques suivent le chemin nominal. Voici ce qui se présente dès qu’on s’en écarte.
Leçon 1 : chaque template embarque son échafaudage et les skills qui vont avec, et celles que vous n’avez pas choisies vous manqueront.
Le choix n’enferme pas, c’est écrit plus haut et c’est vrai : une app s’étend toujours. Mais l’extension se paie, et elle se paie en temps de débogage.
Un cas vécu. J’ai démarré sur le template blank, puis il a fallu écrire en base. Le template to-do fournit ce câblage d’origine, alors que sur blank il faut le reconstituer, et les sessions se sont allongées à déboguer des problèmes d’écriture qui n’auraient simplement pas existé avec le bon point de départ.
La règle que j’en tire : partez du template le plus proche de la cible, même si vous n’êtes sûr qu’à moitié. Se tromper de template coûte plus cher que de démarrer trop équipé.
Leçon 2 : la base SQL se met en veille, et l’app subit un cold start.
Le premier utilisateur de la journée attend plusieurs secondes de plus. Ce n’est pas un défaut mais le comportement de la ressource sous-jacente, et mieux vaut l’annoncer aux utilisateurs plutôt que les laisser le découvrir.
Leçon 3 : admin du workspace n’est pas une permission sur l’item.
Vous pouvez tout voir dans le workspace et être refusé par l’app. Les deux niveaux se gèrent séparément.
Leçon 4 : l’écriture en base n’est pas garantie.
Elle dépend du template, du rôle, et de ce que le schéma déclare. Vérifiez-la explicitement avant d’engager un write-back auprès de qui que ce soit.
Leçon 5 : la fenêtre localhost n’est pas visible.
Le comportement dépend du template, ce qui rend le piège difficile à voir venir.
Sur une data app, les données authentifiées ne s’affichent jamais sur localhost. Vous itérez sur l’URL déployée, ouverte depuis VS Code, dès le premier jour.
Sur une to-do app, localhost fonctionne et affiche vos données, tant que vous n’avez pas déployé. Or il faut déployer tôt, parce que c’est le déploiement qui crée les tables sur lesquelles l’écriture en base s’appuie. Une fois ce déploiement fait, la vue locale est perdue.
D’où la règle : poussez l’itération locale aussi loin que possible avant le premier npx rayfin up, parce que vous ne récupérerez pas cette boucle. Et prévoyez quand même des ajustements fonctionnels ensuite, il y en a toujours.
Leçon 6 : l’authentification par service principal est listée comme non supportée en preview.
Constaté au 7 septembre 2026. Tout ce qui est planifié ou piloté par CI doit en tenir compte dès le cadrage.
Leçon 7 : la preview n’est pas disponible dans toutes les régions.
Aucun contournement n’existe aujourd’hui.
Leçon 8 : héberger sur F2 et partager avec des utilisateurs Fabric gratuits, sans licence Power BI Pro ni F64.
C’est la leçon la plus intéressante sur le plan économique, et elle mérite ses chiffres. Ils arrivent plus bas.
Leçon 9 : la boucle qui fonctionne est Ask, Plan, Design, Human in the Loop + Agent.
Dans cet ordre. L’agent n’intervient qu’une fois la demande cadrée, le plan arrêté et le design figé, et un humain valide avant l’exécution.
Leçon 10 : quiconque atteint l’URL de l’app peut utiliser les opérations assignées au rôle anonymous.
Si vous assignez une opération d’écriture à ce rôle, elle devient ouverte à toute personne qui connaît l’adresse.
La conséquence de la dixième est plus large qu’elle n’en a l’air, et c’est le point le moins intuitif de toute la liste.
⚠ Avertissement
Rayfin crée un SQL analytics endpoint en lecture seule que n’importe quel rapport Power BI ou notebook peut consommer. Les données saisies dans l’app sont donc interrogeables par toute personne ayant accès au workspace, indépendamment des permissions posées sur l’item App. Si votre app collecte quoi que ce soit de sensible, le périmètre à raisonner est le workspace, pas l’app.
Et la leçon qui porte les dix autres : les agents, les skills et les hooks font la différence. Ce n’est pas l’agent seul qui produit un résultat livrable. C’est le cadre qu’on lui donne : des skills qui encodent les conventions maison, des hooks qui vérifient à chaque écriture, et un humain qui valide aux points de passage. Sans ce cadre, vous obtenez une démo. Avec, vous obtenez quelque chose que l’équipe peut reprendre.
- Pratique 1 : l’agent ne touche qu’un workspace de développement. L’agent demande la permission de lancer des commandes, et il la demande sur le workspace que vous lui avez désigné. Ne lui accordez jamais cette permission sur un workspace de production. C’est la règle que je pose en premier sur toute mission, avant même de parler d’architecture.
- Pratique 2 : le design est la source de vérité, le template est la plomberie. Figez le design d’abord. Scaffoldez ensuite. Portez le design, ne le redessinez pas. Les données factices deviennent du DAX en dernier. Quand je procède dans l’ordre inverse, la moitié du temps passe à réconcilier une maquette et un rendu.
- Pratique 3 : définissez un design system une fois, et livrez-le comme template d’organisation. Laissé à lui-même, le rendu visuel part dans toutes les directions : il faut respécifier palette, espacement et ressenti à chaque nouvelle app. Aucune position produit ne traite ce point aujourd’hui, c’est donc à vous de le traiter. Un template d’organisation règle le problème en amont, et durablement.
- Pratique 4 : la sécurité s’audite, elle ne se suppose pas. Le rôle anonymous, le périmètre du endpoint, les permissions sur le modèle sémantique. Formalisez-les en liste de contrôle, à passer avant chaque déploiement plutôt qu’après le premier incident.
- Pratique 5 : lisez le code. C’est indispensable pour monter en compétence ! N’oubliez pas que le code non lu, c’est du code non revu. Si personne dans l’équipe n’a lu ce qui s’exécute, l’équipe ne dépend pas de son code, elle dépend d’un accès continu à l’agent qui l’a écrit. C’est une dépendance fournisseur déguisée en actif possédé.
Cette dernière pratique désigne le véritable déplacement. Rayfin ne supprime pas le travail, il le déporte de la construction vers le contrôle.
La lecture par les licences. Le montage se vérifie étape par étape, avec les tarifs constatés au 6 juillet 2026. L’app est hébergée dans un workspace F2. Un utilisateur reçoit un accès Viewer sur le workspace et une permission Build sur le modèle sémantique. Cet utilisateur n’a qu’une licence Fabric gratuite, pas de Pro, pas même un essai.
Il se connecte et voit les données.
| Chemin | Coût constaté au 6 juillet 2026 |
|---|---|
| Power BI Pro, par utilisateur | 14 $/utilisateur/mois, soit 280 $/mois pour 20 utilisateurs |
| Capacité F64 ou plus, pour partager avec des licences gratuites | environ 5 000 $/mois |
| F2 à la demande | environ 250 $/mois |
| F2 en réservation annuelle | environ 156 $/mois |
Microsoft confirme le cadre : le workspace doit être en F2 ou plus, et à partir de là la distribution ne diffère pas de celle d’un notebook. Aucune licence Power BI par utilisateur n’est requise pour les lecteurs.
La réserve décisive tient en une phrase : tout dépend de la charge, et un F2 peut ne pas suffire.
La lecture par la consommation. Elle conclut l’inverse, et elle se défend : une Fabric App revient plus cher que Power BI, parce que chaque transaction qui passe par le backend consomme des CU en plus.
Les deux arguments tiennent. Le premier parle de licences, le second de consommation par transaction. Le principe de facturation, lui, est tranché côté éditeur : tout passe par les CU Fabric, et Microsoft le présente comme un choix assumé, « that’s not going to change » (cela ne changera pas).
Ce qui n’est pas tranché, c’est la tarification elle-même. Elle n’est pas clairement communiquée à ce jour. En l’état, vous partagez à partir d’un F2 sans licence Power BI Pro par lecteur, là où Power BI en exige une. Prenez-le pour ce que c’est : un état constaté, pas un engagement, et il peut évoluer.
Le point à surveiller de près, c’est la consommation de la base SQL. Les coûts liés à cette base peuvent être à la fois interactifs et background, et cette double nature est mal documentée.
À ma connaissance, ni Microsoft ni la communauté n’ont publié à ce jour de calcul sur un volume de données important. Personne ne sait donc précisément comment une Fabric App chargée se comporte sur la consommation d’une capacité. C’est le trou le plus gênant du dossier, parce qu’il porte exactement sur les cas d’usage les plus prometteurs.
Je pense en particulier aux data apps. C’est là qu’on peut prévoir un nombre sérieux d’applications utiles, celles qui comblent les manques de Power BI : le write-back, les visuels sur mesure, et pourquoi pas le remplacement de certains modèles composites multi-modèles.
Mes propres tests ne montrent aucun problème de capacité. Plus d’une dizaine d’applications construites à ce jour, toutes sur un F2, sans incident. Mais une dizaine d’applications de démonstration ne fait pas une charge de production, et il est trop tôt pour en tirer un avis. À suivre de près.
Reste un coût que l’on omet souvent, celui des tokens lorsque vous construisez avec un agent IA. Sur une de mes sessions, ccusage affiche 51,05 $ d’équivalent API, dont 98,6 % de lectures de cache. Ce n’est pas un problème de formulation des prompts. C’est un problème de profondeur de session.
Trois leviers ont un effet réel : la longueur de session, le routage des modèles, et la réduction de l’effort alloué aux tâches routinières.
La GA est visée pour la fin 2026, confirmée par Microsoft. D’ici là, Microsoft déconseille les charges critiques en production. Voici l’état au 7 septembre 2026, statut par statut.
| Statut | Capacité | Ce que cela ouvre |
|---|---|---|
| Livré | Accès anonyme | Hébergement public de données publiques, très proche de publish to web |
| Livré | Stockage OneLake | Les blobs vont dans le OneLake de l’app, au lieu d’être stockés dans la base |
| Annoncé | Authentification OIDC | Se connecter avec une identité hors Fabric. Ouvre les vitrines externes, données gardées dans Fabric |
| Annoncé | Fonctions | Vos fonctions TypeScript déployées en UDF. C’est la condition des appels d’API tierce |
| Annoncé | Observabilité | La télémétrie de l’app dans Fabric, interrogeable par des humains et par des agents |
| Annoncé | Gestion des secrets | Couplée aux fonctions, pour injecter un secret au moment de contacter un service externe |
| Annoncé | PostgreSQL | Un dialect supplémentaire |
| Plus loin | Temps réel | Un event hub provisionné sur le backend |
Et ce qui bloque encore, aujourd’hui :
- Identité externe. Pas de comptes visiteurs, pas d’inscription, pas de « mes commandes ». OIDC est annoncé, pas livré.
- Appels externes. Sans fonctions ni gestion des secrets, aucun appel d’API tierce.
- Régions. La preview n’est pas disponible partout, et une capacité Fabric reste obligatoire.
- Parité Power BI. Ni drill, ni drillthrough, ni export Excel dans une data app.
- Sources de données. Bases SQL Fabric et modèles sémantiques seulement. Pas d’interrogation directe d’un lakehouse ou d’un warehouse.
- Domaine personnalisé. Pas supporté dans Fabric aujourd’hui. Le chemin recommandé par Microsoft : ne déployer que le backend dans Fabric, poser le front statique sur Azure, et mettre un CDN, un domaine et un traffic manager devant.
- Statut preview. La CLI et
rayfin.ymlpeuvent changer sans préavis.
Un dernier point, peu relayé par la communauté et pourtant déterminant pour une décision d’architecture : des parties de Rayfin passent en open source, et l’auto-hébergement hors Fabric sera possible. La réserve qui s’impose : vous voulez la variante Fabric, parce que vous héritez des modèles de conformité, de gouvernance et de sécurité qu’il faudrait sinon reconstruire vous-même.
Sur le moteur de stockage, je ne tranche pas et vous ne devriez pas non plus. Les descriptions divergent d’une source Microsoft à l’autre : un dialect MySQL comme seule option ici, une base SQL là.
Quand l’éditeur se décrit lui-même de deux façons, c’est le meilleur indice que rien n’est figé. Le moteur est d’ailleurs présenté comme un détail d’implémentation appelé à changer, géré par la Fabric App.
Traitez-le comme tel.
- Rayfin est un backend-as-a-service, pas un constructeur d’applications. Le SDK s’appelle Rayfin, l’artefact déployé s’appelle Fabric App, et la confusion entre les deux fausse toutes les comparaisons qui suivent.
- L’app ne remplace ni les rapports ni Power Apps. Elle remplace publish to web. L’écriture anonyme est la seule capacité vraiment neuve. Embedded garde les comptes nominatifs, le domaine personnalisé et la sécurité par ligne.
- Le modèle sémantique survit et devient plus central. La data app interroge le même modèle via l’API Execute Queries. Le centre de gravité se déplace de la couche de présentation vers la couche sémantique.
- Le coût est le point le moins documenté du dossier. La tarification n’est pas clairement communiquée, les licences plaident pour Fabric Apps et la consommation par transaction plaide contre. Surtout, aucun calcul public n’existe à ce jour sur la consommation de la base SQL à volume important. Mesurez sur votre charge, à votre volume, et ne promettez pas de budget avant.
- La preview a des trous documentés et datés. Identité externe, appels d’API tierce, régions, parité Power BI. Rien de tout cela n’est un défaut caché, tout est documenté. L’erreur consisterait à planifier comme si ces éléments étaient déjà livrés.
- Sachin Patney, General Manager chez Microsoft, à la tête du développement applicatif Fabric et de l’équipe Rayfin, interviewé par Reza Rad, RADACAD Fabric Insider épisode 11, 16 juillet 2026. Source de vérité pour les définitions, la roadmap, la date de GA, les licences et la facturation CU.
- John Savill, Chief Architect chez Microsoft, Rayfin and Fabric Apps Overview, 27 juillet 2026. Le cadrage architectural : OneLake comme couche de virtualisation, découplage backend et front, limites du middle tier.
- Reza Rad, CEO et cofondateur de RADACAD, What is a Fabric App / Rayfin, 24 juin 2026. Prérequis, réglage de locataire, cycle de vie en quatre commandes, templates.
- Reza Rad, Rayfin data app sur un modèle sémantique, 6 juillet 2026. L’argument licences et les chiffres datés.
- Lumio Visuals, chaîne YouTube indépendante sur Power BI et Fabric, Microsoft Fabric Apps, everything you need to know, 29 juin 2026. Le contre-argument coût et le point design system, présentés ici comme opinions.
- Explicit Measures, le podcast de Mike Carlo et Tommy Puglia, qui a suivi le sujet en continu : ep. 535, Microsoft Build Recap le 10 juin 2026, ep. 536, All About RayFin le 11 juin, ep. 547, The Hype of RayFin le 21 juillet, ep. 554, Fabric as a Backend le 13 août, et ep. 555, Anonymous Rayfin Fabric Apps le 18 août. Les épisodes 547 et 554 sont les plus utiles sur la question de fond : est-ce un vrai changement, et un moteur analytique doit-il prendre un rôle applicatif.
- Agentic Thinking, le podcast de Mike Carlo et Matthias Thierbach, qui construit les templates en direct : ep. 17, Build Recap et Awesome Rayfin le 6 juin 2026, ep. 20, Rayfin Build le 10 juin, ep. 23, Fabric Apps Rayfin le 13 juin, et ep. 25, Replit et Fabric Apps le 24 juin. C’est la meilleure source sur la friction réelle de construction, celle que les démonstrations polies ne montrent pas.
- Le repo communautaire de templates, microsoft/awesome-rayfin.
💡 Et si vos équipes relevaient le même challenge ?
Chez Décilia, nous pouvons imaginer avec vous une Tech Day sur mesure, autour de vos enjeux et de vos cas d’usage, dans vos locaux ou chez nous.
👉 Envie de tenter l’expérience ? Parlons-en !