Comment démarrer proprement avec Conductor Gemini CLI ?

Conductor Gemini CLI sert à garder le contexte du projet vivant entre les sessions IA. Je vous montre comment ça marche, pourquoi ça évite le code hors sujet, et comment lancer une première implementation track sans casser votre repo.

Pourquoi Gemini CLI perd le fil ?

Gemini CLI perd le fil parce qu’il est sans état par défaut, donc chaque session repart sans mémoire durable du projet.

Ça veut dire quoi concrètement ? Vous pouvez lui expliquer votre architecture, vos conventions, vos choix techniques, vos contraintes produit… Mais si ce contexte reste juste dans un prompt, il est fragile. Il peut être incomplet, mal reformulé, oublié à la session suivante, ou simplement ignoré au moment où le modèle génère du code.

Dans une équipe dev ou data pressée, ça devient vite pénible. Le code généré peut marcher sur le moment, mais ne pas vraiment s’intégrer au repo. Il crée une nouvelle façon de faire alors qu’un pattern existe déjà. Il contourne une décision technique. Il ajoute une lib alors que l’équipe a choisi de ne pas le faire. Il modifie un fichier au mauvais endroit. Il respecte la demande visible, mais pas le système autour.

J’ai vu ce problème chez des équipes qui testent l’IA en dev. Le premier gain n’est pas la génération de code. Le vrai premier gain, c’est la réduction des malentendus. Quand l’outil comprend mieux le cadre, il propose moins de choses à jeter.

Le problème explose surtout sur un repo existant. Ce qu’on appelle souvent du brownfield, c’est-à-dire un projet déjà en production, avec son historique, ses compromis, ses fichiers déjà rangés, ses patterns internes, ses dettes techniques et ses règles implicites. Dans ce contexte, “fais-moi une feature” ne suffit pas. Il faut savoir où la mettre, comment nommer les objets, quelle couche appeler, quels tests écrire, quelles dépendances éviter, et parfois quelle vieille contrainte produit ne surtout pas casser.

Conductor apporte une réponse assez pragmatique à ça. Le contexte n’est plus une phrase tapée au début d’un prompt. Il devient un artefact stocké dans le dépôt. Un artefact, c’est simplement un fichier ou un ensemble de fichiers que l’équipe peut relire, versionner, corriger et partager. C’est beaucoup plus sain que de compter sur la mémoire courte d’une session CLI.

À partir de là, la bonne question devient simple : qu’est-ce que Conductor stocke vraiment, et comment il organise le workflow autour de Gemini CLI ? C’est là que ça commence à devenir utile.

Conductor change quoi concrètement ?

Conductor transforme le contexte projet en fichiers Markdown et JSON versionnés dans le repo, principalement dans le répertoire conductor/. C’est ça le vrai changement. On arrête de piloter l’agent avec des prompts jetables, et on lui donne une mémoire de travail propre, lisible, commitée, relue à chaque fois.

Le principe derrière, c’est le Context-Driven Development, ou CDD. Dit simplement : je construis le contexte avant de demander du code. Je décris le produit, les contraintes, les conventions, la feature à livrer, puis je planifie l’implémentation. Le code vient après. Ça paraît évident, mais dans la vraie vie, beaucoup d’agents codent trop vite avec trop peu d’informations. Et c’est là qu’ils cassent des trucs.

Conductor organise ça en trois couches assez simples :

• Command Layer : Les commandes slash dans Gemini CLI servent à lancer les actions. Par exemple créer une spec, générer un plan, exécuter une tâche, analyser le projet.
• Artifact Layer : Les fichiers de contexte vivent dans conductor/. On y retrouve les objectifs produit, les specs, les plans, les décisions d’architecture, parfois des fichiers JSON plus structurés.
• Version Control Layer : Git garde l’historique. On peut faire des commits par tâche, relire ce qui a changé, revenir en arrière proprement si l’agent part dans une mauvaise direction.

Ce que j’aime bien avec cette approche, c’est qu’elle force une forme de discipline. À chaque exécution, l’agent ne repart pas juste d’un prompt vague. Il relit les objectifs produit, les conventions de code, les choix d’architecture et le plan d’implémentation. Ça réduit les décisions improvisées. Ça évite aussi le fameux “j’ai corrigé un bug et maintenant trois écrans ne marchent plus”. Je l’ai vu chez un client sur un vieux repo React, le gain n’était pas magique, mais très concret : moins d’allers-retours et des changements plus localisés.

Conductor marche autant sur un projet neuf que sur un repo existant. Sur un brownfield, donc un projet déjà en production ou déjà bien chargé, il analyse le code présent, respecte .gitignore et .geminiignore, puis infère la stack, les patterns et l’architecture. Il ne devine pas tout parfaitement, mais il part avec une base beaucoup plus solide qu’un agent lancé à froid.

