# Approbation utilisateur

Suspend l'exécution jusqu'à validation humaine, puis reprend sur la branche choisie.

## Vue d'ensemble

Quand l'exécution atteint ce nœud, le run est suspendu avec le statut `awaiting_approval` et `last_output` est capturé. L'utilisateur reçoit une notification (in-app, et en option email ou Slack) avec le message d'approbation et un lien de reprise. **Approuver** ou **Rejeter** signe le lien avec un jeton à usage unique et reprend le workflow sur la branche correspondante.

Deux sorties :

- `approved` — empruntée en cas d'acceptation.
- `rejected` — empruntée en cas de refus.

À utiliser pour toute action coûteuse en cas d'erreur : déploiements prod, envoi de factures, publication publique, suppression de données.

## Configuration

| Champ | Description |
| --- | --- |
| `message` | Texte Markdown affiché au relecteur. Supporte les `{placeholders}` du contexte (ex. `Envoyer la facture de {customer_email} d'un montant de {total} ?`). |
| `approvalScope` | Cible d'approbation optionnelle. Laissez vide ou utilisez `any` pour garder le comportement existant, `team_roles` pour les rôles d'équipe, ou `specific_users` pour des approbateurs nommés. |
| `approvalRoles` | Noms de rôles autorisés à approuver quand `approvalScope` vaut `team_roles`. Tableau, texte séparé par virgules, ou un rôle par ligne. |
| `approverEmails` | Adresses email explicites des approbateurs quand `approvalScope` vaut `specific_users`. Tableau, texte séparé par virgules, ou un email par ligne. |
| `minApprovals` | Nombre minimal d'approbations avant reprise. Vaut `1` par défaut ; gardez une valeur positive et inférieure ou égale au nombre d'approbateurs éligibles. |
| Canaux de notification | In-app toujours actif. Email et Slack nécessitent que l'intégration de l'espace soit configurée. |
| Sorties | `approved`, `rejected`. |

Les champs Approval Group sont additifs. Les workflows qui définissent seulement `message` conservent leur comportement actuel.

Le lien de reprise est à usage unique et lié à l'exécution. Le jeton est invalidé dès la reprise.

## Exemple

Contrôler un déploiement prod :

```
Agent (rédige notes de version) → User approval ("Déployer {version} en prod ?")
                                    ├─ approved → HTTP Request (POST /deploy)
                                    └─ rejected → Set state (deploy_skipped=true)
```

Le workflow renvoie `status: awaiting_approval` et reste en pause. Le relecteur reçoit une notification avec le message rendu et deux boutons. Le workflow reprend depuis la branche choisie.

## Pièges

- Les runs en pause sont persistés, mais une file qui grossit coûte. Faites le ménage si des approbations sont oubliées.
- Le relecteur ne voit que le `message` rendu, pas tout le contexte. Faites apparaître toutes les infos décisives dans le message.
- Les sorties sont `approved` et `rejected` — une branche `rejected` non câblée arrête silencieusement le workflow.
- Les jetons d'approbation sont à usage unique. Renvoyer le lien après consommation renvoie 410.
- Si le workflow expire avant décision, le run est marqué `expired` et le lien renvoie 404.

---

*Source: https://agentbuilder.systalink.sn/docs/node-user-approval — human documentation.*
*Other language: [/docs-md/en/node-user-approval.md](/docs-md/en/node-user-approval.md).*
*Machine-readable index: [/llms.txt](/llms.txt).*