Les données CRM sont souvent très demandées et peu fiables dans les entrepôts. Les enregistrements CRM sont mutables, les relations sont complexes, et la couche d’extraction introduit ses propres particularités. Ces défis façonnent chaque décision de modélisation en aval.
La mutabilité est le problème central
La plupart des données de warehouse arrivent sous forme d’événements immuables. Une page vue s’est produite. Une transaction s’est terminée. Vous l’ajoutez et passez à autre chose. Les données CRM ne fonctionnent pas ainsi. Une opportunité change de stade cinq fois avant de se conclure. L’email d’un contact est mis à jour. Le montant d’un deal est révisé la veille de la clôture. Chaque enregistrement est une cible mobile.
Cela signifie que votre warehouse n’a jamais une version “finale” d’un enregistrement CRM tant que l’enregistrement n’est pas réellement clôturé ou archivé. Un snapshot du pipeline pris à 9h peut montrer des données différentes de celui pris à 15h pour le même enregistrement. Si vos parties prenantes demandent “quelle était la valeur du pipeline mardi dernier ?”, vous avez besoin d’un suivi historique pour répondre, pas seulement de l’état actuel.
La mutabilité signifie également que l’extraction incrémentale est plus difficile. Vous ne pouvez pas simplement chercher de nouveaux enregistrements — vous devez détecter les changements dans les enregistrements existants. C’est ce que fait SystemModStamp dans Salesforce et ce que HubSpot approxime via une combinaison de mécanismes.
Extraction par API vs CDC
Contrairement aux sources de bases de données où vous pouvez vous connecter à un binlog pour la capture de données de changement (CDC), les systèmes CRM exposent les données via des API. Cela crée un modèle d’extraction fondamentalement différent.
Le connecteur Salesforce de Fivetran interroge en utilisant le champ SystemModStamp pour les synchronisations incrémentales. Chaque enregistrement Salesforce dispose de ce champ, qui se met à jour chaque fois que l’enregistrement est modifié via l’interface utilisateur, l’API ou une automatisation. Le connecteur interroge pour les enregistrements où SystemModStamp > last_sync_time pour trouver ce qui a changé.
HubSpot n’a pas du tout de CDC véritable. Fivetran utilise un mélange de webhooks pour les suppressions, d’appels API quotidiens et d’inférence pour l’approximer. Cela signifie que les données HubSpot dans votre warehouse peuvent prendre plus de retard sur la réalité que les données Salesforce, et le retard varie selon le type d’objet et la configuration de synchronisation.
L’impact pratique : ne supposez pas que vos données CRM reflètent un état en temps réel. Intégrez des attentes de latence lors de la conception des tableaux de bord et de la logique de reporting.
Suppressions logicielles
Lorsqu’un enregistrement CRM est supprimé, il ne disparaît pas de votre warehouse. Fivetran marque les enregistrements supprimés avec _fivetran_deleted = TRUE plutôt que de les supprimer. C’est délibéré — la suppression définitive du warehouse ferait perdre les pistes d’audit et casserait les analyses historiques.
Mais les délais de suppression diffèrent selon le système :
- Salesforce supprime définitivement les enregistrements 15 jours après leur passage dans la Corbeille. Après cela, même Fivetran ne peut plus les voir.
- HubSpot conserve les enregistrements supprimés pendant 90 jours avant la suppression permanente.
Vos modèles de base doivent filtrer les enregistrements à suppression logicielle de manière cohérente :
SELECT id AS opportunity__id, name AS opportunity__name, stage_name AS opportunity__stage, amount AS opportunity__amountFROM {{ source('salesforce', 'opportunity') }}WHERE NOT _fivetran_deletedCe filtre appartient à chaque modèle de base pour chaque table source CRM. Le manquer dans un seul modèle, et vous aurez des enregistrements fantômes polluant les métriques en aval — des deals clôturés-perdus apparaissant dans les comptages de pipeline, des contacts désactivés s’affichant dans les rapports d’utilisateurs actifs.
Pour l’analyse historique, vous pouvez vouloir un modèle séparé qui inclut les enregistrements supprimés avec un indicateur. Mais la valeur par défaut devrait toujours être de les exclure.
Angles morts des champs de formule
Celui-ci prend les équipes par surprise. Dans Salesforce, les changements de champs de formule ne mettent pas à jour SystemModStamp. Un champ de formule est calculé dynamiquement — il ne “change” pas dans la base de données ; il se recalcule à l’accès. Mais puisque SystemModStamp est ce que Fivetran utilise pour détecter les changements, les valeurs des champs de formule dans votre warehouse peuvent être obsolètes.
Exemple : vous avez un champ de formule days_since_last_activity sur l’objet Account. Le last_activity_date sous-jacent change, la formule se recalcule dans l’interface Salesforce, mais SystemModStamp ne se met pas à jour. La synchronisation incrémentale de Fivetran le manque. Votre warehouse affiche la valeur d’hier.
Le package dbt_salesforce_formula_utils existe spécifiquement pour ce problème. Il recalcule la logique des champs de formule dans votre projet dbt plutôt que de s’appuyer sur les valeurs extraites. C’est l’approche recommandée pour tout champ de formule utilisé dans le reporting.
Alternativement, vous pouvez configurer Fivetran pour exécuter des synchronisations complètes périodiques pour les objets avec des champs de formule critiques. Le compromis est une utilisation plus élevée de l’API et des temps de synchronisation plus longs, mais une exactitude garantie.
Limites de débit
Les API CRM imposent des limites de débit strictes qui contraignent la quantité de données que vous pouvez extraire et la fréquence à laquelle vous pouvez le faire.
Salesforce autorise 100 000 requêtes API par 24 heures sur l’édition Enterprise, plus 1 000 par licence utilisateur. Une grande organisation avec 200 utilisateurs obtient 300 000 requêtes/jour. Cela semble généreux jusqu’à ce que vous teniez compte du fait que chaque intégration — automatisation du marketing, synchronisation des données, applications tierces — puise dans le même pool. Surveillez votre utilisation des API dans Configuration > Présentation du système ; si vous atteignez régulièrement 80%+, la fréquence d’extraction en souffrira.
HubSpot est limité à 190 requêtes par 10 secondes, avec l’API de recherche CRM limitée à 10 000 résultats par requête. Pour les grandes instances HubSpot (100k+ contacts), cela signifie que l’extraction prend plus de temps parce que le connecteur doit paginer à travers les résultats en petits lots.
Ces limites affectent :
- La fréquence de synchronisation : la fréquence à laquelle vous pouvez extraire des données fraîches
- Le coût des actualisations complètes : une re-synchronisation complète d’une grande organisation Salesforce peut consommer une portion significative de votre budget d’API quotidien
- Les intégrations concurrentes : chaque outil accédant à l’API rivalise pour le même pool de limite de débit
Lors de la conception de votre calendrier d’extraction, tenez compte de tous les consommateurs d’API, pas seulement de votre pipeline de données. Un outil d’automatisation du marketing qui déclenche 50 000 appels d’API lors du lancement d’une campagne peut priver votre synchronisation Fivetran si elle partage la même limite de débit.
Implications pour l’architecture
Ces défis — mutabilité, extraction par API, suppressions logicielles, champs de formule, limites de débit — influencent chaque décision de conception en aval :
- Utilisez les snapshots SCD Type 2 pour suivre l’état historique, parce que l’enregistrement actuel n’est pas suffisant
- Filtrez
_fivetran_deleteddans chaque modèle de base, parce que les suppressions logicielles sont universelles - Ne faites pas confiance aux valeurs de champs de formule issues de l’extraction ; recalculez-les dans dbt
- Concevez votre calendrier de synchronisation en tenant compte des limites de débit, et surveillez l’utilisation des API sur tous les consommateurs
- Construisez des tableaux de bord qui reconnaissent la latence des données plutôt que d’impliquer une exactitude en temps réel
Les données CRM nécessitent une ingénierie plus défensive que la plupart des sources pour produire des métriques de pipeline et de clients dignes de confiance.