Le contrôle des accès en pratique

Comment les accès se manifestent à l'écran, comment les concevoir pour un processus de souscription et comment diagnostiquer une commande manquante sans suraccorder.

Présentation

Savoir ce que chaque rôle peut faire est une chose. Raisonner lorsqu'une personne signale un bouton manquant en est une autre : c'est l'objet de cette leçon.

Ce que vous allez apprendre

Les deux façons dont l'accès se manifeste à l'écran
Où se situent réellement les lignes entre les trois niveaux
Comment attribuer l'accès pour un processus de souscription, selon la tâche plutôt que selon la séniorité
Comment diagnostiquer un signalement sans suraccorder

Comment l'accès se manifeste

Les commandes sont absentes, pas désactivées. Un Viewer ne voit pas un bouton Créer une société grisé ; il ne voit aucun bouton. Donc « le bouton a disparu » signifie généralement que le modèle d'accès fonctionne correctement plutôt qu'une anomalie.

Certaines pages affichent un indicateur explicite. Plusieurs portent un marqueur « Unable to edit » : la page des actionnaires, la table de capitalisation, le tableau de bord de souscription, la page des membres. Cela indique à un utilisateur en lecture seule que son état est intentionnel plutôt que de le laisser le déduire de l'absence.

Ensemble : si une commande manque et qu'il n'y a pas d'indicateur, vérifiez le rôle. S'il y a un indicateur, la réponse est déjà à l'écran.

Où se situent les lignes

	Ajouter un membre	Créer une société	Lancer un processus
Admin	Oui	Oui	Oui
Éditeur	Non	Oui	Oui
Lecteur	Non	Non	Non

La ligne Admin/Editor est tracée à la gestion des personnes. La ligne Editor/Viewer est tracée à la modification de quoi que ce soit.

Un Editor peut exécuter un processus de souscription complet. Il ne peut simplement pas décider qui d'autre rejoint le projet.

Concevoir les accès pour un processus de souscription

La question utile n'est pas « quel rôle cette personne a-t-elle », mais « que doit-elle faire ici ».

Qui	Ce qu'il lui faut
Membres de la deal team qui exécutent le processus	Éditeur : sociétés, actionnaires, processus
Personne qui gère les accès de l'équipe	Admin : généralement une ou deux personnes, pas toutes les personnes seniors
Partners, membres d'IC, finance ayant besoin de visibilité	Lecteur : réellement en lecture seule, et mieux que l'envoi de feuilles de calcul
Conseils ayant besoin d'un seul document	Demandez-vous s'ils ont vraiment besoin d'un accès
Personne qui travaille sur tous les projets	Ajoutez-la à chaque projet : les membres sont par projet

Diagnostiquer un signalement

Lorsqu'une personne dit qu'elle ne peut pas faire quelque chose :

Vérifiez son niveau sur ce projet : pas sur le projet auquel vous pensez.
Cherchez un indicateur « Unable to edit » sur la page concernée.
Confirmez que la commande existe pour quelqu'un. Certaines choses sont indisponibles à cause de l'état du processus plutôt que de l'accès : une enveloppe en attente de paiement, une transaction pas encore prête. Ce n'est pas un problème de permissions.
Alors seulement, changez le rôle, et passez au niveau le plus étroit qui permet l'action spécifique.

Cet ordre compte. Passer quelqu'un en Admin parce qu'un bouton manque est la réaction excessive fréquente, et elle accorde généralement beaucoup plus que nécessaire.

Problèmes fréquents

Un Viewer doit téléverser un document. Il ne peut pas. Soit il lui faut Editor, soit le téléversement doit être fait par quelqu'un qui l'a. N'accordez pas Admin pour un téléversement.

Tout le monde sur le projet est Admin. Alors l'accès de personne ne signifie quoi que ce soit. Admin sert à gérer les accès, pas à refléter la séniorité.

Quelqu'un a un accès qu'il ne devrait pas avoir. Les rôles sont par projet, donc retirer une personne d'un projet ne la retire pas d'un autre. Vérifiez chacun.

Une personne a quitté le cabinet. Son accès persiste par projet, et il n'existe pas dans la vue projet un endroit unique qui retire quelqu'un partout. Cela mérite une checklist plutôt que de la mémoire.