Aider : un agent dev en CLI

#Ce qu'est Aider, et ce qu'il fait dans votre dépôt

Aider est un assistant de programmation en ligne de commande, open source, qui se présente lui-même comme de la programmation en binôme avec une IA dans le terminal. Vous lancez la commande aider dans un dépôt Git, vous décrivez un changement en langage naturel, et il propose des modifications de fichiers, les applique, puis les enregistre dans un commit. Il fonctionne avec des modèles hébergés (Claude, GPT, DeepSeek) comme avec des modèles locaux servis par Ollama ou LM Studio, ce qui en fait l'un des rares agents de code utilisables sans qu'une ligne de votre projet ne quitte la machine. Le dépôt officiel dépasse les 49 000 étoiles sur GitHub.

Trois choses le distinguent d'un simple chat. D'abord, il tient une carte du dépôt : à chaque requête, il envoie au modèle une liste des fichiers avec leurs classes, fonctions et signatures principales, de sorte que le modèle sait où chercher sans que vous lui montriez tout. Ensuite, il est intégré à Git : chaque modification devient un commit annulable. Enfin, il boucle sur des commandes que vous lui donnez, linter et tests, et tente de corriger ce qui échoue. Ce n'est pas un agent autonome qui explore le web ou lance des serveurs : c'est un éditeur de code piloté par la conversation.

#Installer Aider

La méthode officielle la plus courte passe par le paquet aider-install, qui installe Aider dans son propre environnement Python isolé et, au besoin, télécharge une version de Python compatible. Le prérequis est un Python entre 3.8 et 3.13 pour cette voie. Des installateurs en une ligne, fondés sur uv, existent pour macOS, Linux et Windows. L'ancienne recette avec pipx fonctionne toujours, mais la documentation actuelle recommande aider-install.

python -m pip install aider-install
aider-install

# Vérifier
aider --version

Placez-vous ensuite à la racine de votre projet. Si le dossier n'est pas un dépôt Git, Aider propose d'en créer un, mais il vaut mieux l'initialiser vous-même : tout le filet de sécurité décrit plus bas repose sur Git.

#Le brancher sur Ollama sans se piéger avec le contexte

La documentation officielle d'Aider pour Ollama tient en quatre gestes : définir la variable OLLAMA_API_BASE (l'adresse habituelle est http://127.0.0.1:11434), télécharger le modèle avec ollama pull, démarrer le serveur, puis lancer aider avec le préfixe ollama_chat/ devant le nom du modèle. Le préfixe ollama_chat/ est explicitement recommandé plutôt que ollama/.

export OLLAMA_API_BASE=http://127.0.0.1:11434
ollama pull devstral:24b
OLLAMA_CONTEXT_LENGTH=8192 ollama serve

# Dans un autre terminal, à la racine du projet
aider --model ollama_chat/devstral:24b

Le piège le plus coûteux est la fenêtre de contexte. Ollama utilise par défaut 2 000 tokens de contexte, ce qui est minuscule pour un agent de code, et, point décisif, il rejette silencieusement ce qui dépasse. Sans le savoir, vous pouvez donc parler à un modèle qui n'a reçu que le début de vos fichiers. Aider limite le problème : par défaut, il règle lui-même la fenêtre d'Ollama à la taille de chaque requête plus 8 000 tokens pour la réponse. Si vous préférez une taille fixe, il faut passer par un fichier de réglages de modèle, pas par le fichier de configuration principal.

- name: ollama_chat/devstral:24b
  extra_params:
    num_ctx: 32768

Le contexte a un prix en mémoire : le cache KV grandit avec la fenêtre, et un modèle de 24 milliards de paramètres qui occupe déjà environ 14 Go en Q4 laisse peu de marge sur une carte de 16 Go. Le guide sur la fenêtre de contexte et celui sur la quantification du cache KV donnent les ordres de grandeur.

#Quel modèle local pour Aider

