Les scores calculés dans BigQuery n’aident pas vos équipes commerciales s’ils restent dans BigQuery. Les représentants travaillent dans Salesforce et HubSpot. Le reverse ETL est le pattern qui comble cet écart : lire depuis un modèle mart dbt, écrire vers des champs personnalisés du CRM.
On parle parfois de « data activation » — l’idée que les données d’entrepôt ne deviennent utiles que lorsqu’elles atteignent les systèmes opérationnels où les décisions sont prises.
L’architecture
La chaîne de synchronisation est simple :
- dbt construit le mart —
mrt__sales__lead_scoresavec le score, le niveau et l’horodatage les plus récents par lead - Le reverse ETL lit le mart — selon un planning, ou déclenché après les runs dbt
- Le reverse ETL écrit dans le CRM — mappe les colonnes vers des champs personnalisés dans Salesforce ou HubSpot
Le modèle mart synchronisé doit contenir au minimum :
lead_id(la clé primaire pour matcher les enregistrements CRM)lead__score(numérique)lead__score_tier(hot / warm / cold)lead__score_updated_at(horodatage — indique quand le score a été calculé)- Optionnellement :
lead__score_breakdownsi vous souhaitez afficher les scores par composante dans le CRM
Dans Salesforce, ces données mappent vers des champs personnalisés sur l’objet Lead : Lead_Score__c, Score_Tier__c, Score_Updated_At__c. Dans HubSpot, elles mappent vers des propriétés de contact personnalisées avec les mêmes noms.
Le paysage des outils en 2026
Trois outils dominent cet espace :
Hightouch — plus de 250 connecteurs de destination, fonctionnalités warehouse-native (transformations de calcul dans la plateforme), split tests et constructeur d’audiences par-dessus la synchronisation. Les tarifs démarrent autour de 350 $/mois. Meilleur choix si vos besoins d’activation vont au-delà de la simple synchronisation de champs.
Census (désormais Fivetran Activations) — Fivetran a acquis Census et l’a intégré à sa plateforme sous le nom « Fivetran Activations ». Le niveau gratuit permet de synchroniser jusqu’à 50 champs de destination, ce qui est suffisant pour le scoring de leads si vous ne construisez pas d’audiences complexes. Le modèle tarifaire a significativement changé avec l’acquisition — vérifiez les conditions actuelles avant de vous engager.
Polytomic — regroupe ETL et reverse ETL sur une seule plateforme, ce qui simplifie la facturation et élimine la duplication de connecteurs entre vos pipelines entrants et sortants. Bibliothèque de connecteurs plus restreinte qu’Hightouch, mais suffisante pour les destinations CRM standard.
Les trois peuvent lire depuis une table ou une vue BigQuery, ce qui signifie que votre mart dbt est une source valide sans configuration supplémentaire. Vous les pointez sur le modèle, mappez les colonnes vers les champs CRM, et configurez le planning de synchronisation.
Fréquence de synchronisation
La fréquence de synchronisation dépend de la rapidité à laquelle vos automatisations aval doivent réagir.
1 à 4 heures convient à la plupart des cas d’usage en sales operations. Les scores de leads changent en raison de signaux comportementaux (nouvelles pages vues, ouvertures d’e-mails, soumissions de formulaires), et ces signaux s’accumulent sur des heures, pas des minutes. Un score de 42 (warm) ce matin peut devenir 85 (hot) l’après-midi si un lead a passé du temps sur la page de tarification. La fenêtre de 1 à 4 heures permet aux représentants de voir un score mis à jour quand ils reprennent le travail après le déjeuner.
15 à 30 minutes est approprié si vous utilisez les changements de champs CRM pour déclencher des séquences d’automatisation marketing. Les workflows HubSpot et le Process Builder / Flow Salesforce peuvent se déclencher sur des changements de valeur de champ. Si « le niveau de score passe à hot » doit déclencher une inscription immédiate dans une séquence de prospection, vous avez besoin de cycles de synchronisation plus courts pour éviter que la séquence se déclenche des heures après l’événement déclencheur.
Le quasi temps réel (moins de 5 minutes) est rarement nécessaire pour le scoring de leads en particulier. Le scoring de leads est un modèle de comportement cumulatif — il n’a pas besoin d’être rafraîchi à l’instant où quelqu’un clique sur un lien. Réservez les synchronisations quasi temps réel pour les déclencheurs événementiels où le timing compte vraiment (par exemple, les signaux d’abandon de panier en e-commerce).
Automatisations CRM en aval
Faire entrer les scores dans le CRM est le prérequis. La valeur provient de ce que vous en faites.
Automatisations courantes une fois les scores intégrés au CRM :
Assignation automatique. Quand Score_Tier__c passe à « hot », assignez le lead à un représentant senior via les règles d’assignation de leads Salesforce. Supprimez le triage manuel du processus.
Notifications Slack. Un webhook du CRM vers Slack notifie immédiatement le représentant assigné quand un lead entre dans le niveau hot. Le représentant voit « Le lead X vient d’atteindre le niveau hot — il a consulté la page de tarification trois fois cette semaine » dans son Slack sans vérifier Salesforce.
Inscription à des séquences de nurturing. Quand Score_Tier__c passe à « warm », inscrivez le lead dans une séquence HubSpot ou une campagne e-mail marketing Salesforce. N’attendez pas qu’un représentant les ajoute manuellement.
Suppression. Les leads dans le niveau « cold » depuis plus de 60 jours sont supprimés de la prospection commerciale mais continuent à recevoir du contenu marketing. Quand leur score remonte (les signaux comportementaux reprennent), la suppression est levée.
Le pattern commun à tous ces cas : la logique de scoring vit dans dbt où elle est versionnée et testable. Le CRM réagit à la sortie. Aucun système n’a besoin de savoir comment le score a été calculé — seulement ce qu’il est et quand il a changé.
Ce qui n’appartient pas au reverse ETL
Le reverse ETL sert à pousser des attributs calculés dans l’entrepôt vers les systèmes opérationnels. Il n’est pas prévu pour :
Remplacer le CRM comme système de référence. Le CRM est propriétaire des données de contact et d’entreprise que vos représentants saisissent, qualifient et mettent à jour. Ne synchronisez pas en retour les attributs CRM que vous avez extraits vers l’entrepôt — cela crée des flux de données circulaires où vous ne pouvez plus déterminer quel système détient la version faisant autorité.
Les données d’événements à haute fréquence. Si vous voulez des événements de flux de clics dans le CRM, utilisez une CDP (Customer Data Platform) ou une intégration directe, pas le reverse ETL depuis l’entrepôt. Synchroniser des millions d’événements de BigQuery vers Salesforce est coûteux et lent.
Les attributs calculés qui appartiennent nativement au CRM. Si HubSpot peut calculer « jours depuis la dernière ouverture d’e-mail » à partir de ses propres données, laissez-le faire. Réservez le reverse ETL aux attributs qui n’existent que grâce à des jointures cross-système — le score d’entrepôt qui combine des données CRM avec des données GA4 que le CRM ne peut pas voir.
Connexion au DAG dbt
La synchronisation reverse ETL lit depuis le même modèle mart dbt que les autres consommateurs en aval. Le mart est l’interface — dbt calcule, le CRM consomme.
Cette séparation est importante pour la maintenabilité. Quand l’algorithme de scoring change, vous mettez à jour les modèles dbt. La configuration reverse ETL ne change pas — elle lit toujours depuis mrt__sales__lead_scores et écrit vers les mêmes champs CRM. L’automatisation CRM ne change pas non plus — elle réagit toujours aux valeurs du champ Score_Tier__c. Le changement est isolé dans la couche entrepôt.
Pour le pipeline de scoring complet qui produit le modèle mart synchronisé ici, voir Scoring de leads basé sur des règles dans dbt et BigQuery ML pour le scoring de leads.