Introduction à Conductor pour Gemini CLI

Lorsque vous utilisez Gemini CLI, il vous suffit de décrire une fonctionnalité que vous souhaitez développer, et l'agent commence immédiatement à écrire du code. Cependant, ce processus peut souvent mener à des résultats insatisfaisants. En effet, l'agent génère du code sans connaître l'architecture spécifique de votre projet, ce qui conduit à des implémentations qui ne correspondent pas à vos attentes. Vous vous retrouvez alors à devoir démêler ce code généré, vous demandant si vous n'auriez pas mieux fait de l'écrire vous-même.

Ce problème ne provient pas de Gemini en soi, mais d'un manque de contexte. L'agent ignore tout de votre projet : les bibliothèques que vous utilisez, vos normes de codage, ou même l'objectif précis de la fonctionnalité. Chaque session commence sans mémoire du passé.

Lancement de Conductor

Pour résoudre ce problème, Google a lancé Conductor en version préliminaire le 17 décembre 2025. Cette extension de Gemini CLI introduit un nouveau flux de travail appelé Context-Driven Development (CDD). Contrairement à une simple fenêtre de chat éphémère, le contexte de votre projet, les spécifications et les plans d'implémentation sont stockés dans des fichiers Markdown au sein de votre dépôt. Ces fichiers sont lus par l'agent à chaque interaction avec votre projet, garantissant que vos directives, décisions techniques et objectifs produits sont toujours pris en compte.

Depuis son lancement, Conductor a connu un succès notable avec plus de 3 600 étoiles et 284 forks sur GitHub. Un Google Codelab, publié en avril 2026, propose un parcours complet pour utiliser Conductor dans un projet.

Comprendre Conductor

Avant d'explorer les commandes de Conductor, il est essentiel de comprendre le modèle sur lequel il repose, car il modifie fondamentalement la manière d'aborder le développement assisté par l'IA.

Les flux de travail de codage AI traditionnels sont sans état. Vous ouvrez une session, décrivez votre besoin, l'agent travaille, puis vous fermez la session. À la prochaine ouverture, l'agent a tout oublié. Comme l'a décrit un développeur de Google Cloud, ce modèle est "transitoire, oublieux et un peu cowboy".

Conductor change la donne en faisant du contexte un élément géré. Plutôt que de redécrire votre projet à chaque session, vous maintenez un ensemble de fichiers Markdown qui conservent cette information de manière permanente. L'agent les consulte à chaque exécution, garantissant que vos normes de codage, vos objectifs produits et vos plans de fonctionnalités sont toujours visibles.

Le post d'annonce de Google cite Benjamin Franklin : "ne pas planifier, c'est planifier d'échouer", pour illustrer la philosophie de Conductor. Le flux de travail de Conductor suit cet ordre : construire le contexte, spécifier la fonctionnalité, planifier l'implémentation, puis écrire le code.

Architecturalement, Conductor fonctionne à travers trois couches collaboratives :

• La Command Layer : c'est l'interface utilisateur avec laquelle vous interagissez via six commandes dans Gemini CLI.
• La Artifact Layer : un répertoire conductor/ dans votre dépôt qui contient des fichiers Markdown et JSON pour l'état du projet.
• La Version Control Layer : Git, utilisé par Conductor pour créer des commits par tâche et gérer les retours en arrière.

Conductor est compatible avec les projets greenfield (nouveaux) et brownfield (existants). Pour les projets brownfield, Conductor analyse votre base de code existante, respecte vos fichiers .gitignore et .geminiignore, et déduit votre pile technologique et votre architecture.

Prérequis et installation

Avant d'installer Conductor, vous devez disposer de trois éléments :

• Gemini CLI doit être installé et fonctionnel. Utilisez npm pour l'installer globalement :

# Installer Gemini CLI globalement
npm install -g @google/gemini-cli

# Vérifier l'installation
gemini --version

Si vous rencontrez des problèmes de permission, préférez un gestionnaire de version Node comme nvm. Après l'installation, redémarrez votre terminal pour que le binaire gemini soit dans votre PATH.

• Une clé API Google ou une configuration Vertex AI est nécessaire pour l'authentification de Gemini CLI. Lors de la première exécution de gemini, il vous demandera de vous authentifier. Sélectionnez Vertex AI et suivez les instructions pour définir votre variable d'environnement GOOGLE_API_KEY ou complétez le flux OAuth pour un usage personnel.

• Git doit être initialisé dans votre répertoire de projet. Conductor s'appuie sur Git pour créer des commits par tâche et gérer les retours en arrière. Pour un nouveau projet :

# Initialiser un nouveau dépôt git si ce n'est pas déjà fait
mkdir my-project && cd my-project
git commit --allow-empty -m "Initial commit"

Avec ces prérequis en place, installez Conductor :

# Installer l'extension Conductor
gemini extensions install https://github.com/gemini-cli-extensions/conductor

Le drapeau --auto-update maintient Conductor à jour automatiquement.

Recommandé pour la plupart des utilisateurs.

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

L'installation télécharge l'extension depuis GitHub, enregistre les six commandes de Conductor, configure un fichier de contexte **GEMINI.md** comme point d'entrée, et définit /conductor comme répertoire de plan. Le processus est rapide.

Vérifiez l'installation en lançant Gemini CLI et en tapant /conductor. Vous devriez voir la liste complète des sous-commandes : setup, newTrack, implement, status, revert, et review.

