Conductor Gemini CLI garde-t-il le contexte IA ?

Conductor Gemini CLI garde le contexte projet dans le dépôt pour que l’agent arrête de repartir de zéro. J’y vois surtout une façon plus fiable de coder avec l’IA : objectifs produit, conventions, architecture, décisions techniques, tout reste lisible et versionné.

Quel problème Conductor règle-t-il ?

Conductor règle le manque de contexte persistant dans les sessions Gemini CLI. C’est ça le vrai sujet. Pas “est-ce que Gemini est intelligent ?”. Pas “est-ce que le modèle sait coder ?”. Le problème, c’est qu’à chaque session, l’agent peut très bien repartir avec une vision incomplète du projet.

Et dans une équipe dev, ça se voit vite. J’ai déjà vu ça chez un client : le code généré était propre en surface, bien indenté, avec des noms de fonctions corrects, parfois même des tests. Mais une fois posé dans le vrai repo, ça ne collait pas. Mauvais pattern. Mauvaise couche applicative. Mauvaise manière de gérer les erreurs. Une logique métier déjà tranchée ailleurs, mais ignorée par l’agent.

Un agent IA peut produire du code plausible parce qu’il sait reconnaître des formes. Il a vu des milliers d’exemples. Mais votre projet, lui, n’est pas un exemple générique. Il a son architecture, ses conventions, ses compromis, ses dettes assumées, ses règles métier un peu tordues, ses décisions techniques prises il y a six mois parce qu’il fallait livrer vite. Si tout ça n’est pas dans son contexte de travail, l’agent improvise.

Et l’improvisation coûte cher. Pas toujours au moment de la génération, justement. Sur le moment, on a l’impression d’avoir gagné du temps. Puis arrive la revue. Puis les corrections. Puis les “attends, pourquoi il a mis ça là ?”. Puis la réécriture. Au final, l’équipe passe du temps à nettoyer du code qui semblait utile, mais qui n’était pas aligné avec le projet.

Le sujet n’est donc pas la qualité brute du modèle. Le sujet, c’est sa mémoire de travail du projet. Est-ce qu’il sait où il est ? Est-ce qu’il comprend les règles locales ? Est-ce qu’il connaît les choix déjà faits ? Est-ce qu’il peut éviter de proposer une solution brillante mais complètement à côté ?

C’est là que Conductor devient intéressant. Si le contexte devient un artefact du dépôt, quelque chose de versionné, lisible et partagé, alors l’agent ne travaille plus dans le vide. Il travaille avec les mêmes repères que l’équipe.

Comment fonctionne le CDD ?

Le Context-Driven Development, ou CDD, consiste à créer et maintenir le contexte avant de demander du code. C’est tout bête dit comme ça, mais c’est exactement ce qui change le comportement d’un agent IA comme Gemini CLI ou Conductor Gemini CLI.

Dans une approche CDD, je ne commence pas par écrire “code-moi cette feature”. Je commence par poser le cadre. Le contexte devient une matière première du projet, au même niveau que le code.

Le workflow ressemble à ça :

• Créer le contexte avec les objectifs produit, les règles métier, les contraintes techniques, les conventions de nommage, les choix d’architecture.
• Spécifier la fonctionnalité avec ce qu’elle doit faire, ce qu’elle ne doit pas faire, les cas limites, les exemples attendus.
• Planifier l’implémentation avec les fichiers à modifier, les dépendances, les risques, les tests à prévoir.
• Générer le code seulement après, quand l’agent a assez d’informations pour travailler proprement.

La différence avec un prompt isolé est énorme. Quand on balance juste une demande à l’agent, il improvise avec ce qu’il voit dans la session. Il peut être brillant sur le moment, puis oublier une décision importante deux échanges plus tard. Avec le CDD, les fichiers de contexte sont conservés dans le dépôt, souvent en Markdown pour les explications humaines et en JSON pour les données structurées. L’agent les relit à chaque exécution, donc les objectifs produit, les guides de style et les choix d’architecture survivent aux sessions.

J’ai vu ça chez un client qui utilisait l’IA pour accélérer un back-office. Au début, chaque développeur avait “son bon prompt”. Résultat, trois styles de code, deux façons de gérer les erreurs, et des composants qui se ressemblaient sans vraiment se ressembler. Le vrai gain est arrivé quand on a arrêté de chercher le prompt magique, et qu’on a documenté le contexte dans le repo. Dans les projets IA, le progrès vient souvent moins de la phrase parfaite que de la discipline autour du contexte.

Approche classique avec prompt isolé	Approche CDD avec contexte versionné
L’agent dépend surtout de la session en cours.	L’agent relit les fichiers Markdown et JSON du dépôt.
Les décisions produit et architecture peuvent être oubliées.	Les décisions survivent aux sessions et aux changements d’équipe.
Le résultat varie beaucoup selon le prompt.	Le résultat est plus cohérent grâce au contexte partagé.

Quelles couches structurent Conductor ?

