Il y a un moment dans chaque projet logiciel où l'on réalise qu'on construisait la mauvaise chose. On a passé des semaines à écrire un routeur de messages, un moteur d'exécution d'outils, un gestionnaire d'état de conversation et un système de retry — puis on découvre que le fournisseur d'IA gère déjà tout ça, mieux qu'on ne pourrait le faire, en un seul appel API.
C'est ce moment qui a conduit à l'architecture de NanoClaw. Le cœur entier — la partie qui transforme un message WhatsApp en une réponse d'agent IA avec utilisation d'outils, navigation web, accès aux fichiers et conversation multi-tours — fait environ 500 lignes de TypeScript. Pas 500 lignes de code de liaison qui importent 50 000 lignes de framework. Cinq cents lignes, au total, construites sur Claude Agent SDK d'Anthropic.
La réaction des développeurs qui lisent le code source pour la première fois est généralement l'incrédulité, suivie de la question qui compte : « Où est le reste ? »
Ce que Claude Agent SDK fait réellement
La plupart des frameworks d'agents IA existent parce que, historiquement, les API de modèles de langage étaient sans état et simples. On envoyait un prompt, on recevait une réponse. Si on voulait l'utilisation d'outils, il fallait construire la boucle d'exécution soi-même. Si on voulait une conversation multi-tours, il fallait gérer l'historique des messages soi-même. Si on voulait que le modèle choisisse entre plusieurs outils, il fallait construire la logique de routage soi-même.
Claude Agent SDK change fondamentalement cette équation. Le SDK ne se contente pas d'appeler l'API Claude — il exécute une boucle d'agent. Vous lui donnez un prompt système, un ensemble d'outils et un message utilisateur. Le SDK gère tout le reste : il envoie le message à Claude, reçoit la réponse, vérifie si Claude veut utiliser un outil, exécute l'outil, renvoie le résultat à Claude, et répète jusqu'à ce que Claude produise une réponse finale. Toute la boucle d'utilisation d'outils — ce que la plupart des frameworks implémentent en des milliers de lignes — se résume à un seul appel de fonction.
Ce n'est pas un simple wrapper. Le SDK gère le streaming, la logique de retry, le comptage de tokens et l'état de la conversation. Il gère les allers-retours entre Claude et les outils sur plusieurs tours, en traitant les cas limites comme les échecs d'exécution d'outils et les limites de fenêtre de contexte. La complexité que NanoClaw n'a pas besoin d'implémenter n'est pas absente — elle a été poussée dans un SDK bien testé, maintenu par l'équipe d'ingénierie d'Anthropic. ## Ce que NanoClaw construit réellement
Si le SDK gère la boucle d'agent, que font réellement les 500 lignes de NanoClaw ? La réponse : tout ce qui entoure la boucle — les parties spécifiques à l'exécution d'un assistant IA personnel plutôt qu'à un simple appel API.
La première responsabilité est l'intégration des canaux. NanoClaw se connecte à WhatsApp via la bibliothèque Baileys, reçoit les messages et les route vers le bon conteneur d'agent. C'est la colle entre « quelqu'un a envoyé un message sur WhatsApp » et « un agent doit traiter ce message ». Ce n'est pas du code compliqué, mais c'est du code essentiel — sans lui, l'agent n'a aucun moyen d'atteindre les utilisateurs là où ils sont déjà.
La deuxième responsabilité est l'orchestration des conteneurs. Chaque conversation d'agent tourne dans son propre conteneur Linux — Apple Container sur macOS, Docker sur Linux. NanoClaw lance les conteneurs, monte les bons répertoires, transmet les secrets via stdin et collecte les réponses. C'est la frontière de sécurité qui empêche un agent compromis d'accéder à quoi que ce soit en dehors de son sandbox. La gestion du cycle de vie des conteneurs fait peut-être 80 lignes de code, mais ces 80 lignes font la différence entre un agent à qui on peut confier de vrais identifiants et un agent à qui on ne peut pas.
La troisième responsabilité est la mémoire persistante. NanoClaw maintient une base de données SQLite des conversations, de l'état des groupes et des tâches planifiées. Chaque groupe WhatsApp obtient son propre fichier CLAUDE.md qui sert de mémoire à long terme de l'agent pour ce groupe. Le système de mémoire est simple — intentionnellement — parce que la partie complexe de la mémoire (décider ce qui est pertinent, quoi rappeler, comment utiliser le contexte) est gérée par Claude lui-même.
La quatrième responsabilité est les tâches planifiées. Les utilisateurs peuvent demander à l'agent de faire des choses à des moments précis — « rappelle-moi à 15h » ou « vérifie ce site web chaque matin ». Le planificateur de type cron de NanoClaw déclenche les conteneurs d'agents aux bons moments, ce qui est une fonctionnalité modeste mais réellement utile qui transforme un chatbot réactif en un assistant proactif.
Pourquoi 500 lignes, ça compte
Le nombre de lignes n'est pas une métrique de vanité. C'est une mesure directe de la surface de maintenance, de la surface de bugs et de la charge cognitive nécessaire pour comprendre le système.
Quand un bug apparaît dans le cœur de NanoClaw, il y a 500 lignes où il peut se trouver. Un développeur peut lire l'intégralité de la base de code en moins d'une heure et comprendre chaque décision qui a été prise. Comparez cela aux frameworks avec 50 000 lignes de code principal — trouver un bug signifie naviguer dans des abstractions, comprendre des systèmes de plugins et tracer l'exécution à travers des couches d'indirection qui existent pour supporter des fonctionnalités que vous n'utilisez peut-être même pas.
Les implications en matière de sécurité sont tout aussi concrètes. Chaque ligne de code est une vulnérabilité potentielle. Le cœur de 500 lignes de NanoClaw a une surface d'attaque plus petite que les parseurs de configuration de la plupart des frameworks. L'isolation par conteneur, la transmission des secrets via stdin, les listes blanches de montage — ces fonctionnalités de sécurité sont implémentées dans un code suffisamment petit pour être audité entièrement en un après-midi.
Et l'histoire des mises à jour est simple. Quand Anthropic publie une nouvelle version de Claude Agent SDK avec une meilleure utilisation des outils, un streaming plus rapide ou de nouvelles capacités, NanoClaw bénéficie de ces améliorations en mettant à jour une seule dépendance. Il n'y a pas de couche d'abstraction à mettre à jour pour exposer les nouvelles fonctionnalités du SDK. Le SDK est le framework. ## La philosophie de ne pas construire
La partie la plus difficile de l'architecture de NanoClaw n'a pas été de la construire — c'était de décider quoi ne pas construire. La tentation d'ajouter un moteur d'exécution d'outils personnalisé, un système sophistiqué de récupération de mémoire, une couche d'abstraction multi-fournisseurs, une marketplace de plugins — ce sont toutes des choses que d'autres frameworks ont construites, et ce sont toutes des choses que NanoClaw n'a délibérément pas.
Chacune de ces fonctionnalités ajouterait des milliers de lignes de code, des dizaines de bugs potentiels et des semaines de charge de maintenance. Et chacune dupliquerait des fonctionnalités que Claude Agent SDK fournit déjà ou que Claude lui-même gère mieux que n'importe quel code écrit à la main.
Le résultat est un projet où les décisions intéressantes sont architecturales, pas implémentationnelles. Comment les conteneurs doivent-ils être isolés ? Comment les secrets doivent-ils être transmis ? Comment la mémoire doit-elle être cloisonnée par groupe ? Ce sont les questions qui comptent pour un assistant IA personnel, et ce sont les questions auxquelles les 500 lignes de NanoClaw sont dédiées.
La prochaine fois que vous évaluez un framework d'agents IA, ne comptez pas les fonctionnalités. Comptez les lignes. Le framework avec le moins de lignes n'est pas le moins capable — c'est peut-être celui qui a suffisamment bien compris le problème pour laisser le fournisseur d'IA faire le gros du travail.