Gemini CLI : le coding agentique dans votre terminal

Gemini CLI est l'outil de coding agentique open source de Google qui vit dans votre terminal : il lit votre projet, modifie des fichiers et exécute des commandes pour vous, depuis un prompt conversationnel. Vous restez là où vous travaillez déjà (le shell), et l'agent prend en charge la boucle de parcours des fichiers, d'édition et d'exécution des tests.

Cette leçon vous fait traverser une vraie session « corrige ce bug et lance les tests », installation comprise. À la fin, vous saurez le pointer vers un repo, le laisser proposer des changements, les approuver et vérifier avec un run de tests.

Ce qu'est réellement Gemini CLI

C'est un agent en ligne de commande. Vous formulez une demande en langage naturel, et il planifie, lit des fichiers, propose des éditions et exécute des commandes shell dans votre répertoire de travail. C'est la même capacité agentique que celle qui alimente Gemini Code Assist dans l'IDE, mais dégroupée en un outil terminal que vous pouvez scripter et piper.

Trois raisons d'y prêter attention en tant qu'utilisateur avancé :

• Gestion d'un large contexte. Le long contexte de Gemini permet à l'agent de charger plusieurs fichiers d'un coup au lieu de deviner à partir d'un seul extrait. Pour les gros refactors, il lit largement avant d'agir.
• Outils intégrés. Il peut grep votre codebase, lire et écrire des fichiers, exécuter des commandes shell et ancrer ses réponses avec Google Search quand il a besoin d'informations à jour.
• Il est open source et extensible. Vous pouvez l'inspecter, le configurer par projet et l'étendre avec le Model Context ProtocolModel Context ProtocolUn standard ouvert qui permet aux assistants IA de se connecter aux outils et données de l'entreprise de façon cohérente et gouvernée, sans intégration sur mesure à chaque fois.Voir la définition complète → (MCP), le standard ouvert pour connecter des agents à des outils et données externes.

Le repo et la documentation officiels se trouvent sur github.com/google-gemini/gemini-cli.

L'installer

Il vous faut Node.js (une version LTS récente). Ensuite, installez la CLI globalement avec npm :

npm install -g @google/gemini-cli
gemini

Au premier lancement de gemini, il vous guide dans l'authentification. Le chemin le plus simple pour un particulier est de se connecter avec son compte Google personnel, ce qui donne droit à un free tier généreux pour la CLI. Si vous avez besoin de limites plus élevées ou voulez facturer sur un projet, vous pouvez à la place définir une GEMINI_API_KEY depuis Google AI Studio ou vous authentifier auprès de Vertex AI pour un usage entreprise.

export GEMINI_API_KEY="your-key-from-aistudio"

Choisissez une méthode d'authentification et tenez-vous-y par environnement. Mélanger un login personnel et une clé APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → dans le même shell est la source la plus fréquente de confusion du type « pourquoi utilise-t-il le mauvais quota ».

La boucle de l'agent : comment se déroule un tour

Avant le walkthrough, comprenez la boucle, car approuver les étapes intelligemment, c'est toute la compétence ici.

1. Vous promptez. En langage simple : « le parser de dates échoue sur les chaînes ISO, corrige-le et fais passer les tests ».
2. Il rassemble le contexte. L'agent lit les fichiers pertinents, souvent en greppant des symboles et en ouvrant les fichiers voisins.
3. Il propose une action. Une édition de fichier (affichée sous forme de diff) ou une commande shell (affichée avant exécution).
4. Vous approuvez ou refusez. Rien ne touche le disque et rien ne s'exécute sans votre oui, sauf si vous activez l'auto-approbation.
5. Il observe le résultat. Sortie des tests, traces d'erreur, codes de sortie des commandes reviennent en entrée.
6. Il itère jusqu'à atteindre l'objectif ou jusqu'à vous demander une direction.

C'est ce comportement d'observation et d'itération qui le distingue de l'autocomplétion. Un test qui échoue n'est pas une impasse ; c'est l'input suivant.

Walkthrough : corriger un bug et lancer les tests

Voici une session concrète. Imaginez un petit projet Python avec un test qui échoue dans un utilitaire de dates.

Lancez la CLI depuis la racine de votre projet pour qu'elle ait le bon répertoire de travail :

cd ~/projects/invoice-tool
gemini

Donnez-lui maintenant la tâche. Soyez précis sur le symptôme et la condition de succès :

> The function parse_due_date in billing/dates.py raises ValueError on
  ISO 8601 strings with a timezone offset. Find the bug, fix it, then
  run the test suite and confirm it passes.

Ce que vous allez voir, dans l'ordre :

Il lit le code. L'agent ouvre billing/dates.py et le fichier de test associé. Comme il dispose d'un vrai contexte, il n'invente pas de signatures de fonctions ; il travaille sur ce qui existe réellement.

Il propose une édition sous forme de diff. Par exemple, il peut découvrir que le code utilise datetime.strptime avec un format fixe et basculer vers datetime.fromisoformat, qui gère les offsets. Le diff est affiché pour relecture :

- return datetime.strptime(raw, "%Y-%m-%d")
+ return datetime.fromisoformat(raw)

Vous lisez le diff, puis tapez y pour l'appliquer. C'est le moment de regarder vraiment. L'agent est bon, pas infaillible. Un diff qui touche des fichiers auxquels vous ne vous attendiez pas est un signal : refusez et demandez pourquoi.

Il propose une commande. Ensuite, il suggère de lancer les tests. Il affiche la commande exacte avant de l'exécuter :

pytest -q

