L'architecture Snowflake expliquée, et à quoi elle sert

L'architecture Snowflake découpe une plateforme de données en trois couches qui évoluent indépendamment : le stockage, le calcul (appelé virtual warehouses) et une couche de cloud services qui coordonne l'ensemble. Les entreprises utilisent Snowflake comme entrepôt de données cloud pour le reporting et l'analytique, et de plus en plus comme lieu de partage de données, d'exécution de Python et de construction d'IA sur des données gouvernées.

Ce seul choix de conception, séparer stockage et calcul, explique l'essentiel de ce que Snowflake fait bien et l'essentiel de ce qu'il coûte.

J'ai travaillé avec Snowflake sur des programmes de plateforme de données dans l'industrie et la défense. Un schéma que je vois souvent : les dirigeants l'achètent pour l'analytique, puis découvrent que les décisions d'architecture (combien de warehouses, quelle édition, où résident les données) déterminent la facture et la position de conformité. Ce guide s'adresse au DSI, au CDO ou à l'architecte qui doit comprendre ces décisions avant de signer.

Snowflake est une plateforme de données entièrement managée qui tourne sur Amazon Web Services, Microsoft Azure et Google Cloud. Vous ne l'installez pas, vous ne la patchez pas et vous ne réglez pas d'index. Vous chargez des données, vous écrivez du SQL (ou du Python), et vous payez séparément le stockage et le calcul.

Snowflake décrit sa conception comme un hybride entre architectures shared-disk et shared-nothing : un stockage central unique des données, interrogé par des clusters de calcul indépendants. Un fait compte tôt pour les acheteurs de la défense : selon le guide des concepts clés et de l'architecture de Snowflake lui-même, la plateforme ne peut pas être installée sur une infrastructure locale ou de cloud privé.

Voici l'empilement, de bas en haut.

1. 03Cloud servicesSécurité, contrôle d'accès, métadonnées, optimisation des requêtes et transactions
2. 02CalculVirtual warehouses : clusters indépendants qui exécutent SQL et Python, facturés en crédits pendant leur fonctionnement
3. 01StockageMicro-partitions compressées en colonnes dans un stockage objet cloud, facturées au téraoctet

Le stockage

Quand vous chargez des données, Snowflake les réorganise dans un format compressé en colonnes et les stocke dans un stockage objet cloud. Il découpe chaque table en micro-partitions, chacune contenant entre 50 Mo et 500 Mo de données non compressées. Snowflake enregistre des métadonnées pour chacune, comme la plage de valeurs de chaque colonne.

Ces métadonnées sont la partie astucieuse. Une requête filtrée sur les ordres de fabrication du mois dernier ignore chaque micro-partition dont la plage de dates ne peut pas correspondre.

C'est ce qu'on appelle le pruning, et c'est pourquoi Snowflake offre de bonnes performances sans index. Cela signifie aussi que la façon dont les données arrivent (triées par date ou par usine, ou au hasard) influe sur le coût pour les très grandes tables.

Le calcul : les virtual warehouses

Un virtual warehouse est un cluster de calcul qui exécute des requêtes et du code. Chacun est indépendant. Vos rapports de clôture mensuelle de la finance peuvent tourner sur un warehouse pendant que la data science exécute de gros traitements sur un autre, sans que l'un ralentisse l'autre.

Les warehouses existent en tailles de T-shirt et ne consomment des crédits que lorsqu'ils tournent. Ils peuvent se suspendre automatiquement quand ils sont inactifs. Les plus grandes tailles accélèrent les requêtes lourdes prises individuellement.

Plus de clusters permettent de servir plus d'utilisateurs en même temps, et c'est ce que font les warehouses multi-cluster : en édition Enterprise et au-delà, un warehouse peut ajouter automatiquement des clusters quand les requêtes commencent à faire la queue, puis les retirer quand la charge baisse. Snowflake est explicite : le multi-cluster aide la concurrence, pas une requête lente isolée. Pour cela, vous redimensionnez.

Mon guide sur les crédits Snowflake et ce qui fait monter la facture détaille le volet coûts.

Les cloud services