Aider est aussi bon que le modèle qui le pilote, et la difficulté est double : le modèle doit raisonner sur le code et respecter un format d'édition strict. Un modèle qui ne suit pas ce format produit des modifications que l'outil ne sait pas appliquer. Le classement public d'Aider, fondé sur 225 exercices Exercism dans six langages, mesure justement cette double capacité ; il est dominé par de très gros modèles hébergés, et les modèles qui tiennent sur une machine personnelle y sont sensiblement moins bien placés. Consultez-le avant d'espérer un résultat de niveau cloud.

Pour un poste local, Devstral 24B, publié par Mistral AI et All Hands AI, est un point de départ cohérent : il est conçu pour les agents de code, il pèse 14 Go dans la bibliothèque Ollama et annonce une fenêtre de 128 000 tokens. Sur un GPU de 12 Go ou moins, il faut descendre vers un modèle plus petit et accepter davantage d'erreurs de format. Le guide « Meilleur LLM local pour coder » compare les candidats actuels ; ce guide-ci ne fige aucun palmarès, car il change trop vite.

#Un premier changement, du prompt au commit

1. 01
   Ajouter les bons fichiers

   Lancez aider en lui passant les fichiers à modifier, par exemple aider src/api.py src/models.py. Les fichiers ajoutés sont ceux qu'il peut éditer ; le reste du dépôt lui est connu par la carte.
2. 02
   Décrire le changement précisément

   Écrivez une demande complète : « Ajoute un endpoint GET /users/:id qui renvoie l'utilisateur, ou une erreur 404 s'il n'existe pas. » Une demande vague produit un diff vague.
3. 03
   Relire le diff

   Aider affiche les modifications et les applique. Regardez-les avec /diff avant de continuer : c'est le moment de refuser, pas après trois demandes supplémentaires.
4. 04
   Vérifier le commit

   Chaque édition est enregistrée avec un message descriptif. Si le résultat est mauvais, /undo annule le dernier commit fait par Aider.
5. 05
   Enchaîner par petites étapes

   Demandez ensuite les tests, la gestion du cas limite, la journalisation, une étape à la fois. Les petites étapes gardent le contexte court et le diff lisible.

#Les commandes de chat qui comptent

Aider propose des dizaines de commandes commençant par une barre oblique ; une poignée suffit pour travailler. La règle générale : ce que vous n'avez pas ajouté au chat n'est pas modifiable, mais la carte du dépôt permet au modèle de savoir que d'autres fichiers existent.

/add et /drop

Ajoutent ou retirent des fichiers du chat. Retirer les fichiers devenus inutiles libère du contexte, ce qui compte beaucoup avec un modèle local.

/read-only

Ajoute un fichier en référence seule : le modèle le lit sans pouvoir l'éditer. Utile pour un fichier de conventions ou un contrat d'interface.

/ask, /code, /architect

Changent le mode de chat, pour un message ou de façon durable avec /chat-mode.

/run et /test

/run lance une commande shell et peut en verser la sortie dans le chat ; /test lance la commande de test et ajoute la sortie au chat si elle échoue, ce qui déclenche une correction.

/diff et /undo

/diff montre les changements depuis votre dernier message ; /undo annule le dernier commit s'il a été fait par Aider.

/tokens

Rapporte le nombre de tokens utilisés par le contexte actuel : le réflexe à prendre pour comprendre pourquoi un modèle local « oublie ».

/map

Affiche la carte du dépôt envoyée au modèle.

#Les modes de chat : code, ask, architect

Aider distingue quatre modes de chat. Le mode code, celui par défaut, modifie vos fichiers. Le mode ask discute du code sans jamais le modifier. Le mode architect fait travailler deux modèles : un modèle architecte propose la solution, puis un modèle éditeur la traduit en modifications précises de fichiers. Le mode help répond aux questions sur Aider lui-même. Il n'existe pas de mode intermédiaire nommé « paired » ; l'association d'un modèle fort et d'un modèle rapide se règle avec les options --model et --editor-model.

Le flux recommandé par la documentation consiste à alterner /ask et /code : on discute de l'approche en mode ask, puis on bascule en mode code, où un simple « go ahead » suffit à exécuter le plan convenu. C'est une version plus fluide du mode architect avec un seul modèle. Pour un modèle local de taille moyenne, c'est souvent le meilleur compromis : vous évitez de charger deux modèles en mémoire, et vous gardez la main sur le plan.

