Autorisations et portées de l'automatisation
L'automatisation influe directement sur le travail des personnes : elle modifie des tâches et des affaires, programme des étapes, envoie des courriels. C'est pourquoi son accès est réparti en niveaux et rattaché à une portée. Les autorisations répondent à deux questions : quoi l'utilisateur peut faire avec l'automatisation (consulter, configurer, exécuter) et où — dans quelle entreprise, quel pipeline ou quel projet.
Cette page explique le modèle d'autorisations afin que les rôles soient répartis de façon réfléchie, et non « tout pour tout le monde ».
Pourquoi séparer les autorisations
Si tout le monde dispose d'un accès complet, l'automatisation est facile à casser : modifier accidentellement la règle d'autrui, exécuter un processus métier sur des données de production, réattribuer des tâches. La séparation des autorisations protège le règlement : l'automatisation est configurée par celui qui est responsable du processus métier, tandis que les exécutants se contentent de réaliser leurs étapes.
Chaque opération sur l'automatisation est vérifiée : en l'absence d'autorisation, l'opération n'est pas exécutée et la réponse affiche un code de motif de refus (visible également dans l'historique des exécutions).
Niveaux d'autorisations
L'accès à l'automatisation se répartit en niveaux :
- consultation — voir les règles, robots, contrôles et processus métier, sans les modifier ;
- gestion — créer et modifier l'automatisation ;
- exécution — lancer l'aperçu et la simulation, exécuter manuellement, traiter les « étapes dues à exécuter » ;
- attribution — adresser les tâches manuelles aux personnes et les recevoir.
Les niveaux sont indépendants : on peut avoir la consultation sans la gestion, ou la possibilité d'exécuter des tâches sans le droit de modifier les modèles.
Consultation
Le droit de consultation donne accès aux listes d'automatisation et à l'historique, mais pas à la modification. C'est le niveau de base pour un responsable qui contrôle ce qui est activé et comment cela fonctionne, sans configurer lui-même les règles. Sans le droit de consultation, la section ou la ligne correspondante est inaccessible.
Gestion
Le droit de gestion permet de créer et de modifier l'automatisation : règles de tâches, robots CRM, contrôles de protection, modèles et processus métier. C'est le niveau du propriétaire du processus. La gestion dans une portée ne confère pas de droits dans une autre : celui qui configure les robots d'un pipeline ne gère pas nécessairement l'automatisation de toute l'entreprise.
Exécution
Le droit d'exécution est distinct de la gestion. Il permet de lancer l'aperçu d'une règle, la simulation d'un processus métier, d'exécuter l'automatisation manuellement et de traiter les « étapes dues à exécuter ». On peut ainsi donner à un collaborateur la possibilité de vérifier et d'exécuter l'automatisation en toute sécurité, sans lui ouvrir l'édition des modèles.
Attribution et réception des tâches
Des autorisations distinctes régissent les tâches manuelles des processus métier : qui peut adresser une tâche aux personnes et qui peut la recevoir. C'est important pour l'audience du processus métier : la tâche ne doit parvenir qu'à ceux à qui elle est destinée. Vérifiez que les bons collaborateurs figurent parmi les destinataires, et non un groupe plus large.
Portées
Les autorisations sont rattachées à une portée. L'automatisation et les contrôles peuvent agir au niveau de :
- l'entreprise — un standard commun pour tous ;
- le département — pour une unité précise ;
- le pipeline ou l'étape — pour une partie du processus de vente ;
- le projet — pour un contexte client précis.
Une autorisation dans une portée restreinte ne s'étend pas à une portée plus large : la gestion de l'automatisation d'un pipeline ne confère pas de droits sur l'entreprise. Accordez les autorisations dans la portée minimale suffisante — cela réduit le risque de modifications accidentelles.
Lecture seule et refus
Si un rôle ne dispose pas du droit d'agir dans la portée requise, l'automatisation apparaît en « lecture seule » et l'opération renvoie un refus avec un motif compréhensible. Ce n'est pas une erreur — c'est un modèle d'accès qui fonctionne. Lorsque l'action voulue est indisponible, vérifiez d'abord le niveau d'autorisation et la portée à laquelle se rattache l'automatisation, plutôt que de contourner la restriction.
Bonnes pratiques
- Accordez les autorisations par rôle : propriétaire du processus, responsable, exécutant.
- Séparez la gestion et l'exécution — tous ceux qui exécutent n'ont pas besoin de l'édition.
- Limitez la portée d'une autorisation au minimum suffisant.
- Vérifiez l'audience des tâches manuelles, pour que les étapes ne parviennent pas à des personnes superflues.
- Analysez les refus par code de motif, plutôt que d'accorder un accès complet « pour que ça marche ».
Erreurs fréquentes
Accorder la gestion à tous. Les règles d'autrui sont modifiées accidentellement, le règlement se casse.
Confondre exécution et gestion. Un collaborateur a seulement besoin d'un lancement, et on lui ouvre l'édition.
Portée d'autorisation trop large. Accès à l'automatisation de toute l'entreprise là où un seul pipeline aurait suffi.
Contourner le refus au lieu de l'analyser. Le motif de refus indique directement quelle autorisation ou portée fait défaut.
Comment vérifier les autorisations
- les sections d'automatisation nécessaires sont visibles sous le rôle de l'utilisateur ;
- la gestion n'est accessible que là où le rôle est responsable du processus métier ;
- l'exécution et la simulation fonctionnent sans le droit d'édition, si c'est ainsi prévu ;
- les tâches manuelles ne parviennent qu'à l'audience cible ;
- les refus sont explicables par code de motif et correspondent à la portée de l'autorisation.