Problème	Réponse Conductor	Impact pour l’équipe
Les prompts sont perdus ou incohérents.	Le contexte est stocké dans conductor/ en Markdown et JSON.	L’équipe partage une même mémoire projet.
L’agent code sans comprendre les objectifs.	Les specs et plans sont relus avant l’implémentation.	Les livrables collent mieux au besoin réel.
Les changements sont difficiles à contrôler.	Git trace les tâches, les commits et les retours arrière.	Le risque baisse, surtout sur les repos existants.

Que faut il installer avant ?

Avant de toucher à Conductor, je prépare trois choses. Gemini CLI, une authentification Google ou Vertex AI, et un dépôt Git déjà initialisé. C’est la base. Sans ça, on perd vite du temps sur des erreurs qui n’ont rien à voir avec le code.

Gemini CLI, c’est l’outil en ligne de commande de Google pour piloter Gemini depuis votre terminal. Le plus simple, dans la majorité des cas, c’est de l’installer avec npm, le gestionnaire de paquets de Node.js.

• npm install -g @google/gemini-cli
• gemini –version
• git init
• git status

Si la commande d’installation vous renvoie une erreur de permissions Node, je vous conseille d’éviter le bricolage du genre sudo partout ou changement de droits système à la main. Ça marche parfois sur le moment, puis ça casse autre chose trois semaines plus tard. L’approche propre, c’est d’utiliser un gestionnaire de versions comme nvm. Nvm permet d’installer Node dans votre environnement utilisateur, sans aller modifier les dossiers système. C’est plus sain, surtout sur une machine de dev.

Côté authentification, vous avez plusieurs options selon votre contexte. Vous pouvez utiliser une clé Google API, passer par une configuration Vertex AI, ou suivre le parcours proposé par Gemini CLI lui-même. Dans certains environnements, le CLI vous proposera une authentification via Vertex AI. Dans d’autres, il ouvrira un flux OAuth dans le navigateur. OAuth, pour faire simple, c’est le mécanisme qui permet de vous connecter avec votre compte Google sans coller votre mot de passe dans le terminal.

Le dernier prérequis, c’est Git. Et là, ce n’est pas décoratif. Conductor s’appuie sur Git pour créer des commits par tâche. C’est vraiment pratique, parce que chaque piste d’implémentation reste traçable. Si une idée part dans le mur, on revient en arrière proprement. J’ai vu ça sauver pas mal de temps chez un client, surtout quand plusieurs tentatives d’implémentation étaient lancées en parallèle.

Une fois Gemini CLI installé, l’authentification prête, et Git initialisé dans votre projet, on peut passer à la suite sans traîner. À ce moment-là, on installe Conductor et on lance la première implementation track.

Comment lancer la première track ?

Pour lancer une première track proprement, je commence par installer l’extension Conductor dans Gemini CLI, idéalement avec l’auto-update, puis je laisse Conductor créer et utiliser ses artefacts de contexte. C’est le point important. Je ne demande pas à l’agent de coder tout de suite.

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

Quand je veux rester aligné avec les évolutions de l’extension, j’ajoute l’option –auto-update. C’est recommandé si vous utilisez Conductor régulièrement, parce que l’extension va bouger, s’améliorer, corriger des comportements.

Ensuite, je repars de la base. Je vérifie que le repo est propre, que Git est clair, que je sais sur quelle branche je travaille. Puis je lance Gemini CLI dans le projet, et j’utilise les commandes slash Conductor disponibles dans l’environnement. Je n’invente pas de raccourcis. Je suis ce que l’extension expose.

Conductor va préparer un répertoire conductor/. Dedans, il formalise le contexte projet, aide à décrire la feature, produit un plan d’implémentation, puis exécute la track en créant des commits liés aux tâches. Une track, ici, c’est juste une séquence de travail cadrée. Pas une conversation vague avec un agent qui modifie dix fichiers sans prévenir.

Mon bon réflexe, c’est de relire avant d’exécuter. Le contexte est-il juste ? La spec feature est-elle assez claire ? Le plan d’implémentation tient-il debout ? J’ai vu trop de projets où l’IA partait vite, mais dans la mauvaise direction. Avec Conductor, le gain vient surtout de là : on force l’agent à comprendre avant de produire.

Je laisse ensuite l’exécution avancer par étapes. Je contrôle les fichiers générés, je relis les changements, je regarde les commits. Si quelque chose sent bizarre, je stoppe et je corrige le contexte ou la spec. C’est moins spectaculaire qu’un prompt magique, mais c’est beaucoup plus fiable.

Ce que je vérifie	Pourquoi	Risque évité
Contexte projet	Pour que l’agent comprenne l’architecture et les conventions	Des modifications incohérentes avec le repo
Spec feature	Pour clarifier le besoin avant le code	Une feature hors sujet ou incomplète
Plan d’implémentation	Pour valider la trajectoire technique	Un enchaînement de tâches mal pensé
Commits Git	Pour garder une trace lisible du travail	Un gros bloc impossible à relire ou à rollback

