---
title: "Modèle d'accès"
description: "L'appartenance à un espace, les rôles owner/writer/reader, un principal unifié, et la confidentialité par l'auto-hébergement — pas par le chiffrement E2E."
---

# Modèle d'accès

Dans Notarium, l'accès s'accorde à l'échelle de l'espace. L'appartenance à un espace assortie d'un rôle est l'unité d'accès : un membre voit tout ce que contient l'espace, un non-membre n'y voit rien. Le même modèle vaut pour les personnes comme pour les agents IA : les uns et les autres obtiennent l'accès par un seul et même mécanisme.

## Rôles

L'appartenance à un espace est un triplet : « espace + participant + rôle ». Il existe trois rôles :

| Rôle | Permissions |
|---|---|
| `reader` | Lit tout dans l'espace : notes, recherche, graphe, le Fil, historique, export |
| `writer` | Tout ce que peut faire un reader, plus la création, la modification et la suppression de notes |
| `owner` | Tout ce que peut faire un writer, plus la gestion des appartenances de l'espace |

Le rôle reader est réellement en lecture seule : l'interface masque toute action d'écriture (créer, modifier, supprimer, glisser-déposer, restaurer depuis la corbeille), et le serveur les rejetterait de toute façon.

On ne peut pas accorder l'accès à une partie seulement d'un espace : pour partager un sous-ensemble de notes, on crée un espace distinct. Il n'existe pas non plus de permissions par note (ACL par note) — l'accès ne s'accorde qu'à l'échelle de l'espace.

## Le principal unifié

Un principal, c'est quiconque effectue une action : une personne dotée d'une session, ou un agent IA muni d'un jeton personnel (PAT). Tous deux passent par un même mécanisme d'octroi, et chaque requête traverse la même vérification : « ce principal peut-il effectuer cette action sur cette ressource ? »

L'accès effectif est l'intersection de deux choses : **ce qu'autorise le compte** (le plafond de permissions du jeton) et **là où le principal est membre**. La session d'une personne culmine aux actions de gestion ; le jeton d'un agent est plafonné à la lecture ou à l'écriture. Les actions de gestion (émettre des jetons, modifier les appartenances) se situent au-dessus du niveau d'écriture : ainsi, un jeton d'agent qui fuite ne peut ni accorder d'accès ni émettre un nouveau jeton. Pour en savoir plus sur les jetons et le raccordement des agents, voir [Connecter un agent](/docs/agents/connect/) et [Sécurité et visibilité](/docs/agents/security/).

Chaque utilisateur dispose de son propre espace personnel, impossible à supprimer — une base de connaissances privée que personne d'autre ne peut atteindre : on ne peut pas inviter un second participant dans un espace personnel (le serveur l'interdit).

> [!note] Administrateur de l'hôte ≠ accès aux données
> Gérer les utilisateurs et rétablir l'accès relève d'une couche distincte de la lecture du contenu. L'administrateur de l'instance crée les utilisateurs et répare les appartenances, mais pour lire les données d'un espace, il lui faut en être membre. Une requête faite sans octroi renvoie la même réponse « introuvable » qu'une requête vers quelque chose d'inexistant — impossible, donc, de sonder par force brute pour découvrir ce qui existe.

## Confidentialité : auto-hébergement, pas E2EE

Notarium n'est délibérément **pas** un produit à chiffrement de bout en bout (E2EE). Un serveur intelligent — recherche plein texte et sémantique, historique des versions, agents IA à l'œuvre — exige par nature l'accès au contenu en clair. Le chiffrement de bout en bout exclurait ces fonctionnalités.

La confidentialité se construit donc autrement : vous conservez le serveur et les fichiers chez vous (auto-hébergement), et les données restent vos fichiers Markdown, sans jamais quitter votre infrastructure. C'est un parti pris assumé : la garantie de confidentialité tient à la possession, non à une cryptographie que le serveur ne pourrait pas voir.

> [!warning] Ce que cela veut dire en pratique
> Le serveur voit le contenu de vos notes en clair — faute de quoi il ne pourrait ni y effectuer de recherche ni les transmettre aux agents. S'il vous faut un modèle où le serveur ne peut absolument pas lire une note, Notarium ne le propose pas. Notarium ne chiffre pas les notes individuelles côté client.

Notarium est conçu pour un auto-hébergement en instance unique : ni inscription ouverte, ni cloud multi-locataire.

Sujets connexes : [Espaces et projets](/docs/concepts/spaces-and-projects/) — les unités d'isolation, [L'humain et les agents](/docs/concepts/human-and-agents/) — l'accès partagé à la base de connaissances, [Authentification](/docs/self-hosting/authentication/) — modes de connexion et jetons.