opinion

Pourquoi j'ai écrit Mini-claude au lieu d'utiliser Aider, Cline ou OpenClaude

Six mois à coder avec des agents IA en local, et la raison pour laquelle j'ai fini par écrire le mien plutôt qu'utiliser Aider ou OpenClaude.

J’ai commencé à utiliser des agents IA en local fin 2025, quelques semaines après être tombé sur un thread r/LocalLLaMA qui faisait l’éloge de qwen2.5-coder dans Aider. À l’époque je tournais sur Claude Code à 200 $/mois, et l’idée d’avoir le même type de boucle d’agent contre un modèle qui tourne sur mon Mac me semblait surtout être une curiosité du week-end. Six mois plus tard j’ai désinstallé Claude Code, je code huit heures par jour avec un agent open source que j’ai écrit moi-même, et je n’ai pas l’impression d’avoir régressé. Cet article essaie d’expliquer comment on en arrive là.

Mini-claude n’existerait pas si j’avais trouvé exactement ce que je cherchais dans le paysage existant. Aider, Cline, Continue.dev, opencode, Crush, gptme, et plus récemment OpenClaude, tous ces projets sont à un coup de git clone du dossier dans lequel je travaille. Pendant les six mois en question j’ai installé chacun d’eux, j’ai fait des projets entiers avec, et j’ai pris des notes. À un moment donné ces notes ont arrêté d’être des bugs et sont devenues une liste de choses que personne n’allait corriger parce que personne ne les considérait comme un problème. C’est ce moment-là qui m’a poussé à écrire mon propre TUI.

Le moment où je me suis dit : il y a quelque chose qui cloche

C’était un dimanche de février 2026. Je faisais un refactor sur un projet Go d’environ 12 000 lignes, avec Aider en mode architect et qwen2.5-coder:14b derrière. L’agent voulait modifier internal/auth/middleware.go. Sauf que ce fichier s’appelait internal/auth/handler.go et qu’auth/middleware.go n’avait jamais existé. Aider a inventé le chemin. Pas une seule fois, sept appels d’outils consécutifs sur un fichier fantôme. Chaque appel renvoyait une erreur, le modèle réessayait avec une variation orthographique, l’erreur revenait, ainsi de suite. J’ai laissé tourner pendant deux minutes avant de couper.

Ce qui m’a frappé n’était pas que ça arrive, les hallucinations de chemin sont un grand classique. Ce qui m’a frappé c’est que je n’avais aucun moyen de comprendre, à chaud, ce qui se passait. Pas de log structuré, pas d’indicateur de boucle, pas de message qui dise “ce modèle vient de t’envoyer le même tool call cinq fois de suite, peut-être qu’il faut faire autre chose”. J’ai relu les notes des cinq jours précédents : trois autres boucles similaires, deux dans Cline, une dans Continue.dev. Toutes silencieuses.

C’est à ce moment-là que j’ai compris que le problème n’était pas le modèle. Le problème était qu’on était en train de construire des agents en local en copiant la philosophie d’agents cloud, sans réaliser que les contraintes ne sont pas du tout les mêmes. Un agent qui parle à Claude Opus peut se permettre des boucles silencieuses : le modèle finit toujours par sortir de la boucle parce qu’il est très fort, et chaque tour coûte trois centimes. Un agent qui parle à un qwen3:8b sur votre Mac, lui, peut tourner en rond une journée entière sans que vous le sachiez, et le coût c’est votre temps.

Aider est excellent. Mais.

Aider a essentiellement inventé le format des modifications par diff unifié et a poussé pendant deux ans des benchmarks honnêtes que personne d’autre ne publiait. Le blog s’est arrêté en mai 2025, et c’est dommage, parce que la moitié de ce que je sais sur les modèles locaux vient de leurs articles (“Details matter with open source models”, “Unified diffs make GPT-4 Turbo 3X less lazy”, la série sur le repo-map en tree-sitter). C’est l’outil que j’ai utilisé le plus longtemps avant d’écrire le mien.