Approuvez. L'agent exécute pytest, capture la sortie et la lit.

Il itère si nécessaire. Admettons que deux tests passent désormais mais qu'un troisième échoue encore à cause d'une comparaison entre datetime naïf et aware. L'agent voit la traceback, propose une édition de suivi (normaliser la gestion des timezones), affiche le diff et relance la suite. Quand tout est vert, il résume ce qu'il a changé et pourquoi.

Le geste clé de votre côté : vous avez fourni la condition de succès (« les tests passent »), donc l'agent avait une mesure objective pour itérer. Des objectifs vagues produisent un travail vague. Des objectifs testables produisent un travail vérifiable.

Contrôler ce que l'agent peut faire

Approuver chaque étape est sûr mais lent. Pour des travaux répétitifs et de confiance, vous pouvez changer le mode d'approbation. Dans une session, vous pouvez passer en mode auto-approbation pour le tour en cours, et pour des runs totalement non surveillés il existe un mode de type YOLO qui approuve les actions automatiquement. N'utilisez cela que dans des environnements jetables ou des sandboxes, jamais sur un repo avec du travail non commité qui compte pour vous.

Une habitude plus sûre : commitez avant de démarrer. Un état git propre signifie que tout changement de l'agent est à un `git diff` de la relecture et à un `git checkout` de l'annulation.

Mémoire de projet avec GEMINI.md

Vous pouvez donner à l'agent des instructions persistantes et propres au projet en ajoutant un fichier GEMINI.md à la racine du repo. La CLI le lit automatiquement et le traite comme un contexte permanent pour chaque session. C'est là que vous encodez vos conventions pour ne pas les retaper.

# Project conventions
- Python 3.12. Use `uv` for env management, not pip directly.
- Run tests with `pytest -q`. Lint with `ruff check .`.
- Prefer `datetime.fromisoformat` over manual format strings.
- Never edit files under `migrations/` without asking first.

Désormais, « lance les tests » signifie de façon fiable pytest -q, et l'agent connaît les zones interdites. Voyez GEMINI.md comme le document d'onboarding du projet pour l'agent.

Étendre la CLI avec des outils et MCP

Par défaut, l'agent lit des fichiers, exécute des commandes et s'ancre avec Google Search. La vraie puissance pour des workflows avancés, c'est de le connecter à vos propres systèmes via des serveurs MCP.

Un serveur MCP expose à l'agent des outils (fonctions) et des données via un protocole standard. Connectez-en un pour votre outil de suivi de tickets, votre base de données ou une API interne, et l'agent peut agir sur ces systèmes aussi : « retrouve le ticket en échec dans notre tracker, reproduis-le, corrige-le ».

Vous configurez les serveurs dans un fichier de réglages, typiquement .gemini/settings.json dans votre projet. Un exemple minimal branchant un serveur MCP local :

{
  "mcpServers": {
    "tickets": {
      "command": "node",
      "args": ["./tools/ticket-mcp-server.js"]
    }
  }
}

Une fois enregistré, l'agent peut découvrir et appeler les outils que ce serveur expose pendant une session. C'est ainsi que vous passez de « corrige le code devant moi » à « corrige la chose décrite dans nos systèmes ». Pour construire des agents multi-étapes plus riches au-delà de la CLI, l'Agent Development Kit (ADK) de Google est le framework vers lequel évoluer ; la CLI est le point d'entrée rapide et interactif.

La scripter (mode non interactif)

Comme c'est une CLI, vous pouvez l'exécuter de façon non interactive et piper sa sortie. Cela la rend utilisable dans des scripts et des outillages proches de la CI. Passez un prompt directement et laissez-la tourner en headless :

gemini -p "Summarize the changes in the last commit and flag any
  function that lost test coverage." > review-notes.md

Combinez cela avec des hooks git ou une étape manuelle avant PR pour obtenir une première passe de relecture automatisée. Gardez ces prompts étroits et en lecture seule quand ils tournent sans surveillance ; réservez les runs qui modifient des fichiers aux sessions interactives et approuvées.

Quand utiliser la CLI plutôt que Code Assist

Les deux partagent le même moteur agentique, donc le choix dépend de là où vous vivez.

• Gemini CLI quand vous êtes dans le terminal : correctifs rapides, runs scriptés, serveurs sans IDE, ou pour piper la sortie vers d'autres outils.
• Gemini Code Assist quand vous êtes dans votre éditeur (VS Code, JetBrains, etc.) et voulez des diffs inline, du chat à côté de votre code et une intégration IDE serrée.

Beaucoup de développeurs utilisent les deux dans la même journée. La CLI est le couteau suisse ; Code Assist est l'établi. La leçon suivante traite Code Assist en profondeur.

Points clés

• Installez avec npm install -g @google/gemini-cli, lancez gemini depuis la racine de votre projet, et choisissez une seule méthode d'authentification (login personnel, clé API depuis AI Studio, ou Vertex AI) par environnement.
• Donnez toujours à l'agent une condition de succès testable (« fais passer les tests »), pour qu'il puisse observer les résultats et itérer au lieu de deviner.
• Commitez avant de démarrer et relisez chaque diff et chaque commande avant d'approuver ; réservez les modes d'auto-approbation aux sandboxes uniquement.
• Utilisez un fichier GEMINI.md pour encoder une fois pour toutes les conventions du projet et les zones interdites, afin que l'agent n'ait plus besoin de rappels.
• Étendez la CLI avec des serveurs MCP dans .gemini/settings.json pour la laisser agir sur vos systèmes réels, et passez à l'ADK quand vous devez construire des agents autonomes.