Actif crm functional Revu le 2026-09-30 crm/crm-customer-state-recalc.md

CRM — Recalcul automatique du statut commercial

Objectif

Sur la fiche client CRM, chaque entité reliée porte un statut commercial (« Prospect froid », « Prospect qualifié », « Prospect opportunité », « Client », « Ancien client », « Prospect abandonné »). Ce statut n'est pas saisi : il est déduit de l'activité réelle du client sur l'entité concernée.

Il est désormais recalculé automatiquement dès que cette activité change, sans aucune intervention.

Règles de calcul

Le statut d'une liaison client ↔ entité est déterminé par la première règle qui s'applique, dans cet ordre :

Situation du client sur l'entité	Statut
Un motif d'abandon est renseigné sur la fiche client	Prospect abandonné
Une affaire gagnée et signée encore en cours, ou une facture de moins de 12 mois	Client
Un abonnement Isi-App validé (entité Isi-Group)	Client
Une affaire terminée / abandonnée, ou une facture de plus de 12 mois	Ancien client
Une affaire en cours (non abandonnée)	Prospect opportunité
Au moins une action commerciale réalisée citant cette entité	Prospect qualifié
Un abonnement Isi-App en période d'essai	Prospect opportunité
Un abonnement Isi-App dont l'essai est expiré	Prospect qualifié
Un simple intérêt produit (tag produit posé sur la fiche)	Prospect froid
Aucun des cas ci-dessus	aucun statut déduit — la liaison n'est pas modifiée

Une action commerciale n'est prise en compte que lorsqu'elle est passée à l'état « Réalisé ». Une action simplement programmée ou annulée ne qualifie pas le prospect.

Quand le statut est-il recalculé

Le recalcul est déclenché automatiquement, sans intervention, dans les cas suivants :

Événement	Périmètre recalculé
Création d'une action commerciale	chaque entité cochée dans « Entités concernées »
Passage d'une action à « Réalisé » (ou tout changement de son état)	idem
Modification des « Entités concernées » d'une action	les entités ajoutées et celles retirées
Changement de client sur une action	l'ancien et le nouveau client
Suppression d'une action commerciale	les entités qu'elle citait
Création ou modification d'une affaire (état, produit, dates de signature / fin / envoi de devis, motif d'abandon)	l'entité du produit de l'affaire, ou toutes les entités du groupe si le produit n'en désigne aucune
Déplacement d'une affaire dans le kanban, abandon ou réactivation d'une affaire	idem
Liaison d'une entité à la fiche client (« Relier des entités »)	l'entité nouvellement reliée

Aucun bouton de recalcul manuel n'est proposé à l'écran. Une liaison dont le statut est resté faux (activité antérieure à cette évolution, donnée importée) se corrige au prochain événement qui la concerne, ou à la main : sur la fiche client, cliquer sur la puce de l'entité, choisir le statut puis Modifier.

Ce que le recalcul fait — et ne fait pas — d'une saisie manuelle

Le statut est une donnée calculée, pas un choix. Le statut proposé dans la modale « Relier des entités » n'est qu'une valeur de départ : dès qu'une règle s'applique, le recalcul la remplace. Deux règles n'ont même pas besoin d'activité sur l'entité — un motif d'abandon renseigné sur la fiche client (→ Prospect abandonné) et un simple tag produit correspondant au catalogue de l'entité (→ Prospect froid). Relier une entité en choisissant « Client » sur un prospect porteur d'un tag produit le ramènera donc à « Prospect froid ». La modale l'annonce sous le champ Statut : « Statut de départ : il sera recalculé automatiquement selon l'activité du client sur cette entité. » Pour imposer un autre statut, le corriger ensuite depuis la puce de l'entité (Modifier), qui ne déclenche aucun recalcul : la correction tient jusqu'au prochain événement qui concerne cette entité.
La liaison n'est jamais vidée de son statut. Quand aucune règle ne s'applique, le calcul ne produit rien et la liaison garde son statut courant. Conséquence : supprimer la seule action réalisée d'une entité (ou la repasser en « Programmé ») ne la fait pas redescendre de « Prospect qualifié » — il faut corriger le statut à la main depuis la puce de l'entité (Modifier).
Le commercial « Suivi par » désigné manuellement n'est jamais remplacé. Le recalcul ne pose un suiveur déduit de l'affaire de référence que lorsque la liaison n'en a pas.

Ce qui a changé

Avant, deux défauts se cumulaient :

Aucun recalcul n'était déclenché par une action commerciale ni par la liaison d'une entité depuis les écrans actuels (fiche client, liste des actions, calendrier). Le statut ne bougeait qu'avec un événement d'affaire (création, modification, déplacement dans le kanban, abandon).
Les actions citant plusieurs entités n'étaient comptées pour aucune d'elles. Un prospect travaillé sur deux entités à la fois restait « froid » même après une action réalisée — c'est le cas constaté sur le client Novances.

Limites connues

Le recalcul passe par une file d'attente : le statut se met à jour quelques secondes après l'enregistrement, pas dans la réponse de l'écran. Rafraîchir la fiche client suffit à le voir.
Une action commerciale sans entité concernée (cas d'une action créée depuis un mail entrant) ne qualifie aucune liaison, et ne déclenche donc aucun recalcul.
Le recalcul ne sait que remplacer un statut par un autre, jamais en retirer un : voir « La liaison n'est jamais vidée de son statut » ci-dessus.
Les affaires « Abonnement Isi-App » générées par le générateur de devis et par la souscription prestataire ne déclenchent pas de recalcul immédiat : le statut suit au prochain événement qui concerne le client sur cette entité.
Aucun rattrapage n'est lancé sur l'existant : les liaisons déjà fausses avant cette évolution (comme celle de Novances) se corrigent au prochain événement qui les concerne.