Nanocoder : un agent de codage en terminal, multi-fournisseurs et piloté par une collective

Le problème visé : rester maître du modèle et du code

La plupart des agents de codage en terminal supposent un compte chez un fournisseur unique et envoient le contenu du projet vers une API distante. Nanocoder prend le problème par l'autre bout. Le README annonce un outil qui exécute le raisonnement agentique sur le modèle de votre choix : Ollama pour un modèle local, ou n'importe quelle API compatible OpenAI, OpenRouter, Anthropic et Google étant cités comme exemples. Le texte de présentation insiste sur trois qualités : respect de la vie privée, priorité au local, ouverture à tous. Ce positionnement vise deux publics. D'abord les équipes qui traitent du code qu'elles ne peuvent pas envoyer à l'extérieur, et pour qui l'exécution locale n'est pas une préférence mais une contrainte. Ensuite les développeurs qui refusent de voir les fonctions utiles placées derrière un palier payant. Le README affirme qu'il n'existe ni fonctionnalité fermée, ni palier payant. C'est une promesse de gouvernance, pas une caractéristique technique, et elle ne se vérifie qu'en lisant le dépôt et son historique de publication.

Un harnais multi-fournisseurs plutôt qu'un client lié à un vendeur

Le choix du fournisseur se fait au lancement, par des options en ligne de commande, et non par un fichier de configuration figé. Le README donne plusieurs exemples : `nanocoder --provider openrouter --model google/gemini-3.1-flash run "analyze src/app.ts"` pour une exécution non interactive, `nanocoder --provider ollama --model llama3.1` pour démarrer en interactif sur un modèle local. Les options peuvent se placer avant ou après la sous-commande `run`, comme le montre `nanocoder run --provider openrouter "refactor database module"`. Cette souplesse d'ordre est un détail d'ergonomie, mais elle indique que l'analyse des arguments a été traitée comme un cas d'usage réel et pas comme un ajout tardif. Le README rattache explicitement ce choix à la nature collective du projet : le harnais reste multi-fournisseurs par principe, l'utilisateur n'étant jamais lié au modèle d'un seul vendeur. Le dépôt liste d'ailleurs les thèmes ai, llm, ollama, openai et openrouter, ce qui confirme la portée du positionnement. Ce que la documentation fournie ne détaille pas, en revanche, c'est le format exact du bloc de configuration destiné aux fournisseurs. Le dossier docs/configuration est mentionné, avec les serveurs MCP, les préférences, la journalisation et les délais d'attente comme sujets, mais aucun exemple de clé n'apparaît dans le README.

Deux modes d'affichage, et un arbitrage assumé sur la souris

C'est la partie la plus concrète de la documentation. Nanocoder propose deux modes de rendu, présentés comme alignés sur ce que livrent Claude Code et Codex. Le mode inline, celui par défaut, écrit sur l'écran principal : les messages terminés sont imprimés une fois dans le scrollback natif du terminal, ce qui laisse fonctionner la barre de défilement, la molette et la recherche du terminal. Le transcript reste visible après la sortie du programme. Le mode fullscreen s'active par `--alt-screen` ou par la préférence `"alternateScreen": true`. Il occupe le tampon d'écran alternatif avec une hauteur fixe et gère le défilement dans l'application : molette, PgUp et PgDn, avec un indicateur de position et un retour automatique en bas à l'arrivée de nouvelle sortie. Le compromis est explicite : le rapport souris est capté par l'application, ce qui prive le terminal de la sélection par cliquer-glisser. La parade documentée est Ctrl+P, qui bascule en mode sélection et rend la souris au terminal pendant la copie. `--no-alt-screen` force le mode inline même si la préférence est activée. Dans les deux modes, `/clear` réinitialise le terminal sur une bannière d'accueil, et une sortie par Ctrl+C ou `/exit` efface proprement l'interface de saisie en laissant le transcript et un message d'adieu. Ce niveau de détail sur le cycle de vie de l'affichage est inhabituel et suggère que ces irritants ont été rencontrés en usage réel.

Installation et premiers pas

La mise en route tient en deux commandes : `npm install -g @nanocollective/nanocoder`, puis `nanocoder`. Le paquet npm est donc la voie principale. Le README signale deux alternatives, Homebrew pour macOS et Linux, et les Nix Flakes, chacune renvoyant à une section de docs/getting-started/installation.md. Une fois lancé, l'outil démarre en mode interactif. Quatre modes de développement sont nommés dans le README : normal, auto-accept, yolo et plan. Ils s'atteignent par l'option `--mode`, avec des exemples comme `nanocoder --mode yolo` pour démarrer directement dans ce mode, ou `nanocoder --mode plan run "audit the auth module"` pour lancer une tâche d'audit en mode plan. Le nom du mode yolo dit assez ce qu'il fait, et le README ne fournit aucune mise en garde supplémentaire à son sujet. C'est un point à garder en tête : un mode qui accepte automatiquement les actions d'un agent mérite d'être essayé dans un dépôt jetable avant de servir sur un projet réel. La documentation renvoie par ailleurs vers une référence complète des commandes slash et une liste de raccourcis clavier, sans les reproduire dans le README.

