Azure Synapse Analytics

Beaucoup d’équipes disent utiliser Synapse sans que cela renseigne sur grand-chose. Le nom recouvre des composants qui n’ont ni la même architecture, ni les mêmes usages, ni surtout le même mode de facturation.

Cette ambiguïté n’est pas un détail de vocabulaire. Elle explique la majorité des mauvaises surprises que nous constatons sur la plateforme, et la moitié des malentendus dans les échanges entre le métier et la direction informatique.

Le premier est l’entrepôt dédié, l’héritier de l’ancien entrepôt de données Azure. Vous provisionnez une puissance de calcul, elle vous est réservée, et elle est facturée tant qu’elle est active, que vous exécutiez des requêtes ou non. C’est le composant qui produit la quasi-totalité des factures inattendues, pour une raison simple : il faut le mettre en pause explicitement. Un entrepôt dédié laissé allumé un week-end de trois jours facture trois jours.

Le deuxième est le moteur SQL sans serveur. Rien à provisionner, rien à éteindre, et une facturation au volume de données lu par requête, appliquée à des fichiers posés dans le stockage. C’est un excellent outil d’exploration et de lecture de fichiers, avec le même piège que tout modèle au volume lu : une requête sans filtre sur un répertoire volumineux coûte immédiatement.

Le troisième est le moteur Spark, pour le traitement distribué et la préparation de données non tabulaires, facturé au temps de calcul des grappes, temps de démarrage compris. Les grappes doivent avoir une extinction automatique courte, faute de quoi elles facturent l’attente.

S’y ajoutent les pipelines d’intégration, techniquement identiques à ceux d’Azure Data Factory, avec les mêmes règles de facturation et le même point de vigilance sur les flux de données de mappage, facturés au temps de calcul.

La première question à poser dans un audit n’est donc jamais « combien coûte Synapse », mais « lequel de ces quatre compteurs tourne chez vous ».

Microsoft a concentré ses développements sur Fabric, qui reprend les mêmes briques dans une offre unifiée, avec un stockage unique en format ouvert, un achat par capacité réservée que l’on peut mettre en pause, et une intégration native avec Power BI. Pour un projet neuf sur Azure, l’examen de Fabric est aujourd’hui un passage obligé.

Cela ne signifie pas qu’il faille migrer dans l’urgence. Une plateforme Synapse qui fonctionne, dont les coûts sont maîtrisés et que l’équipe sait exploiter n’a aucune raison de bouger cette année. Migrer sous la pression d’une annonce produit est une mauvaise façon de dépenser un budget.

Trois signaux justifient en revanche d’instruire le sujet sérieusement. Vous prévoyez un investissement important sur la plateforme dans les mois qui viennent, auquel cas mieux vaut vérifier où le poser. Vos utilisateurs consomment massivement les données dans Power BI, et le mode de lecture directe de Fabric change alors franchement l’équation. Ou vous payez un entrepôt dédié pour un usage qui ne le justifie plus, ce qui rend l’arbitrage économique évident.

Une chose facilite les choses : si vos données sont déjà stockées en format de fichiers ouvert dans le stockage Azure, une partie du chemin est faite, quelle que soit la décision finale.

Quand la plateforme est en place, exploitée par une équipe qui la connaît, avec des coûts sous contrôle. La continuité a une valeur que les comparatifs d’outils oublient systématiquement.

Quand vous avez besoin d’une puissance réservée et prévisible pour des traitements lourds à heure fixe, ce que le modèle dédié fournit bien.

Et quand votre gouvernance est déjà construite autour des réseaux privés et des identités Azure, un socle qui se transpose mais ne se recrée pas gratuitement.

Quand regarder ailleurs

Pour un projet neuf, commencez par comparer Fabric, et si l’indépendance vis-à-vis d’un fournisseur de cloud compte, Snowflake, qui fonctionne de la même façon sur les trois grands.

Si votre charge est très irrégulière, un modèle sans serveur intégral comme BigQuery évite d’avoir à décider d’une taille.

