Comment utiliser Conductor avec Gemini CLI ?

Conductor aide Gemini CLI à coder avec le contexte réel du projet, pas avec des suppositions. L’idée est simple : stocker les specs, les plans et les règles dans le repo, puis laisser l’agent les relire à chaque session. C’est là que le code généré devient moins fragile.

Pourquoi Conductor change le travail avec Gemini CLI ?

Conductor change le travail avec Gemini CLI parce qu’il donne à l’agent un contexte persistant, versionné et lisible à chaque exécution.

Le problème classique avec les assistants de code, c’est qu’ils sont souvent stateless. Ça veut dire qu’ils ne gardent pas vraiment la mémoire utile du projet entre deux sessions. Ils peuvent être très bons sur une tâche isolée, mais ils oublient vite l’architecture, les choix techniques, les conventions internes, les contraintes produit, et même les décisions prises la veille.

Et là, on obtient un truc que j’ai vu souvent : du code qui compile parfois, mais qui ne colle pas au projet. Il utilise le mauvais pattern. Il crée une nouvelle abstraction alors qu’il en existe déjà une. Il ignore une règle métier non écrite. Il propose une dépendance que l’équipe refuse depuis deux ans. Techniquement, ce n’est pas toujours faux. Contextuellement, c’est à côté.

Conductor arrive comme une extension Gemini CLI publiée en preview, donc encore à prendre comme un outil en évolution. Son intérêt n’est pas de rendre l’IA magique. Son intérêt, c’est de la cadrer avec des informations concrètes, stockées dans le dépôt, donc visibles, relues, versionnées, et partageables avec l’équipe.

Au lieu de repartir de zéro à chaque demande, l’agent relit les fichiers de contexte. Il retrouve ce qu’on a décidé, ce qu’on veut construire, ce qu’il ne faut pas casser, et la manière dont le projet fonctionne. C’est beaucoup plus proche d’un développeur qui prend le temps de lire la doc interne avant de toucher au code.

C’est là qu’arrive le Context-Driven Development. Dit simplement : on décrit le projet, on précise la fonctionnalité, on prépare le plan d’implémentation, puis seulement on génère ou modifie le code. On ne demande pas à l’IA de deviner. On lui donne le cadre avant de lui demander d’agir.

Sur des bases de code existantes, c’est souvent ça qui coûte cher. Pas l’erreur de syntaxe. Pas le bug évident. L’erreur chère, c’est l’erreur de contexte. Celle qui force une revue interminable, ou pire, qui introduit une logique contraire au produit.

Sur des projets clients, le vrai gain vient souvent d’un truc presque bête : Conductor force l’équipe à expliciter ce qu’elle croit évident. Et croyez-moi, ce qui est “évident” pour un lead dev ne l’est pas toujours pour le reste de l’équipe, ni pour un agent IA.

La suite détaille où Conductor stocke ce contexte dans le dépôt, et comment Gemini CLI s’en sert concrètement pendant l’exécution.

Comment fonctionne le Context Driven Development ?

Le Context Driven Development fonctionne en plaçant les informations utiles au projet dans des fichiers versionnés que l’agent peut relire avant d’agir.

Avec Conductor et Gemini CLI, l’idée est simple : je donne à l’agent un contexte stable, au lieu de lui demander de deviner à chaque session. On crée d’abord le contexte projet, puis on décrit la fonctionnalité à construire, on prépare un plan d’implémentation, et seulement après on laisse l’agent écrire ou modifier le code.

Ce n’est pas une grosse méthode de gouvernance avec 42 documents. C’est plutôt une façon propre de dire : “Voilà le cadre, voilà ce qu’on veut, voilà les contraintes, maintenant tu peux bosser”. J’ai vu ça faire une vraie différence chez des équipes où l’agent changeait de style à chaque prompt. Une fois le contexte écrit, il improvise beaucoup moins.

