# Les jetons et les portées

Un agent n'a jamais un pouvoir à lui : il agit **avec le jeton nommé qu'on lui a donné**,
et ce jeton porte les mêmes règles que n'importe quel jeton créé à la main dans
*Réglages › Connexions et agents › Accès avancés*.

## Lecture et écriture

Un jeton porte une ou deux portées : `read` et `write`.

- **`read`** laisse lire — tous les `GET`, et les appels d'écriture passés en simulation
  (`dry_run`). C'est la portée d'un agent à qui l'on ne veut confier que la lecture d'un
  planning, un rapport d'avancement, un export.
- **`write`** est nécessaire pour tout le reste — chaque tool qui pose un bloc, déplace une
  ligne, répond à un commentaire. Un jeton en lecture seule qui tente un de ces tools reçoit
  un refus explicite (`SCOPE_INSUFFICIENT`), pas un succès silencieux.

Un jeton nommé né d'un `POST /oauth/authorize` porte les portées demandées par le client au
moment de l'autorisation (le formulaire de consentement les affiche) — Claude Code demande
en général les deux.

## Un jeton par client

Chaque client OAuth qui s'enregistre (Claude Code, Claude Desktop s'il passait par cette
porte, un autre agent) obtient son propre jeton, nommé d'après lui — « MCP · Claude Code »,
« MCP · `<nom du client> ` ». Ce n'est pas un jeton partagé : deux agents différents ont
deux jetons différents, deux lignes différentes dans *Réglages › Connexions et agents › Applications connectées*, et deux
attributions différentes dans le journal du planning (« Claude (vous) », ou « Claude
(Anne) » si le jeton agit pour un autre utilisateur que le propriétaire de l'instance).

Durée : **trente jours**, avec un rafraîchissement automatique valable **quatre-vingt-dix
jours** — un rafraîchissement à usage unique, remplacé par une paire neuve à chaque
utilisation ; le jeton d'accès change de secret, mais reste **le même jeton nommé** (le même
identifiant, la même ligne dans les préférences) tant que le client continue de se
rafraîchir à temps.

## La révocation

- Depuis *Réglages › Connexions et agents › Applications connectées* : révoquer un jeton nommé le coupe immédiatement, **et
  ferme sur-le-champ toute session `/mcp` vivante qu'il portait** — ses flux, ses
  abonnements aux resources compris. Un agent qui tentait un appel au même moment reçoit un
  401, pas une session qui traîne.
- Par le protocole OAuth lui-même : `POST /oauth/revoke` (RFC 7009) révoque un jeton
  d'accès, ou toute une famille de rafraîchissements à la fois — le point que Claude Code
  utilise pour se déconnecter proprement.
- Un jeton **rejoué** (un code d'autorisation ou un rafraîchissement présenté deux fois) est
  traité comme un vol probable : toute la famille de jetons qui en découle est révoquée sur
  l'instant.

## Ce qu'un agent peut faire, et ce qu'il ne peut pas

Un agent peut tout ce que les 101 tools couvrent : construire, modifier, analyser, partager,
publier, exporter et importer des **plannings** — et, depuis `0.22.0`, poser ou lire ses
propres **absences** (`list_absences`, `add_absence`, `remove_absence`,
`get_schedule_risks`). C'est volontairement large — c'est le produit.

Un agent **ne peut pas** :

- **gérer les jetons** (`/api/v1/me/tokens`) ni les sessions de l'écran
  (`/api/v1/me/sessions`) — un client MCP ne crée pas ses propres jetons, ni ceux d'un
  autre ;
- **changer le mot de passe, dénouer Google, ou écrire sur le profil**
  (`/api/v1/me/password`, `/api/v1/me/google`, `PUT /api/v1/me`) — ces routes sont réservées
  à une session d'utilisateur (le cookie de l'écran), refusées à tout jeton nommé avec un
  refus qui le dit explicitement (« les jetons se gèrent avec le jeton de l'écran, pas avec
  un jeton nommé ») ;
- **exporter ou supprimer le compte lui-même, ni changer qui vous êtes.** Ce n'est pas une
  restriction ajoutée après coup : il n'existe, parmi les 101 tools, aucun tool qui touche
  aux **réglages** du compte (mot de passe, profil, Google, export, suppression) — ceux-là
  restent réservés à une session d'utilisateur, comme ci-dessus. Seules vos **absences**
  (depuis `0.22.0`) sont une donnée personnelle qu'un tool peut poser ou lire, parce qu'un
  agent doit pouvoir dire « je suis absent » comme vous le diriez vous-même — jamais celles
  d'un autre compte que le vôtre, et jamais un motif médical (le schéma le refuse). Le
  droit à l'export et à l'effacement du compte **entier** (RGPD) reste à la personne ; ce
  n'est pas une capacité qu'on délègue à un agent qui agit en son nom, même avec un jeton
  `write`.

*(Point de vigilance pour ce dépôt : les routes API de l'export et de la suppression d'un
compte, ajoutées au sprint 16, ne sont pas présentes dans la lignée de branches d'où ce
guide est écrit — voir la clôture du sprint pour ce que cela signifie sur l'état de
`docs/agents/`. L'absence de tout tool MCP dédié au compte, elle, est vérifiable dans le
catalogue actuel indépendamment de ce point.)*

## Une vue embarquée n'est pas un jeton nommé

Dans un hôte MCP Apps, la [vue embarquée](vue-embarquee.md) (`show_schedule`) n'a **aucun
jeton à elle** : elle lit et écrit par l'hôte, sous le jeton nommé (ou l'OAuth) du
connecteur. Pour un client qui n'affiche pas les MCP Apps (Claude Code), `show_schedule`
rend une adresse portant un jeton **d'une heure**, plafonné au planning affiché et au rôle
de qui l'a demandée, **en lecture seule sauf `editable: true`** — un mécanisme différent des
jetons nommés de cette page, jamais visible ni révocable dans *Réglages › Connexions et agents › Applications connectées*. Sous
ce jeton, la liste des membres ne porte pas d'adresse e-mail, et l'agenda pas de motif
d'absence. Il expire de lui-même ; rien à retenir de plus ici.