Connecter Slack et HubSpot sans transformer un canal en flux d’alertes

Relier Slack et HubSpot est l’une des premières intégrations que met en place une équipe commerciale, et l’une des premières qu’elle finit par couper. Le scénario est toujours le même : un canal #ventes reçoit une notification à chaque changement d’étape, puis à chaque nouvelle transaction, puis à chaque e-mail ouvert. Au bout de trois semaines, plus personne ne le lit, et l’intégration a produit du bruit au lieu de l’information.

Quatre méthodes existent. Elles ne coûtent pas la même chose, ne permettent pas les mêmes choses, et le choix se fait moins sur la technique que sur ce que vous voulez voir apparaître dans Slack.

Méthode 1 — L’intégration native HubSpot ↔ Slack

C’est le point de départ, et elle est gratuite. Elle s’installe depuis le marché des applications HubSpot ou depuis le répertoire Slack, en quelques minutes.

Ce qu’elle permet :

• Recevoir des notifications HubSpot dans un canal ou en message direct.
• Créer une tâche HubSpot depuis Slack avec /hs-task.
• Rechercher un contact ou une transaction sans quitter Slack.
• Associer un canal Slack à une transaction, pour que les échanges soient rattachés à la fiche.

Ce qu’elle ne permet pas : conditionner finement une notification. C’est sa limite principale — vous choisissez un type d’événement, pas une règle métier. « Prévenir quand une transaction de plus de 50 000 € passe en négociation sans décideur identifié » n’est pas exprimable.

Pour qui : les équipes de moins de dix personnes qui veulent la fonction « canal rattaché à une transaction ». C’est la fonctionnalité la plus sous-utilisée du lot, et probablement la plus utile : elle règle la question « où est-ce qu’on a parlé de ce dossier ? ».

Méthode 2 — Les workflows HubSpot

Dans les offres HubSpot qui incluent l’automatisation, un workflow peut envoyer une notification Slack en action de fin. C’est plus puissant que la méthode 1, parce que la condition d’entrée peut être aussi fine que vos propriétés le permettent.

Ce qu’elle permet : filtrer sur n’importe quelle propriété, temporiser, enchaîner plusieurs actions, viser un canal ou une personne selon le propriétaire de la transaction.

La limite : le sens unique. Le workflow pousse vers Slack ; il ne lit rien de ce qui s’y dit. Une réponse dans le fil n’a aucun effet dans HubSpot.

Le coût caché : la prolifération. Une équipe qui découvre cette possibilité crée douze workflows en deux mois, et personne ne se souvient six mois plus tard de qui a créé celui qui envoie un message à 7 h du matin. Tenez une liste, avec un propriétaire par workflow.

Méthode 3 — Zapier, Make ou n8n

Un intermédiaire entre les deux outils, avec une interface de scénarios.

Ce qu’elle permet : à peu près tout, dans les deux sens, y compris en passant par un troisième outil. C’est la solution la plus souple des quatre.

Ce qu’elle coûte réellement, et c’est rarement anticipé :

Le troisième point est le plus sérieux. Un scénario Zapier qui échoue parce qu’une propriété HubSpot a été renommée ne prévient personne, et l’équipe s’en aperçoit trois semaines plus tard en constatant qu’une notification ne tombe plus. Si vous partez sur cette voie : un canal #integrations-erreurs dédié aux échecs, et quelqu’un dont c’est explicitement le sujet.

Sur la sous-traitance de données, ces plateformes sont des sous-traitants au sens du RGPD et doivent figurer dans votre registre — voir les dix questions à poser sur les données.

Méthode 4 — Un agent connecté aux deux

La différence est de nature, pas de degré. Les trois premières méthodes transportent des événements : quelque chose s’est produit dans HubSpot, un message apparaît dans Slack. Un agent connecté aux deux transporte des intentions : on lui écrit en langage naturel dans Slack, et il agit dans HubSpot.

Concrètement, dans un fil Slack :