Dans ces fichiers, je peux mettre les infos qui évitent les malentendus :

• La stack technique utilisée, par exemple le framework, le langage, les outils principaux.
• L’architecture du projet, avec les grands dossiers et les responsabilités.
• Les conventions de code, comme le nommage, le style, ou la façon de structurer les fichiers.
• Les standards internes à respecter.
• Les objectifs produit, pour garder le sens fonctionnel derrière le code.
• Les contraintes importantes, par exemple ne pas toucher à une partie sensible.
• Les plans d’implémentation, pour guider l’agent avant qu’il modifie quoi que ce soit.

Markdown est pratique pour ça. C’est lisible par un humain, versionnable dans Git, modifiable sans outil compliqué, et assez clair pour guider un agent de code. Quand il faut représenter l’état du projet ou certains artifacts, des fichiers JSON peuvent aussi être utiles dans la couche d’artifacts. JSON, c’est juste un format structuré clé-valeur, facile à lire par une machine.

Une structure possible dans conductor/ pourrait ressembler à ça. Les noms exacts des fichiers dépendent de l’extension et du workflow utilisé.

conductor/
  contexte-projet.md
  specification-fonctionnalite.md
  plan-implementation.md
  artifacts/
    etat-projet.json

Session Gemini CLI sans contexte persistant	Session avec Conductor
L’agent dépend surtout du prompt du moment.	L’agent peut relire un contexte projet versionné.
Les décisions peuvent varier d’une session à l’autre.	Les décisions restent alignées avec les conventions et contraintes.
Il faut répéter les mêmes informations.	Le contexte est déjà écrit et réutilisable.
L’agent risque davantage d’improviser.	L’agent suit une spécification et un plan plus clairs.

Quelle architecture utilise Conductor ?

Conductor repose sur trois couches simples qui séparent les commandes, les artifacts de contexte et le versioning Git. C’est une architecture assez saine, parce qu’elle évite de tout mélanger dans une grosse conversation avec l’IA, ce que j’ai vu trop souvent finir en brouillard total sur des projets clients.

La première couche, c’est la Command Layer. C’est l’interface qu’on utilise depuis Gemini CLI avec des commandes slash. Le contenu source mentionne six commandes slash, je ne vais pas inventer la liste complète ici, mais l’idée est simple : ces commandes servent à lancer les actions du workflow directement depuis le terminal. Vous restez dans votre environnement de dev, vous déclenchez une spec, un plan, une tâche, ou une action liée au cycle de travail sans ouvrir quinze outils.

La deuxième couche, c’est l’Artifact Layer. Elle vit dans le répertoire conductor/. Ce dossier contient des fichiers Markdown et JSON utilisés pour garder l’état du projet, les specs, les plans et les informations nécessaires au suivi. Pour moi, c’est le cœur du système. Le contexte devient un objet du repo, pas une discussion perdue dans une session Gemini CLI. Et ça change beaucoup de choses. Quand un agent reprend le travail, il ne repart pas juste d’un prompt approximatif, il relit des artifacts structurés.

La troisième couche, c’est la Version Control Layer. Là, on parle de Git. Git suit les modifications, permet de créer des commits par tâche, et surtout de revenir en arrière si l’agent part dans la mauvaise direction. Quand on fait travailler un agent de code, pouvoir rollback rapidement n’est pas une option confortable, c’est une sécurité de base. Une mauvaise modification peut arriver vite, même avec un bon modèle.

Les trois couches se complètent bien. Les commandes déclenchent le workflow, les fichiers conductor/ gardent la mémoire, Git sécurise les changements. J’aime bien l’image suivante : le terminal est le poste de pilotage, le dossier conductor/ est le carnet de bord, Git est le filet de sécurité.