Et si votre usage est majoritairement de l’apprentissage automatique sur des données non tabulaires, Databricks est plus à sa place.

Nous commençons par la lecture de la facture, compteur par compteur. Dans presque tous les cas, l’essentiel du montant provient d’un entrepôt dédié qui n’est pas mis en pause, ou de grappes Spark sans extinction automatique. Ce sont des corrections de quelques heures, et l’effet est immédiat.

Nous travaillons ensuite le socle : modélisation, distribution des tables sur l’entrepôt dédié, organisation des fichiers pour le moteur sans serveur, et sécurité alignée sur vos identités Azure.

Nous instruisons enfin la question de Fabric avec des chiffres plutôt qu’avec un discours produit : ce que la migration coûterait, ce qu’elle rapporterait, et à quelle échéance. Il nous arrive régulièrement de conclure qu’il n’y a rien à faire cette année.

Que contient exactement Azure Synapse Analytics ?

Trois moteurs très différents et un service d’intégration, réunis sous un seul nom. L’entrepôt dédié, où la puissance est réservée et facturée tant qu’elle est active. Le moteur SQL sans serveur, sans rien à provisionner, facturé au volume lu par requête sur des fichiers du stockage. Le moteur Spark pour le traitement distribué, facturé au temps de calcul des grappes. Et les pipelines d’intégration, techniquement identiques à ceux d’Azure Data Factory.

Pourquoi ma facture Azure Synapse est-elle si élevée ?

Dans la grande majorité des cas parce qu’un entrepôt dédié n’est pas mis en pause : la puissance réservée est facturée tant qu’elle est active, que des requêtes s’exécutent ou non, donc un week-end de trois jours facture trois jours. La deuxième cause est l’absence d’extinction automatique courte sur les grappes Spark, qui facturent alors l’attente. La bonne première question d’un audit n’est pas combien coûte Synapse, mais lequel des compteurs tourne réellement.

Faut-il migrer d’Azure Synapse vers Microsoft Fabric ?

Pas dans l’urgence. Une plateforme Synapse qui fonctionne, dont les coûts sont maîtrisés et que l’équipe sait exploiter n’a aucune raison de bouger. Trois signaux justifient en revanche d’instruire le sujet : un investissement important prévu sur la plateforme, une consommation massive des données dans Power BI puisque le mode de lecture directe de Fabric change alors l’équation, ou un entrepôt dédié payé pour un usage qui ne le justifie plus.

Quelle différence entre l’entrepôt dédié et le SQL sans serveur de Synapse ?

Le modèle économique et l’usage. L’entrepôt dédié offre une puissance réservée et prévisible, adaptée à des traitements lourds à heure fixe, mais il facture tant qu’il n’est pas mis en pause. Le moteur sans serveur ne demande aucun provisionnement et facture au volume de données lu par requête sur des fichiers posés dans le stockage : c’est un excellent outil d’exploration, avec le piège classique de la requête sans filtre sur un répertoire volumineux.

Azure Synapse est-il encore un bon choix pour un nouveau projet ?

Pour un projet neuf sur Azure, l’examen de Fabric est devenu un passage obligé, Microsoft y ayant concentré ses développements. Synapse reste pertinent quand la plateforme est déjà en place et exploitée par une équipe qui la connaît, quand une puissance réservée et prévisible est nécessaire, et quand la gouvernance est construite autour des réseaux privés et des identités Azure. Hors Azure, Snowflake apporte l’indépendance vis-à-vis du fournisseur de cloud et BigQuery convient aux charges très irrégulières.

• Microsoft Fabric, la suite unifiée et ce qu’elle change.
• Azure Data Factory, pour l’ingestion depuis des sources sur site.
• Snowflake ou Databricks, si vous ouvrez la comparaison hors Azure.
• Panorama des technologies sur lesquelles nous intervenons.

Sources — documentation officielle de l’éditeur, consultée le 22 août 2026 : mettre en pause un pool dédié, SQL sans serveur.