nanobot : un framework d'agent IA personnel ultra-léger et auto-hébergé, une seule passerelle pour navigateur, terminal et messageries

La première phrase du README de HKUDS/nanobot est claire : c'est un framework open source ultra-léger, auto-hébergé, d'agent IA personnel, écrit en Python. On l'utilise dans un navigateur, un terminal ou une messagerie pour travailler sur des fichiers, retenir des préférences et planifier des tâches. Il faut raccorder soi-même un fournisseur de modèle pris en charge ou un serveur de modèle local, car nanobot ne fournit pas de modèle. Au 13 octobre 2026, le dépôt compte environ 48 978 étoiles et 8 626 forks, une licence MIT, du code Python, une création le 1er février 2026 et une dernière poussée le 12 octobre. Le README donne cinq raisons de le choisir : des flux de travail persistants, une portée native des messageries, la liberté de modèle, un noyau petit et lisible, et la maîtrise de sa pile.

La liste des capacités est large. Il se connecte à Telegram, Discord, Slack, WeChat, e-mail, Mattermost, Linear et d'autres canaux ; lit PDF, Word (.docx), Excel (.xlsx) et PowerPoint (.pptx) avec des outils de fichiers intégrés, par exemple pour résumer un rapport ; emploie shell, recherche et récupération web, intégrations MCP, cron, génération d'images et délégation multi-agents ; conserve historique de session et mémoire à long terme via un mécanisme nommé Dream ; mène des objectifs de longue durée et des automatisations planifiées ; expose un SDK Python et une API compatible OpenAI ; et peut être déployé comme passerelle durable locale ou serveur. La dernière version est la v0.3.5, qui amène l'atelier dans le terminal et facilite la poursuite des conversations entre navigateur, terminal et messageries, avec jusqu'à quatre conversations côte à côte dans la WebUI et l'usage du contexte et la progression du compactage par tour.

Le chemin d'installation est clair. Il faut Python 3.11 ou plus récent. La voie recommandée est le script d'installation : curl install.sh sous Linux et macOS, install.ps1 dans PowerShell sous Windows. Il installe ou met à jour nanobot-ai dans un environnement virtuel actif, uv, pipx ou un venv géré sous ~/.nanobot/venv, ouvre la WebUI sur un poste local et l'assistant de terminal en SSH ou sans écran, et accepte --dry-run pour prévisualiser le plan. Avec sa propre chaîne d'outils, on peut utiliser uv tool install nanobot-ai ou pip. Puis nanobot webui, choix d'un modèle dans les paramètres, enregistrement des identifiants et envoi de « Hello! » pour vérifier la connexion. On choisit un dossier d'essai avec accès restreint, on lui demande de lire notes.txt et d'écrire summary.md, et l'on vérifie que les permissions de fichiers se comportent comme prévu. Les wheels de plateforme incluent la WebUI et l'interface de terminal native sur macOS 13+, Linux glibc 2.17+ (ARM64 et x64) et Windows x64, le x64 exigeant SSE4.2. Pour les fonctions les plus récentes, installer depuis les sources demande Git et Bun.

Le compromis d'architecture est ce qu'il appelle un petit noyau. La passerelle Python possède l'exécution de l'agent, les sessions, les outils, la mémoire et la politique de sécurité, et la WebUI, le TUI et les messageries partagent ce même environnement d'exécution. La boucle centrale construit le contexte, appelle le modèle, exécute les outils demandés et renvoie le résultat ; mémoire, compétences, canaux et intégrations MCP prolongent cette boucle. Le SDK Python intègre l'exécution dans votre propre processus applicatif, tandis que l'API compatible OpenAI démarre un service HTTP séparé pour /v1/chat/completions, où chaque requête contient un message utilisateur, l'historique est géré par le serveur et le modèle vient de la configuration. La WebUI garde des sujets distincts pour différentes tâches et propose des conversations temporaires non enregistrées dans l'historique ni la mémoire. Mais le README avertit que les sujets ne séparent que l'historique et que les dossiers de projet ne choisissent que le lieu du travail sur fichiers ; ni l'un ni l'autre ne crée de mémoire à long terme distincte. Une instance partage profil d'agent, mémoire et compétences entre projets : pour isoler données ou préférences de clients, utilisez des instances séparées.

Pour qui s'auto-héberge, les avertissements de sécurité passent en premier. Le README dit que l'accès à la WebUI donne l'administration de la même instance d'agent, à ne partager qu'avec des opérateurs de confiance. Avant de connecter des messageries, vérifiez séparément l'appairage en message privé, la liste d'autorisation et l'accès aux groupes de chaque plateforme, car approuver un expéditeur privé ne restreint pas l'accès aux groupes partout. Les tâches planifiées exigent une passerelle en marche et un hôte éveillé ; les échéances manquées ne sont pas rejouées après un redémarrage. Enfin, les conversations temporaires envoient tout de même des requêtes au fournisseur de modèle configuré, et les fichiers créés par les outils subsistent après la fermeture : « temporaire » ne veut pas dire « rien n'est envoyé ».

Notre lecture : nanobot vaut parce qu'il fait de l'agent personnel un petit système lisible plutôt qu'un produit lié à un cloud : on voit la boucle centrale, on choisit le modèle, on décide où vivent les données. Les réserves sont aussi nettes. D'abord, étoiles et fréquence de mise à jour montrent une communauté active, pas la stabilité ; le README distingue lui-même la version stable des sources actuelles, et l'usage courant devrait viser la stable. Ensuite, l'agent détient des droits sur fichiers, shell et canaux de messagerie : une erreur de réglage pèse autant que ses capacités ; commencez en accès restreint avec un seul dossier d'essai. Enfin, les frais de modèle ou le matériel local dépendent de votre choix, nanobot ne les résout pas. Déployez d'abord sur une machine ou un conteneur isolé, ne connectez que votre propre compte de messagerie avec une liste d'autorisation, et jugez après une semaine de tâches réelles s'il mérite une place durable.