Fivetran

Écrire un connecteur vers un outil de gestion commerciale prend deux jours. Le maintenir en prend beaucoup plus, mais de façon invisible : l’éditeur change un format de date, ajoute un champ obligatoire, modifie sa politique de limitation d’appels, et la synchronisation tombe un mardi matin sans prévenir.

Multipliez par quinze sources et vous obtenez la réalité de beaucoup d’équipes data : une personne à temps partiel dont le travail consiste à réparer ce que d’autres ont cassé. C’est cette charge que Fivetran fait disparaître, et c’est à cette aune qu’il faut évaluer son prix.

L’outil se connecte à une source, en extrait les données et les dépose dans votre entrepôt en reproduisant fidèlement la structure d’origine. Il ne les nettoie pas, ne les renomme pas et n’applique aucune règle métier. C’est délibéré.

La séparation compte : la copie est un problème d’ingénierie où l’on ne veut aucune créativité, la mise en forme est un problème métier où l’on en veut beaucoup. Les données arrivent brutes, versionnées, et la transformation se fait ensuite dans l’entrepôt avec dbt.

Quand la structure de la source évolue, l’outil s’adapte de lui-même. Une colonne ajoutée apparaît dans l’entrepôt, un type qui change est propagé. Vos modèles de transformation en aval, eux, ne s’adaptent pas tout seuls : c’est là que les tests de dbt prennent tout leur intérêt, en signalant la rupture avant que le tableau de bord n’affiche un chiffre faux.

Sur les bases de données, la capture des changements évite de relire l’ensemble à chaque cycle en s’appuyant sur le journal de transactions. C’est plus léger pour la source, et c’est aussi ce qui a le plus d’effet sur la facture.

Le compteur ne mesure ni le volume stocké, ni le nombre de connexions, mais le nombre de lignes distinctes modifiées, insérées ou supprimées au cours du mois. Une ligne touchée plusieurs fois dans le mois ne compte qu’une fois. Le modèle est cohérent, et il produit trois surprises régulières.

La première vient des sources qui ne savent pas dire ce qui a changé. Certaines interfaces ne proposent que de renvoyer la table entière. Chaque cycle marque alors toutes les lignes comme actives, même si rien n’a bougé. Une table de référence de deux cent mille lignes, parfaitement stable, coûte le prix de deux cent mille lignes actives.

La deuxième vient de la fréquence, mais pas comme on l’imagine. Synchroniser plus souvent ne multiplie pas la facture pour les sources capables de transmettre uniquement les modifications, puisque ce sont les mêmes lignes qui sont comptées. En revanche, sur une source qui renvoie tout, passer de la journée à l’heure multiplie mécaniquement. La règle est donc de régler la fréquence source par source, en fonction de ce que chacune sait faire, et non de façon uniforme.

La troisième vient des resynchronisations complètes. Un changement de configuration, une reprise après incident, une modification de la structure de la source peuvent déclencher une relecture intégrale de l’historique, qui apparaît sur la facture du mois. Ce n’est pas anormal, cela doit simplement être anticipé plutôt que découvert.

Le réflexe utile, avant tout engagement : mesurer sur un mois réel plutôt que d’estimer. Les projections faites à partir du volume de données se trompent presque toujours, parce que ce n’est pas le volume qui est facturé.

Quand vous avez beaucoup de sources logicielles différentes et peu de monde pour s’en occuper. C’est le cas type, et le calcul est presque toujours favorable si l’on compte honnêtement le temps d’ingénierie économisé.

Quand la fiabilité prime sur le coût unitaire, parce qu’une donnée manquante coûte plus cher qu’une ligne de facture.

Et quand vous voulez avancer vite. Une source branchée en une heure change le rythme d’un projet.

Quand il vaut mieux autre chose

Avec deux ou trois sources aux interfaces stables, un script maison bien écrit et orchestré par Airflow coûtera moins cher et vous appartiendra.

