Passer au contenu
  • Il n'y a aucune suggestion car le champ de recherche est vide.

Phase du cycle de vie, statut du lead et phase de transaction

Ce que porte chacune des trois propriétés, le sens unique de la synchronisation entre entreprise et contact, et pourquoi le cycle de vie ne recule pas proprement.

Nous avons trois propriétés qui ressemblent à des étapes et personne ne sait laquelle piloter. Comment se répartissent-elles ?

Trois propriétés, trois portées, et elles ne se remplacent pas.

  • La phase du cycle de vie est portée par le contact et par l'entreprise. Elle décrit la maturité de la relation, d'abonné jusqu'à client.
  • Le statut du lead est un sous-découpage à l'intérieur de la phase de lead qualifié par les ventes. Il décrit l'effort de prise de contact.
  • La phase de transaction est portée par la transaction, via son pipeline. Elle décrit l'avancement d'une affaire.

La règle qui évite quatre-vingt-dix pour cent des erreurs. Une personne a une maturité, une affaire a un avancement. Ne faites pas porter l'avancement d'une affaire par la phase du cycle de vie.

Le piège à connaître. La phase du cycle de vie ne peut être avancée que par les outils HubSpot, jamais reculée. Pour redescendre il faut d'abord vider la valeur, et l'opération efface une partie de l'historique de dates.

Pourquoi ces trois propriétés HubSpot ne portent pas sur le même objet

La contrainte la plus structurante est que le cycle de vie ne recule pas. La documentation est explicite, la propriété ne peut être avancée que par les outils HubSpot, à savoir l'import, la soumission de formulaire, l'API, l'intégration Salesforce et les workflows. Pour redescendre, il faut vider la valeur d'abord, à la main ou par workflow.

Et le retour arrière abîme l'historique. La date d'atteinte de la phase la plus avancée est effacée, tandis que les nouvelles propriétés calculées ne sont pas effacées. Vous obtenez donc un historique de dates incohérent. Conséquence directe, ne modélisez pas un cycle non linéaire sur le cycle de vie. Un client perdu puis reconquis ne se raconte pas proprement avec cette propriété.

La synchronisation entre entreprise et contact est unidirectionnelle et optionnelle. Cochée, elle applique la phase de l'entreprise principale à ses contacts associés. L'inverse n'existe pas, une mise à jour sur un contact ne remonte jamais à son entreprise. Toute architecture orientée comptes doit donc piloter l'entreprise, pas le contact.

Cinq automatisations natives existent, et ce sont des interrupteurs. Définir la phase à la création d'une fiche, à la création d'une transaction, à la victoire d'une transaction, à l'association d'un lead, et synchroniser l'entreprise principale vers ses contacts.

Deux trous d'automatisation à connaître. Un lead créé par une automatisation ne met pas à jour la phase du cycle de vie. Et si vous désactivez l'automatisation de victoire, les propriétés de date de clôture et de délai de closing des contacts et entreprises associés ne sont plus alimentées, ce qui casse vos rapports de délai.

Un détail qui n'en est pas un. Sans règle de création active, une fiche prend la première phase dans l'ordre d'affichage. L'ordre est donc fonctionnel, pas cosmétique.

Enfin, le statut du lead n'a aucune automatisation native. La documentation propose seulement de l'automatiser par workflow. Si personne ne le remplit, il restera vide.

En pratique, répartir le pilotage entre les trois propriétés

La répartition que nous recommandons

Laissez la phase du cycle de vie aux automatisations natives. Elle avance quand une transaction est créée, puis quand elle est gagnée. N'y touchez pas à la main.

Servez-vous du statut du lead pour la prise de contact, et automatisez-le par workflow, sinon il ne vivra pas.

Réservez la phase de transaction à l'affaire. C'est la seule des trois qui décrit un cycle de vente.

Où régler quoi

  1. Les automatisations de cycle de vie se trouvent dans Paramètres, puis les réglages de l'objet concerné, section du cycle de vie.
  2. La personnalisation des phases demande des autorisations de super administrateur.
  3. Les règles interdisant de reculer ou de sauter une phase se trouvent dans l'onglet des règles de pipeline du cycle de vie.

Le test qui révèle une erreur de modélisation

Cherchez une fiche de contact avec la phase client et aucune transaction gagnée. Si vous en trouvez beaucoup, quelqu'un pilote le cycle de vie à la main, et vos rapports de conversion sont faux.

Avant d'ajouter une phase de cycle de vie

Sachez que chaque phase créée génère automatiquement son jeu de propriétés calculées de dates et de durées. Ajouter cinq phases, c'est ajouter plusieurs dizaines de propriétés.

À surveiller sur les trois propriétés d'étape de HubSpot

  • Le cycle de vie ne recule pas. Il faut vider la valeur avant de redescendre.
  • Un retour arrière abîme l'historique de dates, certaines sont effacées et d'autres non.
  • Ne modélisez pas un cycle non linéaire sur le cycle de vie.
  • La synchronisation va de l'entreprise principale vers ses contacts, jamais dans l'autre sens.
  • Un lead créé par automatisation ne met pas à jour la phase.
  • Sans règle de création, une fiche prend la première phase dans l'ordre d'affichage.
  • Le statut du lead n'a aucune automatisation native.
  • Chaque phase ajoutée crée son jeu de propriétés calculées.

Articles liés aux trois propriétés d'étape de HubSpot

Quand nous contacter sur les trois propriétés d'étape de HubSpot

Contactez Yuzu Corp si vos rapports de conversion ne correspondent pas à la réalité vécue par les équipes. Dans la plupart des cas que nous voyons, la cause est un cycle de vie piloté à la main en parallèle des automatisations natives.

Pour aller plus loin, découvrez notre offre RevOps.

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