Objets personnalisés CRM : la décision d’architecture qui transforme votre pilotage

Quand aucune case n’existe pour accueillir les informations nécessaires au bon fonctionnement de l’entreprise, les équipes contournent, bricolent, créent des fichiers parallèles.

Le CRM devient un outil qu’on alimente sans vraiment s’en servir pour décider et les données qu’on y entre ne servent ni les reportings, ni les automatisations, ni l’IA qu’on espère un jour activer.

Les objets personnalisés sont la réponse structurelle à ce problème.

Dans HubSpot, c’est l’une des fonctionnalités les plus puissantes et les moins bien comprises de l’offre Entreprise. Bien utilisée, elle transforme un CRM générique en véritable outil de pilotage. Mal utilisée, elle crée plus de complexité qu’elle n’en résout.

Pourquoi votre CRM standard peut être insuffisant ?

Trois catégories de données pour une réalité qui en nécessite souvent plus

Tout CRM standard repose sur le même modèle : des contacts, des entreprises, des transactions.

Si ce triptyque couvre l’essentiel d’un cycle de prospection classique, il couvre peu de chose au-delà. Or dans une PME qui fonctionne, la réalité commerciale respecte rarement ce schéma, bien au contraire, elle l’excède presque toujours.

Il faut intégrer :

• Ce qu’on livre après la vente,
• Comment on renouvelle les commandes,
• Ce qu’on gère pour plusieurs entités d’un même compte,
• Les processus internes propres à votre secteur,
• …

Rien de tout ça ne fait partie des données à saisir dans un CRM générique. Face à ce décalage entre données nécessaires pour l’opérationnel et les données prises en compte par l’outil, les équipes s’adaptent. De façon prévisible, elles bricolent, contournent, créent des fichiers parallèles. Le CRM reste actif, alimenté, présentable. Mais il ne pilote en réalité qu’une partie du process commercial.

Il documente ce qu’on sait déjà, mais n’aide pas à décider ce qu’on doit faire pour améliorer les ventes.

Un décalage qui s’approfondi sans jamais alerter

Le désalignement entre la structure du CRM et la réalité de l’entreprise s’installe progressivement. On ajoute un champ ici, une convention non écrite là, un statut qu’on explique oralement aux nouvelles recrues. Et pendant ce temps, le décalage entre l’attendu et la réalité grandit.

Les reportings deviennent difficiles à produire parce que la donnée est éparpillée. Les automatisations restent limitées parce qu’on ne peut pas déclencher un workflow sur une information non structurée. L’IA produit des résultats décevants parce qu’elle travaille sur un contexte incomplet. Et chaque nouvelle recrue, chaque nouveau client, chaque nouveau produit aggrave l’écart.

Les 4 signaux d’un CRM mal aligné sur le métier

Les objets personnalisés dans HubSpot

Un objet est une entité métier autonome

On croit fréquemment à tort qu’un objet personnalisé est un simple champs enrichi.

En réalité, un objet personnalisé, est un type de fiche spécifique, adaptée à l’organisation de l’entreprise. C’est une entité à part entière dans votre CRM, avec ses propres enregistrements, ses propres propriétés, ses propres automatisations et ses propres rapports.

Définition

Les composants d’un CRM

Un CRM sert à structurer l’information afin de l’utiliser pour développer l’activité.  Il existe de plusieurs façons de structurer l’information. Chacune répond à un besoin différent, et les confondre abouti souvent à une mauvais utilisation de l’outil.

Composant du CRM	Utilité	Ce qu’il ne fait pas
Propriété personnalisée	Ajoute un champ à une fiche existante	Ne crée pas de nouvelle entité
Association	Relie deux fiches entre elles	Ne décrit pas une entité autonome
Libellé d’association	Qualifie la nature du lien entre deux fiches	Ne porte pas de cycle de vie propre
Pipeline	Organise un processus par étapes	N’est pas une entité, c’est un parcours
Objet personnalisé	Crée un nouveau type de fiche autonome	N’est pas un simple champ ou une relation

En résumé :

