Le reverse ETL est le pattern consistant à déplacer des données hors de votre entrepôt de données vers des outils opérationnels tels que le CRM, les plateformes publicitaires et l’engagement commercial. C’est l’inverse de l’ETL traditionnel, qui déplace des données vers l’entrepôt pour analyse. Le reverse ETL est ce qui rend un entrepôt utilisable comme système de référence pour le go-to-market.
Pourquoi il existe
Pendant la majeure partie de l’histoire de l’analytique, l’entrepôt était une impasse. Les ingénieurs data chargeaient le comportement client, l’usage produit et les revenus dans Snowflake ou BigQuery, les analystes construisaient des tableaux de bord, et les outils opérationnels (Salesforce, HubSpot, Marketo) vivaient dans un monde séparé. Quand le marketing voulait « les utilisateurs qui se sont connectés trois fois la semaine dernière », quelqu’un devait écrire une intégration sur mesure ou attendre un CSV.
Le reverse ETL ferme cette boucle. Des outils comme Hightouch, Census et Polytomic permettent d’écrire une requête SQL une fois contre l’entrepôt, de définir une synchronisation vers une destination, et de faire apparaître les données sous forme de champs dans Salesforce ou d’audiences dans Facebook en quelques minutes.
Quand il compte
Le reverse ETL est le bon pattern quand trois conditions sont réunies : les données sur lesquelles vous souhaitez agir se trouvent déjà dans l’entrepôt et sont difficiles à recalculer ailleurs ; l’outil de destination a une API utilisable ou un connecteur natif ; et l’équipe qui opère les synchronisations est suffisamment data-literate pour gérer des modèles SQL.
Les cas d’usage classiques sont les leads qualifiés par le produit (synchronisation des signaux d’usage produit vers le CRM comme scores de leads), le ciblage d’audience (envoi de segments de l’entrepôt vers les plateformes publicitaires) et la santé client (synchronisation des données support, facturation et produit vers les outils CSM).
Ce qu’il remplace
Le reverse ETL concurrence trois patterns plus anciens : les intégrations API écrites à la main (lentes, fragiles), les iPaaS comme Zapier et Workato (bons pour les workflows simples, coûteux à grande échelle), et les CDP packagés (plus contraignants, moins flexibles). Le pattern CDP composable est essentiellement du reverse ETL plus un modèle d’identité.
Pièges courants
- Synchroniser le mauvais grain. Envoyer chaque événement produit à Salesforce le détruira. Agréger au bon grain (compte-semaine, utilisateur-jour) avant de synchroniser.
- Laisser les modèles dériver. Une synchronisation reverse ETL dépend d’un modèle dbt en amont. Quand le modèle change, la destination se brise silencieusement. Ajoutez des tests et un ownership.
- Activer avant le consentement. Le reverse ETL respecte le consentement que l’entrepôt connaît. Si le consentement n’est pas modélisé dans l’entrepôt, vous envoyez des données non conformes.
Références
- Entrepôt de données vs CDP — le choix d’architecture
- CDP — le pattern alternatif
- Stack RevOps — où s’intègre le reverse ETL