Contrôles de protection
Un contrôle de protection est une règle qui empêche d'exécuter une opération tant qu'une condition n'est pas remplie. Par exemple : impossible de faire passer une affaire à l'étape « Contrat » tant que le montant n'est pas renseigné ; impossible de fermer une tâche tant que la liste de contrôle n'est pas terminée. Le contrôle se déclenche au moment de l'opération, affiche un message clair et indique précisément ce qu'il faut corriger.
Les contrôles de protection sont le « fusible » du processus : ils transforment un règlement issu d'un accord verbal en une règle que le portail applique de la même manière à tout le monde.
Ils se configurent à l'adresse /automation/operation-guards, ainsi que depuis l'automatisation CRM dans la section des contrôles.
Dans le CRM, un contrôle peut protéger une opportunité commerciale ou une demande de service : la finalité du pipeline choisi détermine les opérations disponibles. Les exemples d'affaire, de montant et de gain ci-dessous sont commerciaux ; pour un service, utilisez Delivery window — demo synthétique et aucune fiche ni montant réel.
Quand les contrôles de protection sont nécessaires
Il convient de créer un contrôle là où les collaborateurs « sautent » régulièrement une étape obligatoire :
- ils ferment une tâche avec une liste de contrôle non terminée ;
- ils font avancer une affaire dans le pipeline sans renseigner les champs obligatoires ;
- ils terminent une affaire en gain sans montant ni client ;
- ils lancent une action sans indiquer un motif obligatoire.
Si l'étape est souhaitable mais pas obligatoire, mieux vaut utiliser une suggestion ou une règle de tâche plutôt qu'un blocage strict.
| Outil | Arrête-t-il l'opération ? | Quand l'utiliser |
|---|---|---|
| Contrôle de protection | Oui, il bloque jusqu'à ce que la condition soit remplie | L'étape est obligatoire, elle ne peut pas être sautée |
| Suggestion | Non, elle ne fait que rappeler | L'étape est souhaitable, mais l'entreprise admet des exceptions |
| Règle de tâche | Non, elle exécute l'action elle-même | Il ne faut pas interdire, mais faire automatiquement quelque chose lors d'un événement |
De quoi se compose un contrôle
Un contrôle se construit à partir de trois parties :
- Opération — ce que l'on protège précisément (transition d'étape/de statut ou action).
- Condition — ce qui doit être rempli pour que l'opération aboutisse.
- Message — ce que verra l'utilisateur si la condition n'est pas remplie.
Formulez d'abord la règle avec des mots : « impossible de faire X tant que Y n'est pas réalisé », et ne configurez le contrôle qu'ensuite.
Quelles opérations peuvent être protégées
Le contrôle peut protéger une transition, une action liée, une création, un archivage ou une modification de champ :
- transition — changement d'étape d'une affaire ou de statut d'une tâche ;
- action — bouton ou opération sur une entité (tâche, affaire, projet).
- création — créer une entité CRM ;
- archivage — déplacer une entité CRM vers les archives ;
- modification de champ — modifier un champ ou une valeur sélectionnée.
Le nom de l'entité CRM dépend de l'objectif du pipeline : le scénario commercial parle d'une affaire, le scénario de service d'une demande. Les exemples de montant et de gain sont commerciaux uniquement ; pour le service, utilisez Delivery window — demo, sans fiches ni montants réels.
Portée
Un contrôle possède une portée : toute l'entreprise ou un pipeline spécifique. La portée détermine où la règle s'applique. Un contrôle ciblé sur un seul pipeline ne perturbe pas le travail des autres directions, tandis qu'un contrôle au niveau de l'entreprise fixe un standard obligatoire commun.
Conditions du contrôle
Une condition compare un champ ou un état de l'entité. Sont notamment disponibles :
- champ rempli / non rempli ;
- liste de contrôle terminée ;
- la valeur d'un champ figure dans une liste / n'y figure pas ;
- comparaison numérique (par exemple, montant supérieur à zéro).
Plusieurs conditions peuvent être combinées pour que l'opération n'aboutisse que si toutes les exigences requises sont satisfaites.
Message de blocage et suggestion
Si la condition n'est pas remplie, l'opération n'aboutit pas et l'utilisateur voit un message de blocage. Un bon message explique non pas « c'est interdit », mais ce qu'il faut faire : « Renseignez le montant de l'affaire avant de passer à l'étape "Contrat" ». Le contrôle peut mettre en évidence le champ concerné ou ouvrir la section appropriée, afin que l'utilisateur comprenne immédiatement où aller corriger.
Le message est l'interface du règlement. Un « Opération interdite » incompréhensible agace ; une suggestion claire fait gagner du temps.
Activation et propriété
Un contrôle n'agit qu'après son activation. Chaque contrôle doit avoir un propriétaire responsable du règlement : les contrôles entravent directement le travail des personnes, c'est pourquoi un contrôle oublié ou trop strict bloque le processus. La liste indique qui a modifié la règle et quand.
États et limites
- contrôle désactivé — l'opération aboutit sans restriction ;
- condition remplie — l'opération aboutit normalement ;
- condition non remplie — l'opération est bloquée et un message s'affiche ;
- contrôle trop large — il bloque des opérations qu'il ne devrait pas ;
- pas de droits de gestion sur la portée — le contrôle est accessible en lecture seule.
Bonnes pratiques
- Ne protégez que les étapes réellement obligatoires, et non tout sans distinction.
- Formulez le message comme une instruction : ce qu'il faut remplir ou terminer.
- Utilisez la mise en évidence du champ ou de la section pour orienter l'utilisateur.
- Limitez la portée du contrôle au pipeline concerné si la règle n'est pas générale.
- Désignez un propriétaire et révisez les contrôles lorsque le processus évolue.
Erreurs fréquentes
Bloquer une étape non obligatoire. Un contrôle strict là où une suggestion suffit ralentit le travail et entraîne des contournements.
Message incompréhensible. « Opération interdite » n'explique pas quoi faire et provoque des sollicitations du support.
Portée trop large. Un contrôle sur toute l'entreprise casse le travail des directions auxquelles il n'était pas destiné.
Contrôle sans propriétaire. Quand la règle gêne, on ne sait pas à qui s'adresser pour la modifier.
Comment vérifier le résultat
- lorsque la condition n'est pas remplie, l'opération est effectivement bloquée ;
- le message explique clairement ce qu'il faut corriger ;
- la mise en évidence mène au champ ou à la section appropriés ;
- lorsque la condition est remplie, l'opération aboutit sans entrave ;
- le contrôle n'affecte pas les opérations situées hors de sa portée.
Scénarios liés
Repère conceptuel, pas une capture d’interface ni une preuve d’état.