La couche supérieure gère l'authentification, le contrôle d'accès, les métadonnées, l'optimisation des requêtes et les transactions. Time Travel et le clonage sont pour l'essentiel des opérations sur les métadonnées, donc c'est cette couche qui les rend possibles. Vous y pensez rarement, et c'est bien le but.

Les fonctionnalités intéressantes ne sont pas des ajouts. Elles découlent de la conception du stockage et des métadonnées.

1. Time Travel. Vous pouvez interroger, cloner ou restaurer des données telles qu'elles étaient à un moment passé. L'édition Standard conserve 1 jour. Enterprise et au-delà peuvent conserver jusqu'à 90 jours pour les tables permanentes, comme l'indique la documentation de Time Travel.
2. Fail-safe. Une fois Time Travel expiré, les données des tables permanentes passent dans une période Fail-safe de 7 jours. Seul Snowflake peut les récupérer. Considérez-la comme de la reprise après sinistre, pas comme une sauvegarde que vous contrôlez.
3. Le clonage zero-copy. Un clone de table, de schéma ou de base de données n'utilise aucun stockage supplémentaire à sa création, car il pointe vers les mêmes micro-partitions. Vous ne payez que les données qui changent ensuite. C'est ainsi que les équipes montent en quelques minutes des environnements de test en taille réelle.
4. Le partage sécurisé de données. Un fournisseur partage des tables vivantes avec un autre compte Snowflake, sans aucune copie de données. Le consommateur ne paie que le calcul qu'il utilise pour interroger. Les partages directs fonctionnent au sein d'une région ; le partage interrégional passe par des listings avec auto-fulfilment.
5. Snowflake Marketplace. Les listings vous permettent de publier des data products pour des partenaires précis ou publiquement, y compris des données tierces comme la météo ou des indices de marché.
6. Snowpark. Des bibliothèques pour Python, Java et Scala qui poussent le traitement dans Snowflake au lieu d'en extraire les données. Snowpark Container Services, qui exécute des applications conteneurisées à côté des données, est en disponibilité générale sur les trois clouds dans les régions commerciales.

Pour un industriel, le partage sécurisé de données mérite un pilote. Soyez réaliste sur le point de départ : la plupart des échanges de données avec les fournisseurs que je vois passent encore par des transferts de fichiers.

Partager une table gouvernée est plus propre, et vous pouvez révoquer l'accès. Commencez avec un fournisseur et un jeu de données, et faites la preuve avant de planifier davantage.

Snowflake signifiait autrefois « vos données au format Snowflake ». Cela a changé, et les noms aussi. Situation actuelle, octobre 2026 :

Capacité	Ce qu'elle fait	Statut (octobre 2026)
Tables Apache Iceberg	Données stockées au format ouvert Iceberg, dans votre stockage cloud ou celui de Snowflake	GA depuis juin 2024 ; option de stockage managé par Snowflake en GA depuis juin 2026 (AWS et Azure commerciaux)
Snowflake Horizon Catalog	Gouvernance et catalogue construits sur Apache Polaris ; les moteurs externes lisent les tables Iceberg managées par Snowflake via l'API Iceberg REST	Recommandé pour les nouveaux clients
Snowflake Open Catalog	Service Apache Polaris managé (anciennement Polaris Catalog)	GA, mais fermé aux nouveaux clients ; les utilisateurs existants peuvent continuer
Hybrid tables (Unistore)	Tables orientées lignes pour des recherches transactionnelles à faible latence à côté de l'analytique	GA dans les régions commerciales AWS et Azure uniquement
Snowflake Postgres	PostgreSQL entièrement managé au sein de la plateforme Snowflake	GA depuis le 24 février 2026, sur AWS et Azure

La conséquence pratique : les tables Iceberg permettent à Spark, Databricks ou d'autres moteurs de travailler sur les mêmes fichiers que ceux interrogés par Snowflake, ce qui réduit l'enfermement propriétaire. La présentation d'Open Catalog de Snowflake indique désormais aux nouveaux clients d'utiliser plutôt Horizon Catalog.

