Vous avez un site, vous avez HubSpot, et vous voulez que chaque demande de contact arrive dans le CRM avec son origine, sans doublon et sans ressaisie. Intégrer HubSpot à un site paraît simple : un code à coller, un formulaire qui s'affiche. Les ennuis arrivent plus tard, quand l'équipe commerciale découvre des contacts sans source, des champs vides ou des visiteurs qui ont refusé les cookies et dont on ne sait plus rien.
J'en parle parce que je l'ai fait en mission. J'ai conçu et développé un site B2B en Webflow relié à HubSpot, avec du JavaScript sur mesure et les exigences du RGPD, et sur une autre mission j'ai branché HubSpot et Mailchimp. Voici la méthode que j'en garde, dans l'ordre où je travaille.
01Trois façons de relier un site à HubSpot
Avant de parler de code, il faut choisir le chemin. Il en existe trois, et ils n'ont pas les mêmes contraintes.
Le premier est le formulaire HubSpot intégré. Vous le construisez dans HubSpot, vous copiez son code d'intégration et vous le collez dans un bloc HTML de votre page. HubSpot précise que, pour suivre les analyses, le code de suivi doit aussi être installé sur cette page, et que les domaines non ajoutés aux paramètres de suivi risquent d'être marqués comme spam (HubSpot, style et intégration des formulaires sur un site externe). C'est le chemin le plus court, et celui que je conseille quand l'équipe marketing veut modifier ses formulaires sans moi.
Le deuxième garde le formulaire de votre site, et laisse le code de suivi HubSpot le capturer. Les conditions sont strictes : un formulaire en HTML statique dans une balise form, un champ e-mail, pas d'iframe, aucun script rattaché à l'envoi. Les formulaires ajoutés après le chargement de la page ne sont pas capturés, et les applications à page unique posent le même problème (HubSpot, utiliser les formulaires externes à HubSpot). Je m'en méfie sur un site en Next.js, où l'on passe souvent d'une page à l'autre sans rechargement complet.
Le troisième passe par l'API de soumission. Le site envoie lui-même les données à un formulaire HubSpot, avec un objet de contexte (le jeton du cookie de suivi, l'adresse et le nom de la page) et les options de consentement (HubSpot Developers, Submit data to a form). C'est le chemin qui donne le plus de contrôle, et celui qui demande le plus d'entretien.
Comment je choisis
- Le formulaire intégré, si le site est simple et que le marketing veut la main sur les champs.
- La capture, si le formulaire du site existe déjà, qu'il est propre et qu'il ne change presque jamais.
- L'API, si le formulaire a plusieurs étapes, une logique propre au site ou des contrôles que HubSpot ne fait pas.
Sur le site Webflow dont je parlais, j'ai ajouté du JavaScript sur mesure. Ce choix a un coût : chaque ligne écrite pour le formulaire devient une ligne à maintenir quand HubSpot ou le site évoluent.
02Ce que j'écris avant de toucher au code
Le document que j'écris en premier est une table de correspondance. Une ligne par champ du site, et pour chacune : le nom affiché, le nom technique, la propriété HubSpot qui le reçoit, le type de donnée, s'il est obligatoire, et la valeur attendue quand c'est une liste. Elle ressemble à ceci :
- E-mail professionnel → propriété « email », texte, obligatoire.
- Société → propriété « company », texte, obligatoire.
- Objet de la demande → une propriété personnalisée, liste fermée, obligatoire.
- Page d'origine → transmise dans le contexte, automatique, obligatoire.
Cette table évite deux pannes classiques. La première, c'est la donnée de référence implicite : une liste « Objet » sur le site dont les valeurs ne correspondent pas exactement à celles de la propriété HubSpot, et des contacts qui arrivent avec un champ vide. La seconde, c'est le document qui bouge sans que tout le monde le sache. Je versionne cette table comme une spécification d'intégration : chaque réunion qui change un champ produit une nouvelle version, et tout le monde parle du même document.
Un détail à lire avant de choisir la capture : HubSpot indique que seules les propriétés de type texte à une ligne peuvent être mappées dans ce mode, et que le mappage est automatique (HubSpot, formulaires externes). Si votre table contient des listes fermées, ce chemin vous résistera.
Un exemple public m'a conforté dans cette façon de faire. Dans une conférence de la chaîne HubSpot Developers, une équipe montre un formulaire en plusieurs écrans dont chaque champ correspond un à un à un champ d'un seul formulaire HubSpot. Les éditeurs changent un libellé ou une option dans HubSpot, et le site suit. L'envoi passe par une fonction côté serveur qui pousse les données dans le CRM, ce qui déclenche ensuite les automatisations (HubSpot Developers, How to Build a Flow Framework with HubSpot Forms API). Je retiens surtout la discipline : un champ, une propriété, et une seule source de vérité.
03Le consentement, le point qu'on découvre trop tard
C'est la partie qu'on oublie dans le devis et qu'on découvre en recette. Le code de suivi HubSpot dépose des cookies, dont hubspotutk, qui garde la trace de l'identité d'un visiteur. Ce cookie est transmis avec la soumission d'un formulaire pour la rattacher aux visites, et il sert à dédupliquer les contacts. HubSpot ne range pas ces cookies d'analyse parmi les cookies strictement nécessaires : ils dépendent de la bannière de consentement (HubSpot, cookies définis dans le navigateur d'un visiteur).
Côté règles françaises, la CNIL n'exempte de consentement que les traceurs qui servent uniquement à mesurer l'audience pour le compte de l'éditeur et produisent des données statistiques anonymes, sans recoupement avec d'autres traitements (CNIL, solutions pour les outils de mesure d'audience). Un suivi qui rattache des visites à un contact nommé ne rentre pas, à mon sens, dans ce cadre. Je pars donc du principe que le code de suivi attend l'accord du visiteur.
La conséquence pratique est simple, et elle surprend souvent : un visiteur qui refuse les cookies peut quand même envoyer le formulaire, mais sa fiche arrive sans l'historique de ses visites. Mieux vaut le dire à l'équipe commerciale avant la mise en ligne qu'après.
Le formulaire lui-même doit aussi informer. La CNIL recommande une information en plusieurs niveaux : le minimum (qui collecte, pourquoi, quels droits) directement sur le formulaire, puis un lien vers la notice complète (CNIL, informer les personnes et assurer la transparence). Je l'écris dans la table de correspondance, comme un champ à part entière, pour qu'il ne disparaisse pas d'une version à l'autre.
04Tester comme un visiteur, pas comme l'équipe
Une leçon que je répète souvent : un site peut sembler normal à l'équipe connectée et être cassé pour les visiteurs. Avec HubSpot, l'équipe est connectée au CRM, a déjà ses cookies et a souvent accepté la bannière depuis longtemps. Elle ne voit pas ce que voit un inconnu.
Ma liste de tests avant la mise en ligne :
- Ouvrir le site en fenêtre privée, refuser les cookies, envoyer le formulaire, puis vérifier que le contact arrive quand même dans HubSpot.
- Recommencer en acceptant les cookies, et vérifier que la fiche montre la page d'origine et les visites.
- Envoyer deux fois avec la même adresse e-mail, et vérifier qu'il n'y a pas de doublon.
- Tester chaque valeur de chaque liste fermée de la table, une par une.
- Envoyer depuis une page atteinte par un lien interne, sans recharger, pour vérifier que le formulaire est toujours capté.
- Vérifier sur mobile que le bloc de consentement et le bouton d'envoi restent visibles.
Je range ces tests dans la même liste que le reste de la recette avant mise en production. Ils prennent une heure et ils évitent des semaines de contacts mal rangés.
05Ce que cette intégration ne règle pas
Une intégration propre ne remplace pas une base propre. Si HubSpot contient déjà des doublons, des propriétés créées en double par trois personnes différentes ou des listes jamais nettoyées, brancher le site dessus amplifie le désordre. Dans ce cas, je commence par le ménage, et je le dis avant de commencer.
Elle ne règle pas non plus la mesure. Savoir quelles campagnes amènent des demandes demande un suivi cohérent entre le site, l'outil d'analyse et le CRM, puis quelqu'un qui le lit chaque mois. J'en parle dans l'article sur le reporting SEO automatique.
Et je ne pousse pas l'API par principe. Elle donne du contrôle, mais elle crée du code à maintenir, des identifiants à protéger et des erreurs à surveiller : l'API authentifiée répond 401 quand les identifiants sont faux et 403 quand le compte n'a pas la permission d'envoyer (HubSpot Developers, Submit data to a form). Si personne ne surveille ces réponses, des demandes se perdent en silence. Pour beaucoup de PME, le formulaire intégré suffit, et c'est très bien ainsi.
Enfin, si vous prévoyez de refaire le site, faites l'intégration avec la refonte plutôt qu'avant. Quand je prépare une migration vers Next.js et Sanity, les formulaires font partie de l'inventaire, au même titre que les pages.
06Par où commencer cette semaine
Ouvrez votre site en fenêtre privée, refusez les cookies et envoyez votre propre formulaire. Regardez ensuite ce qui arrive dans HubSpot : la fiche, la source, les champs. Ce test de dix minutes vous dira si vous avez un problème.
Si vous en avez un, écrivez la table de correspondance avant de toucher au code, puis choisissez le chemin. C'est le travail que je fais en diagnostic au début d'une mission, et la table vous restera même si vous changez d'outil un jour. Si vous voulez qu'on regarde votre cas ensemble, mes services décrivent comment je travaille, et on peut en parler.