Le mode architect se justifie pour les modèles qui raisonnent bien mais éditent mal. Il coûte deux requêtes au lieu d'une : ne l'activez que si le mode code produit régulièrement des diffs invalides.

#Git, votre filet de sécurité

Aider s'appuie sur Git pour rendre chaque erreur réversible. À chaque édition, il commit les changements avec un message descriptif, généré par le modèle faible à partir du diff et de la conversation, dans le style des commits conventionnels. Avant de toucher à un fichier ayant des modifications non commitées, il commite d'abord l'existant : votre travail et celui de l'IA restent séparés dans l'historique. Les commits qu'il crée portent la mention « (aider) » dans le nom d'auteur, ce qui permet de les retrouver.

Le corollaire, ce sont de nombreux petits commits. La bonne pratique consiste à faire travailler Aider sur une branche dédiée, à relire, puis à écraser les commits avant de fusionner. Deux options méritent d'être connues : --no-auto-commits désactive l'enregistrement automatique, et --git-commit-verify réactive les hooks pre-commit, que l'outil contourne par défaut avec --no-verify. Si votre équipe s'appuie sur ces hooks, l'option change tout.

git switch -c ai/endpoint-users
aider src/api.py
# ... relire, tester, puis :
git rebase -i main

#Faire tourner vos tests dans la boucle

C'est le réglage qui transforme Aider d'un générateur de code en outil qui se corrige. Avec --test-cmd et --auto-test, il lance votre suite de tests après chaque modification ; si la commande renvoie un code de sortie non nul, il lit la sortie et tente de réparer. Le principe est le même pour le linter, avec --lint-cmd, et Aider lint par défaut les fichiers qu'il édite.

aider --test-cmd "pytest -x -q" --auto-test --lint-cmd "ruff check"

Deux précautions. La commande de test doit être rapide : avec un modèle local, chaque cycle coûte déjà plusieurs dizaines de secondes de génération. Et elle doit afficher les erreurs avec un code de sortie non nul, faute de quoi Aider croit que tout va bien.

#Ce qui échoue avec un modèle local, et comment le contourner

Erreurs de format d'édition

Le modèle renvoie une modification que l'outil ne peut pas appliquer. Passez à un modèle plus grand, ou testez le mode architect. La documentation d'Aider consacre une page de dépannage à ces erreurs.

Oubli de contexte

Symptôme : le modèle ignore un fichier que vous venez d'ajouter. Cause probable : fenêtre trop petite ou contexte saturé. Réponse : /tokens, /drop des fichiers inutiles, puis contexte plus grand.

Fichiers trop longs

Un fichier de plusieurs milliers de lignes sature un contexte local. Découpez-le, ou demandez une modification sur une fonction précise.

Demandes vagues

« Améliore ce code » produit des diffs imprévisibles. Nommez le fichier, la fonction, le comportement attendu.

Erreur de limite de jetons

Aider signale quand un modèle dépasse ses limites et suggère des actions : demander des changements plus petits, découper les fichiers, changer de modèle.

#Aider ou un agent dans l'éditeur

Aider s'adresse à qui travaille au terminal et veut un historique Git propre. Si vous préférez rester dans VS Code, Cline propose une expérience équivalente avec validation étape par étape ; si vous voulez un agent de terminal plus autonome, OpenCode est une piste. Le choix ne dépend pas de la qualité du modèle, qui est la même, mais de l'endroit où vous voulez relire les diffs.

• Aider + Ollama : le workflow complet dans le terminal
• Meilleur LLM local pour coder
• Comprendre la fenêtre de contexte
• Cline + Ollama dans VS Code
• OpenCode + Ollama dans le terminal
• Relire du code avec un LLM local avant commit

• Source : documentation d'Aider pour Ollama
• Source : les modes de chat d'Aider
• Source : intégration Git d'Aider
• Source : lint et tests dans Aider
• Source : Devstral dans la bibliothèque Ollama