Synchroniser un CRM (HubSpot ou Pipedrive) avec n8n : le guide complet

Les intégrations natives de HubSpot et Pipedrive avec vos autres outils s'arrêtent presque toujours au même endroit : un déclencheur simple, une action simple, sans logique conditionnelle, sans déduplication fine, sans possibilité de croiser plusieurs sources avant d'écrire dans le CRM. Dès qu'un besoin sort du cas standard — synchroniser un CRM avec un outil de facturation, enrichir un contact avant de le créer, router un deal selon des règles métier précises — n8n devient la brique qui comble ce vide, sans écrire un backend dédié.

Pourquoi passer par n8n plutôt que les intégrations natives

Les marketplaces d'intégrations natives (HubSpot App Marketplace, Pipedrive Marketplace) couvrent bien les cas génériques : synchroniser avec Gmail, Slack, un formulaire standard. Elles deviennent limitantes dès que vous avez besoin de :

• Logique conditionnelle avant l'écriture (créer un deal seulement si le lead dépasse un score, router vers un pipeline différent selon la source) ;
• Croisement de plusieurs sources avant de toucher au CRM (enrichir un contact avec des données Clearbit ou LinkedIn avant création) ;
• Déduplication précise, au-delà d'une simple correspondance sur l'email exact ;
• Historisation ou journalisation des synchronisations, pour du debug ou un audit ultérieur ;
• Synchronisation bidirectionnelle entre deux systèmes qui ne se parlent pas nativement.

n8n devient alors la couche d'orchestration : un point central qui reçoit les événements, applique les règles, et écrit dans les bons systèmes dans le bon ordre — exactement le rôle qu'il joue déjà dans le pipeline de qualification de leads entrants par IA, où le scoring précède le routage vers le CRM.

Authentification : API Key ou OAuth2 selon le CRM

Le choix d'authentification diffère sensiblement entre les deux CRM.

Pipedrive reste simple : un API Token personnel, généré dans les paramètres du compte, suffit pour la quasi-totalité des workflows de synchronisation interne. Il se configure dans n8n comme credential de type Pipedrive API, sans écran de consentement OAuth à gérer.

HubSpot propose deux voies :

• Une Private App Token : créée depuis les paramètres du compte HubSpot (Settings → Integrations → Private Apps), avec des scopes (permissions) choisis précisément — crm.objects.contacts.write, crm.objects.deals.read, etc. C'est le choix le plus simple pour un usage interne à un seul compte HubSpot, sans écran de connexion tiers.
• OAuth2 : nécessaire si vous développez une intégration destinée à plusieurs comptes HubSpot différents (une app publiée sur le marketplace, par exemple), ou si votre politique de sécurité interne l'impose. n8n gère le flow OAuth2 HubSpot nativement via son node dédié, avec rafraîchissement automatique du token.

Pour un pipeline interne à une seule entreprise — le cas le plus courant — la Private App Token côté HubSpot et l'API Token côté Pipedrive couvrent l'immense majorité des besoins, sans la complexité d'un flow OAuth2 à maintenir.

Créer et mettre à jour des contacts et des deals

n8n propose des nodes dédiés HubSpot et Pipedrive qui couvrent les opérations courantes (Create, Update, Get, Get Many, Search) sans écrire de requête HTTP à la main. Pour un besoin non couvert par le node natif — un endpoint récent, un paramètre de filtre précis — le node HTTP Request reste la solution de repli, en pointant directement sur l'API REST du CRM avec le credential configuré.

Exemple de structure pour créer ou mettre à jour un contact HubSpot via HTTP Request :

POST https://api.hubapi.com/crm/v3/objects/contacts
{
  "properties": {
    "email": "{{ $json.email }}",
    "firstname": "{{ $json.prenom }}",
    "lastname": "{{ $json.nom }}",
    "phone": "{{ $json.telephone }}"
  }
}

Côté Pipedrive, la création d'un deal passe par l'endpoint /deals, avec le contact associé via son person_id :

POST https://api.pipedrive.com/v1/deals
{
  "title": "{{ $json.titre_deal }}",
  "person_id": {{ $json.person_id }},
  "value": {{ $json.montant }},
  "currency": "EUR"
}

Dans les deux cas, le node Set en amont prépare le payload avec les bons noms de champs avant l'appel, ce qui garde le node HTTP Request lisible et évite d'éparpiller la logique de mapping dans l'URL ou les headers.

Déduplication : toujours chercher avant de créer

Le piège le plus fréquent d'une synchronisation CRM automatisée : créer un doublon à chaque exécution parce que le workflow ne vérifie jamais si le contact existe déjà. Ce n'est pas qu'un problème de confort visuel : une étude désormais classique de Thomas Redman, publiée dans Communications of the ACM en 1998, montre que la mauvaise qualité des données — doublons, champs incohérents, enregistrements obsolètes — impose des coûts opérationnels réels à l'organisation qui les subit, en fragilisant la fiabilité des décisions prises à partir de ces données (Redman, 1998, Communications of the ACM). Un contact dupliqué dans HubSpot ou Pipedrive n'est donc jamais anodin : chaque doublon multiplie le risque d'incohérence entre les équipes qui s'appuient sur ce même enregistrement. La séquence correcte tient en trois étapes :

