OpenAgents : un espace de travail partagé pour agents IA, piloté par le launcher agn

Le problème concret : des agents dispersés sans vue commune

Le README décrit une situation précise. Un agent maintient une base de données sur un serveur, un autre gère le marketing et répond aux utilisateurs sur Discord, plusieurs autres construisent des projets dans des terminaux séparés, sur des machines séparées. Aucun endroit unique pour les voir tous, aucune manière de les faire travailler ensemble. L'exemple donné est un rapport de bug : on voudrait que le bot marketing collecte les détails auprès de l'utilisateur, puis fasse intervenir l'agent d'infrastructure dans la même conversation pour lire les journaux. En pratique, cela se termine en copier-coller entre terminaux et en sessions SSH. OpenAgents cible donc les développeurs qui exploitent déjà plusieurs agents en parallèle et qui subissent cette fragmentation. Ce n'est pas un outil pour quelqu'un qui n'a qu'un seul agent dans un seul terminal : le coût d'installation d'un espace de travail ne se justifie pas dans ce cas.

Deux mécanismes : un espace persistant et un partage de ressources

Le projet repose sur deux idées exposées dans le README. La première est un espace de travail unifié, décrit comme un hub persistant accessible à une URL du type workspace.openagents.org/abc123. Tous les agents y apparaissent, quelle que soit la machine qui les exécute. La seconde est le partage de ressources entre agents d'un même espace : les mêmes fils de discussion, les mêmes fichiers, le même navigateur, le même contexte. Le README présente l'espace comme l'équivalent de Slack mais pour des agents. La coordination passe par des @mentions pour diriger une tâche, ou par reprise autonome du travail par un agent. Le navigateur partagé permet à un agent d'ouvrir une page, de cliquer, de prendre une capture et de remplir un formulaire, le tout visible par les autres membres de l'espace. Les tunnels exposent un serveur de développement local en URL publique. Le README ne détaille pas le protocole d'échange entre le launcher local et le hub, ni le format des messages. Cette partie de l'architecture reste à vérifier dans le code si elle conditionne votre adoption.

Le launcher agn : installation et cycle de vie d'un agent

L'installation se fait par script : curl -fsSL https://openagents.org/install.sh | bash sous macOS et Linux, ou irm https://openagents.org/install.ps1 | iex sous PowerShell. Le binaire s'appelle agn. La commande agn seule ouvre un tableau de bord interactif. Le cycle de vie d'un agent tient en quelques commandes documentées : agn create <name> --type <type> --install crée l'agent et installe le runtime dans la même étape, agn connect <name> <workspace-token> le rattache à un espace, agn env <type> --set LLM_API_KEY=sk-... écrit les identifiants, agn up démarre le daemon. Le README précise un point qui provoque des erreurs : agn create n'écrit que la configuration de l'agent. Il faut soit lancer agn install <type> au préalable, soit passer --install pendant la création. Le launcher existe aussi en application de bureau, avec des binaires macOS, Windows et Linux AppImage. Le dépôt publie des versions du launcher à un rythme rapproché, avec par exemple launcher-v0.9.27, launcher-v0.9.26 et launcher-v0.9.25 entre fin août et début septembre 2026.

Couverture des agents : lire le tableau avant de s'engager

Le README liste les agents pris en charge avec un statut explicite, et ce tableau est l'information la plus utile du document. OpenClaw, Claude Code, Codex CLI, Hermes Agent, Cursor, OpenCode, GitHub Copilot CLI, Gemini CLI et Amp sont marqués comme pris en charge. Cline est pris en charge en Beta. DeepSeek Harness est en Preview, en mode headless et épinglé à une version de préversion. Aider est en Beta avec une mention honnête : la suite de tests hors ligne passe (résolution de fournisseur, sessions, sécurité Git, détection d'installation) mais un essai de bout en bout contre un fournisseur de modèle réel n'a pas encore été réalisé. Goose est également en Beta, en mode CLI headless. Cette granularité change la décision. Si votre agent principal est Aider, vous devenez en quelque sorte le vérificateur du chemin d'intégration. Si c'est Claude Code ou Codex CLI, le risque est plus faible. Le README indique aussi que le flux create/connect d'Aider est disponible pour permettre cette vérification par l'utilisateur.

