Aider + Ollama : coder dans le terminal avec un agent 100% local

#Pourquoi Aider dans le terminal

Là où Cline ou Continue vivent dans VS Code, Aider assume le terminal. Vous restez dans votre shell, à la racine de votre dépôt git, et vous dialoguez avec le modèle comme avec un collègue qui aurait accès au code. C'est un workflow différent, plus proche de la ligne de commande, qui plaît à ceux qui vivent dans tmux et n'aiment pas quitter le clavier.

Centré sur git

Chaque modification acceptée devient un commit propre, avec un message rédigé par Aider. Votre historique reste lisible et vous pouvez annuler n'importe quel changement avec un simple git revert.

Repo-map automatique

Aider construit une carte de votre dépôt (signatures de fonctions, classes, structure) qu'il envoie au modèle en plus des fichiers ouverts. Le modèle comprend le contexte sans que vous chargiez tout le projet.

Éditeur agnostique

Aider modifie les fichiers sur disque. Vous continuez d'utiliser votre éditeur habituel en parallèle : Aider voit vos changements, vous voyez les siens.

100 % local avec Ollama

Branché sur Ollama, le modèle tourne sur votre GPU. Votre code et vos prompts ne quittent jamais le poste, ce qui change tout pour du code propriétaire ou sous NDA.

#Prérequis et installation

Trois briques : Python pour Aider, Ollama qui tourne avec un modèle de code chargé, et un dépôt git. Aider exige un dépôt git pour fonctionner pleinement — c'est lui qui pilote les commits.

1. 01
   Vérifiez Ollama

   Ollama doit écouter sur son port par défaut. Lancez ollama list pour confirmer qu'il répond et voir les modèles déjà installés.
2. 02
   Installez Aider

   La méthode recommandée passe par pipx ou par le script d'install officiel, qui isole Aider dans son propre environnement pour éviter les conflits de dépendances Python.
3. 03
   Placez-vous dans un dépôt git

   Ouvrez un terminal à la racine d'un projet versionné. Si le projet n'est pas encore sous git, faites un git init au préalable : Aider en a besoin pour commiter ses modifications.

# Via pipx (isole Aider, n'encombre pas votre Python système)
python -m pip install --user pipx
pipx install aider-chat

# Vérifier l'installation
aider --version

#Configurer Aider pour Ollama

