Botinok : un agent IA en console pour serveurs, qui tourne en local et demande peu de mémoire

Botinok est un agent IA en console destiné à ceux qui travaillent sur des serveurs Linux via SSH et ne veulent pas faire la navette entre le terminal et un chat web. Le projet est conçu comme un outil local sans processus en arrière-plan : on le lance, on règle le problème, on applique le correctif et on le ferme.

D'où vient l'idée

L'histoire de Botinok ne commence pas avec la mode des agents, mais avec une douleur bien connue de tout administrateur système. En quinze ans de travail sur des serveurs Linux, les outils d'infrastructure ont changé plusieurs fois : la configuration manuelle a cédé la place à Ansible, puis Kubernetes est arrivé, et une partie des équipes est ensuite revenue à des schémas plus simples comme docker-compose. Mais les tâches elles-mêmes n'ont pas disparu : il faut fouiller les logs, modifier les configurations, diagnostiquer les pannes de services et garder en tête l'état actuel de la machine.

Les LLM ont ajouté une couche utile à cette routine : on peut vite interroger un modèle sur nginx, systemd ou une erreur dans les logs et obtenir une indication claire. Le problème est ailleurs : le terminal et le chat vivent séparément. Chaque requête devient un copier-coller d'extraits, une explication de contexte et un retour à la console. Botinok est né de l'envie de supprimer ce fossé : installer le modèle directement dans le flux SSH, lui donner accès au contexte de travail et ne pas exiger pour autant une carte graphique puissante ni une infrastructure lourde.

Pourquoi pas OpenClaw

Avant d'écrire son propre outil, l'auteur a essayé OpenClaw, un agent IA auto-hébergé de nouvelle génération, conçu pour fonctionner en continu et automatiser le quotidien. Sur le papier, tout semblait convaincant : un agent riche en intégrations, avec messageries, architecture multicouche et mode 24/7. Mais pour des tâches du genre « se connecter au serveur, comprendre ce qui est cassé, corriger et sortir », cette approche s'est révélée trop lourde et trop éloignée du processus réel d'un administrateur.

• Un schéma multicouche trop complexe pour de simples tâches SSH
• Un accent mis sur le courrier, l'agenda et les réservations plutôt que sur les logs, systemd, Docker et nginx
• Un démon en fonctionnement permanent, qui consomme des ressources même au repos
• Une interface par messagerie, alors que l'administrateur a besoin d'un terminal

« Botinok n'est ni un service d'arrière-plan ni un processus qui reste en permanence actif.

C'est une application ordinaire : on la lance, on travaille, on la ferme. »

Un outil plutôt qu'un service

C'est ici qu'apparaît la principale différence du projet. Botinok n'est pas conçu comme un assistant numérique universel, mais comme un outil appliqué à un environnement précis : le terminal et SSH. Il n'exige ni serveur web, ni service système, ni processus constamment actif. Ce mode ressemble davantage à la façon dont les développeurs utilisent Cursor ou Windsurf dans un IDE : ouvrir un espace de travail, donner du contexte au modèle, accomplir la tâche et terminer la session. Sauf qu'ici, l'espace de travail est un serveur distant et son état actuel.

L'approche compte aussi parce qu'elle abaisse le seuil d'entrée. L'utilisateur n'a pas besoin d'une usine à gaz côté serveur avec une dizaine d'intégrations, ni de 24 Go de VRAM pour essayer un scénario d'agent en local. Une architecture légère dotée d'un jeu d'outils suffit : lire les logs, aider sur les configurations, écrire ou corriger du code et, au besoin, chercher de l'information. Sous cette forme, Botinok ressemble moins à une démonstration des capacités des LLM qu'à une réponse pratique à un scénario de travail très étroit, mais très répandu.

Ce que cela signifie

Botinok illustre un déplacement sur le marché des outils d'IA : au lieu d'un seul assistant géant pour tous les cas, on voit apparaître de plus en plus d'agents spécialisés pour un environnement précis. Pour les équipes DevOps et d'administration, c'est un signal : la prochaine couche utile d'automatisation pourrait vivre non pas dans le navigateur ni dans une messagerie, mais directement dans le terminal.