Couche	Rôle	Intérêt pour l’équipe
Command Layer	Lancer les actions depuis Gemini CLI avec des commandes slash.	Travailler vite depuis le terminal, sans casser le flux de développement.
Artifact Layer	Stocker les specs, plans et états dans conductor/ avec des fichiers Markdown et JSON.	Garder un contexte clair, partagé et réutilisable dans le repo.
Version Control Layer	Suivre les changements avec Git, créer des commits et permettre les rollbacks.	Sécuriser le travail de l’agent et revenir vite en arrière si besoin.

Conductor marche t il sur un projet existant ?

Conductor peut fonctionner sur un projet existant grâce au support brownfield et à la commande /conductor:setup.

Brownfield, ça veut juste dire qu’on parle d’un projet déjà vivant. Un repo avec son historique, ses dossiers, ses choix techniques, ses conventions, et parfois ses petites bizarreries qu’on découvre seulement après avoir cassé un test. C’est le cas le plus fréquent en entreprise. On arrive rarement sur un projet propre, vide, parfait, avec une architecture limpide et une doc à jour.

La commande /conductor:setup sert justement à démarrer dans ce contexte. Elle analyse le dépôt, respecte les fichiers .gitignore et .geminiignore, puis tente d’inférer le stack technique et l’architecture du projet. Dit autrement, Conductor regarde ce qui existe déjà avant de vous poser des questions inutiles.

C’est important parce qu’un bon agent doit d’abord comprendre le terrain. Si votre code montre déjà que vous êtes sur une app Node, Python, React, Laravel ou autre, ça n’a pas beaucoup de sens de vous le redemander. Ça limite aussi les erreurs bêtes, celles qui viennent d’une mauvaise lecture du projet ou d’une hypothèse trop rapide.

Mais il faut être clair sur un point. L’inférence n’est pas une vérité absolue. Conductor peut se tromper, rater une subtilité, confondre un dossier legacy avec le cœur applicatif, ou sous-estimer une dépendance critique. Je relis toujours les fichiers de contexte générés, je corrige les approximations, et je complète ce qui manque. C’est là que l’expertise humaine reste indispensable. L’agent peut accélérer, oui. Mais il ne doit pas devenir l’architecte fantôme du projet.

Sur un projet existant, je commence toujours par clarifier les règles de sécurité, les conventions, les zones sensibles du code et les dépendances critiques avant de demander à un agent de modifier quoi que ce soit. C’est moins spectaculaire qu’un gros prompt de génération, clairement. Mais ça évite souvent des heures de nettoyage derrière.

Avant d’utiliser Conductor proprement, il faut donc poser les bases techniques. On va installer Gemini CLI, préparer l’authentification, puis initialiser Git pour travailler dans un cadre propre.

Comment installer Conductor proprement ?

Pour installer Conductor proprement, il faut d’abord avoir Gemini CLI, une authentification Google ou Vertex AI, puis un dépôt Git initialisé.

Je commence toujours par Gemini CLI, parce que Conductor s’appuie dessus pour parler aux modèles Gemini. Sans ça, on installe une extension qui ne peut pas faire grand-chose.

npm install -g @google/gemini-cli

Une fois l’installation faite, je vérifie que la commande est bien disponible.

gemini --version

Si la commande gemini n’est pas reconnue, ce n’est pas forcément grave. Il faut souvent redémarrer le terminal pour recharger les binaires installés globalement. Sinon, je vérifie le PATH, c’est la variable système qui indique où chercher les commandes exécutables.

Petit point pratique, si npm renvoie des erreurs de permission, j’évite sudo quand c’est possible. Sur une machine de dev, je préfère utiliser nvm, un gestionnaire de versions Node.js. Ça évite pas mal de conflits, surtout quand plusieurs projets utilisent des versions différentes de Node.

Ensuite, il faut que Gemini CLI puisse appeler les modèles. Selon votre configuration, ça peut passer par une clé API Google, Vertex AI, ou un flux OAuth. Je ne vais pas inventer une procédure universelle ici, parce que ça dépend de votre environnement. Le point important, c’est simple : avant d’installer et d’utiliser Conductor efficacement, Gemini CLI doit déjà être authentifié et fonctionnel.

