Utiliser Aider : le guide pas à pas

Pour utiliser Aider, installez-le avec aider-install ou le script en une ligne, placez-vous avec cd dans un dépôt git, lancez-le avec aider --model sonnet --api-key anthropic=<key> (ou un autre fournisseur), ajoutez avec /add les fichiers à modifier et décrivez la modification en langage courant. Aider modifie les fichiers et commite chaque changement dans git, donc /undo permet de revenir en arrière.

Voilà toute la boucle. Ce guide couvre ce qui rend Aider agréable au quotidien : clés API et modèles, choix des fichiers à ajouter, modes ask, code et architect, formats d’édition, comportement avec git, .aider.conf.yml, intégration du lint et des tests, et fichier de conventions. Toutes les commandes et options citées viennent de la documentation officielle d’Aider sur aider.chat, telle qu’elle était en octobre 2026.

Ce qu’est Aider

Aider est un binôme de programmation IA pour le terminal. C’est un agent de code qui fonctionne avec presque tous les LLM : Claude, GPT, Gemini, DeepSeek ou un modèle local. Deux choses le distinguent de la plupart des agents CLI. D’abord, il est construit autour de git : chaque modification devient un commit. Ensuite, il est explicite sur le contexte : c’est vous qui décidez quels fichiers sont dans la conversation, et une carte du dépôt donne au modèle un résumé du reste.

Si vous le comparez à d’autres agents de terminal, comment utiliser opencode et comment utiliser GitHub Copilot CLI suivent le même format pas à pas.

Étape 1 : installer Aider

La documentation d’Aider propose plusieurs méthodes d’installation. Choisissez-en une.

aider-install installe Aider dans son propre environnement Python, pour éviter les conflits avec les paquets de votre projet. Si vous installez avec un simple pip, faites-le dans un environnement virtuel. Si la commande aider est introuvable après une installation avec pip, python -m aider fait la même chose.

Étape 2 : clés API et modèles

Aider communique avec les fournisseurs de modèles grâce à vos propres clés. Le plus rapide pour démarrer est de passer le modèle et la clé en ligne de commande :

cd /to/your/project

# Anthropic
aider --model sonnet --api-key anthropic=<key>

# OpenAI
aider --model o3-mini --api-key openai=<key>

# DeepSeek
aider --model deepseek --api-key deepseek=<key>

Taper une clé à chaque fois devient vite pénible. Aider lit aussi les variables d’environnement habituelles (ANTHROPIC_API_KEY, OPENAI_API_KEY, GEMINI_API_KEY, DEEPSEEK_API_KEY, etc.) ainsi qu’un fichier .env dans votre projet. --api-key provider=<key> fonctionne pour n’importe quel fournisseur : --api-key gemini=xxx définit GEMINI_API_KEY.

Les noms courts comme sonnet sont des alias intégrés. En octobre 2026, la documentation associe sonnet, opus et haiku aux modèles Claude actuels, gemini et flash à des modèles Gemini, deepseek et r1 à DeepSeek chat et reasoner, et 4o à GPT-4o. Vous pouvez définir les vôtres :

aider --alias "fast:gpt-4o-mini" --model fast

Dans une session, /model <name> change le modèle principal, /models <search> liste les modèles disponibles et /reasoning-effort règle l’effort pour les modèles qui le prennent en charge. Aider utilise aussi un « weak model » moins cher pour les messages de commit et les résumés de conversation ; --weak-model permet de le changer. Vous voulez tout faire tourner sur votre propre machine ? Le guide de l’agent de code avec un LLM local explique cette configuration.

Étape 3 : ajouter des fichiers à la conversation

Aider ne modifie que les fichiers présents dans la conversation. Vous pouvez les indiquer au lancement :

aider src/api/users.py tests/test_users.py

ou les ajouter ensuite :

/add src/api/users.py tests/test_users.py

La documentation d’Aider est claire sur un point : n’ajoutez que les fichiers à modifier pour la tâche. Chaque fichier ajouté coûte des tokens, et trop de fichiers peuvent submerger le modèle. Aider construit une carte de tout le dépôt, si bien que le modèle sait déjà où se trouvent les fonctions et classes liées sans que vous les ajoutiez. Si vous n’ajoutez rien, Aider essaie de déterminer lui-même quels fichiers modifier.

Les commandes qui gèrent le contexte :

• /add <files> ajoute des fichiers qu’Aider peut modifier.
• /read-only <files> ajoute des fichiers de référence qu’il peut lire sans les modifier (documentation, module d’exemple).
• /drop <files> retire des fichiers pour libérer du contexte ; /drop seul les retire tous.
• /ls liste les fichiers de la conversation et du dépôt.
• /tokens indique combien de tokens le contexte actuel utilise.
• /map affiche la carte du dépôt et /map-refresh la reconstruit.

Décrivez ensuite la modification :

Ajoute la pagination à l’endpoint list_users : accepte les paramètres de
requête page et page_size, 20 éléments par page par défaut, et mets à jour les tests.

Étape 4 : les modes ask, code et architect

