Snowflake

La plupart des entrepôts de données classiques mélangent le disque et le processeur dans une même machine. Vous dimensionnez pour le pic, vous payez ce dimensionnement toute l’année, et deux traitements lourds lancés en même temps se gênent.

Snowflake a fait le choix inverse, et tout le reste en découle : les coûts, les performances, et les erreurs que nous voyons le plus souvent en mission.

Les données vivent une seule fois dans le stockage objet du cloud. Le calcul se fait dans des entrepôts virtuels, des grappes de machines que l’on démarre, arrête et redimensionne indépendamment les unes des autres.

La conséquence pratique est celle que les équipes attendaient depuis longtemps : le rafraîchissement nocturne des données ne ralentit plus les tableaux de bord de la journée, parce qu’ils tournent sur deux entrepôts différents qui lisent la même donnée. On ne duplique rien pour isoler des charges de travail, on ajoute du calcul.

Sous le capot, Snowflake découpe automatiquement chaque table en micro-partitions et conserve pour chacune les valeurs minimales et maximales de chaque colonne. Une requête filtrée ignore donc les partitions qui ne peuvent pas contenir de résultat, sans que personne ait créé d’index. C’est ce qui explique qu’une table de plusieurs milliards de lignes réponde correctement sans travail d’optimisation préalable.

Sur les très grandes tables, on peut déclarer une clé de regroupement pour orienter ce découpage. C’est utile, et c’est aussi la première chose que les équipes activent trop tôt : le reclassement automatique qu’elle déclenche consomme des crédits en continu. À réserver aux tables volumineuses réellement filtrées sur la même colonne.

Le calcul se facture à la seconde, avec un minimum d’une minute à chaque démarrage. Un entrepôt éteint ne coûte rien. Toute la maîtrise du budget tient donc à deux réglages et à une discipline.

Le premier réglage est la suspension automatique. Un entrepôt qui reste allumé parce que personne n’a fixé de délai d’extinction facture des heures pendant lesquelles aucune requête ne tourne. C’est de très loin la première cause de facture inexpliquée que nous rencontrons.

Le second est la taille. Chaque palier double le nombre de crédits consommés par heure. Doubler la taille pour une requête qui va deux fois plus vite ne coûte donc rien de plus, mais doubler la taille d’un entrepôt qui passe l’essentiel de son temps à attendre double la facture sans rien accélérer. La bonne question n’est jamais la taille de vos données, c’est de savoir si vos requêtes débordent sur le disque local faute de mémoire.

La discipline, enfin, consiste à séparer les charges de travail par entrepôt : un pour les chargements, un pour la restitution, un pour les analystes qui explorent. Cela isole les incidents, et surtout cela rend la facture lisible. Sans cette séparation, personne ne peut dire quelle équipe consomme quoi, et l’arbitrage devient impossible.

Deux mécanismes travaillent gratuitement pour vous : le cache de résultats, qui renvoie sans calcul une requête identique déjà exécutée récemment, et l’élasticité multi-grappes qui absorbe les pics de connexions simultanées. Le second se configure avec un plafond, faute de quoi il absorbe aussi votre budget.

Snowflake conserve l’état antérieur des tables pendant une durée que vous fixez. Une table supprimée par erreur se restaure, et une requête peut interroger les données telles qu’elles étaient hier. Cette rétention se paie en stockage, ce qui reste sans commune mesure avec le coût d’une reprise de données ratée.

Le clonage sans copie en découle. Dupliquer une base entière pour créer un environnement de test est instantané et ne consomme presque pas d’espace au départ, puisque seules les modifications ultérieures occupent du stockage réel. Beaucoup d’équipes s’interdisent de tester sur des volumes réalistes faute d’environnement ; ici l’argument tombe.

Le partage de données mérite aussi d’être connu. Donner accès à un jeu de données à un partenaire, un client ou une filiale ne demande ni export, ni fichier, ni recopie : le destinataire lit la donnée à la source, avec son propre calcul. Pour un groupe qui échange des données entre entités, cela supprime une catégorie entière de traitements.

Quand vos données sont majoritairement tabulaires et que vos équipes travaillent en SQL. C’est le terrain naturel de l’outil, et il n’y demande presque pas d’administration.

Quand plusieurs charges de travail se gênent aujourd’hui sur une même machine. C’est le problème que l’architecture résout par construction.

Et quand vous voulez rester indépendant d’un fournisseur de cloud, puisque la plateforme fonctionne de la même façon sur les trois principaux, avec des données qui ne bougent pas de votre région.