Puis je prépare Git. Si le projet n’est pas encore versionné, je l’initialise.

git init
git add .
git commit -m "Initial commit"

Pour moi, c’est non négociable dès qu’on laisse un agent toucher du code. Conductor travaille par tâches, crée des commits, et permet de revenir en arrière si une modification casse quelque chose. Sans Git, on perd une grosse partie du filet de sécurité.

L’installation de Conductor se fait ensuite avec la commande d’extension Gemini CLI.

gemini extensions install https://github.com/gemini-cli-extensions/conductor

Je recommande aussi l’option –auto-update, surtout pendant une phase preview. L’extension bouge vite, et l’auto-update aide à suivre les corrections et évolutions sans devoir tout surveiller à la main.

gemini extensions install https://github.com/gemini-cli-extensions/conductor --auto-update

Avant de lancer Conductor sur un vrai repo, je vérifie ça rapidement :

• Gemini CLI installé avec gemini –version qui répond correctement.
• Terminal redémarré après installation si la commande n’était pas reconnue.
• Authentification OK via clé API Google, Vertex AI ou OAuth.
• Repo Git initialisé avec au moins un commit propre.
• Conductor installé avec l’option –auto-update si vous voulez suivre les mises à jour.

Et si le vrai sujet c’était de donner une mémoire à vos agents ?

Conductor pour Gemini CLI répond à un problème très concret : un agent de code sans contexte finit vite par deviner. Et dans un vrai projet, deviner coûte cher. Avec le Context Driven Development, je garde les specs, les plans, les standards et l’état du projet dans le repo, dans des fichiers lisibles et versionnés. Gemini CLI peut alors travailler avec une base plus stable. Ce n’est pas une garantie de perfection, mais c’est un cadre beaucoup plus sain. Le bénéfice pour vous est simple : moins d’improvisation, plus de contrôle, et des changements de code plus faciles à relire, suivre et annuler.

FAQ

• À quoi sert Conductor avec Gemini CLI ?
  Conductor sert à donner un contexte persistant à Gemini CLI. Au lieu de laisser l’agent repartir de zéro à chaque session, il stocke les informations importantes du projet dans des fichiers versionnés, que l’agent peut relire avant de coder.
• Qu’est-ce que le Context Driven Development ?
  Le Context Driven Development consiste à documenter le contexte, les spécifications et le plan d’implémentation avant de générer du code. L’objectif est simple : réduire les suppositions de l’agent et l’aider à respecter le stack, l’architecture et les standards du projet.
• Conductor fonctionne-t-il sur un projet déjà existant ?
  Oui, Conductor prend en charge les projets existants avec une approche brownfield. La commande /conductor:setup analyse le dépôt, respecte .gitignore et .geminiignore, puis tente d’inférer le stack et l’architecture pour construire le contexte initial.
• Pourquoi Git est-il important avec Conductor ?
  Git sert de couche de sécurité. Conductor s’appuie sur le versioning pour suivre les changements, créer des commits par tâche et permettre un rollback si l’agent produit une modification incorrecte ou trop risquée.
• Quels sont les prérequis pour installer Conductor ?
  Il faut installer Gemini CLI avec npm, vérifier la commande gemini –version, configurer une authentification via clé API Google, Vertex AI ou OAuth, puis initialiser Git dans le projet. L’installation de Conductor se fait ensuite avec gemini extensions install https://github.com/gemini-cli-extensions/conductor.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent utiliser l’IA sans perdre le contrôle sur leur stack, leurs données et leurs process. Avec webAnalyste et Formations Analytics, j’ai travaillé pour des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez cadrer l’usage de l’IA, automatiser vos workflows ou structurer vos projets data et tracking, contactez-moi.