Aider propose plusieurs modes de conversation, et bien choisir le mode fait l’essentiel de la maîtrise de l’outil.

/ask, /code et /architect suivis d’un message ne s’appliquent qu’à ce message. Tapés seuls, ils changent le mode jusqu’à ce que vous en changiez à nouveau ; /chat-mode <mode> fait la même chose. --chat-mode <mode> choisit le mode au lancement, et --architect en est un raccourci.

Le flux de travail recommandé par la documentation consiste à alterner. Demandez d’abord, affinez le plan, puis laissez-le coder :

/ask Comment ajouter une limitation de débit à la route de connexion sans
toucher aux autres endpoints ? Ne modifie rien pour l’instant.

Quand le plan vous convient, tapez /ok. C’est un raccourci pour « /code Ok, please go ahead and make those changes. » (« D’accord, vas-y, fais ces modifications. »)

Le mode architect répartit le travail entre deux modèles. Le modèle principal décrit comment résoudre le problème, et un modèle éditeur, défini avec --editor-model, le traduit en modifications de fichiers. Si vous ne le précisez pas, Aider choisit un modèle éditeur adapté à chaque modèle principal. Cela aide souvent avec les modèles de raisonnement, bons pour planifier mais moins fiables pour produire des modifications exactes. La contrepartie : le mode architect envoie deux requêtes par modification, il est donc plus lent et plus coûteux.

Étape 5 : les formats d’édition

Un format d’édition est la manière dont le modèle indique à Aider ce qu’il faut changer. Vous aurez rarement à y toucher, car Aider choisit le meilleur format pour chaque modèle, mais il est utile de savoir ce que vous voyez :

Changez-le avec --edit-format <format>, et réglez le format du modèle éditeur avec --editor-edit-format. Si un modèle produit sans cesse des modifications qui ne s’appliquent pas, passer à whole est un test raisonnable pour les petits fichiers.

Étape 6 : git, commits automatiques et /undo

Aider donne le meilleur de lui-même dans un dépôt git. Par défaut :

• Chaque modification d’Aider est commitée avec un message descriptif, rédigé par le weak model dans le style Conventional Commits.
• Si des fichiers contenaient des changements non commités avant qu’Aider les modifie, il les commite d’abord, pour que votre travail et le sien restent dans des commits séparés.
• « (aider) » est ajouté au nom de l’auteur et du committer git sur ses commits.

Le filet de sécurité est donc simple :

• /diff montre les changements depuis votre dernier message.
• /undo annule le dernier commit s’il vient d’Aider.
• /commit commite les modifications que vous avez faites vous-même en dehors d’Aider.
• /git <command> lance n’importe quelle commande git sans quitter la conversation.

Vous pouvez désactiver certaines parties : --no-auto-commits laisse les modifications non commitées pour que vous les relisiez, --no-dirty-commits saute le commit préalable, et --no-git désactive complètement git (la documentation le déconseille). Aider commite par défaut avec --no-verify, donc vos hooks pre-commit ne s’exécutent pas ; ajoutez --git-commit-verify si vous voulez qu’ils tournent. Si vous préférez tenir les modifications d’Aider à l’écart de votre copie principale, lancez-le dans un git worktree séparé.

Étape 7 : configurer .aider.conf.yml

Les options que vous utilisez à chaque fois ont leur place dans un fichier YAML. Aider charge .aider.conf.yml depuis votre dossier personnel, puis la racine du dépôt git, puis le dossier courant ; les fichiers chargés en dernier l’emportent. --config <file> ne charge que ce fichier.

# .aider.conf.yml
model: sonnet
weak-model: haiku
auto-commits: true
dirty-commits: true
lint-cmd: "python: ruff check --fix"
test-cmd: pytest -q
auto-test: false
read: [CONVENTIONS.md]

Les clés du fichier correspondent aux noms longs des options, sans les tirets. Les clés API peuvent aussi y figurer (anthropic-api-key:, openai-api-key: ou une liste api-key: comme - gemini=xxx), mais dans ce cas gardez ce fichier hors de git. Par défaut, Aider ajoute .aider* au .gitignore pour que ses fichiers d’historique ne finissent pas dans les commits.

Étape 8 : intégrer le lint et les tests

Aider passe un linter sur les fichiers qu’il modifie juste après chaque changement, avec des linters intégrés pour la plupart des langages courants. Si le linter signale des problèmes, Aider essaie de les corriger. Vous pouvez utiliser votre propre linter :

aider --lint-cmd "python: ruff check --fix" --lint-cmd "javascript: npx eslint --fix"

La commande doit afficher les erreurs et renvoyer un code de sortie non nul quand elle trouve des problèmes. --no-auto-lint désactive le lint.

Les tests fonctionnent de la même façon, mais ils sont désactivés par défaut. Définissez une commande avec --test-cmd et activez --auto-test : Aider lance alors les tests après chaque modification et tente de corriger les échecs (tout code de sortie non nul). Dans la conversation :