• « Où en est-on avec Acme ? » → une synthèse de la transaction, des derniers échanges et de la prochaine étape, sans ouvrir HubSpot.
• « Note que le budget est validé et passe-les en négociation » → la fiche est mise à jour, avec la trace de qui l’a demandé.
• « Prépare la relance pour Marie » → un brouillon, en attente de validation.

Ce que cela change : la mise à jour du CRM cesse d’être une tâche séparée. Elle se fait dans la conversation où l’information apparaît, ce qui est la seule manière connue de la faire arriver le jour même — le raisonnement complet est dans mettre à jour HubSpot après un rendez-vous.

Les deux exigences non négociables :

La cloison. Un agent lisible depuis Slack doit appliquer les permissions du CRM. Ce qu’une personne voit dans HubSpot, elle le voit via l’agent ; ce qu’elle ne voit pas, l’agent ne le lui dit pas — y compris si elle pose la question dans un canal où quelqu’un d’autre a accès.

La validation. Écrire une note dans HubSpot est réversible. Envoyer un e-mail au client ne l’est pas. Un agent qui accepte « envoie-lui la proposition » depuis Slack sans confirmation explicite est une mauvaise idée, quelle que soit sa précision par ailleurs.

Le but n’est pas que Slack affiche HubSpot. C’est qu’on n’ait plus à ouvrir HubSpot pour que HubSpot soit à jour.

Les six notifications qui valent la peine

Quelle que soit la méthode retenue, le vrai travail est de décider ce qui n’est pas notifié. Voici une liste courte qui survit à l’usage.

1. Une transaction au-dessus du seuil passe en négociation. Le seuil est propre à votre équipe ; sans seuil, tout devient notification.
2. Une date de clôture est repoussée. Le signal le plus prédictif d’une perte, et personne ne le regarde.
3. Une transaction en étape avancée n’a aucune activité depuis 21 jours. Le silence ne déclenche jamais d’événement — il faut le chercher activement, ce que seules les méthodes 2 et 4 permettent.
4. Un formulaire est rempli par un contact déjà associé à une transaction ouverte. Un prospect en cours qui revient sur le site est un signal fort.
5. Une transaction est perdue au-dessus du seuil. Pour la conversation, pas pour le tableau de bord.
6. Un e-mail entrant reste sans réponse depuis 48 h sur une transaction active.

Ce qui ne mérite pas de notification, malgré la tentation : chaque nouvelle transaction créée, chaque ouverture d’e-mail, chaque changement d’étape en début de pipeline, chaque nouveau contact. Ces quatre-là représentent l’essentiel du volume et aucune décision.

Comment choisir en trois questions

Voulez-vous seulement voir, ou aussi agir ? Voir : méthodes 1 ou 2. Agir depuis Slack : méthodes 3 ou 4.

Vos conditions sont-elles exprimables en règles fixes ? Oui : la méthode 2 suffit et ne coûte rien de plus. Non — vous voulez « prévenir quand quelque chose semble bloqué » — il faut une méthode 4.

Qui maintiendra ? C’est la question décisive et la moins posée. Un scénario Zapier sans propriétaire désigné a une durée de vie d’environ six mois. Si personne n’a le temps, restez sur la méthode 1, qui ne casse pas.

Questions fréquentes

L’intégration Slack de HubSpot est-elle gratuite ?

L’intégration native est incluse et ne demande aucun abonnement supplémentaire. Les notifications déclenchées par workflow supposent en revanche une offre HubSpot incluant l’automatisation.

Peut-on mettre à jour une transaction HubSpot depuis Slack ?

Pas avec l’intégration native, qui permet de créer une tâche et de rechercher, pas de modifier une propriété. Il faut passer par une plateforme d’automatisation ou par un agent connecté aux deux outils.

Comment éviter que le canal Slack devienne inutilisable ?

En limitant les notifications à des événements qui appellent une décision — typiquement cinq à sept règles au total — et en supprimant toute notification qui n’a provoqué aucune action pendant deux semaines. La discipline de suppression compte plus que le choix initial des règles.