Snowflake expliqué simplement : trois couches, et pourquoi ça change tout
Stockage, calcul, services : comprendre l'architecture de Snowflake sans jargon, puis organiser ses données en couches qui tiennent dans la durée.
« Snowflake, c'est une base de données dans le cloud. » La phrase est vraie, et elle passe à côté de l'essentiel. Ce qui a fait le succès de Snowflake n'est pas le cloud en soi, c'est une idée d'architecture simple : séparer ce qui stocke les données de ce qui les calcule. Une fois cette idée comprise, presque tout le reste en découle, des coûts à la gouvernance.
L'image de la bibliothèque
Imaginez une grande bibliothèque. Les livres sont rangés une seule fois, dans une réserve commune. Chaque équipe qui veut travailler réserve une salle de lecture, plus ou moins grande selon le travail à faire, et la rend quand elle a fini. Un accueil, à l'entrée, vérifie qui a le droit de consulter quoi et indique où trouver chaque ouvrage.
Snowflake fonctionne exactement ainsi. La réserve, c'est le stockage. Les salles de lecture, ce sont les entrepôts virtuels de calcul. L'accueil, ce sont les services. Dans les bases de données traditionnelles, la réserve et les salles étaient le même bâtiment : pour accueillir plus de lecteurs, il fallait agrandir tout l'édifice, et une équipe trop gourmande ralentissait toutes les autres.
- Livres et salles de lecture dans le même édifice
- Plus de lecteurs : on agrandit tout le bâtiment
- Une équipe gourmande ralentit toutes les autres
- On paie le bâtiment, qu'il soit plein ou vide
- Une réserve commune, les livres rangés une fois
- Une salle par équipe, à la taille du besoin
- Personne ne gêne personne
- On ne paie que les salles occupées
Couche 1 : le stockage, une seule copie de la vérité
Toutes les données sont conservées une seule fois, dans le stockage objet du fournisseur cloud choisi (AWS, Azure ou Google Cloud). Snowflake les découpe en petits blocs compressés, appelés micro-partitions, et note pour chacun ce qu'il contient : plages de dates, valeurs minimales et maximales. Quand une requête ne porte que sur le mois d'août, Snowflake sait d'avance quels blocs ignorer.
Pour l'entreprise, deux conséquences comptent. D'abord, il n'existe plus de copies dispersées d'une même table entre équipes : tout le monde lit la même donnée. Ensuite, le stockage coûte peu et se facture séparément du calcul.
Deux fonctions découlent directement de ce modèle et rendent de grands services au quotidien. Le voyage dans le temps (Time Travel) permet de relire une table telle qu'elle était hier ou la semaine dernière, dans la limite de la durée de rétention configurée : une suppression malheureuse se rattrape sans restaurer de sauvegarde. Le clonage sans copie (zero-copy cloning) crée en quelques secondes un environnement de test complet à partir de la production, sans dupliquer les données tant qu'on ne les modifie pas.
Couche 2 : le calcul, des moteurs à la demande
Le calcul est assuré par des entrepôts virtuels (virtual warehouses) : des grappes de serveurs que l'on crée en quelques secondes, dans une taille au choix, et qui s'arrêtent automatiquement quand personne ne les utilise. On paie le temps pendant lequel ils tournent, pas leur existence.
C'est là que l'architecture change les habitudes. On peut donner un entrepôt aux chargements nocturnes, un autre aux tableaux de bord de la direction, un troisième aux data scientists. Ils lisent les mêmes données, mais ne se gênent jamais : la requête lourde d'une équipe ne ralentit plus le rapport du comité de direction. Et si un traitement a besoin de plus de puissance pendant une heure, on augmente la taille de son entrepôt pour cette heure-là seulement.
Cette souplesse a une contrepartie : un entrepôt mal réglé, trop grand ou qui ne s'éteint jamais, coûte cher. C'est l'objet du FinOps appliqué à Snowflake : des tailles adaptées à chaque usage, une mise en veille automatique courte, un suivi régulier de la consommation par entrepôt et par équipe.
Couche 3 : les services, le cerveau qui ne se voit pas
Au-dessus, une couche de services orchestre l'ensemble. Elle authentifie les utilisateurs, applique les droits, optimise chaque requête avant de l'exécuter et tient à jour les métadonnées. C'est aussi elle qui porte les mécanismes de gouvernance : rôles, masquage dynamique des colonnes sensibles, politiques de lignes qui filtrent automatiquement ce que chacun peut voir.
Le point important pour une DSI est que cette couche est gérée par l'éditeur. Pas d'index à maintenir, pas de serveur à mettre à jour, pas de statistiques à recalculer. Les équipes data passent leur temps sur les données, pas sur la machine.
Organiser ses données en couches
Comprendre l'architecture ne suffit pas : une plateforme Snowflake mal organisée devient vite un grenier où plus personne ne retrouve rien. La pratique la plus répandue consiste à faire circuler les données à travers trois couches logiques, chacune avec un rôle précis.
La couche brute reçoit les données telles qu'elles arrivent, sans transformation. Elle sert de preuve : en cas de doute sur un chiffre, on peut toujours revenir à ce que la source a réellement envoyé.
La couche préparée nettoie et harmonise : formats de dates unifiés, doublons supprimés, codes traduits, contrôles de qualité appliqués. C'est ici que l'on rejette ou signale une donnée incohérente, avant qu'elle ne contamine un indicateur.
La couche métier expose ce que les utilisateurs consomment : des tables et des vues qui parlent leur langage, « coût réel par projet et par mois » plutôt que « jointure des pointages et du référentiel analytique ». Chaque indicateur y est défini une seule fois.
Un outil de transformation comme dbt rend ce découpage concret : chaque étape est un modèle SQL versionné, testé et documenté, et l'ensemble se déploie de façon identique d'un environnement à l'autre.
Trois environnements, une seule méthode
Une plateforme sérieuse distingue au minimum trois environnements : développement, qualification et production. Le développeur travaille sur une copie, souvent obtenue par clonage sans copie ; la qualification permet aux métiers de valider ; la production ne reçoit que ce qui a été testé. Les mêmes modèles dbt passent de l'un à l'autre sans modification manuelle.
- Travail sur un clone de la production
- Modèle dbt écrit et versionné
- Tests automatiques au vert
- Même code, déployé sans retouche
- Validation par les métiers
- Contrôles de qualité des données
- Déploiement de ce qui a été validé
- Traçabilité : quoi, quand, par qui
- Suivi des coûts et des incidents
Cette discipline évite le scénario classique où une modification faite « vite, directement en production » casse le tableau de bord du lundi matin. Elle rend aussi les audits simples : on sait ce qui est en production, depuis quand, et qui l'a validé.
Les droits suivent les couches
L'organisation en couches simplifie enfin la gouvernance. Les ingénieurs data écrivent dans les couches brute et préparée ; les analystes et les outils de restitution lisent la couche métier ; les données personnelles sont masquées dès la couche préparée pour tous ceux qui n'en ont pas besoin. Chaque rôle reçoit le strict nécessaire, et une matrice de droits construite avec les métiers dit qui accède à quoi.
| Brute | Préparée | Métier | |
|---|---|---|---|
| Ingénieur data | ✓ | ✓ | ✓ |
| Analyste métier | ✕ | ◐ | ✓ |
| Outil de restitution | ✕ | ✕ | ✓ |
| Assistant IA | ✕ | ✕ | ◐ |
✓ accès complet ◐ accès restreint ou masqué ✕ pas d'accès
Snowflake n'est pas seul
Snowflake n'a pas le monopole de ces idées. Databricks, Google BigQuery ou Microsoft Fabric séparent eux aussi stockage et calcul, chacun avec ses forces. Le choix dépend de l'existant, des compétences et des usages visés. Ce qui ne change pas d'une plateforme à l'autre, c'est la méthode : des couches claires, des environnements séparés, des droits construits avec les métiers.
À retenir
- Snowflake sépare trois couches : le stockage (une seule copie des données), le calcul (des entrepôts virtuels à la demande) et les services (sécurité, optimisation, métadonnées).
- Cette séparation permet à chaque équipe d'avoir sa puissance de calcul sans gêner les autres, et de ne payer que ce qui tourne.
- Le voyage dans le temps et le clonage sans copie découlent directement de l'architecture et simplifient le quotidien.
- Une plateforme qui tient dans la durée organise ses données en couches brute, préparée et métier, avec dbt pour versionner et tester.
- Trois environnements (développement, qualification, production) et des droits par couche rendent la plateforme fiable et auditable.
Checklist
- Chaque usage (chargements, restitution, exploration) dispose de son propre entrepôt virtuel.
- La mise en veille automatique est courte et la consommation suivie par entrepôt.
- Les données circulent par trois couches : brute, préparée, métier.
- Les transformations sont des modèles dbt versionnés, testés et documentés.
- Développement, qualification et production sont séparés et alimentés par la même méthode.
- Les droits sont définis par couche et par rôle, à partir d'une matrice validée avec les métiers.