• La propriété décrit
• L’association relie
• Le label qualifie
• Le pipeline ordonne
• L’objet stocke

La règle des 3 conditions pour décider

Avant de créer un objet personnalisé, posez-vous trois questions. Si les trois réponses ne sont pas un “oui” franc, il y a presque toujours une solution plus simple et moins coûteuse à maintenir.

1 – La donnée se répète-t-elle sous forme d’enregistrements distincts ?

Vous gérez plusieurs occurrences de la même entité, pas un attribut unique d’une fiche existante. Si votre entreprise a un seul contrat “courant” par client, une propriété suffit. Si elle en gère plusieurs avec des données différentes, un objet s’impose.

2- Chaque enregistrement a -t-il son propre cycle de vie ?

L’entité passe par des étapes, change de statut, a un responsable, une date d’ouverture, une date de clôture. Si elle n’évolue pas dans le temps et ne s’administre pas pour elle-même, ce n’est pas une entité, c’est une donnée.

3- Pilotez-vous, reportez-vous ou automatisez-vous sur cette entité ?

Vous avez des workflows à déclencher dessus, des rapports à construire, des alertes à configurer. Un objet qu’on ne pilote pas et qu’on n’automatise pas devient rapidement un stockage caché que personne ne maintient.

Quelles sont les mauvaises pratiques à éviter absolument ?

La plupart des mauvaises architectures CRM commencent par un objet créé pour de mauvaises raisons. Voici les erreurs les plus fréquentes et ce qu’il faut faire à la place.

Description de l’erreur	Pourquoi c’est un problème	La bonne alternative
Créer un objet au lieu d’une propriété	Complexité inutile pour un simple attribut	Propriété personnalisée sur la fiche existante
Dupliquer un objet natif	On perd les fonctionnalités natives (attribution, prévision…)	Objet natif + propriétés + labels + pipelines
Créer un objet sans cycle de vie	L’objet devient un conteneur de champs sans usage réel	Association label ou pipeline sur l’objet existant
Multiplier les objets sans gouvernance	Le modèle dérive, personne ne sait ce que chaque objet représente	Charte de modélisation + owner défini + documentation

Quels objets personnalisés pour quel type d’entreprise ?

La meilleure façon de comprendre les objets personnalisés n’est pas d’étudier leur définition mais de voir à quoi ils ressemblent.

Plateforme SaaS et abonnements : modéliser ce que le client possède après la vente

Un éditeur SaaS gère des clients avec plusieurs licences coexistantes, chacune à une date de renouvellement différente, un nombre de sièges distinct et un statut propre. Le deal dans le CRM représente la vente initiale pas ce que le client possède aujourd’hui.

Dans ce cas, trois entités méritent chacune leur propre objet :

• L’abonnement : un même client peut en avoir plusieurs simultanément, chacun avec ses propres dates, son propre tarif et son propre statut
• L’espace de travail : chaque licence correspond à un environnement distinct, avec ses propres utilisateurs et son propre niveau d’usage
• L’événement de renouvellement : chaque renouvellement a sa propre échéance, son propre commercial responsable et son propre processus de validation.

Scénario : 60 jours avant chaque renouvellement, un workflow déclenche automatiquement une séquence de suivi commercial. L’objet “Abonnement” porte la date, le nombre de sièges et le responsable sans qu’un humain ait à vérifier manuellement.

Industrie et distribution : suivre ce qu’on a installé, pas seulement ce qu’on a vendu

Un industriel qui vend des équipements ne gère pas seulement des transactions, il gère un parc installé. Chaque machine a une existence propre après la vente : elle tombe en panne, elle est entretenue, elle arrive en fin de garantie. Rien de tout ça ne rentre dans un deal ou une fiche contact.

Trois objets permettent de structurer cette réalité :