Lisez les limites des hybrid tables avant que quelqu'un ne vous les présente comme une base de données opérationnelle. Chaque base est plafonnée à 2 To de données en hybrid tables, et elles ne prennent en charge ni Fail-safe, ni le partage de données, ni la réplication, ni les streams. Elles conviennent très bien pour une table de référence applicative.

Ce ne sont pas des bases de données opérationnelles. Si une application en a besoin à côté de son analytique, Snowflake Postgres est passé en disponibilité générale en février 2026 et constitue le choix le plus honnête.

Snowflake vend quatre éditions : Standard, Enterprise, Business Critical et Virtual Private Snowflake (VPS). L'édition détermine les fonctionnalités de sécurité dont vous disposez, et le prix du crédit augmente avec elle.

Fonctionnalité	Standard	Enterprise	Business Critical	VPS
Time Travel	1 jour	Jusqu'à 90 jours	Jusqu'à 90 jours	Jusqu'à 90 jours
Warehouses multi-cluster	Non	Oui	Oui	Oui
Tri-Secret Secure (clé gérée par le client)	Non	Non	Oui	Oui
Connectivité privée (AWS PrivateLink, Azure Private Link, Google Private Service Connect)	Non	Non	Oui	Oui
Prise en charge HIPAA et PCI DSS	Non	Non	Oui	Oui
Environnement dédié, sans matériel partagé	Non	Non	Non	Oui

Tri-Secret Secure combine une clé Snowflake avec une clé que vous détenez dans le service de gestion de clés de votre fournisseur cloud. Révoquez votre clé, et Snowflake ne peut plus déchiffrer vos données. Pour les fournisseurs de la défense et de l'aéronautique, ce contrôle compte plus que n'importe quelle fonctionnalité analytique.

Pour les travaux du gouvernement américain, Snowflake exploite des régions SnowGov sur AWS GovCloud et Azure Government, ouvertes aux clients et sous-traitants du gouvernement américain. La page des régions prises en charge de Snowflake mentionne la prise en charge de FedRAMP High, d'Impact Level 4 et d'ITAR dans ces régions, d'Impact Level 5 dans une région AWS, et exige l'édition Business Critical ou supérieure. Vérifiez la disponibilité des fonctionnalités région par région : Open Catalog, les hybrid tables et une partie de Snowpark Container Services ne sont pas disponibles dans toutes les régions gouvernementales.

Dans les programmes de défense sur lesquels j'ai travaillé, la première question n'est jamais « à quelle vitesse ça va ». C'est « où sont les données, qui peut les voir, et pouvons-nous le prouver à un auditeur ». Snowflake y répond bien dans la bonne région et la bonne édition.

Il ne peut pas y répondre pour des données qui doivent rester dans vos propres murs. Les charges classifiées ou soumises au contrôle des exportations qui exigent un traitement sur site ont besoin d'une autre plateforme, Snowflake prenant en charge le périmètre non classifié.

L'essentiel de ce que je vois relève de quelques schémas.

1. Reporting d'entreprise et BI. Reporting finance, ventes et opérations à partir des données ERP (SAP, Oracle ou Microsoft Dynamics 365), avec Power BI, Tableau ou équivalent par-dessus. C'est toujours l'usage central. Mon guide pour amener les données ERP dans Snowflake couvre les options d'extraction.
2. Données des opérations industrielles. Les données d'usine et d'opérations que j'ai vues chargées dans Snowflake sont des données de planification de la production. Les données d'historien, de MES, de qualité et de maintenance peuvent se trouver à côté, et les données de capteurs semi-structurées en JSON se chargent nativement.
3. Partage de données avec des partenaires. Fournisseurs, distributeurs et clients peuvent interroger directement des tables gouvernées. En pratique, la plupart des échanges avec les fournisseurs que je vois passent encore par des transferts de fichiers.
4. Data science et IA sur des données gouvernées. Python via Snowpark et les services d'IA de Snowflake, que je traite dans mon article sur Snowflake Cortex AI et Snowflake Intelligence.
5. Consolidation après des acquisitions. Plusieurs ERP, une seule couche de reporting, avec le clonage pour des environnements de test sûrs.

Là où j'hésiterais :

