Il y a un graphique que chaque projet logiciel suit si on le laisse faire. Les lignes de code augmentent. Les dépendances augmentent. Les temps de build augmentent. Le nombre de personnes qui comprennent l'ensemble du système diminue. À un moment donné, le projet franchit un seuil où plus personne ne peut garder l'ensemble en tête, et à partir de ce point, chaque modification est une négociation avec une complexité qu'on ne peut pas entièrement voir.
La plupart des frameworks d'agents IA ont franchi ce seuil il y a des années. LangChain compte des dizaines de milliers de lignes de code principal. Les node_modules d'OpenClaw contiennent plus de 1 200 packages. Même les frameworks « minimaux » tendent à livrer des milliers de lignes une fois qu'on compte le moteur d'exécution d'outils, la couche d'abstraction des fournisseurs, le système de plugins et le parseur de configuration.
Le cœur de NanoClaw fait environ 500 lignes de TypeScript. Ce n'est pas parce qu'il fait moins — il supporte la messagerie WhatsApp, l'isolation par conteneur, la mémoire persistante, les tâches planifiées, les essaims d'agents et la navigation web. C'est parce qu'il fait un pari différent sur l'endroit où la complexité doit résider.
La complexité doit bien résider quelque part
La version honnête de l'argument « moins de code » n'est pas que NanoClaw a éliminé la complexité. C'est que NanoClaw a déplacé la complexité vers des endroits où elle est mieux gérée.
La boucle d'agent — recevoir un message, décider quels outils utiliser, exécuter les outils, gérer les erreurs, gérer la conversation multi-tours — est complexe. Dans la plupart des frameworks, cette complexité vit dans du code applicatif que les mainteneurs du framework ont écrit et que vous devez faire confiance, déboguer et mettre à jour. Dans NanoClaw, cette complexité vit dans Claude Agent SDK, qui est maintenu par l'équipe d'ingénierie d'Anthropic, testé contre le comportement réel de Claude et mis à jour en synchronisation avec le modèle.
L'exécution des outils — navigation web, accès aux fichiers, commandes shell — est complexe. Dans la plupart des frameworks, chaque outil est une implémentation personnalisée avec sa propre gestion d'erreurs, sa propre logique de retry et son propre modèle de sécurité. Dans NanoClaw, les outils sont fournis par Claude Code à l'intérieur du conteneur. Les implémentations d'outils sont maintenues par Anthropic, et ce sont les mêmes outils que des milliers de développeurs utilisent quotidiennement via le CLI de Claude Code. Le modèle de sécurité — sandboxing, application des permissions, gestion des secrets — est complexe. Dans la plupart des frameworks, la sécurité est du code au niveau applicatif qui peut avoir des bugs. Dans NanoClaw, la sécurité est l'isolation par conteneur appliquée par le système d'exploitation. Apple Container et Docker ont été renforcés par des milliers d'ingénieurs pendant de nombreuses années. Les 80 lignes de code d'orchestration de conteneurs de NanoClaw exploitent cet investissement plutôt que d'essayer de le reproduire.
Le pattern est cohérent : les 500 lignes de NanoClaw sont la couche d'orchestration qui connecte des composants bien maintenus et bien testés. La complexité existe, mais elle réside dans des composants maintenus par des équipes disposant de plus de ressources et de plus d'expertise que n'importe quel projet open source individuel ne pourrait en avoir.
Ce qu'on peut faire avec 500 lignes
Les capacités que 500 lignes permettent sont plus larges que ce que la plupart des gens attendent, parce que les capacités viennent des composants, pas du code de NanoClaw.
La navigation web fonctionne parce que l'image du conteneur inclut Chromium et agent-browser. NanoClaw n'implémente pas de navigateur — il en monte un dans le conteneur. L'accès aux fichiers fonctionne parce que le conteneur a un système de fichiers monté. NanoClaw n'implémente pas d'E/S fichier — il configure quels chemins sont disponibles. Les essaims d'agents fonctionnent parce que Claude Code supporte nativement la délégation d'agents. NanoClaw n'implémente pas d'orchestration multi-agents — il lance des conteneurs et laisse Claude gérer la coordination.
Les 500 lignes gèrent les choses spécifiques au cas d'usage de NanoClaw : recevoir les messages WhatsApp via Baileys, consulter l'état du groupe dans SQLite, lancer le bon conteneur avec les bons montages, transmettre les secrets via stdin, collecter les réponses via IPC et les renvoyer à WhatsApp. Ce sont les décisions qui définissent NanoClaw en tant que produit — les choix sur la façon de connecter les utilisateurs aux agents IA de manière sécurisée et pratique.
Tout le reste est délégué à des composants qui le font mieux que NanoClaw ne pourrait. Ce n'est pas de la paresse. C'est la reconnaissance que le meilleur code est celui qu'on n'a pas à écrire, parce que le code qu'on n'écrit pas n'a pas de bugs, ne nécessite pas de maintenance et ne crée pas de vulnérabilités de sécurité. ## Le dividende de la maintenance
Le bénéfice pratique d'une petite base de code se compose au fil du temps d'une manière qui n'est pas évidente au départ.
Quand Anthropic publie une nouvelle version de Claude Agent SDK avec une meilleure utilisation des outils, NanoClaw obtient l'amélioration en mettant à jour une seule dépendance. Il n'y a pas de couche d'abstraction à mettre à jour, pas d'adaptateur à réécrire, pas de matrice de compatibilité à vérifier. Le SDK est utilisé directement, donc les améliorations du SDK se propagent immédiatement.
Quand une vulnérabilité de sécurité est découverte dans un runtime de conteneur, le correctif consiste à mettre à jour Docker ou Apple Container — pas à patcher le code de NanoClaw. La frontière de sécurité est maintenue par les équipes d'infrastructure chez Apple et Docker, pas par un petit projet open source.
Quand un nouveau contributeur veut comprendre la base de code, il peut lire les 500 lignes en moins d'une heure. Il n'a pas besoin de comprendre un système de plugins, une abstraction de fournisseur ou un framework d'exécution d'outils. Toute l'architecture tient dans un seul modèle mental : les messages arrivent de WhatsApp, les conteneurs les traitent avec Claude, les réponses repartent vers WhatsApp.
C'est le dividende de maintenance du code minimal. Chaque ligne que vous n'écrivez pas est une ligne que vous ne déboguez pas, ne documentez pas, n'expliquez pas aux nouveaux contributeurs et ne patchez pas quand le monde change autour de vous.
Quand moins est vraiment plus
La philosophie des 500 lignes n'est pas universellement applicable. Si vous construisez une application IA personnalisée avec une logique métier spécifique, vous avez besoin d'un framework qui vous permet d'exprimer cette logique — LangChain, CrewAI ou des outils similaires. Si vous devez supporter des fournisseurs d'IA que Claude Agent SDK ne couvre pas, vous avez besoin d'une couche d'abstraction de fournisseurs. Si vous avez besoin d'un écosystème de plugins pour des utilisateurs non techniques, vous avez besoin d'un système de plugins.
Le pari de NanoClaw est plus ciblé : pour un assistant IA personnel qui se connecte à des canaux de chat, tourne de manière sécurisée dans des conteneurs et exploite les capacités de Claude via le SDK officiel, 500 lignes ne sont pas juste suffisantes — c'est optimal. Chaque ligne au-delà serait de la complexité qui ne sert pas l'utilisateur, de la charge de maintenance qui n'améliore pas le produit et de la surface d'attaque qui n'a pas besoin d'exister.
L'industrie du logiciel a un biais profond en faveur du plus. Plus de fonctionnalités, plus d'abstractions, plus d'options de configuration, plus de lignes de code. L'hypothèse est que plus de code signifie plus de capacités. NanoClaw est un contre-exemple — un projet où les capacités viennent des composants qu'il connecte, pas du code qu'il contient. Les 500 lignes ne sont pas le produit. Elles sont le pont minimal entre l'utilisateur et l'IA, conçu pour être aussi fin que possible afin que rien ne se mette en travers du chemin.