Limites visibles : ce que la documentation ne tranche pas

Plusieurs points restent ouverts dans le matériel fourni. Le README affirme qu'aucun compte n'est obligatoire et qu'il n'y a pas de verrouillage fournisseur, mais l'espace de travail vit à une URL hébergée sur openagents.org. La question de l'auto-hébergement du hub n'est pas traitée dans le texte disponible. Un lecteur qui a des contraintes de résidence des données doit donc vérifier ce point avant de connecter des agents qui accèdent à des journaux de production ou à des bases de données. Le partage de fichiers et de navigateur entre agents est présenté comme un avantage, mais c'est aussi une surface de confiance : un espace unique où plusieurs agents lisent et écrivent les mêmes fichiers suppose que vous acceptez que leurs périmètres se recouvrent. Enfin, le README ne documente pas de politique de conservation des données ni de gestion des secrets au-delà de la commande agn env, qui écrit des identifiants via le launcher. Ce sont des zones à inspecter dans le dépôt plutôt que des fonctionnalités à supposer acquises.

Face à un orchestrateur de workflows : deux approches opposées

La comparaison utile n'est pas avec un autre produit concurrent mais avec une catégorie d'outils : les orchestrateurs de workflows multi-agents, où l'on décrit un graphe d'étapes, des dépendances et des transitions, et où l'exécution suit ce graphe. OpenAgents prend le chemin inverse. Il ne décrit pas de graphe : il place des agents dans un espace partagé et laisse la coordination émerger par les @mentions, la reprise de travail et le contexte commun. La différence pratique est nette. Un orchestrateur vous donne la reproductibilité et l'audit d'un enchaînement défini à l'avance, au prix d'une modélisation à maintenir à chaque changement d'étape. OpenAgents vous donne la souplesse d'une conversation partagée, au prix de la prévisibilité : le README ne promet nulle part un ordonnancement déterministe des tâches. Si votre cas d'usage est un pipeline de traitement qui doit produire le même résultat à chaque exécution, l'espace de travail collaboratif n'est pas le bon modèle. Si votre cas est exploratoire, avec des agents qui doivent se passer du contexte, il correspond mieux.

Maintenance, licence et coût de mise à jour

Le dépôt est actif : dernière poussée en septembre 2026, branche par défaut develop, aucune archive. La cadence de publication du launcher est élevée, avec trois versions en une semaine environ selon les notes de version fournies. Cette cadence a un coût : un daemon lancé avec agn up et des agents configurés par agn env devront être suivis à chaque mise à jour du launcher, et les agents en statut Preview ou Beta sont explicitement épinglés ou non validés de bout en bout, ce qui augmente la probabilité de rupture. Sur la licence, le projet est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec des obligations de conservation des mentions et du fichier de licence. Le README affiche un badge Apache 2.0 et renvoie à un fichier LICENSE. Cela ne constitue pas un avis juridique : si vous redistribuez le launcher ou un dérivé, faites vérifier les obligations de notice par une personne compétente. Le point à contrôler en premier reste le couple agent plus statut, car c'est lui qui détermine si vous adoptez un chemin validé ou un chemin que vous devrez valider vous-même.

Conclusion éditoriale

OpenAgents convient aux développeurs qui font déjà tourner plusieurs agents de codage sur des machines distinctes et veulent un point d'entrée unique avec fichiers et navigateur partagés. Il ne convient pas à qui cherche un orchestrateur de workflows déterministes ou un simple client pour un seul agent. Avant d'adopter, vérifiez trois choses concrètes : le statut réel de l'agent que vous utilisez dans le tableau du README (Aider est en Beta avec un test de bout en bout non réalisé), la présence d'un fichier LICENSE Apache-2.0 à la racine du dépôt, et si le mode daemon de agn up correspond à votre modèle de déploiement.

Sources officielles

1. License: Apache-2.0
2. openagents-org/openagents on GitHub
3. Project website
4. README
5. Releases