GEMINI.md : donner du contexte projet à Gemini CLI

Un GEMINI.md est le fichier de contexte que Gemini CLI lit automatiquement au démarrage. Vous y décrivez votre projet une fois (stack, commandes, conventions), et l'agent en tient compte à chaque demande, sans que vous ayez à le répéter. C'est l'équivalent du CLAUDE.md de Claude Code. Ce guide vous montre comment générer un GEMINI.md avec /init, quoi y mettre, et comment fonctionne la hiérarchie entre fichier global, fichier de projet et sous-dossiers. Il s'adresse à toute personne qui veut des réponses adaptées à son dépôt plutôt que génériques.

Ce que vous allez apprendre

• Ce qu'est un GEMINI.md et pourquoi il change la qualité des réponses
• Générer un GEMINI.md adapté à votre projet avec /init
• Quoi écrire dedans (et ce qu'il vaut mieux éviter)
• La hiérarchie global / projet / sous-dossiers et comment l'inspecter
• Vérifier que votre contexte est bien chargé

Prérequis

• Gemini CLI installé et une première session réussie. Voir Installer Gemini CLI et Prise en main du REPL.
• Un projet (même petit) ouvert dans votre terminal.

GEMINI.md, c'est quoi ?

C'est un simple fichier Markdown, placé à la racine de votre projet, que Gemini CLI charge automatiquement au lancement. Son contenu rejoint le contexte de l'agent : vos conventions, vos commandes, l'architecture du projet deviennent des informations qu'il connaît d'emblée.

L'effet est concret. Sans contexte, l'agent devine. Avec un GEMINI.md, il applique vos règles. Lors de la validation de ce guide, un GEMINI.md contenant la consigne « commence ta réponse par [DEMO-INVENTAIRE] » a bien été respecté dès le premier prompt, et l'agent décrivait correctement le projet sans qu'on le lui explique :

> En une phrase, que fait ce projet ?
[DEMO-INVENTAIRE] Ce projet est un script Python permettant de lister les
serveurs enregistrés dans une base de données SQLite.

L'équivalent du CLAUDE.md

Si vous venez de Claude Code, GEMINI.md joue exactement le rôle du CLAUDE.md : un mémo de projet versionné, lu à chaque session. La logique est la même, seul le nom de fichier change.

Générer un GEMINI.md avec /init

Le plus simple est de laisser l'agent l'écrire à partir de votre code. Dans le REPL, lancez :

> /init

D'après l'aide intégrée, /init « analyse le projet et crée un GEMINI.md sur mesure ». L'agent lit vos fichiers clés (README, gestionnaire de dépendances, code source) et génère un fichier structuré. Sur un petit projet Flask de test, la génération a produit un fichier complet et exploitable :

# GEMINI.md - Init Demo

## 1. Description du Projet
Init Demo est une application web minimale développée en Python avec Flask...

## 2. Stack Technique
- Langage : Python 3.x
- Framework Web : Flask 3.1.0 (défini dans requirements.txt)
- Structure : src/app.py (point d'entrée), requirements.txt

## 3. Commandes Utiles
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
flask --app src.app run --debug
curl http://127.0.0.1:5000/health

## 4. Conventions de Code
- PEP 8, imports ordonnés, formatage via black ou ruff
- Dépendances épinglées dans requirements.txt
- API : réponses JSON, gestion d'erreurs avec codes HTTP appropriés

Traitez ce fichier généré comme un brouillon : relisez-le, corrigez ce qui est faux ou inventé, ajoutez ce que l'agent ne pouvait pas deviner.

Repartez du généré, ne gardez pas tout

/init est rapide mais générique. Le GEMINI.md qui vous fera gagner du temps contient surtout ce qui ne se lit pas dans le code : pourquoi telle bibliothèque, quelles zones à ne pas toucher, la commande de test exacte, vos règles d'équipe.

Quoi écrire dans un GEMINI.md

Un bon fichier reste court et actionnable. Les rubriques qui rapportent le plus :

• Description : ce que fait le projet, en deux ou trois phrases.
• Stack et structure : langages, frameworks, où se trouve quoi.
• Commandes : installer, lancer, tester, linter. L'agent les réutilisera telles quelles, donnez les vraies.
• Conventions : style de code, nommage, façon de gérer les erreurs.
• Garde-fous : ce qu'il ne faut pas modifier (migrations, fichiers générés, secrets).

Épingler les versions, jamais de secrets

Indiquez les versions exactes de vos dépendances dans le GEMINI.md comme dans votre code (flask==3.1.0, image Docker par digest) : l'agent propose alors des commandes reproductibles. À l'inverse, aucun secret dans ce fichier : il est versionné dans Git et lu à chaque session.

La hiérarchie : global, projet, sous-dossiers

Gemini CLI ne lit pas un seul GEMINI.md, il combine plusieurs niveaux :

Niveau	Emplacement	Usage
Global	~/.gemini/GEMINI.md	Vos préférences pour tous vos projets
Projet	./GEMINI.md (et dossiers parents)	Le contexte du dépôt courant
Sous-dossier	GEMINI.md dans un sous-répertoire	Contexte local à un module

Glissez pour voir

Les contenus s'additionnent, du plus général au plus spécifique. Trois commandes permettent d'inspecter ce qui est réellement chargé :

Commande	Rôle
/memory list	Lister les chemins des GEMINI.md en cours d'utilisation
/memory show	Afficher le contenu mémoire combiné
/memory reload	Recharger après une modification

Glissez pour voir

Seuls les fichiers réellement présents sont chargés. Dans un projet qui n'a qu'un GEMINI.md à sa racine, /memory list confirme un seul fichier, et /memory show l'affiche sous une section Project avec son chemin absolu :

> /memory list
ℹ There are 1 GEMINI.md file(s) in use:

> /memory show
ℹ Current memory content from 1 file(s):
  --- Project ---
  --- Context from: /home/bob/Projets/.../gemini-md-demo/GEMINI.md ---
  # Contexte projet - demo-inventaire
  ...
  --- End of Context ---

Ajoutez un ~/.gemini/GEMINI.md et il apparaîtra en plus, dans une section globale : les niveaux se cumulent, du global au plus local.

Modifié ? Rechargez

Si vous éditez un GEMINI.md pendant une session, lancez /memory reload pour que l'agent prenne en compte la nouvelle version sans redémarrer.

Vérifier que le contexte est bien chargé

Deux réflexes simples :

1. Lister et afficher ce qui est chargé avec /memory list (le nombre de fichiers) puis /memory show : vous devez y voir le chemin de votre GEMINI.md de projet, sous la section Project.

2. Tester une règle : ajoutez une consigne facile à vérifier (par exemple un préfixe imposé dans les réponses), lancez /memory reload, puis posez une question. Si la règle est appliquée, le contexte est bien pris en compte.

À retenir

1. GEMINI.md est un fichier Markdown chargé automatiquement : il donne à l'agent le contexte de votre projet, comme le CLAUDE.md de Claude Code.
2. /init génère un premier GEMINI.md à partir de votre code ; relisez et corrigez le résultat.
3. Mettez-y surtout ce qui ne se lit pas dans le code : commandes réelles, garde-fous, conventions d'équipe.
4. Épinglez les versions, ne mettez jamais de secret (le fichier est versionné).
5. La hiérarchie global / projet / sous-dossier se combine ; inspectez-la avec /memory list et /memory show, rechargez avec /memory reload.

Prochaines étapes

Prise en main du REPL Les commandes /, les fichiers @ et le mode shell ! au quotidien.

Gemini CLI : le hub complet Le pilier de la formation et tous les guides par phase.

Claude Code : le hub L'autre grand agent CLI et son fichier de contexte CLAUDE.md.

Installer Gemini CLI Revenir à l'installation et à l'authentification.

×

📖 Voir la documentation →