# Déclencheurs manuels et chaînés

Trois déclencheurs qu'aucun événement externe ni aucune planification ne démarre : un opérateur qui décide, une autre automatisation qui délègue, et une exécution qui échoue.

## Déclencheur manuel

Exécution initiée par un administrateur, via un bouton dans l'interface d'administration ou `POST /api/automations/{name}/trigger`.

```yaml
trigger:
  type: manual
  label: Sync inventory
  requiredRole: admin
  inputSchema: { warehouse: { type: string } }
```

| Propriété      | Description                                                                    |
| -------------- | ------------------------------------------------------------------------------ |
| `label`        | Libellé du bouton dans l'interface d'administration (par ex. `Export Report`). |
| `inputSchema`  | JSON Schema décrivant les champs d'entrée fournis au déclenchement.            |
| `requiredRole` | Rôle requis pour déclencher. Par défaut `admin`.                               |

Toutes les propriétés sont optionnelles. L'entrée fournie au déclenchement se lit à **`{{trigger.input.*}}`** — et non `{{trigger.inputData}}`, qui ne se résout pas.

:::callout
**Le déclencheur manuel est le seul éligible à `aiAccess`.** Un agent peut invoquer une automatisation manuelle via MCP précisément parce qu'elle ne se déclenche pas d'elle-même : exposer à un modèle une automatisation webhook ou cron reviendrait à lui confier un levier qui se tire aussi tout seul. C'est appliqué au décodage de la configuration, pas seulement conseillé.
:::

## Déclencheur automation-call

Marque une automatisation comme appelable par une autre, via l'action `automation/call` — la base de la composition en sous-workflows.

```yaml
trigger:
  type: automation-call
  inputSchema: { customerId: { type: string } }
```

| Propriété     | Description                                                                                     |
| ------------- | ----------------------------------------------------------------------------------------------- |
| `inputSchema` | Contrat d'entrée attendu (façon JSON Schema). Omis, tout `inputData` de l'appelant est accepté. |

C'est la seule propriété du déclencheur. L'appelé lit ce qu'on lui a donné à `{{trigger.input.*}}`, et voit également `{{trigger.caller}}` (l'automatisation appelante) et `{{trigger.depth}}` (la profondeur actuelle de la chaîne).

La profondeur compte : `automation/call` porte une garde `maxDepth` valant **10** par défaut, si bien qu'une chaîne qui s'appelle elle-même par accident est arrêtée plutôt que de récurser jusqu'à la mort du processus. Les valeurs de retour repassent par l'action `automation/return` — voir [Sous-workflows](/fr/docs/automation-subworkflows).

## Déclencheur automation-failure

Se déclenche lorsqu'une automatisation surveillée échoue — gestion d'échec composable, sans configuration de notification par automatisation.

```yaml
trigger:
  type: automation-failure
  automations: [nightly-sync, billing-run]
```

| Propriété     | Description                                                                                                     |
| ------------- | --------------------------------------------------------------------------------------------------------------- |
| `automations` | Noms (kebab-case) des automatisations à surveiller, au moins un. **Omettez la clé** pour surveiller tout échec. |

Omettre `automations` et fournir un tableau vide ne sont pas équivalents : le tableau vide est rejeté au décodage, tandis que l'omission est la façon documentée de tout surveiller.

Une seule automatisation dotée de ce déclencheur remplace une action de notification dupliquée dans chaque flux. Pointez-la vers les traitements dont l'échec silencieux ferait réellement mal — une synchronisation nocturne, une facturation — et faites-lui écrire dans le canal que votre équipe lit.

:::callout
**Réagir à un échec n'est pas composer un sous-workflow.** `automation/call` invoque une cible qui déclare un déclencheur `automation-call` et attend un résultat. Ce déclencheur-ci s'active _après_ qu'une autre automatisation a déjà échoué, et ne peut pas influencer cette exécution. Voir [Nouvelle tentative et échec](/fr/docs/automation-retry-failure) pour la récupération en cours d'exécution.
:::

## Pages connexes

- [Présentation des déclencheurs](/fr/docs/automation-triggers) — les neuf types en un coup d'œil.
- [Sous-workflows](/fr/docs/automation-subworkflows) — les actions `automation/call` et `automation/return`.
- [Nouvelle tentative et échec](/fr/docs/automation-retry-failure) — les tentatives par action avant qu'une exécution ne soit déclarée en échec.
- [Exécutions d'automatisation](/fr/docs/automation-runs) — inspecter, rejouer et annuler des exécutions.
- [Intégration MCP](/fr/docs/mcp-integration) — comment `aiAccess` expose une automatisation manuelle à un agent.