Ce qui m’a fait décrocher tient en trois points. Le premier, c’est que la commande aider lance un mode qui code par défaut. Pas de cran intermédiaire pour faire de la review, ou pour faire du pair-programming où l’IA refuse d’écrire et te pose des questions. Le /ask est sympa mais reste un workaround, pas un mode de premier rang. Le deuxième, c’est que l’auto-commit Aider crée un commit par tour de boucle ; rewinder devient vite folklorique sur une longue session. Le troisième, c’est que l’écosystème Python est lourd à porter sur certaines machines (j’ai passé deux heures à debugger un conflit de venv sur un VPS OVH, et ce n’était pas la première fois).

Si je n’avais eu besoin que d’un outil qui fasse “agent → édit → commit” sur un projet bien posé, je serais encore sur Aider. Le problème c’est que je voulais autre chose.

Cline, Continue, opencode : trois excellents outils dans le mauvais shell

Cline et Continue sont des extensions VS Code. Je passe la moitié de ma journée dans Vim sur une session tmux, sur un VPS ou sur ma machine selon les jours. VS Code n’est pas mon environnement, et passer toute ma boucle de feedback à travers une extension qui pilote une UI Electron pour piloter un modèle qui tourne en local, c’est trois couches d’indirection que je n’arrive pas à justifier.

Opencode est un TUI, en TypeScript/Bun. Il est rapide, le diff viewer est superbe, l’équipe sort des releases tous les deux jours et le changelog est exemplaire. Le seul problème c’est que c’est un outil exécution-first : il code, il code bien, et il n’a aucune ambition pédagogique. Si vous voulez apprendre quelque chose en l’utilisant, c’est à vous de faire l’effort de lire ce qu’il fait, l’outil ne va pas vous aider.

Crush, c’est l’agent Go de Charm. Le craft visuel est ridicule de qualité (c’est Charm, on ne s’attendait à rien d’autre), mais l’équipe ne publie quasi rien sur l’outil lui-même. Une session d’agent Crush ressemble à beaucoup d’autres : un loop, des tools, un diff, un commit. Quand j’ai essayé de comprendre comment ils géraient les boucles de tool-call qui échouent, j’ai fini par lire le code source.

Tous ces outils ont un point commun : ils répondent à la question comment l’IA peut coder plus vite. C’est une excellente question. Ce n’est juste pas la seule.

OpenClaude est arrivé. Et j’ai quand même fini par publier le mien.

Quand j’ai commencé Mini-claude en mars, OpenClaude n’existait pas encore, du moins pas la version Gitlawb. Quand elle est sortie en avril, j’ai sérieusement envisagé d’arrêter le mien. Le pitch est convaincant : c’est, pour autant qu’on puisse en juger, une réécriture/un fork des internals de Claude Code avec un router multi-provider greffé dessus. npm install -g openclaude et vous avez une boucle d’agent qui se branche sur Ollama, Gemini, GitHub Models, Codex OAuth, et qui fait passer le tout par ANTHROPIC_BASE_URL. C’est le clone le plus crédible de Claude Code en open source.

J’ai quand même continué pour cinq raisons concrètes.

D’abord, le runtime. OpenClaude tire Node, ses deps et tout le folklore npm derrière. Mini-claude est un binaire Go de 11 Mo qui ne dépend de rien. Sur un Mac M2 propre, le time go run github.com/hugostarte/Mini-Claude/cmd/tui@latest rend la main en 800 ms ; un npx openclaude chez moi tourne à 3,4 secondes pour la même boucle vide. C’est pas dramatique mais ça se sent à l’usage.

Ensuite, la philosophie. OpenClaude est un agent qui exécute. C’est sa raison d’être : faire passer le modèle pour Claude et coder. Je voulais un agent qui sache faire autre chose : poser les questions qui me feraient trouver la réponse moi-même. C’est guided. Cette idée, que la valeur d’un agent de code n’est pas seulement d’écrire du code mais aussi parfois de refuser d’en écrire, n’est dans aucun autre outil que je connaisse. C’est probablement le seul angle qui justifie qu’on rajoute un projet de plus à la liste.