• Équipement installé : chaque machine est une entité distincte avec son numéro de série, sa date d’installation, son historique d’interventions et son statut de garantie. Un client peut en avoir vingt, chacune à un stade d’installation différent.
• Site client : Un client peut exploiter plusieurs sites géographiques, chacun avec ses propres équipements, ses propres interlocuteurs techniques et ses propres niveaux de service. Confondre site et entreprise génère des données impossibles à démêler.
• Contrat de maintenance : Le contrat de maintenance n’est pas l’accord initial, c’est un engagement distinct, avec ses propres dates, ses propres conditions et son propre processus de renouvellement. Il doit pouvoir être piloté indépendamment.

Scénario : le technicien saisit son rapport d’intervention directement sur la fiche “Équipement”. Un workflow alerte le commercial 30 jours avant la fin du contrat de maintenance. Le dirigeant voit en un tableau de bord combien d’équipements arrivent en fin de garantie ce trimestre.

Conseil et agences : piloter la mission, pas seulement la transaction

Pour un cabinet ou une agence, l’accord représente la vente pas la mission car il est possible d’avoir plusieurs mission pour un même client. Ainsi, ce qui mérite d’être suivi, n’est pas le contrat mais ce qui se passe pendant la mission : l’avancement, le budget consommé, les livrables produits, les avenants demandés. Ces informations n’ont aucune place naturelle dans un CRM standard. Sans objet dédié, tout atterrit sur la fiche entreprise et devient rapidement illisible pour quiconque n’a pas suivi le dossier depuis le début.

Trois objets structurent cette réalité :

1. Mission : lorsqu’il y a plusieurs missions simultanées chez un client, chacune avec ses propres intervenants, son propre budget et son propre avancement. La mission devient l’unité de travail le contrat n’est que l’aspect administratif de l’accord commerciale.
2. Livrable : chaque livrable a une date d’échéance, un statut et un responsable. Tracker les livrables sur la fiche mission permet de détecter les retards avant qu’ils impactent la relation client.
3. Avenant : quand le périmètre change en cours de mission, un avenant doit être documenté, validé et tracé. Sans objet dédié, les avenants se perdent dans des e-mails et la marge avec eux.

Scénario : chaque mission est associée au deal d’origine, à l’entreprise cliente et aux contacts impliqués. Les livrables sont trackés sur la fiche “Mission”. Quand le budget consommé dépasse 80%, un workflow alerte le directeur de mission avant que la marge ne dérive.

Franchises et réseaux : structurer sans tout centraliser

Dans un réseau de franchises ou de points de vente, le problème n’est pas le manque de données mais plutôt leur incohérence entre les entités. Le siège a besoin de visibilité consolidée. Chaque franchisé a besoin d’autonomie locale. Créer une entreprise par point de vente dans le CRM génère des doublons et efface la relation hiérarchique avec la tête de réseau.

Trois objets permettent de tenir les deux niveaux en même temps :

• Point de vente : chaque point de vente est une entité opérationnelle distincte, associée à la franchise parente. Il a ses propres performances, ses propres leads entrants et son propre animateur réseau, sans pour autant être une entreprise indépendante dans le CRM.
• Candidat franchisé : le recrutement d’un franchisé suit un processus distinct du cycle de vente classique : entretiens, validation financière, formation initiale, ouverture. Ce processus mérite son propre pipeline et ses propres étapes.
• Audit réseau : chaque visite d’audit produit des données propres à un point de vente à une date donnée. Sans objet dédié, les résultats d’audit s’accumulent dans des notes ou des fichiers sans jamais alimenter un pilotage réseau structuré.

Résultat concret : les leads entrants sur le site central sont routés automatiquement vers le bon point de vente selon le code postal. Le siège consulte les performances consolidées par région sans demander de rapport à chaque franchisé.

Comment implémenter correctement des objets personnalisés dans HubSpot ?

Créer un objet personnalisé prend dix minutes dans HubSpot. Défaire une mauvaise architecture CRM prend des mois. La différence entre les deux, c’est ce qu’on fait avant de cliquer sur “Créer” à savoir : la gouvernance, les rôles, le test, et l’ordre dans lequel on déploie.

Avant de créer : la fiche de gouvernance à rédiger

