Tu passes tes vendredis soir à réparer des scripts SQL qui ont planté parce que HubSpot a ajouté une colonne. Tu exportes des CSV à la main pour que le CEO ait son tableau de bord le lundi matin. Et quand quelqu’un te demande un nouveau KPI, tu réponds: « compte 2 semaines, le temps de tout reconstruire. »
On connait cette histoire par coeur. On l’a vécue. Et en 2 semaines, on l’a entièrement changée en migrant vers un stack Fivetran + dbt + Snowflake. Voici le stack exact, le budget mensuel réel, et les 3 erreurs qui nous ont couté du temps (et de l’argent).
Le problème de départ: scripts SQL fragiles et nuits sans sommeil
Notre pipeline ETL tenait avec du fil de fer. Des scripts SQL écrits par une seule personne, des exports Excel pour le reporting, et une gestion des données qui ressemblait plus à du bricolage qu’à de l’ingénierie.
Chaque changement de schéma upstream nous cassait la journée. HubSpot ajoutait un champ? Le pipeline plantait. Stripe modifiait une API? Rebéllion. Et on découvrait le problème le lendemain matin, quand les données du jour n’arrivaient pas.
Le coût caché de cette maintenance manuelle, c’était du temps humain. Beaucoup. Notre responsable data passait 3 jours par semaine à réparer des pipelines, vérifier des fichiers, relancer des jobs. Sans parler de la dépendance à une seule personne qui savait « où éttait le bug ».
Le déclencheur, ce vendredi soir où le pipeline CRM a planté silencieusement à 18h. Personne ne s’en est rendu compte avant le lundi matin. Résultat: 2 jours de données perdues, un reporting faux, et une réunion d’urgence. Ce jour-là, on a décidé qu’on ne pouvait plus continuer comme ça.
Pourquoi Fivetran + dbt + Snowflake (et pas autre chose)
Notre cahier des charges était simple: on voulait des pipelines automatisés, sans maintenance lourde, avec un budget prévisible. Pas de data engineer senior à recruter. Pas d’infrastructure à gérer.
Le trio qu’on a choisi coche toutes les cases:
- Fivetran pour l’ingestion no-code. On connecte nos sources (HubSpot, Stripe, Google Ads) en quelques clics, sans écrire une ligne de code. Pas de connecteurs à maintenir: Fivetran gère les évolutions de schéma pour nous.
- dbt pour les transformations. Une surcouche SQL qui tourne directement dans le warehouse. Le code est versionné dans Git, les tests de qualité sont automatiques, et le déploiement est industrialisé.
- Snowflake pour le stockage cloud. Un data warehouse qui monte en charge tout seul, sans qu’on ait à provisionner du serveur. On paye ce qu’on consomme, point.
Ce qu’on a éliminé: les scripts SQL fragiles, les exports manuels, les pipelines non testés. On est passés d’un modèle ETL classique (transformer avant de charger) à un modèle ELT (charger d’abord, transformer dans le warehouse). Résultat: la donnée arrive plus vite, les transformations sont plus flexibles, et le coût d’infrastructure est maitrisé.
Les alternatives qu’on a testées et pourquoi on a dit non
Avant d’atterrir sur ce stack, on a regardé les autres options. Voici ce qu’on a trouvé:
| Outil | Prix d’entrée | Ce qu’on a retenu |
|---|---|---|
| Airbyte Cloud | 10 $/mois | Excellent catalogue de connecteurs (600+), mais facture imprévisible. Les crédits s’accumulent vite. |
| Airbyte self-hosted | 0 $ licence | 500-3 000 $/mois d’infrastructure + 20-40h/mois de maintenance. Pour une PME, c’est un coût caché énorme. |
| Stitch (Qlik) | 100 $/mois | Prix attractif au départ, mais facturation row-based. À 100M lignes, on monte à 1 500 $/mois. |
| Hevo | 239 $/mois | Bon pricing flat, dbt inclus, alternative solide. Moins de connecteurs que Fivetran mais plus prévisible. |
| Coupler.io | 24 $/mois | Très simple mais trop limité pour un vrai data warehouse. Idéal pour du spreadsheet. |
Notre décision: Fivetran pour l’ingestion car le pricing au MAR (Monthly Active Rows) est prévisible à notre volume, et la maintenance zéro nous fait gagner un temps fou. Airbyte serait top si on avait une équipe d’ingénieurs dédiée à l’infra. Ce n’était pas notre cas.
Le plan de route en 2 semaines (jour par jour)
On avait lu que la mise en place d’une Modern Data Stack pouvait prendre 1 à 3 mois. Nous, on voulait aller plus vite. Pari tenu: en 14 jours, nos premiers dashboards étaient opérationnels. Et on n’a pas recruté de data engineer senior pour ça.
Semaine 1: ingestion et warehouse
Jour 1-2: On crée un compte Snowflake. Configuration du warehouse: 5 minutes. Pas d’infrastructure à gérer, pas de serveur à provisionner. On choisit un X-Small warehouse avec auto-suspend à 5 minutes d’inactivité. Détail qui va compter plus tard.
Jour 2-4: On connecte nos 3 sources critiques via Fivetran. HubSpot pour le CRM, Stripe pour le billing, Google Ads pour le marketing. Quelques clics dans l’interface, on autorise les accès API, et les données commencent à arriver dans Snowflake en temps réel.
Astuce: on a résisté à la tentation de tout connecter d’un coup. 3 sources, pas 15. Ca évite de se noyer dans la complexité et ça permet de valider le pipeline de bout en bout avant d’ajouter des sources supplémentaires.
Semaine 2: transformations dbt et dashboards
Jour 8-10: On installe dbt Core (la version gratuite, open source). On crée nos premiers modèles. Le principe est simple: on écrit du SQL dans des fichiers .sql, dbt les exécute dans Snowflake dans le bon ordre, en gérant les dépendances.
Les 5 modèles essentiels qu’on a construits pour une PME:
- Staging: on importe les tables brutes sans les modifier
- Cleaning: on normalise les noms de colonnes, on supprime les doublons, on gère les NULL
- Finance mart: MRR, ARR, churn rate, revenu par client
- Marketing mart: coût d’acquisition par canal, ROI par campagne
- Product mart: utilisation produit, activation, rétention
Jour 11-14: Tests de qualité automatiques avec dbt. Chaque modèle est validé avant d’être matérialisé. Pas de données douteuses qui remontent dans les dashboards. On connecte Looker pour la visualisation et en 14 jours, le premier dashboard finance est en ligne.
Le game changer selon nous: le dbt dry run. Un pipeline CI qui valide un modèle en 10 secondes. Feedback loop ultra rapide.
Le budget mensuel réel de la stack (chiffres à l’appui)
Voila la question qu’on nous pose tout le temps: combien ça coûte vraiment? Pas le prix marketing, le coût réel. Voici nos chiffres:
Selon le volume de Monthly Active Rows (MAR). Nous sommes à ~350 $.
| Service | Cout mensuel | Commentaire |
|---|---|---|
| Fivetran | 200-500 $/mois | |
| Snowflake | 100-300 $/mois | Avec auto-suspend active. Sans, on aurait été à 600-900 $. |
| dbt Core | 0 $/mois | Version open source. dbt Cloud est optionnel à 100 $/mois. |
| Looker | Inclus | Dans notre forfait existant. Compter 100-300 $/mois sinon. |
| Total stack | 300-900 $/mois | Tout compris. |
Mettons ça en perspective. Un data engineer à plein temps coûte entre 5 000 et 8 000 $/mois. Même en prenant le haut de notre fourchette à 900 $/mois, le retour sur investissement est immédiat. Et on n’a pas besoin d’un data engineer dédié pour faire tourner la stack.
Le piège des crédits Snowflake qu’on a failli ne pas voir
Snowflake facture à la consommation de crédits. Chaque requête, chaque chargement, chaque requête de maintenance consomme des crédits. Le modèle de pricing est à la consommation: tu ne payes que ce que tu utilises. C’est un énorme avantage… à condition de ne pas laisser tourner ton warehouse 24h/24.
Si tu laisses un warehouse X-Small tourner non-stop, tu consommes des crédits en permanence, même quand personne n’interroge les données. La facture peut facilement être multipliée par 3.
Nos 3 règles pour ne pas se faire piéger:
- Auto-suspend: le warehouse s’éteint automatiquement après 5 minutes d’inactivité
- Scheduling: on planifie les runs dbt en début de nuit, pas en continu
- Sizing adapte: un X-Small suffit pour une PME. On ne prend pas plus gros que nécessaire
Le vrai ROI: 3 jours par semaine de gagnés pour la team data
Avant l’industrialisation, notre responsable data passait 3 jours par semaine à: réparer des scripts qui avaient planté, exporter manuellement des CSV, vérifier la cohérence des chiffres dans Excel, relancer des jobs échoués. Ajouté à ça les nuits à stresser quand un pipeline était en cours.
Aujourd’hui, le pipeline ETL est entièrement automatisé. Les données arrivent toutes seules de HubSpot, Stripe et Google Ads dans Snowflake. dbt les transforme et les teste chaque nuit. Les dashboards sont à jour au réveil.
La métrique qui change tout: le time to insight. Avant, ajouter un nouveau KPI prenait 2 semaines (extraire les données, écrire le script, tester, déployer). Aujourd’hui, c’est 1 heure. On écrit un modèle dbt, on le teste, on le matérialise, et le KPI apparait dans le dashboard.
La team data peut enfin travailler sur des sujets à valeur ajoutée: analyse des comportements clients, modélisation prédictive, recommandations produit. Au lieu de passer son temps à éteindre des incendies.
Les 3 erreurs qu’on ne referait pas
On a appris en faisant. Et parfois, en cassant. Voici les 3 erreurs qu’on aimerait ne pas avoir commises:
Erreur 1: tout vouloir connecter d’un coup. On a failli connecter 15 sources dès le jour 1. Résultat: complexité inutile, bugs impossibles à tracer, temps perdu. La bonne approche: commencer par 3 sources critiques, valider le pipeline complet, puis ajouter les sources une par une.
Erreur 2: oublier d’optimiser les requêtes Snowflake. Nos premières requêtes n’étaient pas filtrées. On scannait des tables entières pour un seul indicateur. Résultat: des crédits qui partent en fumée. La leçon: toujours filtrer, toujours limiter les colonnes, toujours utiliser les clustering keys quand les tables dépassent 1 million de lignes.
Erreur 3: négliger la gouvernance des données dès le jour 1. On n’avait pas défini qui pouvait accéder à quoi. Résultat: des requêtes coûteuses lancées par tout le monde, et des questions de sécurité qu’on a dû traiter en urgence. Aujourd’hui, la gouvernance est dans notre checklist de démarrage: rôles, permissions, row-level security si nécessaire.
Et si on devait recommencer demain?
On referait le même stack, sans hésitation. Fivetran pour l’ingestion, dbt pour les transformations, Snowflake pour le warehouse. Ce trio est parfait pour une PME qui veut industrialiser ses pipelines sans recruter une équipe data de 10 personnes.
Mais on ajouterait 2 choses:
- Reverse ETL dès le début. Une fois les données propres dans le warehouse, les renvoyer vers les outils métier (CRM, plateformes publicitaires) pour activer la donnée en temps réel. C’est le pipeline d’activation qui vient compléter le pipeline d’analyse.
- Un DataOps dédié si l’équipe dépasse 7 personnes. Le ratio idéal selon les retours de Brevo: 1 DataOps pour 7-8 profils data. Ce rôle crée les conditions pour que les analystes soient autonomes (CI/CD, infrastructure as code, outils analytics).
La checklist pour une PME qui veut se lancer:
- Identifier les 3 sources critiques (CRM, billing, marketing)
- Créer un compte Snowflake avec auto-suspend
- Connecter les sources via Fivetran (comptez 2 jours)
- Installer dbt Core et créer les 5 modèles essentiels (4 jours)
- Ajouter les tests de qualité automatiques (2 jours)
- Configurer les dashboards (3 jours)
- Former l’équipe à l’utilisation des données (1 jour)
Une fois la donnée propre et centralisée, les cas d’usage IA deviennent possibles. Segmentation client automatisée, prédiction de churn, recommandations personnalisées. Tout repose sur une base de données fiable.
FAQ
Est-ce que Fivetran est vraiment no-code?
Oui, complètement. Tu connectes tes sources via l’interface, tu autorises les accès API, et les données arrivent dans Snowflake automatiquement. Pas de code, pas de configuration complexe. Les connecteurs sont prêts à l’emploi.
Combien de temps pour former une équipe a dbt?
Si ton équipe connait déjà SQL, compte 2 jours pour les bases. Le principe est simple: tu écris du SQL dans des fichiers, dbt gère l’ordre d’exécution et les tests. La difficulté n’est pas technique, elle est dans la modélisation des données.
Snowflake ou BigQuery pour une PME?
Les deux sont excellents. Snowflake est plus simple à configurer (pas de projet Google Cloud à gérer), BigQuery est moins cher à très petit volume. Notre choix: Snowflake pour la simplicité et l’auto-suspend qui évite les surprises de facturation.
Peut-on faire la même chose avec Airbyte?
Oui, tout à fait. Airbyte a un catalogue de connecteurs encore plus large (600+). La différence: Airbyte demande plus de maintenance d’infrastructure, surtout en self-hosted. Pour une équipe lean, Fivetran est plus simple.
Quel est le vrai risque de vendor lock-in avec Fivetran?
C’est une question légitime. Si un connecteur Fivetran casse ou manque une fonctionnalité, tu es dépendant de l’éditeur pour le corriger. Avec Airbyte (open source), tu peux forker et corriger toi-même. Notre compromis: on accepte ce risque car Fivetran nous fait gagner beaucoup de temps, et on garde toujours la possibilité de migrer vers Airbyte si nécessaire.
Si tu veux suivre l’aventure, abonne-toi !
