# Permissions et approbation

Deux questions distinctes, deux blocs distincts. `permissions` dit qui peut mettre un [agent](/fr/docs/ai-agents) en mouvement. `approval` dit lesquelles de ses actions s'arrêtent pour attendre une personne une fois qu'il tourne.

## Qui peut invoquer

```yaml
agents:
  - name: support-agent
    role: support
    systemPrompt: You are a courteous support assistant.
    permissions:
      type: agent
      trigger: [admin, member]
```

| Propriété                 | Description                                                                                 |
| ------------------------- | ------------------------------------------------------------------------------------------- |
| `permissions.type`        | Discriminant de type d'utilisateur. Toujours `agent`.                                       |
| `permissions.trigger`     | Qui peut invoquer : `all`, `authenticated`, ou un tableau de rôles comme `[admin, member]`. |
| `permissions.emailDomain` | Domaine de l'adresse synthétique de l'agent. Vaut `agents.sovrium.local` par défaut.        |

`trigger` régit les surfaces d'invocation — le [panneau de chat](/fr/docs/ai-chat), l'API, une automatisation. Il ne régit **pas** ce que l'agent peut ensuite faire : cela reste son rôle plus sa [liste blanche d'outils](/fr/docs/agent-tools). Un `viewer` autorisé à déclencher un agent de rôle admin déclenche quelque chose de plus privilégié que lui : lisez donc `trigger` comme une délégation, et réglez-le délibérément.

## Approbation humaine dans la boucle

`approval` insère une personne entre la décision du modèle et son effet.

| Propriété             | Description                                                                                             |
| --------------------- | ------------------------------------------------------------------------------------------------------- |
| `approval.mode`       | `none` (exécuter aussitôt), `all` (tout attend), ou `selective`.                                        |
| `approval.required`   | Actions nécessitant une approbation — un sous-ensemble de `tools.actions`. Requis si `mode: selective`. |
| `approval.timeout`    | Secondes avant expiration d'une approbation en attente. Vaut `3600` par défaut.                         |
| `approval.escalation` | `{ after: <secondes>, to: <rôle> }` — confier une demande sans réponse à un autre rôle.                 |

```yaml
approval:
  mode: selective
  required: [record.delete, email.send]
  timeout: 1800
  escalation:
    after: 600
    to: admin
```

Lisez cela comme une chronologie. L'agent décide d'envoyer un courriel ; la demande part vers un humain. Dix minutes plus tard, personne n'a agi : elle escalade vers `admin`. Vingt minutes après cela, le délai expire et la demande s'éteint sans avoir été exécutée.

:::callout
**`after` doit être inférieur à `timeout`.** Une escalade programmée à l'expiration ou au-delà ne se déclenche jamais — la demande meurt avant que quiconque soit sollicité. Laissez après l'escalade assez de marge pour que le rôle escaladé puisse réellement répondre ; `after: 600` avec `timeout: 660` est techniquement valide et pratiquement inutile.
:::

## Choisir un mode

| Mode        | Approprié quand                                                                                       |
| ----------- | ----------------------------------------------------------------------------------------------------- |
| `none`      | Toutes les actions possibles sont réversibles et à faible enjeu. Un analyste en lecture seule.        |
| `selective` | L'essentiel du travail est routinier mais quelques actions sortent de l'immeuble. La réponse usuelle. |
| `all`       | Un agent tout neuf en qui vous n'avez pas encore confiance, ou dont tout le périmètre engage.         |

`selective` est le choix courant en pratique, et la discipline consiste à se demander, pour chaque action : si le modèle se trompe, puis-je annuler ? Un `record.update` sur une table auditée se rattrape. Un `email.send`, non — le message est parti. Un `auth.banUser` non plus, du point de vue de l'utilisateur banni.

Passer un nouvel agent en `all` pendant une quinzaine de jours est un moyen peu coûteux d'apprendre ce qu'il fait réellement avant de resserrer en `selective`. La file d'approbation fait alors office de journal d'intentions.

## Approbation et planification

Les exécutions planifiées respectent l'approbation. Un agent en `mode: all` sur un cron nocturne ne s'exécute pas à 3 h du matin — il met une demande en file, qui attend l'arrivée de quelqu'un et expire si `timeout` passe d'abord.

Cette combinaison est généralement une erreur, et elle mérite d'être nommée : un déclencheur sans surveillance associé à un garde-fou surveillé produit un agent qui, très fidèlement, ne fait rien la nuit. Soit vous resserrez en `selective` pour que la partie routinière avance, soit vous acceptez que la planification ne fasse que préparer du travail pour le matin. Voir [Planification et limites](/fr/docs/agent-schedule-limits).

## Pages associées

- [Présentation des agents](/fr/docs/ai-agents) — l'agent que ces blocs configurent.
- [Outils](/fr/docs/agent-tools) — les actions parmi lesquelles `approval.required` choisit.
- [Planification et limites](/fr/docs/agent-schedule-limits) — les exécutions sans surveillance.
- [Rôles et RBAC](/fr/docs/auth-roles-rbac) — les rôles nommés dans `trigger` et `escalation`.
- [Chat IA](/fr/docs/ai-chat) — l'une des surfaces que régit `trigger`.