Fivetran est une plateforme d’ELT managé qui réplique des données depuis des applications, bases et API vers un cloud data warehouse. Son intérêt se mesure moins à la rapidité de paramétrage qu’à la maintenance transférée à l’éditeur, au volume réellement synchronisé et à la capacité de vos équipes à réconcilier les données chargées avec leurs sources.
En bref
- Fivetran automatise l’extraction et le chargement, tandis que les transformations métier restent habituellement exécutées dans l’entrepôt.
- Les connecteurs Fivetran couvrent des applications SaaS, des bases transactionnelles, des fichiers, des API et certaines sources événementielles.
- La synchronisation automatique s’appuie sur des chargements initiaux, puis sur des mécanismes incrémentaux dont le comportement dépend de la source.
- Les tarifs Fivetran reposent sur l’activité de données synchronisées et demandent une simulation sur plusieurs mois avant tout engagement.
- Dans une migration de données décisionnelles, Fivetran ne remplace ni la recette, ni la documentation des règles de gestion, ni la validation des écarts par les métiers.
Cet article s’adresse aux responsables BI et aux chefs de projet qui examinent Fivetran comme solution d’intégration de données pour remplacer ou compléter des flux existants. Il ne traite ni de la protection des données personnelles, qui relève de votre DPO, ni du paramétrage détaillé de plateformes cloud hors du périmètre décisionnel.
Comment fonctionne l’ELT managé de Fivetran entre source et entrepôt
Fivetran applique une mécanique d’ELT, pour Extract, Load, Transform. L’outil lit les données d’une source, les charge dans une destination analytique, puis laisse les transformations s’exécuter dans l’entrepôt. Cette séparation mérite d’être posée dès le départ, car elle change la répartition des responsabilités par rapport à un ETL historique exécuté dans Informatica PowerCenter, Talend ou un moteur propriétaire.
Le premier chargement récupère le périmètre sélectionné dans la source. Pour une application SaaS, il s’agit souvent des objets exposés par l’API, avec leurs colonnes et leurs relations. Pour une base de production, l’extraction peut s’appuyer sur des journaux de transactions ou sur une lecture incrémentale fondée sur une clé et une date de mise à jour. Le mode retenu dépend du connecteur, des droits accordés et des capacités de la source.
Après ce premier chargement, Fivetran exécute une synchronisation automatique. Le principe paraît direct, mais il ne faut pas assimiler cette synchronisation à un miroir exact de la production. Les suppressions, les retards de disponibilité d’API, les modifications de schéma et les limites de débit peuvent produire des décalages temporaires. Dans un dispositif de pilotage financier, ce point doit être mesuré avant la bascule d’un tableau de bord.
La documentation officielle décrit les connecteurs, les fréquences disponibles et les comportements de synchronisation dans son catalogue de connecteurs Fivetran, consulté le 15 mars 2026. Le catalogue est utile pour vérifier qu’une source est bien couverte, mais il ne remplace pas une lecture du détail technique du connecteur concerné. Deux connecteurs peuvent porter des noms proches tout en n’exposant pas les mêmes objets ou la même fréquence de mise à jour.
Le chargement n’efface pas les règles de gestion existantes
Un pipeline de données Fivetran charge des tables. Il ne reconstitue pas automatiquement les règles métier qui étaient enfouies dans un univers BusinessObjects, une requête Web Intelligence, une procédure stockée ou une étape Talend. Un indicateur de chiffre d’affaires peut dépendre d’exclusions de statuts, d’avoirs, de dates comptables et de conventions de change. Ces règles doivent être reprises dans le modèle de transformation ou dans le modèle sémantique de la cible.
Cette distinction est décisive lors d’une migration de données. Si les équipes chargent les transactions de vente dans Snowflake ou BigQuery sans inventorier les filtres du socle précédent, le nouveau tableau de bord peut produire un écart cohérent techniquement mais inacceptable pour la direction financière. L’écart n’est pas une anomalie tant qu’il n’est pas expliqué. Il devient un motif de refus lorsqu’il apparaît à quelques jours de la bascule.
Fivetran propose également l’orchestration de transformations, notamment avec dbt, selon la documentation produit Transformations, consultée le 15 mars 2026. Cela permet de déclencher des modèles après le chargement. La plateforme ne décide toutefois pas de la formule d’une mesure, du niveau de granularité d’un fait ou du traitement d’une dimension à évolution lente. Ces choix restent dans le périmètre du projet décisionnel.
Avant d’ouvrir un connecteur en production, documentez les tables attendues, le mode d’incrément, la fréquence cible, la fenêtre de retard acceptable et le propriétaire métier du contrôle. Ce registre paraît administratif. Il évite pourtant de confondre un flux techniquement vert avec une donnée utilisable pour le pilotage.
Quels connecteurs Fivetran vérifier avant de remplacer vos flux existants
Les connecteurs Fivetran constituent le cœur du produit. Ils couvrent des applications métier en SaaS, des bases relationnelles, des entrepôts, des systèmes de fichiers, des API et certaines plateformes de publicité ou de paiement. L’intérêt pour une équipe décisionnelle est de ne pas développer et maintenir chaque extraction à partir de zéro. La contrepartie est une dépendance au périmètre réellement couvert par le connecteur éditeur.
La vérification doit partir du parc existant, pas de la liste marketing des sources compatibles. Un connecteur CRM peut récupérer les comptes, opportunités et activités. Il peut ne pas restituer un champ personnalisé, un historique particulier ou une relation utilisée par un rapport de direction. Un connecteur de base PostgreSQL peut fonctionner avec la réplication logique, mais son activation peut impliquer des prérequis sur le serveur source que l’équipe d’exploitation doit valider.
| Famille de source | Mécanisme à contrôler | Risque pour le reporting | Preuve à demander avant bascule |
|---|---|---|---|
| Application SaaS | API, quotas, objets et champs disponibles | Objets absents ou délai entre saisie et extraction | Inventaire des objets et test sur une période clôturée |
| Base transactionnelle | Journalisation, clé primaire et traitement des suppressions | Doublons, lignes manquantes ou historique incomplet | Comptage source-cible et contrôle des clés |
| Fichier ou stockage objet | Convention de nommage, format et dépôt | Chargement du mauvais fichier ou rupture de schéma | Journal de réception et contrôle de structure |
| API interne | Pagination, authentification et contrat d’interface | Extraction partielle lors d’un changement d’API | Jeu de tests et alerte sur les réponses en erreur |
Ce tableau est construit à partir des catégories de connecteurs et des exigences de configuration décrites dans la documentation Fivetran, consultée le 15 mars 2026. Il ne constitue pas une garantie de compatibilité. La documentation détaillée de chaque connecteur doit être conservée dans le dossier de conception, avec la version et la date de consultation.
Les évolutions de schéma doivent être surveillées, pas seulement acceptées
Fivetran détecte et propage des évolutions de schéma selon les paramètres du connecteur et de la destination. C’est utile lorsqu’un éditeur SaaS ajoute une colonne ou modifie un objet. Cette capacité ne dispense pas de surveiller l’effet du changement sur les modèles aval. Une colonne renommée, une valeur de statut ajoutée ou une relation devenue facultative peut modifier un calcul sans provoquer d’échec visible.
Les flux historiques contiennent souvent des transformations implicites. Un mapping Informatica peut convertir une date, rejeter une ligne ou alimenter une table d’erreurs. Un job Talend peut filtrer les entités inactives. La reprise dans Fivetran exige de distinguer ce qui relève de l’extraction brute, ce qui relève du contrôle de qualité et ce qui relève d’une règle de gestion. Reprendre l’ensemble dans un seul modèle dbt rend le diagnostic plus difficile.
Sur un parc décisionnel déjà stabilisé, le bon point de départ est un échantillon de sources critiques. Sélectionnez une source de ventes, une source de référentiel clients et une source de comptabilité, puis comparez les volumes sur plusieurs clôtures. Si les objets attendus ne sont pas tous disponibles ou si les historiques divergent, la migration de données doit être suspendue sur ce périmètre. Changer d’outil ne corrige pas une définition métier incomplète.
Comment organiser un pipeline de données Fivetran sans déplacer la dette décisionnelle
Un pipeline de données Fivetran correctement paramétré commence par une séparation nette entre les couches. La couche d’atterrissage reçoit les données répliquées. La couche de préparation applique les corrections techniques documentées. La couche métier porte les mesures et dimensions validées. Sans cette séparation, les équipes finissent par intégrer des calculs métier dans des tables de chargement, puis ne savent plus expliquer l’origine d’un chiffre.
Le chargement brut doit rester aussi proche que possible de ce que la source fournit. Cela donne un point d’appui pour les réconciliations. Si une facture est présente dans la table source et absente du modèle métier, le projet doit pouvoir localiser l’étape qui l’a filtrée. À l’inverse, si l’on transforme la donnée dès l’extraction sans conserver le niveau brut, chaque écart devient une enquête coûteuse.
La documentation Fivetran indique que les transformations peuvent être exécutées au sein du flux à partir de modèles dbt, dans la page dbt Core transformations, consultée le 15 mars 2026. Cela répond au besoin d’orchestration. Cela ne remplace pas un protocole de recette avec des critères d’acceptation, des jeux de données de référence et une décision explicite sur les écarts.
La recette doit comparer des périmètres identiques
La comparaison entre ancien et nouveau socle doit porter sur la même période, les mêmes filtres et le même niveau de granularité. Comparer un total mensuel issu d’un rapport Web Intelligence avec une table de transactions chargée le lendemain n’a pas de valeur de recette. Il faut d’abord vérifier la date d’arrêté, le fuseau horaire, les annulations, les suppressions et les statuts exclus.
Une méthode praticable consiste à définir trois contrôles. Le premier compare le nombre de lignes par source et par période. Le deuxième compare les montants agrégés selon les axes utilisés par le pilotage. Le troisième vérifie un échantillon de clés métier, par exemple des commandes, factures ou comptes clients. Les anomalies sont classées entre écart de chargement, différence de transformation et différence de définition.
- Fixez une date de référence identique entre la source historique et la cible avant chaque série de contrôles.
- Conservez les requêtes de comparaison, leurs résultats et les décisions de correction dans un dossier accessible au projet.
- Faites valider les écarts métier par le propriétaire fonctionnel, pas uniquement par l’équipe technique.
- Prévoyez un double run sur les rapports de direction lorsque les règles de calcul ont été déplacées.
Le double run ne signifie pas que les deux rapports doivent afficher les mêmes chiffres sans aucune variation. Il sert à qualifier les écarts, à déterminer leur origine et à accepter formellement ceux qui résultent d’une nouvelle règle ou d’une correction de qualité. Une tolérance sans explication ne protège pas la bascule.
La dette décisionnelle se déplace lorsque les connecteurs sont activés avant que les définitions ne soient reprises. Dans ce cas, l’outillage est récent, mais les chiffres restent contestés. Le chantier doit donc être piloté par les contrôles attendus par les utilisateurs, et non par le seul nombre de flux mis en production.
Comment lire les tarifs Fivetran et construire une estimation défendable
Les tarifs Fivetran ne se lisent pas comme une licence fixe par utilisateur. La grille commerciale repose sur l’activité de données synchronisées, avec des modalités qui peuvent évoluer selon l’offre, les fonctionnalités et le niveau de service. La page de tarification Fivetran, consultée le 15 mars 2026, présente les offres et renvoie vers un calculateur ou une estimation adaptée au volume.
La documentation tarifaire mentionne également un essai gratuit de quatorze jours sur cette même page, relevé le 15 mars 2026. Cet essai est utile pour mesurer le comportement de quelques connecteurs. Il ne permet pas, à lui seul, de prévoir le coût annuel si les données synchronisées pendant le test ne représentent pas les clôtures, les pics d’activité ou l’historique à reprendre.
Le point qui mérite un arbitrage est la définition de l’activité facturable. Dans un système de ventes, une commande peut être créée, modifiée plusieurs fois, annulée, puis complétée par des éléments de livraison et de facture. Une estimation fondée sur le seul nombre de commandes initiales sous-estime potentiellement le volume traité. Le même sujet apparaît avec les objets de CRM modifiés quotidiennement par des workflows.
Un calcul de scénario vaut mieux qu’un budget figé
Un scénario de chiffrage doit isoler les sources, les tables, la fréquence et la période de mesure. Prenons un périmètre d’étude composé de trois flux, un CRM, une plateforme de paiement et une base de commandes. Le calcul ne doit pas reprendre un montant théorique sans données de volumétrie. Il doit mesurer les lignes créées et modifiées sur une période représentative, puis tester les conséquences d’une fréquence plus élevée.
Le tableau suivant ne donne pas un prix public, car les modalités tarifaires et les remises contractuelles ne peuvent pas être supposées. Il fournit une méthode de préparation du dossier avant d’utiliser le calculateur Fivetran ou de demander une proposition commerciale.
| Source analysée | Mesure mensuelle à relever | Facteur de variation à tester | Élément exclu du coût de plateforme |
|---|---|---|---|
| CRM | Créations et modifications d’objets actifs | Automatisations et campagnes commerciales | Conception des modèles métier |
| Paiement | Transactions, remboursements et mises à jour | Pic saisonnier et corrections comptables | Recette financière |
| Base de commandes | Lignes créées, modifiées et supprimées | Fréquence de synchronisation choisie | Administration de la base source |
| Historique initial | Volume à reprendre avant exploitation | Rechargements et tests de reprise | Nettoyage métier de l’historique |
Le coût global ne se limite pas aux tarifs Fivetran. Il faut distinguer la plateforme d’intégration, la consommation du cloud data warehouse, la construction des transformations, la recette, la reprise des droits et l’exploitation. Mélanger ces postes dans une seule ligne de budget masque l’origine d’un dépassement et rend l’arbitrage plus difficile.
Fivetran convient moins bien lorsque le volume de changements est instable, que la source impose une logique d’extraction sur mesure ou que les règles d’intégration sont principalement procédurales. Dans ce cas, un flux existant documenté peut coûter moins à maintenir qu’une reprise qui impose de reconstruire les contrôles. Le choix inverse devient défendable lorsque la maintenance de nombreux extracteurs maison absorbe une charge récurrente clairement mesurée.
Dans quels cas Fivetran aide une migration de données et dans quels cas il faut différer
Fivetran peut accélérer une migration de données lorsque les sources sont standardisées, que les objets nécessaires sont couverts par les connecteurs et que la destination analytique est déjà choisie. Son apport porte sur l’extraction, le chargement, la surveillance opérationnelle et l’adaptation aux évolutions de certaines API. Il ne transforme pas un parc de rapports mal documenté en modèle décisionnel cohérent.
Le premier inventaire doit porter sur les flux réellement utilisés. Un socle ancien peut contenir des jobs exécutés chaque nuit sans alimenter aucun rapport consulté. À l’inverse, un rapport peu ouvert peut être utilisé pour une clôture trimestrielle ou un contrôle réglementaire. Les journaux d’exécution, les statistiques de consultation et les entretiens avec les propriétaires métier doivent être rapprochés avant toute décision de reprise.
Les critères qui justifient un pilote limité
Un pilote est pertinent lorsque l’organisation peut isoler un périmètre contrôlable. Il peut inclure une application SaaS connue, une destination déjà exploitée et un tableau de bord dont les mesures sont documentées. Le pilote doit inclure la recette, pas seulement l’activation technique du connecteur. Un chargement réussi prouve que le flux fonctionne. Il ne prouve pas que le résultat est acceptable pour le pilotage.
La documentation Fivetran fournit des informations sur la surveillance des synchronisations et les états de connecteurs dans sa rubrique Fivetran Dashboard, consultée le 15 mars 2026. Les journaux d’exécution et les alertes doivent être intégrés au processus d’exploitation. Une alerte de retard n’a de valeur que si une personne identifiée sait déterminer l’impact sur les tableaux de bord concernés.
Un pilote doit aussi vérifier les conditions de retour arrière. Si le nouveau flux charge des données incomplètes pendant une clôture, quel rapport reste la référence temporaire, qui publie la décision et comment les utilisateurs sont-ils informés ? Ces éléments relèvent du pilotage de la bascule. Ils ne sont pas fournis par le connecteur.
Les situations où la migration doit attendre
La migration doit être différée lorsque les règles de gestion restent inconnues, que la source n’expose pas les données nécessaires ou que les propriétaires métier ne peuvent pas participer à la recette. Elle doit également attendre si les coûts de consommation ne sont pas estimés sur une période représentative. Un contrat fondé sur une volumétrie sous-évaluée crée un problème budgétaire qui n’a rien de technique.
Une automatisation ETL peut être utile pour des flux spécifiques, mais elle doit être évaluée face à l’ELT managé sur les mêmes critères. Comparez la charge de maintenance, les mécanismes de reprise sur incident, la couverture de la source, les coûts de licence et la capacité à tracer un écart jusqu’à son origine. Le débat ne porte pas sur une opposition théorique entre ETL et ELT. Il porte sur les flux que vous devez exploiter et justifier.
Fivetran n’est donc pas une réponse automatique à tous les besoins d’intégration de données. Avant toute décision, sortez douze mois de volumétrie pour les sources candidates, recensez les règles métier portées par les flux existants et préparez un jeu de contrôles de recette. C’est ce dossier, davantage que la démonstration d’un connecteur, qui permet de défendre un arbitrage devant la direction.
Quelle différence entre Fivetran et un ETL classique ?
Fivetran applique principalement une logique ELT. Les données sont extraites puis chargées dans la destination analytique, et les transformations sont réalisées ensuite dans l’entrepôt, souvent avec des modèles dbt. Un ETL historique transforme plus fréquemment les données avant leur chargement.
Les connecteurs Fivetran couvrent-ils toutes les données d’une application SaaS ?
Non. La couverture dépend de l’API, des objets exposés, des champs accessibles et des limites définies par l’éditeur de la source. Le détail du connecteur doit être vérifié avant de valider un périmètre de migration.
Comment sont calculés les tarifs Fivetran ?
La tarification dépend notamment de l’activité de données synchronisées et de l’offre retenue. La page officielle de tarification, consultée le 15 mars 2026, doit être rapprochée d’une mesure représentative des créations et modifications des sources concernées.
Fivetran garantit-il que les chiffres du nouveau reporting seront identiques à ceux de l’ancien ?
Non. Les écarts doivent être anticipés, mesurés et expliqués lors de la recette. Ils peuvent provenir des filtres historiques, des horaires de chargement, des transformations, des données supprimées ou des définitions métier reprises différemment.
Le dossier complet Chantiers de migration : chiffrer la charge et sécuriser la bascule