• /lint passe le linter sur les fichiers de la conversation et les corrige, ou sur tous les fichiers modifiés si aucun n’est ajouté.
• /test <command> lance une commande et, si elle échoue, ajoute la sortie à la conversation.
• /run <command> (ou !<command>) lance une commande shell et vous permet de partager sa sortie.

Étape 9 : un fichier de conventions

Aider n’a pas de fichier d’instructions de projet intégré qu’il chargerait tout seul. La méthode documentée est un simple fichier Markdown chargé en lecture seule :

# CONVENTIONS.md
- Prefer httpx over requests for making http requests.
- Use types everywhere possible.
- Every new endpoint needs a test in tests/api/.

aider --read CONVENTIONS.md

ou /read-only CONVENTIONS.md pendant une session, ou encore read: CONVENTIONS.md dans .aider.conf.yml pour qu’il soit chargé à chaque fois. Les fichiers en lecture seule sont mis en cache quand le prompt caching est activé, donc le coût reste faible. Si vous tenez déjà un AGENTS.md pour d’autres agents, vous pouvez le charger à la place ; CLAUDE.md et AGENTS.md donne des conseils pour écrire des règles que les agents suivent vraiment.

Deux autres fonctions à connaître

Les scripts. --message (ou -m) envoie une seule instruction, applique les modifications et quitte, ce qui permet de lancer facilement Aider en boucle sur des fichiers :

for FILE in *.py ; do
  aider --message "add descriptive docstrings to all the functions" $FILE
done

Ajoutez --yes-always pour accepter automatiquement les confirmations, et --message-file pour lire l’instruction depuis un fichier.

Le mode watch. Lancez Aider avec --watch-files et continuez à travailler dans votre éditeur. Écrivez un commentaire qui se termine par AI! et Aider fait la modification ; terminez-le par AI? et Aider répond à la question. Cela fonctionne avec les commentaires #, // et --.

Pièges courants

• Ajouter tout le dépôt. Plus de fichiers, c’est un coût plus élevé et des modifications de moins bonne qualité. Ajoutez ce qui change, utilisez /read-only pour les références et faites confiance à la carte du dépôt.
• Oublier le commit des changements en cours. Aider commite vos modifications non commitées avant de toucher un fichier. Si cela vous surprend, commitez ou faites un stash avant, ou utilisez --no-dirty-commits.
• Compter sur les hooks. Les commits sautent les hooks pre-commit, sauf si vous passez --git-commit-verify.
• Le mode architect pour tout. Il double le nombre de requêtes. Réservez-le aux modifications délicates ; le mode code suffit pour les petits changements.
• Des clés dans une configuration commitée. Si .aider.conf.yml contient des clés API, gardez-le dans votre dossier personnel ou hors de git.
• Les longues conversations. Les anciens messages coûtent des tokens à chaque requête. /clear efface l’historique de la conversation et /reset retire aussi les fichiers.

Utiliser Aider dans AgentVera

AgentVera est une application de bureau pour macOS, Windows et Linux qui exécute des agents CLI côte à côte dans de vrais terminaux, avec vos propres installations et vos propres clés. Aider fait partie des agents pris en charge ; la page Aider dans AgentVera donne les détails :

• Vos clés, votre configuration. Aider lit les clés des fournisseurs dans les variables d’environnement ou dans .aider.conf.yml, comme d’habitude. Le modèle choisi dans AgentVera est passé avec --model, et l’effort low, medium ou high avec --reasoning-effort.
• Un historique séparé par agent. Chaque agent Aider garde son propre fichier d’historique sous ~/.aider/agentvera/ et le reprend avec --restore-chat-history à la réouverture de l’application : plusieurs agents Aider ne mélangent donc jamais leurs historiques.
• Les rôles comme fichier en lecture seule. Aider ne permet pas d’étendre son prompt système, donc le rôle de l’agent est passé avec --read, le même mécanisme qu’un fichier de conventions.
• Des panneaux à côté des autres agents. Lancez Aider dans la grille du Workspace à côté de Claude Code ou Codex, et démarrez des agents dans leurs propres worktrees depuis le panneau Git.
• Relecture et flows. Les agents Aider bénéficient de la code review automatique à la fin de chaque tour, et ils fonctionnent dans les flows (Pro et Team), les diffusions et les tâches planifiées.

Une limite à connaître : les serveurs MCP configurés dans AgentVera ne sont pas transmis à Aider. La grille, les worktrees et la code review sont dans l’offre gratuite. Téléchargez AgentVera pour l’essayer.

En résumé

Installez Aider, placez-vous dans un dépôt git, lancez-le avec un modèle et une clé, et n’ajoutez que les fichiers dont la modification a besoin. Utilisez /ask pour planifier et /ok ou /code pour appliquer, essayez /architect pour les problèmes plus difficiles, et appuyez-vous sur /diff et /undo, puisque chaque modification est un commit. Mettez vos réglages par défaut dans .aider.conf.yml, vos règles dans CONVENTIONS.md, et laissez --lint-cmd et --test-cmd repérer les erreurs avant vous. Si vous utilisez aussi l’agent de GitHub, comment utiliser GitHub Copilot CLI est le même guide pour cet outil.