# Outils

Le bloc `tools` est la liste blanche de capacités d'un [agent](/fr/docs/ai-agents) : les tables auxquelles il peut toucher et les actions qu'il peut entreprendre. C'est ce que vous écrivez de plus lourd de conséquences sur un agent, car c'est le seul endroit où « à quoi sert cet agent » devient vérifiable par la machine.

```yaml
agents:
  - name: support-agent
    role: support
    systemPrompt: You are a courteous support assistant. Resolve tickets accurately.
    tools:
      tables: [tickets, customers]
      actions: [record.read, record.update, email.send]
```

| Propriété       | Règle                                                                                    |
| --------------- | ---------------------------------------------------------------------------------------- |
| `tools.tables`  | Noms de tables accessibles à l'agent. Au moins une ; chacune doit exister dans `tables`. |
| `tools.actions` | Types d'actions autorisés. Au moins une, choisie dans la liste ci-dessous.               |

Un agent sans bloc `tools` n'a **aucun accès**. Sûr par défaut, et discret à ce sujet — un agent qui semble ne rien faire est souvent un agent dont vous avez oublié la liste blanche.

## Le double garde-fou

Chaque appel qu'un agent tente traverse deux vérifications indépendantes, et les deux doivent l'autoriser :

1. **Garde-fou RBAC** — le [rôle](/fr/docs/auth-roles-rbac) de l'agent permet-il cette opération sur cette table ?
2. **Garde-fou liste blanche** — cette table et cette action figurent-elles dans `tools` ?

L'ordre importe peu ; la conjonction, si. La propriété que cela vous procure est que **`tools` ne peut que restreindre un rôle, jamais l'élargir**. Inscrire `record.delete` sur un agent dont le rôle ne peut pas supprimer n'accorde rien. Relire un agent revient donc à relire son rôle — la liste blanche ne peut pas introduire clandestinement une capacité que le rôle a refusée.

Les règles au niveau ligne et au niveau champ s'appliquent par-dessus, inchangées. Un agent lié à un rôle qui ne voit que les enregistrements de son équipe ne voit que ceux-là, quoi que dise sa liste blanche.

:::callout
**Listez le plus petit ensemble qui fasse le travail, et redérivez-le quand le prompt change.** Une liste blanche dérive comme un jeu de permissions : quelqu'un ajoute `record.delete` pour un nettoyage ponctuel et cela reste. Puisque le garde-fou est une conjonction, resserrer `tools` est toujours sans danger à essayer — si l'agent fonctionne encore, l'entrée n'a jamais été nécessaire.
:::

## Actions disponibles

Les actions suivent le même vocabulaire `type.operator` que le [moteur d'automatisation](/fr/docs/automation-actions-overview) : une règle que vous comprenez déjà depuis une automatisation signifie ici la même chose.

| Catégorie   | Actions                                                                        |
| ----------- | ------------------------------------------------------------------------------ |
| **Record**  | `record.read`, `record.create`, `record.update`, `record.delete`               |
| **État**    | `state.get`, `state.set`, `state.increment`, `state.delete`, `state.list`      |
| **HTTP**    | `http.request`                                                                 |
| **IA**      | `ai.generate`, `ai.classify`, `ai.extract`                                     |
| **Code**    | `code.runTypescript`                                                           |
| **E-mail**  | `email.send`                                                                   |
| **Auth**    | `auth.createUser`, `auth.assignRole`, `auth.banUser`, `auth.unbanUser`         |
| **Fichier** | `file.upload`, `file.download`, `file.delete`, `file.list`, `file.getMetadata` |

Quelques-unes méritent un commentaire.

**État** est un magasin clé-valeur persistant entre exécutions. C'est ce qui fait d'un agent autre chose qu'un prompt sans mémoire — un agent planifié peut se souvenir de ce qu'il a traité la fois précédente sans table dédiée.

**IA** permet à un agent d'enchaîner des sous-tâches : classer un ticket, en extraire des champs, puis rédiger une réponse. Chacune est un nouvel appel de modèle imputé au budget de jetons de l'agent.

**Auth** est ce que cette liste contient de plus tranchant. `auth.createUser`, `auth.assignRole` et `auth.banUser` signifient qu'un agent peut modifier qui a accès à votre application. Ne les accordez qu'à un agent dont le rôle est lui-même assez privilégié pour le justifier, et placez-les derrière une [approbation](/fr/docs/agent-approvals).

**`code.runTypescript`** s'exécute en bac à sable, mais reste la capacité la plus large d'ici — c'est l'action qui fait passer « ce que l'agent peut faire » d'une liste à un langage.

## Interne ou externe

`tools` délimite ce que l'agent peut faire **à l'intérieur** de Sovrium. Atteindre l'extérieur — la recherche web ou la récupération de documents d'un serveur MCP externe — relève d'une liste blanche distincte, `mcp.allowedTools`. Voir [Mode client](/fr/docs/mcp-client-mode).

Les deux sont indépendantes par conception. Un agent interne en lecture seule capable de chercher sur le web est une configuration parfaitement cohérente, et l'inverse aussi.

## Pages associées

- [Présentation des agents](/fr/docs/ai-agents) — l'agent auquel ce bloc appartient.
- [Permissions et approbation](/fr/docs/agent-approvals) — encadrer les actions listées ici.
- [Planification et limites](/fr/docs/agent-schedule-limits) — à quelle fréquence elles peuvent s'exécuter.
- [Rôles et RBAC](/fr/docs/auth-roles-rbac) — le premier garde-fou.
- [Vue d'ensemble des actions](/fr/docs/automation-actions-overview) — le même vocabulaire dans les automatisations.
- [Mode client](/fr/docs/mcp-client-mode) — la liste blanche externe.