# Planification et limites

Un [agent](/fr/docs/ai-agents) qui ne répond que lorsqu'on lui parle n'a besoin d'aucun de ces deux blocs. Celui qui se réveille tout seul a besoin des deux : `schedule` pour décider quand, et `limits` pour décider combien il peut consommer une fois que personne ne regarde.

## Exécution planifiée

```yaml
schedule:
  cron: '0 9 * * MON'
  timezone: Europe/Paris
  taskPrompt: Summarize last week's new tickets and post the digest.
```

| Propriété             | Description                                                                 |
| --------------------- | --------------------------------------------------------------------------- |
| `schedule.cron`       | Expression cron standard à 5 champs (`*/15 * * * *`, `0 9 * * MON`).        |
| `schedule.timezone`   | Identifiant IANA. Vaut `UTC` par défaut.                                    |
| `schedule.taskPrompt` | Obligatoire. Envoyé au modèle comme message utilisateur à chaque exécution. |

`cron` et `timezone` sont tous deux validés au décodage de la configuration, avec le même analyseur que les [déclencheurs cron d'automatisation](/fr/docs/automation-triggers). Une expression malformée ou un fuseau inconnu fait échouer `sovrium validate` hors ligne — vous l'apprenez à votre bureau, pas par une tâche qui ne s'est jamais déclenchée.

`taskPrompt` fait la différence entre une planification et un réveille-matin. Le prompt système dit qui est l'agent ; le prompt de tâche dit à quoi sert cette exécution-ci. Rédigez-le comme une instruction avec un état final défini — « résume les nouveaux tickets de la semaine et publie le condensé » — plutôt qu'un mandat ouvert comme « vérifie les tickets », qui ne donne au modèle aucun point d'arrêt.

:::callout
**Définissez `timezone` dès que la planification signifie quelque chose pour une personne.** `0 9 * * MON` en UTC par défaut se déclenche à 10 h à Paris la moitié de l'année et à 11 h l'autre moitié. Un condensé qui arrive avant le début de la journée de travail n'est lu par personne. Les fuseaux gèrent l'heure d'été ; un décalage UTC figé dans l'expression cron, non.
:::

Deux blocs interagissent avec la planification. Un agent désactivé (`enabled: false`) saute entièrement ses exécutions, ce qui est la façon propre d'en suspendre un sans supprimer sa configuration. Et l'[approbation](/fr/docs/agent-approvals) s'applique toujours — un `mode: all` sur un cron nocturne met une demande en file à 3 h du matin au lieu de s'exécuter, et celle-ci expire sans réponse si `timeout` passe avant l'arrivée de quelqu'un.

## Limites opérationnelles

`limits` plafonne la consommation. Chaque champ est facultatif et retombe sur une valeur système.

| Propriété                    | Défaut   | Plafonne                                                        |
| ---------------------------- | -------- | --------------------------------------------------------------- |
| `limits.maxActionsPerMinute` | `30`     | Les actions de base de données et de courriel par minute.       |
| `limits.maxTokensPerDay`     | `200000` | Les jetons de modèle par 24 heures. Remise à zéro à minuit UTC. |
| `limits.maxConcurrentTasks`  | `5`      | Les exécutions de tâches simultanées.                           |

Chacun répond à une défaillance différente, et la distinction compte au moment de choisir les valeurs :

- **`maxActionsPerMinute`** borne une boucle. Un agent qui relit mal sa propre sortie et réessaie peut marteler une table des centaines de fois par minute ; c'est le plafond qui transforme cela en anomalie lente plutôt qu'en panne.
- **`maxTokensPerDay`** borne la facture. C'est la seule limite de cette page qui a un coût direct en monnaie, et la seule que vous pouvez estimer à l'avance — évaluez les jetons d'une exécution, multipliez par le nombre d'exécutions quotidiennes, ajoutez de la marge.
- **`maxConcurrentTasks`** borne la contention. Il compte surtout pour les agents déclenchés par des utilisateurs plutôt que par cron, où dix personnes peuvent invoquer le même agent en même temps.

```yaml
limits:
  maxActionsPerMinute: 20
  maxTokensPerDay: 150000
  maxConcurrentTasks: 3
```

Le budget de jetons se réinitialise à minuit UTC, indépendamment du `timezone` de l'agent. Un agent planifié à 23 h à Auckland dépense sur une fenêtre qui bascule en milieu d'après-midi locale — bon à savoir avant qu'une exécution ne s'interrompe mystérieusement à mi-parcours.

## Dimensionner un agent planifié

Raisonnez à rebours depuis le cron. Un agent quotidien qui lit cent enregistrements et écrit un résumé consomme peut-être vingt mille jetons et trente actions ; `maxTokensPerDay: 100000` laisse alors de la marge pour un mauvais jour sans en laisser pour un emballement. Un agent en `*/15 * * * *` s'exécute quatre-vingt-seize fois par jour : le même coût unitaire exige donc un budget supérieur de deux ordres de grandeur — et c'est en général le signe qu'il faut reconsidérer la planification, pas le budget.

## Pages associées

- [Présentation des agents](/fr/docs/ai-agents) — l'agent que ces blocs configurent.
- [Permissions et approbation](/fr/docs/agent-approvals) — ce qui se passe quand une exécution planifiée réclame un humain.
- [Outils](/fr/docs/agent-tools) — les actions décomptées par `maxActionsPerMinute`.
- [Déclencheurs d'automatisation](/fr/docs/automation-triggers) — le même analyseur cron.
- [Fournisseurs d'IA](/fr/docs/ai-providers) — le modèle dont vous budgétez les jetons.