# Questions en direct

Pendant l'appel, l'interlocuteur peut demander une information que la mission ne contient pas (« Le 20 h est complet,
19 h 45 vous irait ? »). L'agent vocal ne décide jamais à ta place : il dit « un instant, je vérifie » et te pose la
question, à toi ou à ton agent. Dans toutes les offres.

## Le déroulé

1. L'agent vocal pose la question : webhook `appel.question`, champ `question` dans `GET /v1/missions/{id}` et
   `/direct`, `pending_question` dans l'outil MCP `get_call`.
2. Tu as **45 secondes** pour répondre. Pendant ce temps, l'agent garde la conversation : il fait patienter
   l'interlocuteur avec des phrases courtes, sans rien accepter.
3. Tu réponds : `POST /v1/missions/{id}/answer` (MCP : `answer_call_question`). L'agent transmet ta réponse et
   continue.
4. Tu as besoin d'un peu plus de temps ? Demande une **prolongation de 60 secondes** (voir plus bas). L'agent demande
   à l'interlocuteur s'il veut bien patienter ; **seulement s'il accepte**, le délai est prolongé, une seule fois.
5. Pas de réponse à temps, ou l'interlocuteur préfère ne pas attendre : l'agent lui propose d'être rappelé dès qu'il
   aura la réponse. **S'il le souhaite**, l'appel se termine en `rappel_demande` et la question reste ouverte : ta
   réponse sera donnée au rappel. S'il ne le souhaite pas, l'appel se termine en `echec` et le résumé cite la question
   restée sans réponse. Une réponse qui arrive en retard, alors que l'appel est encore en cours, est quand même
   transmise.

## Le délai, visible partout

La question porte son échéance, pour que ton agent sache combien de temps il lui reste :

```json
"question": {
  "id": "q_1a2b3c4d",
  "texte": "Le 20 h est complet, 19 h 45 convient-il ?",
  "delai_s": 45,
  "expires_at": "2026-11-06T18:42:31Z",
  "seconds_left": 38,
  "prolongation": null,
  "prolongation_possible": true
}
```

| Champ | Sens |
|---|---|
| `delai_s` | Délai accordé au départ pour cette question (45 s) |
| `expires_at` | Échéance (ISO 8601, UTC), reculée de 60 s si une prolongation est acceptée ; fie-toi à elle plutôt qu'à ton horloge |
| `seconds_left` | Secondes restantes au moment de la réponse du serveur |
| `prolongation` | `null`, `demandee`, `acceptee`, `refusee` ou `impossible` |
| `prolongation_possible` | `true` tant qu'aucune prolongation n'a été demandée pour cette question et que le délai court encore |

Le webhook `appel.question` contient `question_id`, `question`, `expires_at`, `seconds_left`, `delai_s` et
`prolongation_possible`. En MCP, `pending_question` contient `expires_at`, `seconds_left` et `can_hold`.

## Demander 60 secondes de plus

```bash
curl -s -X POST $TEL_API/v1/missions/mis_3f2a9c0d1b7e4a55/question/prolonger \
  -H "Authorization: Bearer $TEL_KEY"
```

Corps facultatif : `{"question_id": "q_…"}` (pour être sûr de prolonger la bonne question). Réponse immédiate :
`{"ok": true, "question_id": "q_…", "prolongation": "demandee", "secondes": 60, "expires_at": "…", "seconds_left": 21}`.
La décision de l'interlocuteur arrive ensuite (webhook ou `/direct`). MCP : `hold_call_question(call_id, question_id?)`.

- L'agent vocal demande à l'interlocuteur : « Je vérifie auprès de la personne, ça peut prendre une minute : vous
  pouvez patienter ? »
- **Il accepte** : `prolongation` passe à `acceptee`, `expires_at` recule de 60 s.
- **Il refuse**, ou préfère être rappelé : `prolongation` = `refusee`. L'agent propose le rappel s'il le souhaite.
- Le webhook `appel.question_prolongation` donne le résultat : `{question_id, etat, expires_at, seconds_left}` avec
  `etat` = `acceptee`, `refusee` ou `impossible`.
- Une seule prolongation par question, et jamais plus de 2 minutes d'attente au total pour l'interlocuteur.
- Erreurs (409) : `aucune_question` (pas de question en attente, ou autre `question_id`), `question_expiree` (le délai
  est déjà passé : envoie quand même ta réponse, elle sera donnée pendant l'appel ou au rappel),
  `prolongation_deja_utilisee`. 502 `prolongation_impossible` si l'agent vocal n'a pas pu être joint. En MCP :
  `no_pending_question`, `question_expired`, `hold_already_used`.

## Conseils pour ton agent

- **Tu connais la réponse ?** Réponds tout de suite, en moins de 10 secondes.
- **Tu dois demander à ton humain ?** Demande la prolongation **d'abord**, puis pose-lui la question. Les gens mettent
  souvent plus d'une minute à voir un message : si l'échéance passe, laisse le rappel se faire et envoie quand même ta
  réponse, elle sera dite au début du rappel.
- **Mets dans la mission tout ce qu'on pourra te demander** (nom, téléphone de rappel, créneaux acceptables, limites) :
  c'est la meilleure façon d'éviter les questions.
- Avec n8n, Hermes ou un serveur : préfère le webhook `appel.question` au sondage, tu gagnes plusieurs secondes.
- N'invente jamais une réponse. Un code, un mot de passe ou un numéro de carte : c'est ton humain qui décide (écris la
  valeur `[secret: …]` pour qu'elle soit masquée dans ce que nous gardons).

## Après l'appel : la question reste ouverte

Si l'appel s'est terminé pendant l'attente, la mission garde `question` avec `apres_appel: true`. Tu peux encore
répondre avec `/answer` : la réponse est gardée et l'agent la donne dès le début du rappel. Renvoyer la même réponse
est sans effet (`deja_recue: true`) ; une réponse différente renvoie 409.

> **Le rappel aujourd'hui** : notre ligne fonctionne sans rappel automatique (`RAPPELS_MODE=notification`). Quand
> l'interlocuteur souhaite être rappelé, tu reçois l'événement `rappel_suggere` (webhook `appel.rappel_suggere`, avec
> `question_ouverte` et, s'il a donné une heure, `suggere_le`) et tu relances d'un clic : `POST /v1/missions/{id}/rappeler`.
> L'agent reprend avec le contexte de l'appel précédent. Le rappel automatique (`appel.rappel`, relance planifiée)
> n'existe qu'en mode `auto`, qui n'est pas activé.