Votre CRM gère des contacts, des entreprises et des transactions. Sauf que votre activité, elle, gère aussi des abonnements, des sites, des contrats, des machines ou des candidatures. Et ces choses-là finissent en propriétés entassées sur la fiche entreprise, ou dans un Google Sheet que personne ne met à jour.
L'objet personnalisé sert exactement à ça. Encore faut-il savoir quand il se justifie, parce qu'un objet créé trop tôt coûte plus cher qu'une propriété de trop.
Ce guide donne le critère de décision, les quatre choix à trancher avant de cliquer sur créer, la façon de l'alimenter par workflow, et les limites qui surprennent les équipes en cours de route.
Ce qu'est un objet personnalisé dans HubSpot
HubSpot livre des objets standard : contacts, entreprises, transactions, tickets, produits, devis. Un objet personnalisé ajoute un type d'enregistrement à cette liste, avec ses propres propriétés, ses propres associations et ses propres vues.
Concrètement, chaque enregistrement devient une fiche à part entière. Elle a un historique, elle s'associe à des contacts et à des entreprises, elle se filtre dans une liste, elle déclenche des workflows, elle remonte dans les rapports.
Point important avant d'aller plus loin : les objets personnalisés sont réservés aux éditions Enterprise (Marketing Hub, Sales Hub, Service Hub, Content Hub, Data Hub, Smart CRM et Revenue Hub). Sur une édition Pro, la question ne se pose pas, il faudra passer par des propriétés ou par un objet standard détourné. La documentation HubSpot le précise, et renvoie au catalogue produits pour les quotas exacts, qui dépendent de l'abonnement.
Quand une propriété suffit, et quand elle ne suffit plus
Le test tient en une question : est-ce qu'une entreprise peut en avoir plusieurs à la fois, chacun avec sa propre date et son propre statut ?
Si la réponse est non, une propriété fait le travail. Le secteur d'activité, l'effectif, le CRM utilisé, la date du dernier audit : tout ça reste des propriétés sur la fiche entreprise, et c'est très bien.
Si la réponse est oui, la propriété commence à mentir. Prenez un client qui a trois sites, chacun avec sa date de renouvellement de contrat et son responsable. Le jour où vous mettez trois adresses dans un champ texte, vous avez perdu : impossible de filtrer sur un seul site, impossible de déclencher une relance sur une seule échéance, impossible de compter les sites dans un rapport.
Quelques cas où l'objet se justifie vraiment :
- des abonnements ou des contrats avec des dates et des montants distincts
- des sites, des établissements ou des points de vente rattachés à un même groupe
- des signaux d'intention, quand vous voulez garder l'historique événement par événement plutôt qu'un compteur
- des candidatures, des dossiers, des projets, tout ce qui a son propre cycle de vie
Et deux cas où il ne se justifie pas : une information qui ne change jamais, et une information que personne ne filtrera jamais. Créer un objet pour stocker une donnée que vous n'utiliserez pas dans une liste, un workflow ou un rapport, c'est de la dette.
Les quatre choix à trancher avant de créer l'objet
Ces quatre décisions se prennent avant, sur papier, parce que certaines ne se rattrapent pas sans tout refaire.
Le nom singulier et pluriel. HubSpot les utilise partout dans l'interface. Un nom vague comme « Élément » ou « Donnée » rend les vues illisibles trois mois plus tard.
La propriété d'affichage. C'est elle qui identifie la fiche dans les listes et les associations. Un identifiant technique y est illisible, un libellé parlant y change tout. Si aucune propriété ne fait un bon titre, créez-en une qui se remplit par workflow à partir des autres.
Les propriétés d'unicité. Elles empêchent deux enregistrements identiques et servent de clé quand une intégration pousse de la donnée. Sans clé d'unicité, votre import crée des doublons dès la deuxième synchronisation.
Les associations. Avec quels objets standard cet objet doit-il se relier, et dans quel sens. C'est le point le plus structurant, et il a sa section.
Les associations, le vrai sujet
Un objet personnalisé isolé ne sert à rien. Sa valeur vient de ce à quoi il se rattache.
Posez-vous la question dans les deux sens. Un contrat appartient à une entreprise, et une entreprise a plusieurs contrats. Un signal appartient à un contact, et ce contact appartient à une entreprise, donc le signal doit remonter jusqu'à l'entreprise pour être exploitable par les commerciaux qui travaillent au niveau du compte.
HubSpot permet aussi de nommer les rôles d'une association, ce que la documentation sur les associations détaille. Un même contact peut être signataire d'un contrat et utilisateur d'un autre : sans libellé, les deux liens se ressemblent et vos rapports mélangent tout.
Dernier point : décidez tout de suite si l'association est obligatoire dans votre process. Un enregistrement créé sans entreprise associée devient orphelin, il n'apparaît dans aucune vue de compte, et personne ne le retrouve.
Les workflows qui alimentent l'objet
Un objet ne vit que s'il se remplit tout seul. Trois mécaniques couvrent la plupart des besoins, et la documentation sur les workflows donne le détail de chacune.
La création automatique. Un workflow sur un autre objet crée l'enregistrement. Une transaction qui passe en gagnée crée le contrat associé, avec ses dates reprises de la transaction.
La mise à jour croisée. Un workflow sur l'objet personnalisé écrit sur l'entreprise associée. C'est ce qui permet à vos commerciaux de voir l'essentiel sur la fiche entreprise sans ouvrir chaque enregistrement : date de la prochaine échéance, nombre de contrats actifs, montant total.
Le déclenchement. L'objet devient la source d'une action commerciale. Une échéance dans 90 jours crée une tâche pour le propriétaire du compte, un signal qui fait franchir un seuil de score lance une séquence.
Sur ce dernier point, la logique rejoint celle du scoring dynamique des comptes : l'objet stocke les événements, le score les agrège, le workflow décide quoi en faire.
Ce que ça change dans les rapports
C'est souvent la vraie raison de créer l'objet, et elle arrive trop tard dans la réflexion.
Tant que l'information vit dans une propriété texte, vous ne pouvez pas la compter. Une fois qu'elle est un enregistrement, vous comptez, vous segmentez, vous croisez avec les transactions. Le nombre de contrats par segment, le montant qui arrive à échéance ce trimestre, la répartition des signaux par type sur les comptes Tier 1 : tout ça devient un rapport standard.
Avant de créer l'objet, écrivez les trois rapports que vous voulez sortir. Si vous n'arrivez pas à en écrire trois, l'objet n'est probablement pas nécessaire.
Les limites à connaître avant de se lancer
L'édition. Enterprise uniquement, on l'a dit. C'est le premier filtre.
Les quotas. Le nombre d'objets personnalisés et de propriétés dépend de votre abonnement. HubSpot renvoie à son catalogue produits, donc vérifiez le vôtre avant de prévoir quatre objets.
Les intégrations. Beaucoup d'outils tiers gèrent parfaitement contacts, entreprises et transactions, et ignorent vos objets personnalisés. Avant de construire, vérifiez que les outils qui devront lire cette donnée savent la lire.
Le coût de maintenance. Chaque objet ajoute des vues à tenir, des permissions à régler, des workflows à documenter. Un objet qui n'a plus de propriétaire au bout de six mois devient une zone morte du CRM.
Cinq erreurs qui coûtent cher
Créer l'objet avant d'avoir écrit le process. L'objet matérialise une façon de travailler. Si elle n'est pas décidée, vous modélisez du flou.
Oublier la clé d'unicité. C'est l'erreur la plus courante, et elle ne se voit qu'à la deuxième synchronisation, quand la base double.
Mettre trop de propriétés dès le départ. Commencez par celles qui servent à filtrer, à déclencher ou à compter. Les autres s'ajoutent quand le besoin apparaît.
Ne pas remonter l'information sur l'entreprise. Si vos commerciaux doivent ouvrir trois fiches pour comprendre un compte, ils ne le feront pas. Un ou deux champs de synthèse sur la fiche entreprise suffisent à régler ça.
Laisser l'objet sans propriétaire. Quelqu'un doit répondre de sa qualité, comme pour les autres objets du CRM.
Par où commencer
Écrivez d'abord les trois rapports attendus et le process qui produit les enregistrements. Ensuite, tranchez les quatre choix de structure. Créez l'objet avec cinq propriétés, pas vingt. Branchez un seul workflow de création, vérifiez pendant deux semaines qu'il ne fabrique pas de doublons, puis ajoutez les workflows de mise à jour et de déclenchement.
Si votre besoin ressemble à ce qu'on vient de décrire mais que l'équipe n'a pas le temps de le construire, c'est le genre de chantier que prend en charge notre agence CRM, avec des consultants sur place en Île-de-France et un accompagnement en région. Et si vous débutez sur la plateforme, commencez plutôt par notre guide complet de HubSpot.
