Rôles et autorisations

Pathrule commence comme un outil individuel et devient un produit d'équipe. Dès que vous invitez des collègues, une question se pose : qui peut voir et modifier quoi ? Cette page présente les rôles que vous attribuez, la façon dont l'accès se restreint de l'organisation à l'espace de travail, et l'endroit où la vérification a réellement lieu.

En résumé : les rôles sont attribués au niveau de l'organisation, l'accès peut être restreint par espace de travail, et chaque lecture et chaque écriture sur un espace de travail Pathrule Cloud est vérifiée par la base de données au regard de l'utilisateur connecté. La même vérification s'applique, que la requête provienne de la console web sur app.pathrule.io, du CLI Pathrule, de l'extension VS Code ou du serveur MCP utilisé par un client IA.

Un espace de travail local créé avec --local n'a pas de compte et réside sur une seule machine : les rôles ne s'y appliquent donc pas tant que vous ne l'avez pas déplacé vers le cloud.

Les quatre rôles

Les rôles sont attribués à chaque personne au niveau de l'organisation. Un propriétaire ou un administrateur invite un collègue par e-mail et choisit son rôle (Editor par défaut) ; le collègue accepte l'invitation pour rejoindre l'organisation. Invitez depuis Members dans la console web, ou depuis le terminal :

pathrule invite colleague@example.com --role viewer

Quelques garde-fous en découlent :

• Les changements de propriété exigent l'autorité d'un propriétaire, et l'organisation doit conserver un propriétaire.
• Les changements de propriété et de membres sont vérifiés côté serveur, y compris l'obligation de conserver un propriétaire.

Les changements de membres exigent une session autorisée en cours de validité. Les actions sensibles d'archivage et de suppression d'un espace de travail exigent en plus une authentification récente.

Sièges et offres

Chaque personne de l'organisation occupe un siège, quel que soit son rôle.

• Solo et Pro sont prévus pour une seule personne. Ils ne permettent pas d'inviter ; pour travailler à plusieurs, passez à Team.
• Team est facturé par siège, avec un minimum de deux, propriétaire compris. Inviter au-delà des sièges payés nécessite un siège supplémentaire ; si vous avez moins de sièges que de membres, tout le monde conserve son accès et les nouvelles invitations restent en attente.
• Les sièges Enterprise sont convenus avec l'équipe commerciale.

Les sièges et les factures se trouvent sous Billing dans la console web ; pathrule billing l'ouvre depuis le terminal. Consultez Pathrule Web.

Accès aux espaces de travail : toute l'organisation ou privé

Un rôle définit ce qu'une personne peut faire. Le mode d'accès d'un espace de travail définit qui peut y accéder tout court. Chaque espace de travail relève de l'un de ces deux modes.

• Toute l'organisation. Chaque membre de l'organisation y a accès, avec son rôle d'organisation.
• Privé. Seules les personnes explicitement ajoutées à l'espace de travail y ont accès. Être membre de l'organisation ne suffit pas.

Les propriétaires et les administrateurs changent ce mode dans les paramètres de la console web, sous Workspace, Access. Lorsqu'un espace de travail devient privé, seuls ses membres explicites y ont accès. Vérifiez la liste et ajoutez les personnes qui en ont besoin : l'appartenance à l'organisation ne donne plus accès à elle seule. Dans un espace de travail privé, c'est le rôle de la personne dans cet espace qui détermine ce qu'elle peut y faire ; vous pouvez donc lui accorder un niveau d'accès différent de celui dont elle dispose ailleurs.

Perdre un accès ne détruit rien

Les changements d'autorisations ne détruisent jamais le travail et ne le masquent que rarement.

• Perte du droit d'écriture (par exemple, passage de Editor à Viewer) : rien ne disparaît. Vous pouvez toujours lire tout ce que vous pouviez lire auparavant ; les écritures faites par vous, ou par un assistant agissant en votre nom, sont refusées.
• Perte de l'accès à un espace de travail (retrait d'un espace de travail privé ou de l'organisation) : c'est seulement dans ce cas que son contenu disparaît de votre vue. Le contenu reste à l'équipe.

La même limite s'applique à l'assistant. Lorsqu'un client IA tente d'écrire là où un membre n'a pas le droit d'écrire, l'appel d'outil MCP renvoie un refus d'autorisation explicite que l'assistant peut vous relayer en langage clair, au lieu d'échouer en silence ou de donner l'impression d'avoir réussi. Le contexte reçu par un assistant, ainsi que les fichiers d'instructions que Pathrule écrit pour lui, proviennent exclusivement des espaces de travail que ce membre peut lire.

Où la vérification a lieu

Rien de tout cela n'est appliqué dans l'application que vous utilisez à un instant donné. Chaque lecture et chaque écriture sur un espace de travail Cloud passe par un contrôle d'accès en base de données, résolu en fonction de l'utilisateur connecté, de son appartenance à l'organisation et du mode d'accès de l'espace de travail. Les contrôles d'accès font partie des opérations de base de données du serveur ; ce n'est pas un simple bouton masqué dans l'interface.

• Une seule vérification pour toutes les surfaces. La console web, le CLI Pathrule, l'extension VS Code, le serveur MCP local et Remote MCP passent tous par le même contrôle d'accès appliqué par la base de données. Une modification depuis le terminal et une écriture depuis un client IA sont soumises aux mêmes règles.
• Aucune clé d'administration partagée. Chaque surface utilise un token de courte durée propre à l'utilisateur, jamais une clé de service partagée qui pourrait ouvrir les données d'une autre équipe. Un client compromis ne peut jamais atteindre que ce à quoi cet utilisateur a déjà accès.
• Résolution côté serveur. Les rôles d'organisation et d'espace de travail sont résolus sur le serveur, sans faire confiance au client : une requête modifiée ne peut pas s'octroyer un accès qui ne lui a pas été accordé.

Pour une vue complète de la protection du cloud, consultez la présentation de la sécurité.

En auto-hébergé

L'édition Enterprise auto-hébergée exécute le même modèle de rôles et d'autorisations dans votre propre compte Cloudflare. Les rôles et les modes d'accès aux espaces de travail se comportent de la même façon ; la différence est que les données et la base de données résident dans votre compte. L'authentification unique via votre propre fournisseur d'identité est mise en place dans le cadre du contrat Enterprise et s'appuie sur les mêmes rôles d'organisation décrits ici. Consultez Enterprise auto-hébergé pour comprendre le fonctionnement de ce déploiement.