Un objet personnalisé crée une structure dans votre CRM qui sera utilisée par vos équipes, alimentée par vos intégrations et interrogée par vos automatisations. Son nom interne, choisi à la création, ne pourra plus être modifié. C’est une décision d’architecture, pas un paramétrage anodin.

Avant de vous lancer dans l’utilisation d’HubSpot, rédigez une fiche de gouvernance pour chaque objet envisagé.

Elle doit répondre à huit questions :

Nom métier et nom interne : Comment s’appelle cet objet dans le langage de l’entreprise, et quel identifiant technique choisit-on (sachant qu’il ne pourra plus changer).

Description d’usage : Qu’est-ce que cet objet représente exactement, et pourquoi un champ ou une association ne suffit pas.

Identifiant unique : Quelle propriété identifie chaque enregistrement de façon unique et permet d’éviter les doublons lors des imports ou des synchronisations API.

Propriétés obligatoires : Quels champs doivent être renseignés à la création sans lesquels l’enregistrement est inutilisable.

Associations autorisées : À quels autres objets cet objet sera-t-il relié (contacts, entreprises, deals, tickets, autres objets personnalisés).

Pipeline éventuel : Cet objet passe-t-il par des étapes et si oui, lesquelles, avec quelles règles de transition.

Usages de reporting et d’automatisation : Quels rapports veut-on produire, quels workflows veut-on déclencher (avant de créer, pas après).

Propriétaire et source de vérité : Qui est responsable de cet objet dans le temps, et quelle est la source principale d’alimentation (saisie manuelle, import, API, synchronisation.)

Les rôles : qui décide, qui exécute, qui valide

Un objet personnalisé n’est pas une décision technique, c’est une décision d’entreprise. L’erreur la plus fréquente est de laisser l’administrateur CRM décider seul de l’architecture, sans que les équipes métier ni la direction n’aient validé le besoin.

Le résultat : un objet techniquement bien créé, mais qui ne correspond pas à la façon dont les équipes travaillent réellement.

Décision	Qui décide	Qui exécute	Qui valide
Créer un nouvel objet	Direction / RevOps	Admin CRM	Équipe métier
Définir les propriétés	Équipe métier	Admin CRM	RevOps
Configurer les workflows	RevOps	Admin CRM	Direction commerciale
Valider avant déploiement	RevOps	Admin CRM	Direction

Le déploiement en 4 étapes

Un déploiement réussi ne commence pas par la création de l’objet, il commence par la validation du besoin et se termine par la formation des équipes. Voici l’ordre à respecter.

1. Valider le besoin avec les 3 conditions : Avant tout, appliquer la règle des 3 conditions. Si les trois réponses ne sont pas “oui”, chercher une solution plus légère (propriété, association ou élément natif HubSpot).
2. Rédiger la fiche de gouvernance : Compléter les huit points de gouvernance avant d’ouvrir HubSpot. Cette fiche devient la documentation de référence de l’objet pour les équipes actuelles et futures.
3. Tester dans le sandbox HubSpot : Créer l’objet dans l’environnement sandbox avant de le déployer en production. Tester les propriétés, les associations, les workflows et les rapports. Attention : les identifiants diffèrent entre sandbox et production, certaines intégrations devront être reconfigurées.
4. Déployer, former, ajuster : Déployer en production, former les équipes sur le nouvel objet et ses usages, puis ajuster les propriétés et les workflows dans les premières semaines selon les retours terrain.

Le coût et le ROI à attendre

Les objets personnalisés sont réservés à l’offre HubSpot Entreprise. C’est le point de passage obligé. Au-delà de la licence, le coût réel comprend le temps de configuration, l’accompagnement d’un partenaire si le modèle est complexe, et la maintenance dans le temps.

En face de ce coût, les gains mesurables sont concrets :

• réduction du temps de reporting,
• suppression des fichiers parallèles,
• automatisations opérationnelles sur des entités qui ne l’étaient pas,
• contexte métier plus riche qui améliore directement la pertinence des suggestions IA (point souvent sous-estimé).

Ce qu’il faut retenir

FAQ sur les objets personnalisés