Découvrez comment les objets personnalisés HubSpot permettent de structurer des données spécifiques à votre métier pour un CRM plus efficace et adapté.
Lorsque l’on commence à utiliser HubSpot sérieusement, on se rend rapidement compte d’une réalité : les objets standard — Contacts, Entreprises, Transactions, Tickets — ne suffisent pas toujours pour représenter la complexité d’un métier. Certains éléments ne sont ni un contact, ni une opportunité commerciale, ni un ticket support. Ce sont pourtant des pièces essentielles du puzzle opérationnel.
C’est ici que les objets personnalisés HubSpot prennent tout leur sens. Ils permettent d’ajouter au CRM une brique métier qui n’existe pas par défaut, exactement comme si HubSpot avait prévu un objet supplémentaire rien que pour vous.
Un objet personnalisé est un objet CRM que l’on crée soi-même, avec sa propre fiche, ses propriétés, ses associations, son pipeline, ses workflows et ses rapports. En clair, c’est un nouveau type de fiche dans le CRM, au même titre qu’un contact ou qu’une transaction, mais conçu pour refléter votre réalité métier.
On ne parle pas ici d’une simple propriété ajoutée à un objet existant. Une propriété décrit quelque chose. Un objet personnalisé, lui, représente une entité complète. C’est toute la différence.
C’est cette possibilité de créer une entité métier entière qui permet à HubSpot de devenir un véritable CRM opérationnel et non un simple outil marketing.
Les Custom Objects au sens strict HubSpot; avec leur schéma, leur nom, leurs propriétés et leurs associations – ne sont disponibles que sur les portails qui ont au moins un Hub en Enterprise (Sales, Service, Marketing, Data).
Cependant, HubSpot propose d’autres objets CRM natifs qui peuvent être activés via le data model et utilisés comme de vrais objets métiers :
Listings (immobilier),
Rrendez-vous
Cours
Services
Ce qui est top, c'est que depuis 2025 on peut renommer ces objets, les associer entre eux, créer des propriétés, les utiliser dans des workflows, bref, des vraies objets additionnels, disponibles dans les abonnements comme le Hub Sales Pro ! Pour en savoir plus, n'hésitez pas à consulter le guide des abonnements et des tarifs HubSpot.
Prenons un cas client Hubspot dans un cabinet de recrutement, très parlant pour comprendre l’intérêt réel d’un custom object : une agence de recrutement.
Elle doit suivre des candidats, des clients… mais aussi deux entités centrales :
les postes à pourvoir,
les candidatures.
Ces deux entités n’existent pas dans HubSpot par défaut. Elles ne correspondent à aucun objet standard. Comment stocker ces données là via Contact / Entreprise ou Transaction ?
L’objet “Poste” représente chaque poste ouvert chez un client. Il possède ses propres informations : intitulé, description, type de contrat, localisation, date d’ouverture, responsable du dossier, statut du poste. Il est relié à l’entreprise cliente, aux contacts RH, et bien sûr aux candidatures.
Cet objet existe parce qu’un poste est une entité métier autonome. Il a son propre cycle de vie, son propre pipeline, ses propres critères de réussite. Le réduire à un deal serait une erreur, car les étapes ne sont pas des étapes commerciales, mais des étapes de recrutement.
L’objet “Candidature”, lui, représente chaque candidature reçue. Une candidature a son statut, son CV, sa source, sa date, son score de screening, sa décision finale, et les informations opérationnelles nécessaires au recruteur.
Elle est associée :
au contact (le candidat),
au poste concerné,
et parfois indirectement à l’entreprise.
C’est ici que le custom object montre toute sa valeur : un candidat peut générer plusieurs candidatures. Sans objet dédié, le suivi serait impossible. Avec l’objet “Candidature”, chaque candidature vit indépendamment, progresse dans son propre pipeline, et alimente un reporting fiable.
Parce qu’il représente exactement la réalité d’une agence de recrutement :
l’entreprise publie un poste ;
le poste reçoit plusieurs candidatures ;
les candidatures avancent dans un pipeline ;
le candidat, lui, reste une seule fiche contact.
Le CRM devient ainsi un vrai système métier, où chaque élément est enregistré à l’endroit logique, associé correctement et exploitable en reporting.
Créer un objet personnalisé ne doit jamais être un réflexe. C’est une décision structurante qui a un impact sur le reporting, les automatisations, les associations et l’expérience utilisateur. Il existe cependant des situations très précises où ce choix s’impose naturellement.
C’est le cas de figure le plus fréquent.
Dès qu’un même contact peut posséder plusieurs éléments du même type, un custom object devient la seule solution saine.
Dans une agence de recrutement, un candidat peut postuler à plusieurs postes, parfois en parallèle. Si l’on tente d’enregistrer ces informations dans la fiche contact, on se retrouve avec des propriétés dupliquées, des données écrasées ou des champs multipliés à l’infini.
En créant un objet “Candidature”, chaque candidature devient une fiche autonome. Cela permet de conserver un historique propre, d’afficher des vues claires, de segmenter précisément et d’exploiter pleinement le reporting.
Certains éléments métiers avancent dans un pipeline qui n’a rien à voir avec le cycle commercial ou le support client.
Un poste à pourvoir progresse selon ses propres statuts : ouvert, priorisé, shortlist, pourvu, fermé. Une candidature évolue dans un parcours différent : reçue, screening, envoyée au client, entretien, décision.
Ces processus ne doivent pas être mélangés avec les transactions commerciales.
Créer un objet personnalisé permet d’attribuer à chaque entité son pipeline spécifique, parfaitement lisible et adapté à son fonctionnement réel.
Certaines entités ne sont naturellement ni un contact, ni une entreprise, ni un deal, ni un ticket.
Un poste n’est pas un deal.
Une candidature n’est pas un contact.
Une fiche de poste n’est pas un ticket.
Les forcer dans des objets standard entraîne rapidement du bruit, des données incohérentes et une difficulté à exploiter le CRM. Lorsque l’élément représente une entité métier bien définie, la création d’un objet personnalisé est toujours la solution la plus propre.
Dès que les relations dépassent le simple “un élément lié à un seul contact”, il faut envisager un custom object.
Dans le recrutement, un poste peut recevoir plusieurs candidatures, et un candidat peut postuler à plusieurs postes. Ces relations croisées ne peuvent pas être représentées correctement avec des propriétés classiques.
Un objet “Poste” et un objet “Candidature” permettent de modéliser naturellement ces liens 1-à-n et n-à-n, tout en garantissant un modèle de données cohérent et scalable.
Le reporting est un indicateur fort de la nécessité d’un objet personnalisé.
Sans objet “Poste”, il est impossible de mesurer des métriques importantes du recrutement comme les délais de recrutement, le taux de remplissage ou le temps moyen passé dans chaque étape.
Sans objet “Candidature”, on ne peut pas analyser le taux de conversion, l’efficacité des sources, ou les performances des recruteurs.
Un objet dédié devient donc essentiel pour disposer d’un reporting fiable, exploitable et orienté décision.
Créer un objet personnalisé demande de la préparation. La première étape consiste à définir précisément son périmètre : son nom, sa finalité, ce qu’un record représente, ses propriétés, ses associations et son pipeline éventuel. Cette définition est essentielle, car un objet mal pensé entraîne une dette technique difficile à corriger.
Une fois la structure pensée, l’objet se crée dans les paramètres HubSpot, via le menu des objets personnalisés (voir ci-après). Enfin, l’objet prend vie dans les workflows. Une bonne architecture fait en sorte que :
les candidatures se créent automatiquement lorsqu’un formulaire est rempli ;
les statuts se mettent à jour sans intervention manuelle ;
les tâches se créent au bon moment ;
les alertes internes partent selon les critères.
Un objet personnalisé inutilement manuel devient un fardeau. Un objet intégré à des workflows devient un moteur de productivité.
Beaucoup d’entreprises se trompent lorsqu’elles se lancent dans les objets personnalisés. La première erreur consiste à forcer un élément métier dans un deal. Par exemple, transformer un poste en transaction ou une candidature en ticket. Cela crée un CRM illisible et des pipelines incohérents.
La seconde erreur est de stocker dans le contact des informations qui devraient être dans un objet. Une candidature n’est pas une propriété. Un poste non plus. Ce sont des entités métier indépendantes.
Autre piège : créer des dizaines de propriétés, faute d’avoir pensé aux objets personnalisés plus tôt. Chaque nouvelle propriété doit avoir une raison d’exister. Si vos propriétés se ressemblent, ou si elles se répètent, c’est souvent le signe qu’un objet supplémentaire est nécessaire.
Enfin, il faut éviter de multiplier les objets personnalisés sans justification. Chaque objet doit représenter une entité réelle dans le métier. Pas un simple concept interne ou temporaire. Un bon CRM est celui où chaque objet a une fonction évidente et compréhensible pour l’équipe.
La création d’un objet personnalisé dans HubSpot se fait directement depuis les paramètres du portail. Le processus est simple, mais chaque étape doit être réfléchie, car la structure d’un objet ne se modifie pas librement une fois qu’il est créé.
Voici comment procéder, étape par étape.
L’ensemble des objets personnalisés se gère dans les paramètres HubSpot. Depuis la barre verticale, on accède à la catégorie « Objets », puis à la section dédiée aux objets personnalisés. C’est ici que l’on retrouve la liste des objets existants et que l’on peut en créer un nouveau.
Si aucun objet n’existe encore, HubSpot affiche un écran d’introduction. Si des objets sont déjà présents, un bouton en haut à droite permet d’en créer un supplémentaire.
Lors de la création, HubSpot demande des éléments essentiels :
Le nom singulier de l’objet (par exemple : « Poste »).
Le nom pluriel affiché dans les listes (par exemple : « Postes »).
Une description optionnelle qui permet d’expliquer à quoi l’objet sert.
Ce sont ces libellés qui apparaîtront partout dans le CRM. Ils doivent donc être clairs, explicites, et cohérents avec la terminologie métier.
Chaque objet doit avoir une propriété qui servira de nom à chaque enregistrement.
C’est l’équivalent du « Prénom + Nom » pour un contact.
Pour un objet « Poste », cela peut être « Intitulé du poste ». HubSpot demande de définir cette propriété : son type (texte ou nombre), son libellé, et éventuellement de la rendre unique si nécessaire.
Cette propriété joue un rôle central : elle apparaît dans les listes, dans les recherches, dans les associations et dans les workflows.
Une fois les informations de base confirmées, HubSpot génère automatiquement l’objet dans le portail. Celui-ci apparaît alors dans le menu des objets, aux côtés des Contacts, Entreprises, Deals ou Tickets.
À ce stade, l’objet existe mais il est encore « vide » : il n’a ni propriétés supplémentaires, ni associations, ni pipeline.
Dès que l’objet est créé, on peut lui ajouter des propriétés.
C’est ici que l’on construit réellement sa structure : statut, type, dates, informations internes, données opérationnelles, etc.
Les propriétés doivent correspondre à des besoins concrets : segmentation, automatisation, affichage, reporting.
Créer trop de propriétés alourdit l’outil ; en manquer rend l’objet inutilisable.
HubSpot permet ensuite de spécifier à quels autres objets l’objet personnalisé doit être relié.
Dans le cas d’un modèle “Poste / Candidature”, un poste est associé à :
une entreprise,
des contacts internes ou RH,
des candidatures.
Les associations sont essentielles : elles déterminent la manière dont les utilisateurs naviguent dans les fiches et comment les workflows pourront relier les données.
Si l’objet suit un processus interne, HubSpot permet de lui associer un pipeline.
Il peut s’agir, par exemple, du pipeline d’un poste : ouvert, priorisé, shortlist, pourvu, fermé.
Chaque étape peut être configurée selon les besoins internes.
Le pipeline rend l’objet exploitable en gestion opérationnelle et en reporting.
Les objets personnalisés HubSpot jouent un rôle crucial dès que votre métier ne rentre plus dans les limites des objets standard. Ils deviennent essentiels lorsque vous devez représenter plusieurs éléments pour un même contact ou une même entreprise, lorsque ces éléments suivent un processus propre, lorsqu’ils doivent être associés entre eux, ou lorsqu’ils sont nécessaires au reporting métier.
Un custom object ne doit pas être créé pour faire joli. Il doit être créé pour que HubSpot reflète exactement la réalité du métier.
Si vous avez besoin d'aide pour construire votre modèle de données, n'hésitez pas à contacter une agence Hubspot.
Découvrez comment le bon CRM peut stimuler les ventes des PME et comparez les meilleurs CRM afin d'optimiser vos performances commerciales.
Hubspot vs Pipedrive ? Quel est le meilleur CRM pour votre entreprise ? On compare les fonctionnalités, les performances et le tarifs des deux...
Découvrez comment HubSpot Service révolutionne le service client grâce à des fonctionnalités puissantes pour une expérience personnalisée et efficace.