Qui doit avoir le droit de créer des propriétés

Faut-il ouvrir la création de propriétés aux responsables d'équipe, ou la garder centralisée ?

Gardez-la centralisée, et pour une raison technique qui tranche le débat avant qu'il ne devienne politique.

L'autorisation de modifier les paramètres des propriétés n'est pas isolable. La documentation est explicite, elle donne aussi accès à la création et à la modification des pipelines et des phases.

Autrement dit, vous ne pouvez pas laisser un responsable créer une propriété sans lui laisser aussi la structure de vos pipelines. Ce n'est pas un arbitrage de confiance, c'est le périmètre de l'autorisation.

Et une seconde raison, moins connue. La restriction d'accès à une propriété n'est pas un contrôle de sécurité, elle est contournable par l'API.

Le piège à connaître. L'autorisation de modifier les paramètres des propriétés donne aussi accès à la création et à la modification des pipelines et des phases. Elle n'est pas isolable, c'est le périmètre du droit.

Pourquoi cette autorisation emporte aussi la structure des pipelines

Comprendre pourquoi la restriction de propriété ne protège rien. Vous pouvez, en Entreprise et en tant que super administrateur, restreindre la vue ou la modification d'une propriété. Mais la documentation prévient que tous les utilisateurs, quel que soit leur accès, peuvent définir ou modifier une propriété restreinte via l'API. C'est donc un outil de confort d'interface, pas de confidentialité.

Certaines propriétés ne se restreignent d'ailleurs pas du tout, dont l'email, le prénom, la phase du cycle de vie, le nom de transaction, le pipeline, la phase, la date de clôture, la devise et la date de dernière activité.

Restreindre a un coût visible pour les utilisateurs. Une propriété restreinte casse les vues enregistrées, les workflows, les rapports et les tableaux de bord des personnes qui n'y ont pas accès. Le rapport ne se charge simplement plus.

Les ensembles d'autorisations sont le bon outil pour industrialiser, avec trois pièges. Ils demandent Entreprise, sont plafonnés à cent, et leur création est réservée aux super administrateurs. Premier piège, on ne peut assigner que des autorisations que l'on possède soi-même. Deuxième piège, et il surprend, assigner un ensemble écrase les autorisations individuelles de la personne. Troisième piège, modifier un ensemble propage immédiatement le changement à tous ses porteurs.

Et le siège plafonne tout. L'accès réel d'une personne est la combinaison de son ensemble d'autorisations et de son siège, pas l'un des deux.

Un piège d'équipes imbriquées à connaître. Donner l'accès à une équipe enfant donne le même accès à l'équipe parente.

Sur la traçabilité, vous en savez plus que vous ne croyez, mais pas tout. La liste des propriétés se filtre par utilisateur créateur, et l'export contient le créateur, les usages et le taux de remplissage. En revanche la date de création n'est pas à l'export, elle n'est accessible que par API.

Et l'angle mort du journal d'audit vaut ici aussi. Les modifications de propriétés qui ne sont pas faites par un utilisateur, par exemple une soumission de formulaire, n'y apparaissent pas.

En pratique, décider qui peut créer des propriétés

Le modèle que nous recommandons

Une ou deux personnes portent l'autorisation de modifier les paramètres des propriétés. Tous les autres passent par une demande. C'est plus lent, et c'est précisément l'intérêt, parce qu'une bonne partie des demandes trouve une propriété existante qui fait déjà le travail.

Où se règle l'autorisation

Dans Paramètres, Utilisateurs et équipes, sur la fiche de l'utilisateur, onglet CRM, section des paramètres d'objet. Rappelez-vous qu'elle emporte les pipelines.

Comment industrialiser sans se piéger

Créez un ensemble d'autorisations par rôle réel, pas par personne.
Sachez qu'en l'assignant, vous écrasez les autorisations individuelles existantes. Notez-les avant.
Testez toute modification d'ensemble sur un utilisateur, puisque le changement se propage à tous immédiatement.

Retrouver qui a créé quoi

Dans la liste des propriétés, filtrez par utilisateur créateur. Pour un inventaire complet, exportez, vous obtiendrez le créateur, les usages et le taux de remplissage de chaque propriété.

Ce qu'il ne faut pas faire

Compter sur la restriction de propriété pour protéger une donnée sensible. Elle est contournable par l'API. Pour une donnée réellement sensible, c'est le stockage de données sensibles qu'il faut regarder.

À surveiller sur le droit de créer des propriétés dans HubSpot

L'autorisation de créer des propriétés emporte les pipelines et les phases. Elle n'est pas isolable.
La restriction de propriété est contournable par l'API. Ce n'est pas un contrôle de sécurité.
Certaines propriétés ne se restreignent pas, dont l'email, la phase du cycle de vie et le pipeline.
Une propriété restreinte casse les vues, workflows et rapports des utilisateurs sans accès.
Assigner un ensemble d'autorisations écrase les autorisations individuelles.
Modifier un ensemble se propage immédiatement à tous ses porteurs.
Le siège plafonne l'accès, quel que soit l'ensemble attribué.
Donner l'accès à une équipe enfant le donne à l'équipe parente.
La date de création d'une propriété n'est pas à l'export, seulement par API.

Quand nous contacter sur le droit de créer des propriétés dans HubSpot

Contactez Yuzu Corp pour construire vos ensembles d'autorisations. Le piège de l'écrasement des autorisations individuelles se paie cher sur un portail déjà peuplé, et il vaut mieux relever l'existant avant d'assigner.

Pour aller plus loin, découvrez le cas Thiga, audit, refonte et gouvernance HubSpot.

Auteur, sources et date de vérification

Rédigé par Quentin Préchoux
Fondateur de Yuzu Corp · 8 ans sur HubSpot · Nantes & Paris
Yuzu Corp est partenaire HubSpot Diamond et membre du Claude Partner Network
Publié le 31 août 2026 · Vérifié sur HubSpot le 31 août 2026