## Configurer votre projet avec /conductor:setup

Exécutez cette commande une fois par projet. Elle établit la fondation sur laquelle tout le reste repose. Depuis votre session Gemini CLI, dans votre répertoire de projet :

/conductor:setup

Conductor commence à analyser votre projet. Pour un projet brownfield, il scanne votre base de code pour déterminer ce avec quoi il travaille, respectant .gitignore pour éviter les répertoires lourds en tokens comme node_modules ou __pycache__. Pour un nouveau projet, il vous demande de décrire ce que vous construisez.

Il vous guide ensuite à travers une série de questions pour remplir six artefacts qu'il crée dans un nouveau répertoire conductor/ :

├── product.md # Vision produit, utilisateurs, objectifs, fonctionnalités clés, critères de succès ├── product-guidelines.md # Normes UI, ton et voix, comportement de gestion des erreurs ├── tech-stack.md # Langages, frameworks, bases de données, infrastructure ├── workflow.md # Préférences TDD, stratégie de commit, protocole de vérification ├── code_styleguides/ # Guides de style spécifiques au langage (générés automatiquement par langage trouvé) │ ├── python.md │ ├── typescript.md └── tracks.md # Registre maître de toutes les pistes (commence vide)

Chaque artefact a un rôle précis. product.md répond à "que construisons-nous et pour qui". tech-stack.md garantit que l'agent ne propose jamais une bibliothèque ou un modèle en dehors de votre pile. workflow.md définit vos préférences en matière de développement piloté par les tests (TDD), votre stratégie de commit, et les étapes de vérification manuelle requises avant de progresser dans les phases. code_styleguides/ contient des guides par langage que Conductor fournit avec des modèles pré-remplis, que vous pouvez personnaliser.

Une fois la configuration terminée, vous verrez le répertoire conductor/ dans votre projet. Engagez-le :

Commiter le contexte Conductor dans votre dépôt

git add conductor/ git commit -m "chore: initialize Conductor context-driven development"

Dès lors, tout membre de l'équipe qui clone le dépôt et ouvre Gemini CLI a immédiatement accès au contexte complet du projet, sans besoin de conversations d'intégration.

## Démarrer une fonctionnalité avec /conductor:newTrack

Une piste est la manière dont Conductor représente une unité de travail. Une fonctionnalité, un correctif, un changement architectural — tout cela constitue une piste. Les pistes donnent à l'agent un champ d'application défini, ce qui est essentiel pour éviter qu'il ne s'égare.

Pour commencer une piste, décrivez ce que vous souhaitez construire :

/conductor:newTrack "Ajouter un bouton de basculement du mode sombre à la page des paramètres, en conservant la préférence dans localStorage"

Vous pouvez également appeler /conductor:newTrack sans argument et décrire la fonctionnalité de manière interactive lorsque Conductor vous le demande.

Conductor prend votre description, lit le contexte complet du projet à partir de conductor/, et génère trois fichiers dans un nouveau répertoire conductor/tracks/<track_id>/ :

conductor/tracks/ └── dark_mode_20260614/ ├── spec.md # Le "quoi et pourquoi" -- exigences, objectifs, contraintes techniques, hors du champ ├── plan.md # La liste de contrôle d'implémentation par phases et par tâches └── metadata.json # ID de la piste, date de création, statut actuel

L'ID de la piste est formaté en shortname_YYYYMMDD, donc dark_mode_20260614 pour une piste de mode sombre créée le **14 juin 2026**. Cela permet de garder les pistes triées chronologiquement.

spec.md contient la spécification : quel problème cela résout, quels sont les objectifs, les exigences techniques, et ce qui est explicitement hors du champ. La section hors du champ est cruciale pour éviter que l'agent ne surcharge une fonctionnalité.

plan.md est la liste de contrôle d'implémentation, organisée par phases. Une fonctionnalité de mode sombre pourrait ressembler à ceci :

Plan d'Implémentation - Basculement du Mode Sombre

Phase 1 : Fondation

• [ ] Tâche : Ajouter la clé theme au schéma localStorage et la documenter dans le README du projet
• [ ] Tâche : Créer un hook useTheme qui lit/écrit la valeur theme et par défaut à la préférence système
• [ ] Tâche : Écrire des tests unitaires pour useTheme -- vérifier le comportement par défaut, lecture de localStorage, écriture dans localStorage
• [ ] Tâche : Conductor - Vérification Manuelle de l'Utilisateur 'Fondation' (Protocole dans workflow.md)

Phase 2 : Composant UI

• [ ] Tâche : Construire le composant ThemeToggle avec un bouton de basculement accessible (aria-label, support clavier)
• [ ] Tâche : Appliquer des classes CSS conditionnelles basées sur la valeur actuelle du thème provenant de useTheme
• [ ] Tâche : Écrire des tests de composant pour ThemeToggle -- rend correctement, déclenche le basculement au clic
• [ ] Tâche : Conductor - Vérification Manuelle de l'Utilisateur 'Composant UI' (Protocole dans workflow.md)

Phase 3 : Intégration à la Page des Paramètres

• [ ] Tâche : Importer ThemeToggle dans la page des paramètres

Chaque phase est clairement définie, ce qui permet à l'agent de travailler efficacement tout en respectant vos spécifications et votre contexte.