Transformer Gemini CLI en un Système Multi-Agents Autonome

📖 Sommaire

• 1. La Philosophie : Le Système de Fichiers comme “État”
• 2. Le Pouvoir des Commandes Personnalisées
• 3. Le Piège de la Crise d’Identité
• 4. Sécurité et Bonnes Pratiques
• Conclusion

L’idée de créer des systèmes où plusieurs intelligences artificielles collaborent pour accomplir une tâche complexe fascine les développeurs. Si de nombreux frameworks existent pour orchestrer ces “agents”, ils nécessitent souvent d’apprendre de nouvelles bibliothèques et d’écrire des scripts complexes.

Cependant, il existe une approche beaucoup plus simple et élégante : utiliser le système de fichiers comme état (state) et les invites (prompts) comme chef d’orchestre. C’est exactement ce qu’il est possible de réaliser avec Gemini CLI, en exploitant uniquement ses fonctionnalités natives !

Dans cet article, nous allons voir comment monter une équipe d’agents IA virtuels, uniquement avec des fichiers .toml et une bonne dose d’ingénierie de prompt (Prompt Engineering).

1. La Philosophie : Le Système de Fichiers comme “État”

L’un des plus grands défis dans la création d’un système multi-agents est la gestion de la mémoire et de la communication entre les différents processus. Plutôt que de coder un gestionnaire d’état complexe en Python ou Node.js, l’approche Filesystem-as-State s’avère redoutablement efficace.

Le principe est simple : chaque tâche, chaque plan et chaque journal d’exécution (log) est sauvegardé sous forme de fichier dans un répertoire dédié.

graph TD
    A[Orchestrateur Gemini] --> B(Dossier `.gemini/agents/`)
    B --> C[/tasks/]
    B --> D[/plans/]
    B --> E[/logs/]
    B --> F[/workspace/]

    C -.->|Tâches JSON en attente| A
    D -.->|Contexte long terme| A
    A -.->|Résultats bruts| E
    A -.->|Fichiers créés/modifiés| F

Dans ce modèle, le dossier /tasks/ agit comme une file d’attente (queue). Chaque agent est un “travailleur sans état” (stateless worker) qui vient lire un fichier de tâche, effectue son travail, écrit le résultat, puis s’éteint. C’est transparent et extrêmement facile à déboguer : si ça plante, il suffit d’ouvrir le fichier texte pour comprendre pourquoi !

2. Le Pouvoir des Commandes Personnalisées

La magie opère grâce au système de commandes personnalisées de Gemini CLI. Une commande personnalisée n’est rien d’autre qu’un fichier .toml placé dans le répertoire .gemini/commands/. Le nom du fichier définit la commande (par exemple, agents/run.toml devient /agents:run).

Ce fichier .toml contient le prompt principal qui va guider l’IA. Pour créer notre système, nous définissons un “Orchestrateur”.

Lorsque l’on tape /agents:run, le prompt de l’orchestrateur lui demande de lire la file d’attente /tasks/ et de lancer une nouvelle instance de gemini-cli en arrière-plan (via une commande shell générée par l’IA elle-même).

sequenceDiagram
    participant Dev as Développeur
    participant CLI as Gemini CLI (Orchestrateur)
    participant FS as Système de Fichiers
    participant Agent as Sous-Agent (CLI enfant)

    Dev->>CLI: Tape `/agents:run`
    CLI->>FS: Lit `/tasks/` (Cherche tâche en attente)
    FS-->>CLI: "Tâche trouvée: Coder un script"
    CLI->>CLI: Génère la commande shell `gemini -e coder-agent -y`
    CLI->>Agent: Lance le Sous-Agent en arrière-plan
    Agent->>FS: Effectue le travail dans `/workspace/`
    Agent->>FS: Marque la tâche "Terminée"

3. Le Piège de la Crise d’Identité

Lors de la mise en place d’un tel système, un bug fascinant peut survenir : la crise d’identité de l’agent.

Imaginons que l’orchestrateur lance l’agent “Codeur” en lui passant simplement la description de la tâche : “Crée un guide sur Fibonacci”. L’agent enfant démarre, lit la tâche, mais au lieu de coder… il essaie de déléguer la tâche à nouveau ! Il se comporte comme l’assistant générique par défaut, créant une boucle infinie de délégation.

La solution réside dans le Prompting direct : Au lieu de dire à l’agent enfant “Voici une tâche”, l’orchestrateur doit générer une commande avec un prompt imposant l’identité : gemini -e coder-agent -p "TU ES l'agent codeur. Ton ID de tâche est XYZ. Ta mission est de : ..."

Cette simple contrainte force le sous-modèle à assumer son rôle d’expert sans essayer de jouer au manager.

flowchart LR
    A[Prompt Faible] --> B{Comportement de l'Agent}
    B -->|Je suis un assistant global| C[Délègue la tâche (Boucle infinie)]

    D[Prompt Fort et Contraint] --> E{Comportement de l'Agent}
    E -->|Je suis le Coder-Agent| F[Écrit le code demandé]

    style C fill:#f99,stroke:#333,stroke-width:2px
    style F fill:#9f9,stroke:#333,stroke-width:2px

4. Sécurité et Bonnes Pratiques

Un système qui génère et exécute ses propres commandes shell doit être manipulé avec précaution !

Dans cette architecture, l’orchestrateur lance les sous-agents avec le drapeau -y (ou --yolo), ce qui approuve automatiquement les appels d’outils (comme la modification de fichiers).

• Limitez la portée : Si vous créez un agent “Revue de Code”, configurez son extension pour qu’il n’ait accès qu’à des outils de lecture (Read-Only) ou à des scanners statiques, sans possibilité d’écrire sur le disque.
• Gardez-le simple : Ne demandez pas à l’orchestrateur de deviner quel agent lancer. Il est préférable que l’utilisateur assigne explicitement la tâche à un agent précis (ex: /agents:start cloud-architect "Créer un bucket").

Conclusion

Ce cas d’usage démontre qu’il n’est pas toujours nécessaire de déployer des infrastructures lourdes pour tester des concepts avancés d’IA. En combinant la puissance de la ligne de commande, le système de fichiers et des prompts strictement contraints, on obtient un système d’orchestration multi-agents robuste et transparent.

C’est un excellent aperçu de l’avenir du développement : le développeur passe de “codeur” à “manager” d’une équipe d’experts virtuels hyperspécialisés !