Conductor tient grâce à trois couches complémentaires. Je le vois comme une petite ossature autour de Gemini CLI, pas comme un simple pack de commandes. L’idée, c’est de donner à l’agent un cadre clair, des fichiers à relire, et un filet de sécurité quand il modifie du code.

La Command Layer, c’est la couche des commandes slash dans Gemini CLI. Vous tapez une commande du style /plan, /task ou /review, et Conductor déclenche une action cadrée. Ça évite de repartir d’un prompt vague à chaque fois. L’agent sait ce qu’on attend de lui, dans quel mode il doit travailler, et avec quel niveau de détail. C’est bête, mais ça change tout sur les longues sessions.

L’Artifact Layer, c’est le répertoire conductor/ et ses fichiers de contexte. Dedans, on retrouve les infos que l’agent doit pouvoir relire : objectifs, décisions, tâches, contraintes, état d’avancement. Pour moi, c’est la partie la plus intéressante. Conductor ne cherche pas seulement à piloter un agent IA. Il organise aussi la mémoire de travail autour de lui. Et franchement, sur un projet client avec beaucoup de règles métier, c’est souvent ça qui évite les réponses hors sujet trois jours plus tard.

La Version Control Layer, c’est Git. Pas juste pour faire propre. Git sert à tracer les tâches, commiter les étapes importantes, comparer ce qui a changé, et revenir en arrière si l’agent part dans une mauvaise direction. Avec l’IA, cette sécurité devient essentielle. On laisse un outil générer ou modifier des fichiers, donc il faut pouvoir vérifier, isoler, annuler. Sans ça, on travaille un peu les yeux fermés.

Couche	Rôle	Bénéfice concret
Command Layer	Piloter Gemini CLI avec des commandes slash	On évite les prompts flous et on garde une façon stable de travailler
Artifact Layer	Stocker le contexte dans conductor/	L’agent retrouve les objectifs, les décisions et les tâches sans tout réexpliquer
Version Control Layer	Utiliser Git pour suivre les changements	On peut contrôler, commiter, comparer et revenir en arrière si besoin

Cette architecture marche bien sur un projet neuf, parce qu’elle pose les règles dès le départ. Elle marche aussi sur un projet existant, peut-être même encore mieux, parce qu’elle force à remettre un peu d’ordre dans le contexte avant de demander à l’IA de toucher au code.

Comment l’installer proprement ?

Il faut installer Gemini CLI, configurer l’authentification Google, initialiser Git, puis installer l’extension Conductor. C’est la base propre. Si un de ces morceaux manque, ça marche parfois, mais on se retrouve vite avec des erreurs bêtes, surtout sur Node ou sur les droits d’accès Google.

Pour installer Gemini CLI, je pars d’un environnement Node propre. Si vous avez déjà eu des erreurs du style permission denied avec npm, je conseille d’utiliser nvm. Nvm, c’est un gestionnaire de versions Node. Ça évite d’installer des paquets globaux avec sudo, et franchement, ça m’a sauvé pas mal d’installations chez des clients.

Commande d’installation : npm install -g @google/gemini-cli

Commande de vérification : gemini –version

Ensuite, il faut configurer l’authentification. Gemini CLI peut fonctionner avec plusieurs modes selon votre environnement : une Google API key, Vertex AI si vous êtes sur un setup Google Cloud plus entreprise, ou un flux OAuth navigateur. OAuth, c’est simplement le mode où Gemini ouvre votre navigateur pour vous connecter avec votre compte Google.

Avant Conductor, je préfère avoir un dépôt Git déjà initialisé. Conductor s’appuie sur le projet, ses fichiers, son historique et ses règles d’exclusion. Sur un nouveau dossier, je fais souvent ça :

mkdir mon-projet
cd mon-projet
git init
git commit --allow-empty -m "Initial commit"

Après ça, j’installe Conductor depuis l’extension officielle :

Commande d’installation : gemini extensions install https://github.com/gemini-cli-extensions/conductor

Je recommande aussi l’option –auto-update quand elle est disponible dans votre contexte d’installation. C’est pratique pour garder l’extension à jour sans devoir y penser. Sur des outils IA qui bougent vite, rester bloqué sur une vieille version peut créer des comportements difficiles à comprendre.

Sur un projet existant, Conductor peut déjà inférer beaucoup de contexte depuis le code. Il lit la structure, repère les fichiers importants, et respecte normalement .gitignore et .geminiignore. Le fichier .geminiignore, c’est l’équivalent côté Gemini pour dire ce qu’il ne doit pas prendre en compte. Très utile pour exclure des dumps, des secrets, des builds ou des gros fichiers inutiles.

• Installer Gemini CLI avec npm.
• Vérifier la version avec gemini –version.
• Configurer l’authentification Google adaptée à votre cas.
• Initialiser Git avant de lancer Conductor.
• Installer Conductor depuis le dépôt officiel.
• Utiliser –auto-update si vous voulez éviter les mises à jour manuelles.
• Vérifier .gitignore et .geminiignore avant de travailler sur un vrai projet.

