Microsoft Fabric

La situation typique avant Fabric ressemble à ceci. Une base sur site, un service Azure pour l’ingestion, un espace de stockage, un entrepôt, et Power BI par-dessus. Cinq briques, cinq factures, et des copies de données à chaque étage parce qu’aucune ne lit vraiment le format de la précédente.

Fabric met tout ça dans un seul produit. Ce n’est pas une brique de plus, c’est plutôt le contraire : on retire les connecteurs intermédiaires et les duplications. Pour une PME qui n’a pas d’équipe d’infrastructure, c’est souvent ce qui rend un projet data faisable.

Il n’y a qu’un seul OneLake par organisation, et tous les composants y écrivent au même format, Delta Parquet. Ce choix d’apparence anodine conditionne le reste.

Il permet d’abord les raccourcis. Un raccourci est une référence vers des données qui vivent ailleurs, dans Azure Data Lake Storage, sur Amazon S3 ou dans un autre espace de travail. Rien n’est copié, rien n’est synchronisé : Fabric lit sur place. C’est utile quand une partie des données ne peut pas bouger, pour des raisons contractuelles ou réglementaires.

Il permet ensuite Direct Lake, et c’est le vrai argument technique pour qui fait déjà du Power BI. Direct Lake lit les fichiers Delta directement dans OneLake. Vous n’importez pas, donc vous n’avez pas d’actualisation à programmer ni de copie en mémoire. Vous n’êtes pas non plus en DirectQuery, donc chaque clic ne repart pas interroger la source. Sur des modèles volumineux, la différence se voit tout de suite.

Data Factory reprend l’ingestion et les pipelines, avec les mêmes notions que le service Azure du même nom. Data Engineering apporte les carnets de notes et Spark managé pour ce qui dépasse le SQL. Le Data Warehouse est un entrepôt classique interrogeable en T-SQL, avec des transactions, posé sur le même stockage Delta.

S’ajoutent Real-Time Intelligence pour les flux d’événements et les requêtes KQL, un espace Data Science branché sur MLflow, et Power BI, qui n’est plus un produit voisin mais un composant de la plateforme.

Dans la pratique, la plupart des projets que nous voyons n’utilisent que trois de ces briques. Le reste sert le jour où il sert.

Fabric ne facture pas le service consommé mais une capacité réservée, exprimée en unités de calcul. Tous les composants puisent dans le même réservoir. Deux conséquences méritent d’être connues avant de signer, parce qu’elles se découvrent sinon à l’usage.

La première est plutôt une bonne nouvelle : une capacité en pause n’est pas facturée. Les contenus restent en place, seul le calcul s’arrête. Pour une entreprise dont les rapports sont consultés en journée et les traitements lancés la nuit, l’économie est réelle, à condition d’automatiser la mise en pause. Peu de gens le font.

La seconde est moins agréable. Comme tout le monde partage le même réservoir, un traitement lourd peut ralentir les rapports de tous les autres. Le dimensionnement n’est donc pas une formalité administrative à régler après coup : c’est une décision d’architecture, et elle se prend au moment où l’on décide quels traitements tournent quand.

Le cas le plus favorable, de loin, est celui d’une entreprise déjà installée sur Power BI et Microsoft 365. L’authentification et les droits existent, les équipes connaissent l’interface, et Direct Lake apporte un gain immédiat sur les modèles lourds. Si vous êtes dans cette situation, la question est plutôt quand que si.

Si votre socle est déjà mature sur Snowflake ou BigQuery, la réponse est généralement non. Migrer un entrepôt qui fonctionne pour unifier une facture ne se rentabilise presque jamais. Branchez Power BI dessus et gardez l’existant : c’est moins spectaculaire, mais c’est ce que nous recommandons le plus souvent dans ce cas.

Reste le cas des besoins modestes et stables. Une capacité réservée a un coût plancher, et en dessous d’un certain volume un entrepôt facturé à l’usage revient moins cher. Il faut faire le calcul, pas le supposer.

Dernier point à connaître : Fabric est un service géré, ce qui est son intérêt et sa limite. Les réglages de bas niveau ne sont pas exposés. Si votre équipe a l’habitude de tout paramétrer, elle va trouver la plateforme fermée.

Nous commençons par le cadrage : quelle capacité, quels espaces de travail, quelle politique de pause. Vient ensuite l’organisation du stockage en couches successives, du brut au restituable, avec les règles qui l’empêchent de se déliter au bout de six mois. C’est la partie que tout le monde saute et que tout le monde regrette.

Nous reprenons aussi les modèles Power BI existants pour les passer en Direct Lake quand c’est pertinent, en signalant les cas où il vaut mieux rester en import. Le reste du temps, nous construisons l’ingestion, y compris depuis des sources comptables, et nous posons la gouvernance : droits, traçabilité, sensibilité, documentation du modèle.

Quelle différence entre Direct Lake, Import et DirectQuery dans Power BI ?

Import copie les données dans le modèle et impose une actualisation programmée. DirectQuery renvoie une requête à la source à chaque interaction, donc la performance dépend de celle de la source. Direct Lake lit les fichiers Delta directement dans OneLake : pas de copie, pas d’actualisation à programmer, et des temps de réponse proches de l’import sur de gros volumes.

Peut-on mettre une capacité Fabric en pause pour réduire la facture ?

Oui, et une capacité en pause n’est pas facturée. Les contenus restent en place, seul le calcul s’arrête. Quand les rapports sont consultés en journée et les traitements lancés la nuit, la mise en pause automatisée fait une vraie différence sur la facture. Encore faut-il l’automatiser, ce que peu d’organisations font.

Faut-il migrer de Snowflake ou BigQuery vers Fabric ?

Rarement. Si l’entrepôt fonctionne et que les équipes le maîtrisent, migrer pour unifier une facture ne se rentabilise pas. Mieux vaut brancher Power BI sur l’existant. Fabric s’impose surtout quand la stack est déjà Microsoft, ou quand il n’y a pas encore d’entrepôt du tout.

Qu’est-ce qu’un raccourci OneLake ?

Une référence vers des données stockées ailleurs : Azure Data Lake Storage, Amazon S3, ou un autre espace de travail Fabric. La donnée n’est ni copiée ni synchronisée, elle est lue sur place. C’est utile quand une partie des données ne peut pas être déplacée pour des raisons contractuelles ou réglementaires.

• Power BI, la couche de restitution, désormais intégrée à Fabric.
• Azure Data Factory, d’où vient la partie ingestion et ce qui change.
• dbt, pour industrialiser les transformations, y compris sur un entrepôt Fabric.
• Snowflake et BigQuery, les deux alternatives à peser avant de trancher.

Sources — documentation officielle de l’éditeur, consultée le 22 août 2026 : Direct Lake, capacités et licences.