Modes unifiés : combiner outils, permissions et comportements

Le concept de modes unifiés

Les agents custom que nous avons vus dans les leçons précédentes définissent un profil statique : un modèle, des outils, un niveau de sécurité. Les modes unifiés vont plus loin en combinant plusieurs dimensions dans une configuration cohérente, activable d’un seul geste. Un mode unifié regroupe un ensemble d’outils autorisés, des permissions spécifiques, un comportement porté par le prompt système, des règles d’auto-approbation et des restrictions contextuelles.

L’intérêt apparaît dès que votre journée change plusieurs fois de nature. Sans modes unifiés, vous jonglez entre plusieurs paramètres à chaque changement de contexte : vous passez d’une tâche de revue de code à du déploiement, et il faut changer l’agent, ajuster les permissions, modifier le prompt. Le mode unifié encapsule tout cela dans un seul profil, que vous activez au lancement ou en cours de session.

# Activer le mode "deploy"
vibe --agent deploy-mode

# Basculer vers le mode "review"
# Shift+Tab → sélectionner review-mode

Structure d’un mode unifié

Techniquement, un mode unifié est un agent custom ; la différence avec un agent classique est conceptuelle. Vous ne concevez plus le fichier .toml comme « un assistant qui sait faire X », mais comme un contexte de travail complet : ce que vous avez le droit de faire pendant cette phase du projet, avec quel niveau de vigilance, et sous quelle forme les résultats vous reviennent.

Le mode revue ci-dessous en est l’illustration la plus nette. Il est en lecture seule, donc auto-approuvé sans risque, et son prompt impose un format de rapport exploitable directement dans une pull request.

# ~/.vibe/agents/review-mode.toml
display_name = "Review Mode"
description = "Mode revue de code : lecture seule, analyse approfondie, suggestions."

safety = "safe"
auto_approve = true
model = "mistral-large-latest"

system_prompt = """
Vous êtes en mode revue de code.
Objectif : analyser la qualité, la sécurité et la maintenabilité du code.
Règles :
- Ne jamais modifier de fichiers
- Produire un rapport structuré (problèmes critiques, avertissements, suggestions)
- Citer les lignes de code concernées avec leur numéro
- Proposer des correctifs sous forme de diff
Format de sortie : Markdown avec sections Critique / Avertissement / Suggestion
"""

enabled_tools = [
  "read_file",
  "grep",
  "list_dir"
]

Le mode déploiement est son exact opposé, et cette opposition est voulue. Il dispose de bash, donc du pouvoir de casser quelque chose, mais son auto_approve = false vous replace dans la boucle et son prompt décrit une séquence stricte que l’agent doit suivre du premier au dernier point.

# ~/.vibe/agents/deploy-mode.toml
display_name = "Deploy Mode"
description = "Mode déploiement : build, test, deploy avec validation à chaque étape."

safety = "destructive"
auto_approve = false
model = "codestral-latest"

system_prompt = """
Vous êtes en mode déploiement.
Séquence obligatoire :
1. Vérifier que tous les tests passent
2. Builder le projet
3. Valider le build (pas d'erreurs, pas de warnings)
4. Demander confirmation avant le déploiement effectif
5. Déployer
6. Vérifier que le service répond
Ne jamais déployer si les tests échouent.
"""

enabled_tools = [
  "read_file",
  "write_file",
  "bash",
  "grep",
  "list_dir",
  "ask_user_question"
]

Concevoir des modes complémentaires

L’idée est de créer un ensemble de modes qui couvrent votre cycle de développement, de la découverte à la correction. Le mode exploration ouvre la marche : lecture seule, auto-approuvé, il sert à comprendre un dépôt avant d’y toucher.

display_name = "Explore Mode"
safety = "safe"
auto_approve = true
system_prompt = """Explorez le codebase, identifiez l'architecture, les patterns et les dépendances."""
enabled_tools = ["read_file", "grep", "list_dir"]

Vient ensuite le mode développement, celui dans lequel vous passerez le plus de temps. Il écrit, il exécute des commandes — pour lancer les tests, notamment — mais il demande votre validation, et son prompt lie chaque changement à l’écriture de tests.

display_name = "Dev Mode"
safety = "neutral"
auto_approve = false
system_prompt = """Implémentez les fonctionnalités demandées. Écrivez des tests pour chaque changement."""
enabled_tools = ["read_file", "write_file", "edit_file", "bash", "grep", "list_dir"]

Le mode correction, enfin, est délibérément étroit. Pas de write_file, seulement edit_file : l’agent modifie l’existant sans créer de nouveaux fichiers, ce qui l’empêche de « refactorer au passage » un bug qu’on lui demandait simplement de corriger. C’est parce qu’il est aussi contraint qu’on peut se permettre de l’auto-approuver.

display_name = "Fix Mode"
safety = "neutral"
auto_approve = true
system_prompt = """Corrigez les bugs signalés. Minimisez les changements. Ne touchez que le code concerné."""
enabled_tools = ["read_file", "edit_file", "grep"]

Basculer entre les modes et les organiser

En session interactive, Shift+Tab fait passer d’un mode à l’autre : Vibe affiche la liste de tous vos agents, built-in et custom, avec leur description — c’est là que les descriptions soignées de la leçon précédente paient. Depuis la ligne de commande, vous démarrez directement dans un mode, ou vous inspectez le contenu du répertoire d’agents.

# Démarrer directement dans un mode
vibe --agent review-mode

# Lister les agents disponibles
ls ~/.vibe/agents/

Adoptez enfin une convention de nommage claire. Le suffixe -mode distingue immédiatement vos contextes de travail des agents utilitaires plus ponctuels, et l’ordre alphabétique du répertoire reste lisible même après une dizaine de fichiers.

~/.vibe/agents/
├── review-mode.toml      # Revue de code
├── deploy-mode.toml      # Déploiement
├── dev-mode.toml         # Développement
├── fix-mode.toml         # Corrections
├── explore-mode.toml     # Exploration
└── doc-mode.toml         # Documentation

Points clés à retenir

• Un mode unifié est un agent custom conçu comme un contexte de travail complet
• Il combine outils, permissions, prompt système et modèle en une seule configuration
• Créez des modes complémentaires pour couvrir votre cycle de développement
• Shift+Tab permet de basculer entre modes en temps réel
• Nommez vos fichiers de manière cohérente pour les retrouver facilement
• Chaque mode doit avoir un objectif clair et des permissions adaptées