Acces et roles
L'acces determine qui voit quoi et qui peut faire quoi dans le portail. Pour le proprietaire et l'administrateur, ce n'est pas une simple liste de cases a cocher, mais un modele de responsabilite : l'employe travaille avec ses propres taches et clients, le responsable voit son departement, et les donnees des autres restent fermees tant que l'acces n'a pas ete accorde de maniere consciente.
Cette page explique le modele d'acces. Sa configuration se trouve dans la section d'administration du portail : voir Administration du portail.
Roles
Repère conceptuel, pas une capture UI ni une preuve de données du portail.
L'acces repose sur trois roles :
- Administrateur : configure le portail, les droits et les politiques ; voit et gere un large perimetre.
- Responsable : est responsable de son departement ou de son domaine ; voit le travail de son equipe.
- Employe : travaille avec ses propres taches, clients et documents.
Le role definit le niveau d'acces de base, tandis que les droits precis sont affines par des politiques par perimetres et par modules.
Perimetres d'acces
Repère conceptuel, pas une capture UI ni une preuve de données du portail.
L'acces n'est pas accorde "a tout d'un coup", mais par perimetres. Un perimetre correspond aux limites dans lesquelles s'applique un droit : l'entreprise entiere, un departement, un pipeline, une etape, un projet ou un utilisateur precis.
Ainsi, un meme employe peut disposer d'un large acces dans son projet et d'aucun acces dans celui d'un autre. Cela permet d'ouvrir exactement ce qui est necessaire au travail, sans reveler l'inutile.
Droits : lire, modifier, gerer
Repère conceptuel, pas une capture UI ni une preuve de données du portail.
Dans chaque perimetre, un droit se compose de plusieurs niveaux :
- Lire : voir les objets et leur contenu ;
- Creer : creer de nouveaux objets ;
- Modifier : editer les objets existants ;
- Gerer : configurer l'acces et les regles dans ce perimetre.
Distinguez les niveaux de maniere consciente : le droit de voir ne signifie pas le droit de modifier, et le droit de travailler ne signifie pas le droit de distribuer l'acces a d'autres.
Ce qu'une regle controle
Repère conceptuel, pas une capture UI ni une preuve de données du portail.
Le selecteur couvre taches et CRM, ainsi que workflows, chats, projets, utilisateurs, entreprise, temps, automatisation, assistant IA, operations et documents. Choisissez perimetre et role. Pour un service, la valeur peut etre explicite, heritee du parent ou issue du fallback; Appliquer aux enfants la propage. Creer et Gerer sont distincts de Lire et Modifier.
Les regles de taches controlent l'affectation vers le bas, vers le haut et entre services, avec direction, profondeur, roles et listes d'utilisateurs independants de la visibilite. Dans le CRM, visibilite et cible pipeline/etape sont dans la meme regle; laissez ces champs vides si aucun perimetre ne s'applique.
Pour les modules dotés d’un schéma d’automatisation, l’éditeur affiche aussi des capacités sous les droits CRUD. Pour chaque capacité, choisissez Autoriser, Refuser ou Hériter ; ce réglage est distinct de lire, modifier et gérer. Les actions groupées appliquent un état à toutes les capacités. Pour l’assistant, des préréglages facultatifs couvrent les réponses, les réponses et actions, ou le retour à l’héritage. Ils modifient la règle uniquement et ne lancent aucune automatisation.
Si une règle de service hérite du parent ou du fallback du module, ces contrôles restent désactivés jusqu’au choix d’une source explicite. Si le schéma manque, le bloc affiche cet état au lieu d’accepter un nom technique saisi à la main.
Pour Operations, la liste commence par les droits enregistres pour le module Operations et leurs libelles localises lisibles. Un droit deja enregistre dans la politique reste visible meme s'il ne figure pas dans la liste habituelle du module, afin de pouvoir le verifier et le modifier deliberement. Une liste plus courte ne retire pas l'acces : avant d'enregistrer, verifiez Autoriser, Refuser ou Heriter pour chaque droit visible et ne tapez pas de nom technique a la main.
Verifier et annuler les changements
Repère conceptuel, pas une capture UI ni une preuve de données du portail.
Supprimer une regle ou appliquer une revision exige une raison. Les longs resumes de l'historique sont extensibles. Explain et Simulate verifient l'acces CRM sans modifier la regle.
Mode d'acces par defaut
Repère conceptuel, pas une capture UI ni une preuve de données du portail.
Pour les modules, on definit un mode d'acces par defaut, c'est-a-dire ce qui se passe lorsqu'aucune regle explicite n'existe :
- Strict : par defaut l'acces est ferme ; seul ce qui est explicitement autorise par une politique s'ouvre. Convient aux donnees sensibles et aux grandes entreprises.
- Ouvert : par defaut l'acces en lecture et en travail est ouvert, et les politiques restreignent certains perimetres. Convient a une petite equipe avec un haut niveau de confiance.
Il est plus sur de commencer par le mode strict dans les modules contenant des donnees clients et financieres, puis d'ouvrir l'acces au fur et a mesure des besoins.
Historique des changements et justification
Repère conceptuel, pas une capture UI ni une preuve de données du portail.
Modifier un acces est une decision de gestion, et non une retouche discrete. C'est pourquoi, lors de la modification d'une politique, le systeme demande d'indiquer une raison du changement, et l'historique des modifications est conserve : on voit qui a change l'acces, quand et pourquoi.
C'est important pour le controle et l'analyse des incidents : si quelqu'un a vu quelque chose de trop ou, au contraire, a perdu un acces, l'historique permet de comprendre quel changement en est la cause.
Le journal utilise des libellés compréhensibles pour les champs modifiés et n’affiche
ni noms internes de champs ni détails techniques. Lorsqu’un champ n’a pas de libellé associé,
il est résumé par +N au lieu d’exposer des données techniques. Après l’enregistrement
d’une règle, le registre bascule vers son module afin que la nouvelle ligne reste
visible ; vérifiez-la à cet endroit puis relisez l’accès obtenu.
Bonnes pratiques
Repère conceptuel, pas une capture UI ni une preuve de données du portail.
- Accordez l'acces par perimetre et par role, et non "au cas ou" a toute l'entreprise.
- Distinguez le droit de voir du droit de modifier ; reservez le droit de gerer l'acces a un cercle restreint.
- Dans les modules contenant des donnees clients et financieres, conservez le mode strict par defaut.
- Lors de la modification d'une politique, indiquez une raison claire : elle restera dans l'historique.
- Reexaminez periodiquement les acces : retirez ceux devenus inutiles lorsque les roles et les projets changent.
Erreurs frequentes
Repère conceptuel, pas une capture UI ni une preuve de données du portail.
- Accorder un large acces a toute l'entreprise au lieu d'un acces par perimetre.
- Confondre le droit de voir et le droit de modifier : l'employe modifie par erreur les donnees d'autrui.
- Laisser le mode ouvert par defaut dans un module contenant des donnees sensibles.
- Modifier des politiques sans raison : il devient ensuite impossible de comprendre pourquoi l'acces est devenu tel.
- Ne pas reexaminer les acces apres un changement de role ou la fin d'un projet.
Sections liees
Repère conceptuel, pas une capture UI ni une preuve de données du portail.