Système de clarification multi-choix

Quand Vibe demande avant d’agir

Mistral Vibe n’est pas un outil qui exécute aveuglément vos instructions. Quand une demande est ambiguë ou que plusieurs approches sont défendables, il active son système de clarification multi-choix et vous présente des options avant de procéder. Le mécanisme repose sur un outil intégré, ask_user_question, disponible pour les agents mais pas pour les subagents, et qui fonctionne de deux manières.

La première est le choix multiple : Vibe énumère des options numérotées et vous répondez par un numéro ou par le texte de l’option. C’est rapide et sans ambiguïté, ce qui en fait le format par défaut dès qu’il existe un nombre fini de réponses raisonnables.

Vibe : Quel framework de test utilisez-vous ?
  1. Vitest
  2. Jest
  3. Mocha
  4. Pytest
  5. Autre (précisez)

La seconde est la saisie libre, réservée aux questions dont la réponse ne peut pas être devinée : un nom de table, un identifiant, un chemin. Vibe attend alors une réponse textuelle.

Vibe : Quel est le nom de la table de base de données à migrer ?
> users_profiles

Les trois situations qui déclenchent une question

Le premier déclencheur est l’ambiguïté pure. Vous demandez de refactorer « le composant de login » alors que le dépôt en contient deux ; plutôt que de parier sur l’un des deux et de vous rendre un travail à jeter, Vibe vous fait trancher. Remarquez la troisième option, qui évite l’aller-retour lorsque la réponse est « les deux ».

Vous : Refactore le composant de login

Vibe : J'ai identifié deux composants liés au login :
  1. src/components/LoginForm.tsx (formulaire)
  2. src/components/LoginModal.tsx (modale)
Lequel souhaitez-vous refactorer ?
  3. Les deux

Le deuxième déclencheur est la pluralité des approches techniques. Ajouter de la validation à un formulaire engage une dépendance qui restera dans le projet pendant des années ; ce genre de décision vous appartient, pas au modèle.

Vous : Ajoute de la validation au formulaire

Vibe : Quelle approche de validation préférez-vous ?
  1. Zod (validation de schéma, typage TypeScript)
  2. Yup (validation déclarative, écosystème Formik)
  3. Validation manuelle (sans librairie)
  4. Valibot (léger, tree-shakable)

Le troisième est la décision à impact. Une demande banale en apparence — « mets à jour les dépendances » — peut cacher un changement de version majeure. Vibe hiérarchise alors les options du plus sûr au plus risqué, en annonçant explicitement le niveau de risque de chacune.

Vous : Mets à jour les dépendances

Vibe : La mise à jour de React 18 → 19 est un changement majeur.
  1. Mettre à jour uniquement les patchs (sûr)
  2. Mettre à jour les mineurs (risque faible)
  3. Tout mettre à jour, majeurs inclus (vérification requise)

Régler le curseur agent par agent

Ce comportement n’a rien d’automatique : il dépend de ce que vous autorisez. Pour qu’un agent puisse vous interroger, ask_user_question doit figurer dans ses outils autorisés.

display_name = "Careful Developer"
safety = "neutral"
auto_approve = false

enabled_tools = [
  "read_file",
  "write_file",
  "edit_file",
  "grep",
  "ask_user_question"  # Active les clarifications
]

À l’inverse, un agent destiné à tourner sans supervision — dans un pipeline, la nuit, ou simplement pour un travail répétitif que vous ne voulez pas arbitrer — doit être privé de cet outil. Retirer ask_user_question ne suffit pourtant pas : sans consigne de repli, l’agent bloquerait ou choisirait au hasard. Le prompt système doit donc lui dire quoi faire à la place.

display_name = "Silent Worker"
safety = "neutral"
auto_approve = true

system_prompt = """
Ne posez jamais de questions. En cas d'ambiguïté :
- Choisissez l'option la plus conservatrice
- Documentez votre choix dans un commentaire
"""

enabled_tools = [
  "read_file",
  "write_file",
  "edit_file",
  "grep"
  # Pas de ask_user_question
]

Entre le tout et le rien, le prompt permet de doser. Un agent qui vous interrompt toutes les deux minutes pour choisir un nom de variable est aussi pénible qu’un agent muet est risqué ; formulez donc un seuil explicite pour qu’il ne vous sollicite que sur ce qui compte vraiment.

system_prompt = """
Règles de clarification :
- Posez une question UNIQUEMENT si le choix affecte l'architecture
- Pour les décisions cosmétiques, choisissez la convention du projet
- Proposez toujours 3 options maximum
- Incluez toujours une option "Les deux" ou "Tout" quand c'est pertinent
"""

Le cas particulier des subagents

Rappel important : les subagents ne peuvent pas poser de questions. C’est une contrainte de conception, pas un oubli — un subagent doit être entièrement autonome. Quand il rencontre une ambiguïté, il lui reste trois recours : appliquer l’option par défaut documentée dans son prompt, documenter ce choix dans le résultat qu’il retourne, et signaler l’ambiguïté à l’agent principal, qui pourra lui vous interroger. Écrire ces valeurs par défaut n’est donc pas un luxe, c’est la condition pour qu’un subagent produise un résultat exploitable.

# Subagent avec fallback clair
agent_type = "subagent"
system_prompt = """
En cas d'ambiguïté, appliquez ces règles par défaut :
- Framework de test : Vitest
- Style de code : conventions du projet (détectées via config)
- Format de sortie : Markdown
Documentez chaque choix par défaut dans votre rapport.
"""

En pratique, réservez les clarifications aux décisions qui engagent l’architecture ou la sécurité et laissez l’agent trancher seul le formatage ou le nom d’une variable temporaire. Tenez-vous à trois à cinq options pour ne pas transformer chaque question en formulaire, et placez toujours en premier le choix qui ferait office de défaut raisonnable. L’arbitrage est simple à énoncer : moins de questions donne plus de fluidité, mais augmente le risque d’un mauvais choix silencieux.

Points clés à retenir

• Vibe utilise ask_user_question pour demander des clarifications avec choix multiples ou saisie libre
• Le système s’active quand la demande est ambiguë ou que plusieurs approches sont possibles
• Incluez ask_user_question dans enabled_tools pour activer les clarifications
• Les subagents ne peuvent pas poser de questions — ils doivent être autonomes
• Guidez le comportement de clarification via le prompt système
• Moins de questions = plus de fluidité, mais plus de risque de mauvais choix