Deux API pour un seul besoin métier : transformer une soumission de formulaire WordPress en contact qualifié dans le CRM du client. C’est un besoin récurrent sur les projets d’agence dès qu’un formulaire de contact dépasse la simple notification par e-mail. Mais HubSpot et Salesforce, les deux CRM les plus fréquemment rencontrés côté client, n’abordent pas du tout l’intégration de la même manière, et le choix technique en amont détermine largement la complexité du code à maintenir ensuite.
Ce comparatif s’appuie sur un cas réel : un formulaire de demande de devis d’agence, avec nom, e-mail, société et budget estimé, à pousser en temps réel vers le CRM au moment de la soumission. L’objectif n’est pas de désigner un vainqueur universel, mais d’objectiver les différences d’effort d’intégration selon le CRM déjà en place chez le client.
Authentification : deux philosophies opposées
HubSpot, pour un usage d’intégration privée à une seule instance, permet l’utilisation d’un jeton d’accès privé généré directement dans l’interface, sans flux OAuth complet à implémenter côté serveur. Pour une intégration publique distribuée à plusieurs clients HubSpot différents, un flux OAuth 2.0 standard est nécessaire, mais reste d’une complexité raisonnable, bien documenté sur developers.hubspot.com.
Salesforce impose une authentification plus lourde dans tous les cas de figure : soit un flux OAuth 2.0 complet avec redirection utilisateur, soit un flux JWT Bearer pour une intégration serveur à serveur sans interaction humaine, qui nécessite la génération d’un certificat, sa configuration dans une « Connected App » côté Salesforce, et la signature d’un jeton à chaque appel. C’est un effort d’intégration initial significativement plus élevé, justifié par un modèle de sécurité plus strict adapté aux grandes organisations.
Modèle de données : simplicité contre exhaustivité
Créer un contact via l’API HubSpot se résume à un appel POST sur /crm/v3/objects/contacts avec un objet JSON de propriétés :
POST https://api.hubapi.com/crm/v3/objects/contacts
Authorization: Bearer {token}
Content-Type: application/json
{
"properties": {
"email": "contact@exemple.fr",
"firstname": "Camille",
"company": "Atelier Nova",
"budget_estime": "15000"
}
}
Côté Salesforce, la création d’un enregistrement passe par l’API REST sur un objet standard comme Lead (ou un objet personnalisé), mais le modèle impose de respecter des champs obligatoires définis par l’administrateur Salesforce du client, souvent différents d’une organisation à l’autre : source du lead, statut initial, propriétaire assigné. Le mapping de champs à établir en amont avec l’équipe côté client est systématiquement plus long que pour une intégration HubSpot standard.
Comparatif synthétique
| Critère | HubSpot | Salesforce |
|---|---|---|
| Complexité d’authentification | Faible à modérée | Élevée |
| Rigidité du modèle de données | Souple, propriétés libres | Champs obligatoires par organisation |
| Documentation développeur | Très accessible | Complète mais dense |
| Limites de débit (rate limit) | Généreuses en usage standard | Variables selon l’édition souscrite |
| Temps d’intégration typique | 1 à 2 jours | 3 à 5 jours |
Gérer les limites de débit sans perdre de leads
Les deux API imposent des limites de requêtes par période, mais les stratégies de repli diffèrent. Sur HubSpot, un code 429 retourné doit déclencher une nouvelle tentative après le délai indiqué dans l’en-tête de réponse. Sur Salesforce, l’édition souscrite par le client détermine un plafond d’appels journalier strict : un pic de soumissions de formulaire un jour de forte affluence peut suffire à l’atteindre, ce qui impose de prévoir une file d’attente locale (via Action Scheduler par exemple) plutôt qu’un envoi synchrone systématique.
Le critère qui tranche vraiment
Sur le terrain, le choix technique n’est presque jamais motivé par une préférence d’API : il est imposé par le CRM déjà utilisé par le client commercial et marketing. La vraie question à poser en amont du projet n’est donc pas « HubSpot ou Salesforce ? » mais « quel CRM l’équipe commerciale du client utilise-t-elle déjà, et avec quel niveau d’édition ? ». Une intégration Salesforce mal dimensionnée sur une édition d’entrée de gamme peut se heurter à des limites d’API absentes des éditions supérieures.
Sur nos projets, on documente systématiquement les champs obligatoires du CRM cible avant d’écrire la moindre ligne d’intégration. C’est l’étape qui évite les allers-retours de dernière minute avec l’administrateur CRM du client.
Notre verdict
Pour un formulaire d’agence simple avec un volume modéré de soumissions, l’API HubSpot demande un effort d’intégration nettement inférieur et convient à la grande majorité des cas. Salesforce reste incontournable dès que le client impose ce CRM en interne, mais son intégration doit être budgétée en conséquence : authentification JWT Bearer, mapping de champs personnalisé et gestion de file d’attente locale ne sont pas optionnels sur ce terrain.
