Snowflake vs Microsoft Fabric : quel choix pour remplacer SQL Server ?

Quand un DSI décide de migrer son infrastructure SQL Server/SSIS vers le cloud, la question tombe inévitablement dans les premières minutes de cadrage : Snowflake ou Fabric ? La réponse « ça dépend » est correcte mais insuffisante. Cet article détaille les critères concrets qui orientent le choix.

Deux philosophies fondamentalement différentes

Snowflake est un data warehouse cloud pur. Il fait une seule chose — stocker et calculer des données relationnelles — et il le fait exceptionnellement bien. Le stockage et le compute sont complètement séparés : vous pouvez stocker 10 To de données à un coût marginal et ne provisionner du compute que quand vous en avez besoin. Cette architecture a une conséquence directe : les traitements nocturnes qui coûtent cher en infrastructure SQL Server ne coûtent presque rien sur Snowflake quand ils ne tournent pas.

Microsoft Fabric est une plateforme analytique intégrée. Elle regroupe dans un seul environnement le Lakehouse (OneLake), le Data Warehouse, les pipelines d’intégration (Dataflow Gen2), les notebooks Spark, Real-Time Analytics et Power BI. Le modèle de licence est basé sur des capacités (F SKU) achetées à la plateforme, pas à l’usage individuel de chaque composant.

Dit autrement : Snowflake est un outil spécialisté, Fabric est une plateforme généraliste. Ni l’un ni l’autre n’est « meilleur » — ils répondent à des besoins différents.

Critère 1 : votre écosystème existant

Si votre entreprise est déjà sur Azure avec Power BI comme outil de reporting principal, Active Directory pour l’authentification, et une culture Microsoft forte dans les équipes, Fabric est le choix de moindre friction. L’intégration avec Power BI est native (mode Direct Lake, pas de copie de données), la sécurité se configure dans Azure AD (pas de deuxième système d’identité), et les Data Factory pipelines remplacent SSIS avec une interface graphique familière.

Si votre entreprise est multi-cloud (AWS + Azure, ou GCP + Azure), ou si vous avez un besoin stratégique d’éviter le vendor lock-in, Snowflake est le choix logique. Snowflake fonctionne de manière identique sur AWS, Azure et GCP. Vous pouvez même répliquer des données entre clouds sans pipeline externe.

Critère 2 : le modèle de coût

C’est souvent le critère décisif, et c’est aussi celui où les comparaisons simplistes sont les plus dangereuses.

Snowflake facture séparément le stockage (environ 23 $/To/mois compressé) et le compute (crédits consommés par seconde). Le compute peut être démarré et arrêté automatiquement. Pour des charges de travail ponctuelles (traitements nocturnes, analyses ad hoc), c’est très efficace. Pour des charges constantes (reporting interactif toute la journée par 500 utilisateurs), le compute tourne en permanence et les crédits s’accumulent.

Fabric facture par capacité (F2, F4, F8… jusqu’à F2048). La capacité est partagée entre tous les composants : pipelines, warehouse, notebooks, Power BI. L’avantage est la prévisibilité : vous savez exactement combien vous payez chaque mois. L’inconvénient est le dimensionnement : si vous sous-estimez la capacité, les performances se dégradent pour tout le monde simultanément.

En général, Snowflake est plus économique pour les charges de travail sporadiques avec de gros volumes, et Fabric est plus économique pour les usages continus de taille moyenne dans un écosystème Microsoft.

Critère 3 : les compétences de votre équipe

Si votre équipe data est à l’aise avec le SQL pur et aime travailler en mode « code-first » avec Git, DBT et des workflows CI/CD, Snowflake + DBT est un terrain naturel. L’ensemble de la chaîne est contrôlé par du code versionné, testé et déployé automatiquement.

Si votre équipe est plus orientée « low-code » ou vient d’un background SSIS/Data Factory avec des interfaces graphiques, Fabric est plus accessible. Les Dataflow Gen2 ont une logique proche d’SSIS (sources, transformations visuelles, destinations), et le Data Warehouse de Fabric se requête en T-SQL standard — vos développeurs SQL Server ne sont pas dépaysés.

Critère 4 : le cas hybride

C’est un scénario que nous observons de plus en plus : Snowflake pour le stockage massif et le compute lourd (traitements de transformation, data science), Power BI/Fabric pour la couche de reporting et de consommation. Les deux s’intègrent via le connecteur Snowflake natif de Power BI (DirectQuery ou Import), et Fabric peut également accéder à Snowflake via des shortcuts OneLake.

Cette architecture hybride combine le meilleur des deux mondes : l’élasticité et l’indépendance de Snowflake pour le stockage et les transformations, la puissance d’intégration de Fabric/Power BI pour la consommation et le partage.