Avec de très gros volumes de lignes de faible valeur unitaire, journaux techniques ou données de capteurs, le modèle de facturation joue contre vous.

Et si la source est un développement interne, il n’y a pas de connecteur tout fait : autant écrire directement le chargement dans votre entrepôt.

Des alternatives à code ouvert existent, auto-hébergeables, avec un coût déplacé du logiciel vers l’exploitation. Nous les regardons quand le budget est serré et qu’une compétence technique existe en interne.

Nous cadrons le périmètre avant l’abonnement : quelles sources justifient un connecteur managé, lesquelles se traitent autrement, et quelle facture réelle attendre une fois la mesure faite plutôt que l’estimation.

Nous construisons la chaîne complète en aval, parce qu’un chargement sans transformation ne sert à rien : modèles et tests avec dbt, orchestration, puis restitution.

Nous intervenons enfin sur les factures qui ont dérapé. Le diagnostic porte presque toujours sur les mêmes points : sources en relecture intégrale qu’on pouvait passer en mode incrémental, fréquences réglées uniformément sans regarder ce que chaque source sait faire, et connecteurs actifs pour des données que plus personne n’utilise.

Comment Fivetran est-il facturé ?

Au nombre de lignes distinctes modifiées, insérées ou supprimées au cours du mois, et non au volume stocké ni au nombre de connexions. Une ligne touchée plusieurs fois dans le mois n’est comptée qu’une fois. Les projections faites à partir du volume de données se trompent donc presque toujours : avant tout engagement, il faut mesurer sur un mois réel plutôt qu’estimer.

Pourquoi ma facture Fivetran augmente-t-elle sans que mes données changent ?

Trois causes reviennent. Les sources incapables d’indiquer ce qui a changé, dont l’interface ne propose que de renvoyer la table entière : chaque cycle marque alors toutes les lignes comme actives même si rien n’a bougé. Une fréquence réglée uniformément sans tenir compte de ce que chaque source sait faire, ce qui multiplie la facture sur ces sources-là. Et les resynchronisations complètes déclenchées par un changement de configuration, une reprise après incident ou une évolution de la structure de la source.

Fivetran transforme-t-il les données ?

Non, et c’est délibéré. L’outil extrait et charge en reproduisant fidèlement la structure d’origine, sans nettoyer, renommer ni appliquer de règle métier. La copie est un problème d’ingénierie où l’on ne veut aucune créativité, la mise en forme est un problème métier où l’on en veut beaucoup. La transformation se fait ensuite dans l’entrepôt, généralement avec dbt, dont les tests signalent les ruptures quand la structure de la source évolue.

Faut-il payer Fivetran ou écrire ses propres connecteurs ?

Cela dépend du nombre de sources et de la stabilité de leurs interfaces. Avec beaucoup de sources logicielles différentes et peu de monde pour s’en occuper, le calcul est presque toujours favorable si l’on compte honnêtement le temps d’ingénierie économisé, car maintenir un connecteur coûte bien plus que l’écrire. Avec deux ou trois sources stables, un script maison orchestré par Airflow coûtera moins cher et vous appartiendra.

Quand Fivetran est-il déconseillé ?

Avec de très gros volumes de lignes de faible valeur unitaire, journaux techniques ou données de capteurs, le modèle de facturation joue contre vous. Avec une source développée en interne, il n’existe pas de connecteur tout fait et autant écrire directement le chargement. Et quand le budget est serré alors qu’une compétence technique existe en interne, les alternatives à code ouvert auto-hébergeables méritent d’être comparées, le coût étant déplacé du logiciel vers l’exploitation.

• dbt, la transformation qui vient juste après le chargement.
• Airflow, pour orchestrer ce qui n’est pas couvert par un connecteur.
• Talend, l’approche opposée, complète et à installer.
• Panorama des technologies sur lesquelles nous intervenons.

Sources — documentation officielle de l’éditeur, consultée le 22 août 2026 : lignes actives mensuelles.