1. Les systèmes transactionnels à fort volume. Les hybrid tables et Snowflake Postgres aident, mais les transactions de votre ERP et de votre MES ont leur place dans leurs propres bases de données.
2. Le pilotage des machines en temps réel. Snowflake convient à l'échelle de la minute, pas de la milliseconde. Y faire entrer des flux de données de capteurs, pas de problème. Fermer une boucle de régulation, non.
3. Les exigences strictes de déploiement sur site. Il n'existe aucune installation sur site.
4. Le machine learning sur mesure et l'ingénierie des données lourds en Spark. C'est faisable, mais beaucoup d'équipes trouvent Databricks plus naturel. Mon comparatif Snowflake vs Databricks examine ce choix.

Schéma en flocon vs schéma en étoile : une tout autre chose

Les personnes qui cherchent Snowflake tombent souvent sur le « snowflake schema », ou schéma en flocon. Il n'a rien à voir avec le produit. Un schéma en flocon est un modèle de données dans lequel les tables de dimensions sont normalisées en sous-tables, si bien que le diagramme se ramifie comme un flocon de neige.

Un schéma en étoile garde chaque dimension dans une seule table à plat. Vous pouvez construire l'un ou l'autre modèle dans Snowflake, ou dans n'importe quel autre entrepôt. La plupart des équipes BI préfèrent les schémas en étoile pour des requêtes plus simples.

Avant de signer, écrivez quatre décisions : quelle édition votre position de conformité exige, quel cloud et quelle région, comment vous répartirez les charges de travail entre warehouses, et si vos données restent au format Snowflake ou en Iceberg. Demandez à l'éditeur et à votre intégrateur de vous montrer l'estimation de crédits par warehouse, pas un chiffre annuel unique. La plupart des mauvaises surprises de coûts sur Snowflake sont des décisions d'architecture que personne n'a mises par écrit.

Si des données ERP sont dans le périmètre, lisez d'abord pourquoi les migrations de données SAP échouent ; les mêmes problèmes de qualité des données vous suivent sur n'importe quelle plateforme. Si vous souhaitez un second avis sur une décision Snowflake, contactez-moi.

À quoi sert Snowflake ?

Principalement d'entrepôt de données cloud pour le reporting et l'analytique sur des données métier comme les données ERP, CRM et opérationnelles. Les entreprises l'utilisent aussi pour partager des données vivantes avec des partenaires, faire de la data science en Python via Snowpark et construire des applications d'IA sur des données gouvernées.

Quelles sont les trois couches de l'architecture Snowflake ?

Le stockage, le calcul et les cloud services. Le stockage conserve les données dans des micro-partitions compressées en colonnes. Le calcul se compose de virtual warehouses qui exécutent les requêtes. Les cloud services gèrent la sécurité, les métadonnées, l'optimisation des requêtes et les transactions. Le stockage et le calcul évoluent et sont facturés séparément.

Snowflake est-il une base de données ou un entrepôt de données ?

Les deux, selon la définition. C'est une base de données SQL conçue pour les charges analytiques, c'est pourquoi on l'appelle généralement entrepôt de données cloud. Avec les tables Iceberg, les hybrid tables et Snowflake Postgres, il couvre désormais aussi le lakehouse et certains cas d'usage transactionnels, dans certaines limites.

Snowflake peut-il fonctionner sur site ?

Non. Snowflake tourne uniquement sur AWS, Microsoft Azure et Google Cloud. Pour les charges du gouvernement américain et de la défense, il propose des régions SnowGov sur AWS GovCloud et Azure Government, qui exigent l'édition Business Critical ou supérieure.

Le schéma en flocon (snowflake schema) a-t-il un lien avec l'entreprise Snowflake ?

Non. Un schéma en flocon est un modèle de données avec des tables de dimensions normalisées. Il est antérieur à l'entreprise et fonctionne dans n'importe quel entrepôt.

De quelle édition Snowflake les entreprises réglementées ont-elles besoin ?

Généralement Business Critical. Elle ajoute Tri-Secret Secure avec une clé gérée par le client, la connectivité privée et la prise en charge HIPAA et PCI DSS, et c'est le minimum pour les régions gouvernementales. Virtual Private Snowflake ajoute un environnement dédié, sans matériel partagé.