AgenticSeek : un agent autonome local, sous GPL-3.0, qui dépend surtout de votre matériel

Le problème visé : exécuter un agent autonome sans API tierce

La promesse du dépôt tient en une phrase : une alternative locale à Manus AI, sans clés d'API et sans abonnement mensuel. Le README insiste sur le fait que les clés d'API restent optionnelles et que l'usage local est le but premier du projet. Le public visé est donc précis : quelqu'un qui possède du matériel suffisant pour servir un modèle de raisonnement, et qui préfère que ses fichiers, ses requêtes de recherche et ses conversations ne quittent pas sa machine. Le fichier .env contient une variable WORK_DIR, décrite comme le répertoire de travail qu'AgenticSeek pourra lire et modifier. C'est le point le plus sensible du projet : l'agent n'a pas seulement accès à un bac à sable, il a accès à un chemin réel de votre disque. La question de l'adoption se résume donc à deux critères indépendants : la puissance de votre GPU ou de votre CPU, et votre tolérance à donner à un processus autonome des droits de lecture sur un dossier de travail.

Une équipe d'agents plutôt qu'un seul prompt

Le README décrit une sélection automatique d'agent : la requête est routée vers le spécialiste jugé le plus adapté, sans que l'utilisateur ait à choisir. Le projet parle aussi de découpage de tâches complexes en étapes exécutées par plusieurs agents. Cette organisation explique pourquoi le dépôt liste des sujets comme llm-agents et autonomous-agents plutôt qu'un simple wrapper de chat. Elle explique aussi une contrainte matérielle : chaque agent qui raisonne occupe de la mémoire de modèle, et la planification multiplie les appels. Sur une machine juste dimensionnée, un agent unique qui écrit du code et un agent unique qui navigue ne coûtent pas la même chose qu'une chaîne de planification complète. Le README ne fournit aucune mesure de latence ni de consommation mémoire, et je ne peux donc pas quantifier ce surcoût. Ce que l'on peut dire, c'est que l'architecture multi-agents est un choix de conception qui déplace le coût du cloud vers votre RAM.

SearxNG et Redis : les deux services que Docker doit faire tourner

La navigation web ne repose pas sur une API de recherche commerciale mais sur SearxNG, un métamoteur auto-hébergé, lancé via Docker Compose. C'est ce qui rend l'absence de clé d'API crédible pour la partie recherche. Redis apparaît également dans la configuration, avec REDIS_BASE_URL pointant par défaut vers redis://redis:6379/0, et le README indique de laisser cette valeur inchangée. La partie la plus délicate de la configuration est justement l'adressage de SearxNG, et le dépôt consacre un tableau entier à ce piège. Si vous lancez l'interface web avec le backend dans Docker, SEARXNG_BASE_URL doit valoir http://searxng:8080, et ce port reste 8080 même si vous avez changé SEARXNG_PORT. Si vous lancez le CLI avec le backend sur l'hôte, il faut utiliser http://localhost:8080, ou le port modifié. Le README est explicite : le nom d'hôte searxng n'existe qu'à l'intérieur de Docker. C'est une erreur de configuration facile à commettre et coûteuse à diagnostiquer, parce que le symptôme est une recherche qui échoue silencieusement plutôt qu'un message d'erreur parlant.

Mise en route : les commandes et les clés réellement présentes dans le dépôt

Le chemin documenté commence par cloner le dépôt et copier le fichier d'exemple. Le README donne trois commandes : git clone https://github.com/Fosowl/agenticSeek.git, puis cd agenticSeek, puis mv .env.example .env. Vient ensuite l'édition de .env, où il faut renseigner WORK_DIR, OLLAMA_PORT, LM_STUDIO_PORT, CUSTOM_ADDITIONAL_LLM_PORT et, si nécessaire, corriger SEARXNG_PORT et SEARXNG_BASE_URL selon le tableau cité plus haut. Les variables OPENAI_API_KEY, DEEPSEEK_API_KEY, OPENROUTER_API_KEY, TOGETHER_API_KEY, GOOGLE_API_KEY et ANTHROPIC_API_KEY sont présentes mais marquées optionnelles. Docker doit être démarré avant tout, et le dépôt propose docker info comme test de bon fonctionnement. Les prérequis sont stricts sur un point : Python 3.10.x est fortement recommandé, et le README avertit que d'autres versions peuvent provoquer des erreurs de dépendances. Deux modes de lancement sont mentionnés : ./start_services.sh full pour l'interface web avec backend conteneurisé, et uv run cli.py pour le mode terminal avec backend sur l'hôte. Le README précise aussi que le fichier .env n'est lu qu'au démarrage du processus : après modification, il faut redémarrer le backend. Aucune version publiée n'apparaît dans les informations disponibles, donc l'installation se fait depuis la branche main.