1. Rechercher par email — endpoint /crm/v3/objects/contacts/search chez HubSpot (filtre EQ sur la propriété email), ou /persons/search?term=...&fields=email chez Pipedrive.
2. Node IF — teste si la recherche renvoie au moins un résultat ({{ $json.total > 0 }} côté HubSpot, {{ $json.data.items.length > 0 }} côté Pipedrive).
3. Branche Update ou Create — si un résultat existe, on met à jour l'enregistrement trouvé (PATCH avec son ID) ; sinon, on crée un nouvel enregistrement.

Cette logique de recherche-avant-création est la même brique que celle utilisée pour éviter les doublons dans une base de contacts Supabase ; voir notre guide de connexion n8n-Supabase pour l'équivalent côté base de données propre, si votre CRM sert de source secondaire plutôt que de source de vérité.

Synchronisation bidirectionnelle : CRM vers outil, et outil vers CRM

Une vraie synchronisation bidirectionnelle nécessite deux workflows n8n distincts, chacun déclenché par sa propre source :

• CRM → autre outil : un Webhook HubSpot ou Pipedrive (configuré côté CRM pour notifier n8n sur contact.propertyChange ou deal.updated) déclenche un workflow qui répercute le changement vers l'outil tiers (facturation, base produit, outil de support).
• Autre outil → CRM : l'inverse, un événement dans l'outil tiers (nouvelle commande, ticket résolu) déclenche un workflow qui écrit dans le CRM via le node dédié.

Le risque classique de ce montage : une boucle infinie, où la mise à jour déclenchée par le workflow A relance le webhook qui alimente le workflow B, qui remet à jour le CRM, qui redéclenche A. La parade la plus fiable consiste à comparer un timestamp ou un hash de contenu avant d'écrire, et à ignorer l'écriture si rien n'a réellement changé — un simple node IF comparant updatedAt côté source et destination suffit dans la plupart des cas. Pour sécuriser le webhook entrant côté n8n contre les appels non désirés, appliquez les mêmes principes que dans notre article sur la sécurisation d'un webhook n8n.

Gérer les rate limits des API CRM

HubSpot et Pipedrive imposent tous deux des limites de débit :

• HubSpot : selon le plan, entre 100 et 190 requêtes toutes les 10 secondes pour les Private Apps, avec un en-tête X-HubSpot-RateLimit-Remaining renvoyé sur chaque réponse.
• Pipedrive : un système de « budget » quotidien par token, avec des en-têtes X-RateLimit-Remaining et X-RateLimit-Reset indiquant le solde restant et le moment de réinitialisation.

Pour une synchronisation qui traite un lot de contacts d'un coup (import initial, resynchronisation complète), le node Loop Over Items associé à un node Wait entre chaque lot évite de saturer ces limites — la même mécanique détaillée dans notre article sur les rate limits des API IA dans n8n, transposable telle quelle aux API CRM.

Mapping de champs personnalisés

Les champs personnalisés (custom properties/fields) demandent un mapping explicite, car leur identifiant technique diffère souvent du libellé affiché dans l'interface :

• HubSpot référence ses propriétés personnalisées par un nom interne (internal_name), visible dans Paramètres → Propriétés → nom de la propriété. Ce nom s'ajoute directement dans l'objet properties de la requête, au même niveau que les champs standards.
• Pipedrive identifie ses champs personnalisés par un hash (par exemple 5f3e2a1b4c9d8e7f...), récupérable une fois via l'endpoint /dealFields ou /personFields, puis à conserver dans un node Set ou une variable d'environnement pour éviter de le redemander à chaque exécution.

Un node Set placé juste avant l'appel de création/mise à jour centralise ce mapping : il transforme les noms de champs lisibles de votre source (budget_estime, secteur_activite) vers les identifiants techniques attendus par le CRM, ce qui garde le reste du workflow lisible et facile à maintenir.

En résumé

Synchroniser un CRM avec n8n plutôt qu'avec l'intégration native du CRM apporte trois choses que les intégrations standards n'offrent pas : de la logique conditionnelle avant l'écriture, une déduplication fiable par recherche systématique avant création, et une synchronisation bidirectionnelle maîtrisée entre plusieurs systèmes. La brique d'authentification (Private App Token HubSpot, API Token Pipedrive) se configure en quelques minutes ; l'essentiel du travail se joue ensuite dans le mapping de champs et la gestion des rate limits. Si votre pipeline CRM s'appuie déjà sur du scoring ou de la qualification par IA en amont, le Pack Inbox IA illustre la même architecture webhook + logique métier + écriture CRM, appliquée au tri d'emails entrants.