Troisièmement, /undo comme primitive git. Mini-claude auto-commit chaque tool call destructif avec un message structuré miniclaude: <tool> <path>, et /undo rewinde le dernier commit miniclaude, jamais un commit que vous avez fait à la main. Plus de “rollback” maison qui marche à moitié : si vous êtes dans un repo git, vous pouvez revenir en arrière. Si vous n’êtes pas dans un repo git, l’agent vous dit qu’il ne peut pas garantir l’undo. Aucune surprise. OpenClaude propose un système de “checkpoints” mais les semantics ne sont pas documentées publiquement, et de mémoire ça ne survit pas à une crash de l’agent.

Quatrièmement, la mémoire cross-tool. Mini-claude lit le premier qu’il trouve dans cet ordre :

MINICLAUDE.md → AGENTS.md → CLAUDE.md → GEMINI.md →
.cursorrules → .windsurfrules → .github/copilot-instructions.md

Cela veut dire que si vous arrivez avec un repo qui était déjà setup pour Claude Code ou Cursor, vous n’avez rien à faire. Le CLAUDE.md est lu tel quel. Je ne sais pas pourquoi c’est moi qui ai eu envie d’écrire ça, c’est trois jours de boulot et c’est une fonctionnalité que tout le monde devrait avoir. Aucun autre agent local ne le fait.

Enfin, la privacy par construction. C’est le point que je tiens le plus à défendre, et il mérite sa propre section.

Privacy par construction, pas par politique

Quand vous installez Cursor, vous pouvez désactiver le “Privacy Mode” dans les settings. Quand vous installez Continue, vous pouvez désactiver la télémétrie dans une variable d’env. Quand vous installez OpenClaude, le code source ne fait pas d’appel à un endpoint d’analytics, du moins pas dans la version que j’ai auditée. Ces trois affirmations sont vraies, et elles sont à des niveaux de garantie complètement différents.

Mini-claude est volontairement à l’autre extrême du spectre : la seule connexion sortante du binaire est vers votre serveur d’inférence local. C’est tout. Pas de “désactivez la télémétrie”, parce qu’il n’y a aucune télémétrie à désactiver. Pas d’opt-out analytics, parce qu’il n’y a aucune analytics. Le navigateur que browser_open utilise est votre Chrome, avec votre session, sur votre IP. Vous pouvez le vérifier en cinq minutes :

# 1. lancer mini-claude
go run github.com/hugostarte/Mini-Claude/cmd/tui@latest

# 2. dans un autre terminal, voir ce que la PID écoute
ss -tnp | grep mini

# 3. ce que vous devez voir : une seule connexion sortante
# ESTAB 0 0 127.0.0.1:55432 127.0.0.1:11434 users:(("tui",pid=...,fd=8))
# c'est votre Ollama. Point.

Cette différence entre “promesse” et “construction” est subtile mais elle compte. Une promesse demande de la confiance. Une construction permet une vérification. Pour un développeur, la deuxième catégorie est plus simple à recommander à son équipe ou à son DPO.

Les trois choses que je voulais et que personne ne donnait

Si je devais résumer ce qui m’a fait sauter le pas, c’est ces trois manques.

Premièrement, un mode pédagogique qui ne soit pas un mode dégradé. La plupart des outils qui prétendent expliquer le font dans une fenêtre annexe, ou via une commande “ask” qui interrompt le flow. Mini-claude a quatre modes (auto, explain, guided, review) et vous pouvez passer de l’un à l’autre en plein milieu de la session avec /mode guided. Chaque mode change ce que l’agent est autorisé à faire : guided n’a aucun outil, donc il ne peut pas écrire de code même s’il en avait envie. review est en lecture seule. Cette contrainte structurelle évite tout un tas de bugs (un mode review qui édite “par accident” un fichier, par exemple).

Deuxièmement, une honnêteté radicale sur les modèles. Mini-claude lit la taille du modèle au démarrage, fait un probe one-shot pour vérifier si le tool calling natif fonctionne, et affiche weak tool calling dans le header si le résultat est moyen. Pour qwen2.5-coder sur Ollama, par exemple, le résultat est “weak”, la documentation de Mini-claude le dit explicitement, et recommande mistral:7b, qwen3:8b ou llama3.1:8b à la place. Je suis fatigué des comparatifs qui mettent qwen2.5-coder en tête sur HumanEval et oublient de mentionner qu’il fait n’importe quoi dès qu’on lui demande un tool call.

