OpenAgent : un assistant personnel auto-hébergé qui exécute des boucles d'agent en Go
⚡️next-generation personal AI assistant powered by LLM, RAG and agent loops, supporting computer-use, browser-use and coding agent, demo: https://demo.openagentai.org
En bref
- De quoi s’agit-il ?
- OpenAgent réunit plusieurs fournisseurs de modèles, une base de connaissances RAG et des boucles d'agent capables de piloter un navigateur, un shell ou des fichiers Office. Le binaire unique simplifie le déploiement, mais la surface d'exécution ouverte demande un examen attentif avant toute adoption.
- À qui s’adresse-t-il ?
- OpenAgent convient aux développeurs et aux équipes techniques qui veulent un assistant auto-hébergé, unifié autour de MCP et d'une base RAG, sur une machine dont ils contrôlent l'accès. Il ne convient pas aux environnements où l'exécution de commandes shell ou le pilotage d'un navigateur par un modèle doit rester impossible, ni à ceux qui cherchent un simple client de chat sans boucle d'agent.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 6 jours.
- En quel langage est-il écrit ?
- Principalement Go, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Un assistant qui exécute, pas seulement qui répond
La plupart des interfaces de chat se contentent de renvoyer du texte. OpenAgent ajoute une boucle d'agent : le modèle peut appeler des outils, observer le résultat, puis décider de l'étape suivante. Le README énumère ces capacités sous forme de tableau : pilotage d'un navigateur réel (navigation, clics, formulaires, captures d'écran), recherche et récupération de pages web, exécution de commandes shell, lecture et écriture de fichiers Word, Excel et PowerPoint, et branchement de serveurs compatibles MCP en SSE, Stdio ou StreamableHTTP. Le public visé est donc technique : développeur seul, équipe qui veut un assistant interne, ou personne qui préfère garder ses documents et ses clés d'API sur sa propre machine plutôt que chez un fournisseur SaaS. Le projet se présente comme auto-hébergeable, ce qui est le point de départ de tout le reste.
Ce que le binaire unique implique vraiment
Le README insiste sur un point : OpenAgent est distribué comme un binaire unique, sans installation. Les binaires précompilés couvrent Linux, macOS et Windows, en x86_64 et arm64, et le script d'installation démarre le service sur le port 14000. Windows est annoncé comme fonctionnant nativement, sans WSL ni Docker. Cette contrainte de forme a des conséquences concrètes sur l'exploitation. Un seul processus à superviser, pas de chaîne de dépendances système à reconstruire à chaque mise à jour. En contrepartie, tout ce que l'agent peut faire (shell, navigateur, fichiers) s'exécute dans le contexte de ce processus unique. Le README ne décrit pas de mécanisme de sandbox, de conteneur d'exécution ni de restriction de privilèges pour les commandes shell. C'est un choix de conception assumé, mais il déplace la responsabilité de l'isolation vers celui qui déploie.
Installation et premiers pas sur le port 14000
Sur macOS, Linux ou WSL, la commande donnée par le README est : curl -fsSL https://raw.githubusercontent.com/the-open-agent/openagent/master/scripts/install.sh | bash. Sous Windows, l'équivalent PowerShell est : irm https://raw.githubusercontent.com/the-open-agent/openagent/master/scripts/install.ps1 | iex. L'interface est ensuite accessible sur http://localhost:14000. Trois variables d'environnement optionnelles sont documentées : OPENAGENT_VERSION, INSTALL_DIR et BIN_DIR, ce qui permet d'épingler une version ou de choisir l'emplacement des fichiers. Pour une compilation depuis les sources, les prérequis sont Go 1.25.0 ou plus récent pour le backend (go build), et Node.js 20 avec Yarn 1.x pour le frontend (cd web && yarn install && yarn start). Une option Docker existe via docker-compose up. À noter : le README ne documente pas de fichier de configuration principal ni de clés de configuration pour les fournisseurs de modèles. La sélection des modèles et des serveurs MCP semble passer par l'interface web, ce qui est pratique pour un usage personnel mais rend la configuration moins reproductible dans un déploiement automatisé.
RAG, MCP et le point de jonction avec vos outils
Le volet RAG accepte l'upload de PDF, de documents Word, de feuilles Excel et d'autres formats, qui sont découpés, vectorisés et indexés automatiquement, puis interrogés par recherche sémantique. Le README ne précise pas les modèles d'embedding utilisés, la taille des segments, ni le moteur de recherche vectorielle sous-jacent. Ces détails comptent : ils déterminent la qualité du rappel sur des documents longs ou tabulaires, et ils ne peuvent pas être évalués depuis la documentation seule. L'intégration MCP est plus intéressante, car elle transforme OpenAgent en hôte de tools : tout serveur compatible expose ses outils à l'agent, et le README mentionne un affichage transparent des appels d'outils, arguments et valeurs de retour compris. Cette lisibilité est un vrai argument pour le débogage, à condition que les journaux détaillés montrés dans les captures soient effectivement persistés et consultables. Le projet annonce plus de trente fournisseurs de modèles, d'OpenAI à Ollama en passant par Bedrock, OpenRouter ou DeepSeek, avec changement de fournisseur par conversation sans modification de code.
La limite qui compte : un agent avec accès au shell
Un assistant qui exécute des commandes shell et pilote un navigateur est un outil à double tranchant. Le README ne décrit ni liste blanche de commandes, ni confirmation avant exécution, ni environnement isolé. Il faut donc supposer que le modèle dispose du même niveau d'accès que l'utilisateur qui lance le binaire. Une injection de prompt via une page web récupérée ou un document ingéré devient alors un vecteur d'exécution, pas seulement une curiosité. La documentation ne traite pas ce scénario, et c'est la lacune la plus sérieuse du matériel fourni. Autre cas où l'outil ne convient pas : si votre besoin se limite à interroger un modèle avec votre base documentaire, la boucle d'agent et l'exécution de code ajoutent de la surface sans bénéfice. Enfin, la cadence de publication (v2.90.0, v2.90.1 et v2.91.0 en quelques jours selon les notes de version) suggère un projet en évolution rapide, ce qui complique la validation d'une version avant mise en production.
Face à LibreChat ou Open WebUI : la différence d'architecture
Les alternatives les plus proches, comme LibreChat ou Open WebUI, sont d'abord des interfaces de discussion multi-fournisseurs : elles ajoutent parfois des outils et une recherche documentaire, mais le cœur reste la conversation. OpenAgent place la boucle d'agent au centre : l'exécution d'outils n'est pas une extension, c'est le mode de fonctionnement. Cette différence change la nature du déploiement. Une interface de chat peut être exposée à un petit groupe sans grand risque, car la pire conséquence d'une erreur est une mauvaise réponse. Un hôte d'agent qui exécute des commandes et ouvre des pages web se place du côté de l'infrastructure, avec les précautions correspondantes : machine dédiée, réseau restreint, compte utilisateur sans privilèges. Le choix entre les deux dépend donc moins de la liste de fonctionnalités que du niveau de confiance que vous accordez au modèle pour agir sur votre système.
Licence, mises à jour et coût réel de maintenance
Le projet est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial, la modification et la redistribution, avec conservation des mentions de copyright et du fichier de licence, et une clause de brevets explicite. Elle n'impose aucune obligation de publication de vos modifications. Les coûts d'exploitation se répartissent ailleurs : les appels aux fournisseurs de modèles restent facturés par ces fournisseurs, sauf si vous passez par Ollama en local, et l'indexation RAG consomme des embeddings à chaque document ingéré. Côté mises à jour, la cadence observée entre v2.90.0 et v2.91.0 implique des montées de version fréquentes ; les variables OPENAGENT_VERSION et INSTALL_DIR permettent d'épingler une version et de contrôler l'emplacement, ce qui est la seule protection documentée contre une mise à jour non désirée. Le README ne décrit pas de procédure de sauvegarde de la base de connaissances ni de migration de schéma entre versions. Avant de constituer un corpus documentaire important, c'est le point à clarifier en priorité.
Conclusion éditoriale
OpenAgent convient aux développeurs et aux équipes techniques qui veulent un assistant auto-hébergé, unifié autour de MCP et d'une base RAG, sur une machine dont ils contrôlent l'accès. Il ne convient pas aux environnements où l'exécution de commandes shell ou le pilotage d'un navigateur par un modèle doit rester impossible, ni à ceux qui cherchent un simple client de chat sans boucle d'agent. Avant tout déploiement, vérifiez la configuration des fournisseurs de modèles et des serveurs MCP dans l'interface, puis testez le comportement du binaire face à des instructions ambiguës dans un environnement isolé, car c'est là que se joue la différence entre un assistant utile et un accès non surveillé à votre machine.
Notes de la communauté