Quand est ce utile en équipe ?

Conductor devient surtout utile quand plusieurs personnes, ou plusieurs sessions IA, doivent travailler avec la même compréhension du projet. C’est là que les prompts improvisés montrent vite leurs limites. Chacun explique le contexte à sa manière, l’IA oublie une partie, et au bout de trois itérations on ne sait plus vraiment ce qui a été décidé.

Avec Conductor, l’idée est plus simple : je garde un contexte explicite, lisible, versionné et réutilisable. Ce n’est pas magique, mais en équipe ça change beaucoup de choses.

Les cas où je le vois vraiment bien fonctionner sont assez concrets :

• Un repo existant : L’IA peut comprendre les conventions du projet, les dossiers importants, les règles à respecter, au lieu de repartir de zéro à chaque session.
• L’onboarding d’un dev : Un nouveau membre peut s’appuyer sur une base de contexte propre pour comprendre plus vite le code, les choix techniques et les zones sensibles.
• Une refonte par petites touches : On peut cadrer les changements, éviter les gros tunnels, et garder une trace de ce qu’on veut moderniser sans tout casser.
• La génération de features encadrées : L’IA peut produire du code, mais dans un périmètre défini, avec des contraintes claires.
• L’automatisation de tâches récurrentes : Documentation, tests, nettoyage, migration de fichiers, petits scripts. Ce sont souvent les meilleurs usages au début.
• L’expérimentation IA sans perdre le contrôle : On teste, mais avec un cadre. Pas juste une conversation jetable qui disparaît après coup.

Le lancement en preview du 17 décembre 2025, les milliers d’étoiles GitHub depuis le lancement, et le Google Codelab publié en avril 2026 montrent qu’il y a un vrai intérêt pour ce type de workflow. Je ne survends pas la maturité du produit pour autant. On est encore sur un outil jeune, à tester avec méthode, surtout sur des projets sérieux.

Conductor ne remplace pas la revue de code. Il ne remplace pas non plus la responsabilité d’architecture. La décision reste chez vous. Il rend juste le contexte plus stable, plus partageable, plus contrôlable. Et franchement, c’est déjà énorme.

Dans mes missions data, IA et automatisation, je vois toujours la même chose : les outils IA deviennent vraiment utiles quand ils travaillent sur des artefacts stables, pas sur des prompts improvisés à la volée.

Si vous voulez tester sérieusement Gemini CLI sur un vrai projet, Conductor donne un cadre beaucoup plus fiable qu’une session IA jetable.

Alors, vous le testez sur quel repo ?

Conductor Gemini CLI règle un problème très concret : l’IA qui code sans mémoire fiable du projet. En stockant le contexte, les specs et les plans dans le dépôt, il donne à Gemini CLI une base persistante, relue à chaque exécution. Le workflow CDD oblige à clarifier avant de générer, et Git garde une trace tâche par tâche avec possibilité de rollback. Ce n’est pas magique, il faut toujours relire, valider, arbitrer. Mais pour un projet sérieux, surtout en brownfield, ça change le niveau de contrôle. Le bénéfice pour vous : moins de code hors sujet, plus de continuité, et une IA beaucoup plus exploitable au quotidien.

FAQ

• À quoi sert Conductor avec Gemini CLI ?
  Conductor sert à rendre le contexte projet persistant. Au lieu de repartir de zéro à chaque session, Gemini CLI peut s’appuyer sur des fichiers Markdown et JSON stockés dans le dépôt, avec les conventions, les specs et les plans d’implémentation.
• Qu’est ce que le Context-Driven Development ?
  Le Context-Driven Development consiste à construire le contexte avant de générer du code. Avec Conductor, on formalise d’abord le projet, puis la feature, puis le plan d’implémentation. Le code arrive après, avec moins de risques de partir dans une mauvaise direction.
• Conductor marche t il sur un projet existant ?
  Oui. Sur un repo existant, Conductor analyse le code, respecte .gitignore et .geminiignore, puis infère la stack et l’architecture. C’est justement utile en brownfield, là où les conventions implicites coûtent cher quand l’IA ne les voit pas.
• Pourquoi Git est important avec Conductor ?
  Conductor s’appuie sur Git pour créer des commits par tâche et permettre un retour arrière propre. C’est une sécurité simple mais essentielle quand on laisse un agent IA modifier du code dans un vrai projet.
• Quels prérequis faut il pour installer Conductor ?
  Il faut Gemini CLI installé, une authentification Google API ou Vertex AI, et un dépôt Git initialisé. L’installation de l’extension se fait avec gemini extensions install https://github.com/gemini-cli-extensions/conductor, idéalement avec l’auto-update activé.

 

 

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. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’accompagne des équipes comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor sur des sujets data, IA et automatisation très opérationnels. Si vous voulez cadrer vos usages IA, fiabiliser vos workflows ou industrialiser vos automatisations, je peux vous aider. Contactez-moi.