Quand l’utiliser sur un vrai projet ?

Conductor est utile quand le projet a assez de règles, de dette ou d’historique pour que le contexte compte vraiment. Si votre codebase est petite, neuve, sans conventions fortes, vous pouvez souvent vous débrouiller avec Gemini CLI seul et quelques bons prompts. Mais dès que vous répétez les mêmes consignes, “respecte notre architecture”, “utilise notre naming”, “ne touche pas à cette couche”, là Conductor commence à avoir du sens.

Sur un projet greenfield, donc un projet neuf, je l’utiliserais surtout comme garde-fou au démarrage. Pas pour générer 40 fichiers trop vite. Plutôt pour poser le cadre avant que l’agent parte dans tous les sens. Architecture, conventions de dossiers, style TypeScript ou Python, règles de tests, choix de librairies, objectifs produit. C’est là que le contexte aide vraiment. On donne une direction stable à l’IA avant de lui demander de produire.

Sur un projet brownfield, donc une application existante avec son historique, ses compromis et parfois ses bizarreries, l’intérêt est encore plus évident. Le risque classique avec un agent IA, c’est qu’il code “proprement” mais pas comme votre projet. Il ignore les standards déjà en place, réinvente une abstraction, casse une convention implicite. J’ai vu ça chez un client sur une app Node assez ancienne. Le code généré était correct isolément, mais il ne ressemblait pas au reste. Résultat, review pénible et refactor derrière.

Les cas où je le trouve vraiment utile sont assez concrets :

• Refactor : Garder les contraintes métier et techniques visibles pendant que l’agent déplace ou simplifie du code.
• Ajout de fonctionnalité : Générer une nouvelle feature sans sortir du pattern déjà utilisé dans l’application.
• Harmonisation de style : Aligner les noms, les erreurs, les logs, les tests et les formats de réponse API.
• Stack existante : Produire du code cohérent avec React, NestJS, FastAPI, Laravel ou autre, sans réexpliquer toute la stack à chaque prompt.

Je reste prudent quand même. Conductor ne garantit pas que l’agent comprend tout. Il faut relire. Il faut commiter proprement. Il faut garder les artefacts de contexte à jour, sinon l’IA s’appuie sur une photo périmée du projet. Et là, ça peut devenir pire qu’un prompt simple.

Ma règle de décision est simple : si votre équipe utilise déjà Gemini CLI et Git, l’essai est logique dès que les prompts répétés commencent à coûter du temps. Pas besoin d’en faire une grande migration. Vous testez sur un refactor ou une petite feature, vous mesurez si les reviews sont plus fluides, et vous gardez seulement si ça réduit vraiment le bruit.

Et si le vrai levier était le contexte ?

Je retiens surtout une chose : Conductor Gemini CLI remet le contexte au bon endroit, dans le dépôt, avec le code. Ça évite à l’agent de redécouvrir le projet à chaque session et ça oblige l’équipe à formaliser ce qui compte vraiment : architecture, conventions, objectifs, décisions. Le CDD n’enlève pas la revue humaine, et heureusement. Il rend juste l’assistance IA plus stable, plus alignée, plus facile à annuler grâce à Git. Si vous utilisez déjà Gemini CLI, c’est une piste sérieuse pour réduire les corrections inutiles et obtenir un code plus cohérent avec votre projet.

FAQ

• À quoi sert Conductor pour Gemini CLI ?
  Conductor sert à donner un contexte persistant à Gemini CLI. Au lieu de repartir d’un prompt isolé à chaque session, l’agent relit des fichiers de contexte stockés dans le dépôt. Ça l’aide à respecter l’architecture, les conventions et les objectifs du projet.
• Qu’est-ce que le Context-Driven Development ?
  Le Context-Driven Development, ou CDD, consiste à préparer le contexte avant de demander du code. On définit le contexte projet, puis la fonctionnalité, puis le plan d’implémentation, et seulement après on génère le code. C’est plus cadré qu’un simple échange avec un agent IA.
• Conductor fonctionne-t-il sur un projet existant ?
  Oui, Conductor peut être utilisé sur un projet brownfield. Lors du setup, il peut analyser le dépôt existant, respecter .gitignore et .geminiignore, puis inférer des éléments de stack et d’architecture. Ça reste à relire, mais c’est utile pour démarrer sans tout documenter à la main.
• Pourquoi Git est-il important avec Conductor ?
  Git permet de versionner le contexte et le code généré. Conductor s’appuie sur cette logique pour travailler par tâche, garder une trace des changements et revenir en arrière si une génération part dans la mauvaise direction. Pour moi, c’est une sécurité indispensable.
• Quels sont les prérequis pour installer Conductor ?
  Il faut Gemini CLI installé, une authentification Google configurée via API key, Vertex AI ou OAuth selon le mode choisi, et un dépôt Git initialisé. L’installation de l’extension se fait avec la commande 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. Avec mon agence webAnalyste et mon 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. Si vous voulez mettre en place des workflows IA plus fiables dans votre business, contactez-moi.