Quand il vaut mieux autre chose

Pour de l’apprentissage automatique lourd, du traitement d’images, de son ou de texte à grande échelle, Databricks reste plus à sa place, même si Snowflake a beaucoup progressé sur l’exécution de code Python au plus près des données.

Pour une application transactionnelle, ce n’est pas le bon outil : l’entrepôt est fait pour lire beaucoup, pas pour écrire ligne à ligne à haute fréquence.

Et si votre entreprise vit déjà entièrement dans l’écosystème Microsoft, examinez Fabric avant de trancher : l’intégration avec Power BI et l’achat par capacité réservée changent le calcul.

Nous concevons le socle : organisation des bases et des schémas, séparation des entrepôts par usage, rôles et droits d’accès, et modélisation des données pour qu’elles servent réellement à décider.

Nous reprenons aussi des plateformes dont la facture a doublé sans que personne sache pourquoi. Le diagnostic tourne presque toujours autour des mêmes points : entrepôts sans extinction automatique, dimensionnement décidé au jugé, charges mélangées, clé de regroupement activée sur une table qui n’en avait pas besoin, et rétention laissée au maximum partout.

Nous branchons enfin la couche de transformation avec dbt et l’orchestration avec Airflow ou Dagster, puis la restitution avec Power BI. Et quand une autre plateforme conviendrait mieux à votre situation, nous le disons.

Comment fonctionne l’architecture de Snowflake ?

Snowflake sépare le stockage du calcul. Les données vivent une seule fois dans le stockage objet du cloud, et le calcul se fait dans des entrepôts virtuels que l’on démarre, arrête et redimensionne indépendamment. Deux charges de travail peuvent donc lire la même donnée sans se gêner, sur deux entrepôts distincts. Les tables sont découpées automatiquement en micro-partitions dont les valeurs extrêmes sont mémorisées, ce qui permet d’ignorer les partitions non pertinentes sans créer d’index.

Pourquoi ma facture Snowflake augmente-t-elle ?

Dans la grande majorité des cas parce que des entrepôts virtuels restent allumés sans requête à traiter, faute de délai de suspension automatique. Le calcul est facturé à la seconde avec un minimum d’une minute par démarrage, donc un entrepôt éteint ne coûte rien. Les autres causes fréquentes sont un dimensionnement décidé au jugé alors que chaque palier double la consommation horaire, l’absence de séparation des charges par entrepôt, une clé de regroupement activée sur une table qui n’en avait pas besoin, et une rétention laissée au maximum partout.

Faut-il définir une clé de regroupement sur ses tables Snowflake ?

Rarement, et jamais par défaut. Le découpage automatique en micro-partitions suffit dans la plupart des cas. Une clé de regroupement déclenche un reclassement automatique qui consomme des crédits en continu, ce qui ne se justifie que sur des tables volumineuses réellement filtrées sur la même colonne. C’est l’une des optimisations que les équipes activent le plus souvent trop tôt.

À quoi servent le voyage dans le temps et le clonage sans copie ?

Le voyage dans le temps conserve l’état antérieur des tables pendant une durée configurable : une table supprimée par erreur se restaure et une requête peut lire les données telles qu’elles étaient hier. Le clonage sans copie permet de dupliquer une base entière instantanément, sans consommer d’espace au départ puisque seules les modifications ultérieures occupent du stockage réel. C’est ce qui rend possible de tester sur des volumes réalistes sans doubler la facture de stockage.

Snowflake convient-il à tous les cas d’usage ?

Non. Il est à sa place sur des données majoritairement tabulaires avec des équipes qui travaillent en SQL. Pour de l’apprentissage automatique lourd ou du traitement d’images, de son et de texte à grande échelle, Databricks reste plus adapté. Pour une application transactionnelle qui écrit ligne à ligne à haute fréquence, ce n’est pas le bon outil. Et sur une organisation entièrement Microsoft, il faut examiner Fabric avant de trancher.

• Snowflake ou Databricks, les quatre critères qui tranchent encore entre les deux.
• BigQuery, l’autre entrepôt sans serveur, et son modèle de facturation opposé.
• dbt, pour organiser les transformations qui tournent dessus.
• Panorama des technologies sur lesquelles nous intervenons.

Sources — documentation officielle de l’éditeur, consultée le 22 août 2026 : entrepôts virtuels et facturation, voyage dans le temps, micro-partitions et clustering.