Ce que le dépôt ne promet pas

Le README contient une phrase que beaucoup de projets de cette catégorie évitent : le projet a démarré comme projet secondaire, avec zéro feuille de route et zéro financement. Il faut la prendre au sérieux. Cela signifie qu'il n'existe pas d'engagement de compatibilité entre versions, pas de canal de correctifs de sécurité, et qu'une mise à jour de la branche main peut casser une configuration qui fonctionnait. La fonction vocale est elle-même décrite comme en cours de développement, donc la présenter comme une capacité acquise serait inexact. Autre limite structurelle : le projet est taillé pour des modèles de raisonnement locaux, et le README admet que si votre matériel ne peut pas faire tourner de LLM en local, il faut se tourner vers les fournisseurs distants listés. Dans ce cas, l'argument de confidentialité tombe, et il ne reste qu'une interface d'orchestration. Enfin, la licence GPL-3.0 a une conséquence concrète : si vous redistribuez une version modifiée d'AgenticSeek, vous devez fournir le code source correspondant sous la même licence. Un usage interne n'est pas concerné, mais intégrer le code dans un produit distribué change la donne. Je ne donne pas d'avis juridique ici, seulement la lecture de l'identifiant de licence déclaré.

Face à un agent hébergé ou à un cadre d'orchestration générique

L'alternative la plus directe est un agent hébergé du type de ceux qui facturent à l'usage : vous ne gérez ni Docker, ni SearxNG, ni modèle, et vous obtenez des mises à jour continues. Le compromis est inverse et symétrique : vos requêtes et vos fichiers transitent par un tiers, et le coût revient chaque mois. AgenticSeek troque cette facture contre du matériel, de la configuration et de la maintenance. Une seconde alternative, plus proche techniquement, consiste à assembler soi-même un cadre d'orchestration générique avec un moteur de recherche auto-hébergé. La différence n'est pas dans les briques, qui sont largement les mêmes, mais dans le travail déjà fait : routage d'agents, intégration de SearxNG, interface web et mode vocal sont fournis ici. Vous payez cette commodité en dépendance à un projet sans feuille de route, et en acceptant les choix de conception de quelqu'un d'autre, notamment le fait que l'agent lit et écrit dans WORK_DIR.

Coût de maintenance et cycle de mise à jour

Trois sources de friction rendent la maintenance non triviale. D'abord Python 3.10.x, qui vieillit : à mesure que les bibliothèques abandonnent cette version, l'écart entre ce que le projet épingle et ce que publie l'écosystème se creuse. Ensuite les services conteneurisés : SearxNG et Redis évoluent de leur côté, et rien dans les informations disponibles n'indique qu'une version soit épinglée. Enfin l'absence de release publiée signifie qu'il n'existe pas de point de retour étiqueté vers lequel revenir après une régression. La pratique raisonnable est de noter le commit sur lequel vous êtes et de ne mettre à jour qu'en connaissance de cause. Sur le plan de la licence, GPL-3.0 s'applique au code distribué, pas à vos données ni à vos conversations, mais elle contraint toute redistribution d'une version modifiée. Si votre organisation interdit les licences copyleft fortes dans les produits livrés au client, c'est un critère d'exclusion à vérifier avant même d'installer Docker.

Conclusion éditoriale

AgenticSeek s'adresse aux développeurs qui disposent déjà d'une machine capable de servir un modèle de raisonnement en local et qui acceptent de gérer eux-mêmes Docker, SearxNG et un fichier .env. Ceux qui comptent sur un laptop sans GPU, ou qui veulent un service maintenu avec des versions stables, devraient passer leur chemin : le README précise que le projet a zéro feuille de route et zéro financement. Avant d'investir du temps, vérifiez trois choses dans cet ordre : que Python 3.10.x est bien la version active, que docker info répond, et que votre moteur d'inférence expose réellement le modèle que vous comptez utiliser sur le port déclaré dans OLLAMA_PORT ou LM_STUDIO_PORT.

Sources officielles

1. Fosowl/agenticSeek on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README