Troisièmement, un /audit déterministe. C’est une commande qui rassemble l’arbo du projet, le README et le manifeste (go.mod, package.json, pyproject.toml…) de manière déterministe, pas via le modèle, et qui ne demande au modèle que de synthétiser. Résultat : même un modèle 4B faible en tool calling peut vous faire un audit utile, parce que la partie qui demande de la fiabilité est faite en Go.

Choix techniques en deux paragraphes

Mini-claude est en Go, sur Bubble Tea / Lip Gloss / Bubbles pour le TUI, avec le client HTTP de la stdlib pour parler à n’importe quel serveur OpenAI-compatible. Pas de framework agent, pas de SDK propriétaire, pas de wrapper LangChain. Le loop d’agent fait 300 lignes de Go ; les tools sont une registry dans internal/tools/ ; les modes sont quatre fichiers qui injectent un system prompt différent et restreignent la liste des tools disponibles. Vous pouvez lire le tout en deux heures.

Le choix de Go n’est pas idéologique. C’est juste qu’une fois que vous décidez que vous voulez un binaire unique, statique, qui démarre instantanément et qui parle HTTP, vous arrivez assez vite à Go ou Rust. Rust aurait été défendable mais j’ai 8 ans de Go derrière moi et 3 mois de Rust. À 3 jours de boulot près sur le développement, je préférais shipper. Plus tard peut-être.

Ce qui ne marche pas (encore)

Mini-claude n’a pas de support MCP. Ce sera dans la prochaine release. Les hooks non plus. Les sessions sauvegardées (resumer une conversation) sont en travaux. Les binaires prébuilt macOS / Linux / Windows arrivent, pour l’instant c’est go build ./... ou go run github.com/hugostarte/Mini-Claude/cmd/tui@latest. Le cycle-detection dont je parlais plus haut existe mais il est rustique : trois tool calls identiques d’affilée et l’agent vous demande s’il faut continuer. C’est mieux que les boucles muettes mais c’est très loin d’être suffisant.

Tout ça arrivera. Le /undo et la mémoire cross-tool, ce sont les choses dont je voulais m’assurer dès la v0 parce que ce sont des features qui colorent la philosophie du projet, pas des add-ons. Le reste, c’est du sprint normal.

Où on en est, où on va

Mini-claude est sur miniclaude.fr depuis une semaine. Le repo est sur github.com/hugostarte/Mini-Claude. La licence est MIT. Il n’y a pas de société derrière, pas de financement, pas de roadmap “enterprise”. Je suis seul à coder dessus pour l’instant et ça me convient.

Ce que j’écrirai sur ce blog dans les semaines qui viennent va ressembler à ça : du retour d’expérience honnête, des comparatifs qui mesurent ce que les autres ne mesurent pas (la qualité du tool calling sur les vrais modèles que les gens utilisent en local, par exemple), et des explications de design pour les choix qui m’ont demandé du temps. Pas du contenu généré, pas de “Ultimate Guide to AI Coding Agents in 2026”. Si vous avez des suggestions de sujets ou des questions techniques précises, ouvrez une issue sur le repo, c’est probablement là que je creuserai en priorité.

Si vous voulez tester, le quickstart tient en trois commandes :

ollama pull mistral:7b
cd ~/code/votre-projet
go run github.com/hugostarte/Mini-Claude/cmd/tui@latest

/mode guided pour le pair-programming socratique, /mode review pour faire lire un repo à l’agent sans qu’il touche à rien, /audit pour la synthèse déterministe. Le reste est dans la doc.

À dans deux semaines pour le prochain article, probablement un benchmark honnête de mistral:7b, qwen3:8b et llama3.1:8b sur un protocole de tool calling reproductible. Histoire de remplir un peu le vide laissé par Aider.