Les permissions de Shaire et ce que nous avons refusé

Les permissions sont cette partie de l’outil qu’on ne remarque que lorsqu’elles sont mal conçues. Voici comment fonctionne notre modèle, y compris les éléments que nous avons délibérément laissés de côté.

Deux mécanismes, pas un seul

Derrière la question « A-t-il le droit de faire ça ? », se cachent en réalité deux concepts distincts que Shaire traite séparément.

Les rôles de l’espace de travail définissent l’accès global d’un utilisateur. Il y en a quatre (Propriétaire, Administrateur, Membre et Invité) qui gèrent des actions comme la modification des paramètres ou l’invitation de nouveaux membres.

Les permissions par élément définissent ce qu’une personne peut faire sur un dossier précis. Elles s’appliquent au cas par cas, selon l’action requise.

Garder ces deux notions séparées est essentiel. C’est en les mélangeant qu’on se retrouve avec des usines à gaz de vingt rôles différents, sans que plus personne ne comprenne qui a le droit de faire quoi.

Une échelle à quatre niveaux

Nos accès fonctionnent comme une échelle stricte, et non comme une liste de cases à cocher :

• Lecture — Idéal pour montrer l’avancement d’un projet sans risquer la moindre modification.
• Commentaire — Parfait pour récolter des feedbacks sans céder le contrôle du contenu.
• Édition — Le niveau standard pour collaborer sur le fond.
• Contrôle total — Permet de partager, renommer, déplacer ou supprimer l’élément.

Cette logique d’échelle signifie que chaque niveau inclut le précédent. Si une personne hérite de deux niveaux d’accès différents, c’est toujours le plus fort qui l’emporte.

Les droits vivent sur les dossiers

Une tâche hérite des droits de sa liste. Une liste hérite du dossier qui la contient, et les sous-dossiers héritent du dossier parent. C’est simple, prédictible et redoutablement efficace. Nous n’avons pas créé de permissions à la tâche ou à la page, car une règle compréhensible en une phrase vaut cent fois mieux qu’une flexibilité que personne ne sait gérer.

La gestion des dossiers privés

Passer un dossier en privé a deux effets immédiats :

1. Cela coupe l’héritage descendant : le dossier ne reçoit plus les droits de son parent.
2. Cela suspend l’accès par défaut des membres pour toute l’arborescence qui en découle.

Sous un dossier privé, la cascade de droits reprend normalement. C’est pourquoi un seul accès donné sur un dossier privé débloque tout ce qu’il contient. Et comme le statut « privé » n’écrase pas les données de permissions, le fait de rendre le dossier public à nouveau restaure instantanément les accès précédents.

Pensez « Équipes » plutôt qu’« Individus »

Dans Shaire, vous pouvez donner l’accès d’un dossier à une équipe entière. Donnez le contrôle du dossier « Design » à l’équipe Design, et le nouveau graphiste qui vous rejoint en novembre y aura accès dès son arrivée. Finis les oublis où le petit nouveau passe sa première semaine à demander des accès sur Slack.

S’il ne peut pas le voir, c’est une 404

Si vous n’avez pas accès à un élément, essayer d’y accéder vous renverra une erreur « 404 Introuvable » plutôt qu’un « 403 Interdit ». Vous dire « Cet élément existe mais vous n’y avez pas accès », c’est déjà fuiter une information. En revanche, si vous pouvez voir l’élément mais que votre niveau de droit est insuffisant pour agir, vous obtiendrez bien une erreur 403.

Le refus : la fonctionnalité que nous avons bannie

On nous demande souvent de pouvoir créer des exceptions négatives : « Donne l’accès à tout le monde, sauf à Sam ». Cela paraît anodin, mais c’est la fonctionnalité qui rend un système de permissions impossible à auditer. Au lieu de suivre une simple chaîne d’accès, vous devez croiser toutes les règles pour savoir laquelle gagne.

Dans Shaire, l’accès est uniquement accordé, jamais révoqué. Si Sam ne doit pas voir le dossier, Sam ne doit simplement pas être dans le groupe qui y a accès.

Un bon système de permissions doit être prédictible. Le nôtre l’est.