Aider parle à Ollama via son endpoint OpenAI-compatible. Deux choses à régler : l'URL de base d'Ollama (variable d'environnement) et le modèle à utiliser. Le plus propre est de poser un fichier .aider.conf.yml à la racine du projet (ou dans votre dossier personnel pour un réglage global), pour ne pas retaper les options à chaque lancement.

# Indique à Aider où trouver l'API Ollama
export OLLAMA_API_BASE=http://127.0.0.1:11434

# Lancer Aider avec un modèle Ollama (préfixe ollama/)
aider --model ollama/qwen2.5-coder:7b

Pour ne plus rien retaper, mettez ces réglages dans un fichier de configuration. Aider lit automatiquement un .aider.conf.yml trouvé à la racine du dépôt ou dans votre dossier personnel.

# Modèle principal servi par Ollama (préfixe ollama/ obligatoire)
model: ollama/qwen2.5-coder:14b

# Modèle léger pour les tâches annexes (messages de commit, résumés)
weak-model: ollama/qwen2.5-coder:7b

# Auto-commit des modifications acceptées (comportement par défaut)
auto-commits: true

# Ne pas committer automatiquement les fichiers que VOUS modifiez
dirty-commits: false

- name: ollama/qwen2.5-coder:14b
  extra_params:
    num_ctx: 8192

#Quel modèle selon la VRAM

Aider envoie beaucoup de contexte (fichiers ajoutés + repo-map) et attend un patch bien formé en retour. Un modèle trop petit produit des diffs cassés qu'Aider n'arrive pas à appliquer. Visez le plus gros coder que votre carte charge confortablement, en gardant de la marge pour le contexte.

#Le workflow de bout en bout

Voici le cycle typique d'une modification, du lancement d'Aider au commit. Une fois ce rythme pris, vous enchaînez les changements sans jamais quitter le terminal.

1. 01
   Lancez Aider à la racine du dépôt

   Aider démarre, lit la config, construit le repo-map, et affiche une invite. Il indique le modèle actif et le nombre de fichiers détectés.
2. 02
   Ajoutez les fichiers concernés avec /add

   N'ajoutez que les fichiers que la tâche doit modifier. Moins il y a de fichiers dans le contexte, plus le modèle reste précis. Le repo-map donne déjà au modèle une vue du reste du projet.
3. 03
   Décrivez la modification en français

   Tapez votre demande en langage naturel : « ajoute la validation de l'email dans le formulaire d'inscription ». Aider réfléchit, puis propose un patch.
4. 04
   Relisez le diff proposé

   Aider montre le diff avant d'appliquer. Vérifiez-le. Si quelque chose ne va pas, répondez pour corriger : « non, utilise une regex plus stricte ».
5. 05
   Laissez Aider committer

   Une fois le patch appliqué, Aider crée automatiquement un commit avec un message descriptif. Votre historique git reste propre et chaque changement est traçable.
6. 06
   Itérez ou annulez

   Continuez avec la modification suivante. Si un commit d'Aider ne vous convient pas, /undo annule le dernier commit qu'il a créé, sans toucher au reste.

$ aider
Aider v0.x — model: ollama/qwen2.5-coder:14b
Repo-map: 42 fichiers

> /add src/auth/register.py
Added src/auth/register.py to the chat

> Ajoute la validation de l'email dans le formulaire d'inscription

[Aider propose un diff, l'applique, puis :]
Commit a1b2c3d  feat: valider le format de l'email à l'inscription

#Commandes clés au quotidien

Aider se pilote avec des commandes slash dans son invite. Une poignée suffit à couvrir 90 % des usages.

/add fichier

Ajoute un ou plusieurs fichiers au contexte de l'édition. C'est sur ces fichiers qu'Aider écrira. Limitez-vous au strict nécessaire.

/drop fichier

Retire un fichier du contexte. Utile quand vous changez de tâche pour repartir d'un contexte propre.

/architect

Active le mode plan-puis-code : le modèle raisonne d'abord sur l'approche, puis génère le diff. Idéal pour les changements non triviaux.

/diff

Affiche les modifications apportées depuis le dernier commit, pour relire ce qu'Aider a changé avant de continuer.

/undo

Annule le dernier commit créé par Aider. Filet de sécurité immédiat si une modification part de travers.

/run commande

Exécute une commande shell (tests, linter) et réinjecte la sortie dans le chat. Aider peut alors corriger en se basant sur les erreurs réelles.

/ask question

Pose une question sur le code SANS déclencher de modification ni de commit. Pour comprendre avant d'agir.

#Limites du local face au cloud

Soyons honnêtes : un modèle local sur 8 à 16 Go n'égale pas un modèle cloud de pointe. Connaître les limites évite la frustration et aide à choisir le bon outil selon la tâche.

Diffs parfois mal formés

Les petits modèles produisent parfois un patch qu'Aider n'arrive pas à appliquer (format cassé). Monter en taille de modèle ou élargir num_ctx réduit nettement ce problème.

Contexte plus court

Un modèle cloud encaisse des dizaines de fichiers. En local, gardez le contexte serré : peu de fichiers /add à la fois, et appuyez-vous sur le repo-map plutôt que de tout charger.

Raisonnement multi-fichiers

Les refactors qui touchent beaucoup de fichiers d'un coup restent le point faible du local. Découpez en plusieurs petites tâches, ou passez en /architect pour structurer.

Vitesse liée au GPU

La latence dépend de votre carte. Un 32B sur une carte modeste sera lent. Si la réactivité prime, un 7B ou 14B bien réglé est plus agréable au quotidien.

#Questions fréquentes