Licence et coût de maintenance : les zones d'ombre

Le champ de licence du dépôt vaut NOASSERTION, ce qui signifie que GitHub n'a pas su rattacher le fichier de licence à un identifiant SPDX connu. Le README, lui, parle d'un projet à but non lucratif, sans palier payant et financé par des sponsors, Atlas Cloud apparaissant comme sponsor avec un lien vers une offre d'accès API. Ces deux éléments ne disent pas la même chose : une absence de palier payant n'est pas une licence. Avant d'intégrer Nanocoder dans un processus d'entreprise, il faut donc ouvrir le fichier LICENSE à la racine et le lire, en particulier pour savoir si des conditions s'appliquent à la redistribution ou à l'usage interne. Je ne peux pas trancher ce point à partir des éléments fournis, et personne ne devrait le faire à votre place. Sur la maintenance, les faits disponibles sont plus rassurants : trois publications entre juin et août 2026, v1.28.1 le 28 juin, v1.29.0 le 26 juillet, v1.30.0 le 26 août, et un dernier envoi sur la branche main daté du 9 septembre 2026. Le rythme est mensuel et régulier sur cette fenêtre. Le dépôt n'est pas archivé. Cela ne dit rien de la longévité du projet, mais cela indique qu'il n'est pas abandonné au moment où ces lignes sont écrites.

Ce que la documentation ne permet pas de conclure

Trois lacunes méritent d'être signalées avant de s'engager. La première concerne la qualité du code produit par l'agent. Le README mentionne des fonctionnalités étendues, dans docs/features : des Skills décrits comme des commandes, des sous-agents, des outils et des déclencheurs d'événements, des hooks de cycle de vie, un démon par projet, la gestion de points de contrôle et la gestion de tâches. Aucun de ces mécanismes n'est expliqué dans le README lui-même. Savoir si le démon par projet tient la charge sur un gros dépôt, ou si les points de contrôle produisent des instantanés utilisables, demande de lire les pages correspondantes. La deuxième lacune porte sur la compatibilité réelle des fournisseurs. Le README cite Anthropic et Google comme exemples d'API compatibles OpenAI, ce qui est une affirmation de compatibilité, pas une liste de modèles validés. Un modèle qui répond à l'API peut néanmoins mal se comporter dans une boucle agentique avec appels d'outils. La troisième est l'absence de toute indication de performance, de latence ou de consommation de contexte. C'est normal pour un README, mais cela signifie qu'un essai sur votre propre base de code reste la seule mesure qui compte.

Face à quoi on le compare

La comparaison la plus directe est celle que le README établit lui-même : Claude Code et Codex, dont Nanocoder dit reprendre les deux modes d'affichage. La différence d'approche n'est pas dans l'interface mais dans le couplage. Ces deux outils sont liés à un fournisseur unique, ce qui simplifie la configuration et garantit un comportement homogène, au prix du choix du modèle et du lieu de traitement des données. Nanocoder inverse la contrainte : vous choisissez le fournisseur, vous assumez la variabilité des modèles et la configuration qui va avec. Un autre point de comparaison, en langage TypeScript comme Nanocoder, serait un assistant qui s'installe comme greffon d'éditeur plutôt que comme programme de terminal. La différence tient alors au modèle d'exécution : un agent en terminal travaille sur des commandes et des fichiers, avec les modes yolo ou auto-accept qui vont avec, tandis qu'un greffon d'éditeur reste dans le périmètre du fichier ouvert et de son contexte. Le choix entre les deux dépend de la façon dont vous travaillez, pas de la qualité intrinsèque de l'un ou de l'autre. Le README ne cherche d'ailleurs pas à trancher : il revendique la filiation sur les modes d'affichage et la rupture sur la gouvernance.

Conclusion éditoriale

Nanocoder convient aux développeurs qui veulent un agent de codage en terminal sans dépendre d'un fournisseur unique, et qui acceptent de lire la documentation du dépôt pour configurer eux-mêmes leur modèle. Il ne convient pas à qui cherche une licence claire avant déploiement, ni un support commercial avec engagements. Avant d'adopter, vérifiez le fichier LICENSE à la racine du dépôt, puis lancez `nanocoder --provider ollama --model llama3.1` pour confirmer que la détection du modèle local fonctionne sur votre machine.

Sources officielles

1. Issues
2. Nano-Collective/nanocoder on GitHub
3. Project website
4. README
5. Releases