holaOS : un espace de travail agentique que l'entreprise assemble elle-même

Le problème visé : l'agent qui ignore l'outil où le travail se fait

La plupart des produits agentiques livrent une interface finie et laissent l'équipe s'y adapter. holaOS prend le parti inverse : il fournit des briques (applications, outils de chat, skills, intégrations, modèles, agents, mémoire) que l'entreprise assemble selon son fonctionnement réel. Le public visé est celui qui a déjà des systèmes en place et ne veut pas les remplacer pour obtenir un agent utile.

Le point de friction que le projet attaque est précis. Selon le README, le contexte de travail vit dans un fil Slack, un groupe Feishu ou un message DingTalk, et non dans un document. Un agent qui ne lit que des fichiers passe à côté des décisions. holaOS propose donc de connecter ces outils, avec une autorisation accordée par outil et par portée : l'agent ne lit rien avant approbation. C'est une réponse à un problème organisationnel, pas à un problème de modèle.

HolaApps : l'application réelle comme surface d'agent

Le mécanisme central décrit dans le README est celui des HolaApps. Une application installée depuis la place de marché intégrée s'ouvre comme une interface interactive à côté de l'agent, et non comme un transcript de conversation. L'agent agit dans l'application, l'utilisateur peut reprendre la main, et le résultat reste dans l'application.

La synchronisation du contexte est bidirectionnelle : ce qui est cliqué, saisi ou ouvert dans l'interface devient du contexte disponible pour l'agent. Le README donne l'exemple d'une HolaApp Notion ouverte côte à côte avec l'agent qui la parcourt. Il indique aussi qu'une HolaApp peut pointer vers n'importe quelle URL et n'importe quel serveur MCP, l'application vivant sur la machine de l'utilisateur.

C'est un choix architectural lourd. Faire cohabiter un agent et une interface web interactive dans la même fenêtre suppose de gérer l'état de l'application, la capture du contexte et la reprise manuelle. Le README ne détaille pas cette mécanique interne, et c'est la principale zone d'ombre du projet pour qui veut évaluer la robustesse avant d'installer.

Mémoire partagée et agents interchangeables

holaOS revendique l'exécution de Claude Code, de Codex et de son propre agent dans le même espace de travail, sans changement d'outillage. Le README insiste sur le fait que ces agents partagent la même mémoire, les mêmes outils, les mêmes skills et les mêmes applications. L'objectif affiché est d'éviter de reconstruire son environnement à chaque changement d'agent.

Le projet cite plus de 100 intégrations, avec OAuth en un clic pour Gmail, Notion, Slack, GitHub, Linear et une cinquantaine d'autres, ainsi que la prise en charge de serveurs MCP apportés par l'utilisateur ou installés depuis une place de marché. Les skills permettent d'empaqueter un flux de travail une fois pour que n'importe quel agent le rejoue, et les combos regroupent skills et intégrations en une installation unique.

Cette couche d'abstraction a un coût implicite. Plusieurs agents partageant une mémoire unique signifie qu'une dérive de contexte se propage à tous, et le README ne décrit ni politique de rétention, ni mécanisme d'isolation par projet. Pour un usage individuel c'est confortable ; pour plusieurs équipes sur la même instance, la question reste ouverte.

Le modèle des modèles : intégré par défaut, BYOK en option

Le README présente un compte unique donnant accès à plusieurs modèles sans clé d'API à gérer, avec Kimi K3 et GLM 5.2 cités pour le volume courant, et GPT 5.6, Claude Opus 5 et Fable 5 pour les tâches difficiles. Le choix du modèle se fait par tâche et par agent.

L'alternative est le BYOK : fournir ses propres clés pour OpenAI, Anthropic ou tout point de terminaison compatible OpenAI ou Anthropic. Le README précise que ces appels passent par le compte de l'utilisateur et non par le forfait holaOS. C'est la partie la plus concrète du modèle économique, et elle mérite d'être lue attentivement : le chemin par défaut dépend d'un service opéré par l'éditeur, tandis que le chemin BYOK sort de ce périmètre. La promesse local-first porte sur les données de travail, pas sur les inférences effectuées via le compte intégré.

Installation : plateformes annoncées et documentation à vérifier

Les badges du dépôt annoncent macOS (Apple Silicon et Intel), Windows et Linux, une application de bureau Electron et un runtime TypeScript. La CI est exposée via un workflow GitHub Actions. Le README renvoie vers une page de démarrage rapide sur le site du projet et vers une section Quick Start, mais le texte fourni ne contient ni commande d'installation, ni clé de configuration, ni extrait de fichier de paramétrage.

Je ne peux donc pas donner ici de commande vérifiée. Toute personne qui évalue holaOS doit ouvrir la page de démarrage rapide et la section Quick Start du dépôt, puis confirmer trois points : la méthode d'installation par plateforme, l'emplacement des fichiers de configuration, et la façon dont les identifiants OAuth des intégrations sont stockés localement. Les clés de configuration citées dans le README sont les intégrations, les serveurs MCP, les skills et les combos ; leur syntaxe exacte n'est pas fournie dans le matériel dont je dispose.

Limites et cas où holaOS n'est pas le bon outil

La première limite est structurelle : holaOS est une application Electron. Il n'y a, dans le matériel fourni, aucune mention d'un mode serveur, d'une image conteneur ou d'une API sans interface graphique. Un besoin d'exécution sur une machine distante, dans un pipeline CI ou derrière un accès partagé ne trouve pas de réponse documentée ici.

La deuxième concerne la licence. Le dépôt affiche NOASSERTION, ce que GitHub utilise lorsque le fichier de licence n'est pas reconnu comme un standard. Le README, lui, affiche un badge Apache 2.0 modifiée. Une licence Apache 2.0 modifiée n'est pas la licence Apache 2.0 : les conditions ajoutées peuvent restreindre l'usage commercial, l'hébergement pour des tiers ou la redistribution. Le fichier LICENSE doit être lu avant toute décision d'adoption, et un service juridique devra se prononcer.

La troisième est la dépendance à l'offre intégrée. Le confort sans clé d'API passe par un compte holaOS. Une organisation qui interdit les fournisseurs d'inférence intermédiaires devra basculer entièrement en BYOK, ce qui annule une partie de l'intérêt annoncé.

Enfin, la documentation publique accessible dans ce dépôt reste mince sur les mécanismes internes : synchronisation de contexte entre application et agent, format de la mémoire partagée, isolation entre agents. Ce sont précisément les questions qu'un ingénieur se pose avant d'installer.

Face aux harnais d'agent en ligne de commande

L'alternative la plus directe n'est pas un autre espace de travail, c'est l'absence d'espace de travail. Claude Code et Codex s'utilisent seuls, en terminal, avec les fichiers du dépôt courant et les serveurs MCP déclarés dans leur propre configuration. La différence d'approche est nette : le harnais en ligne de commande traite le terminal et le système de fichiers comme la surface de travail, tandis que holaOS ajoute une couche Electron avec des applications interactives, une place de marché, une mémoire partagée entre agents et des intégrations OAuth gérées dans l'interface.

Le compromis suit cette ligne. Le harnais en ligne de commande est plus simple à auditer, plus facile à scripter et ne dépend d'aucune place de marché. holaOS apporte ce que la ligne de commande ne fournit pas : voir l'agent agir dans Notion ou dans un navigateur, et reprendre la main au même endroit. Si votre travail se passe entièrement dans des fichiers et des commandes, la couche supplémentaire n'apporte rien. Si votre travail se passe dans des interfaces web et des fils de discussion, elle vise exactement ce manque.

Coût de maintenance et implications de licence

Le dépôt indique une dernière poussée en août 2026 et une version étiquetée latest datée du 6 août 2026. Sur cette base, le projet est actif. Cela ne dit rien de la compatibilité ascendante : le README ne décrit aucune politique de version, aucune branche de maintenance, aucun engagement sur la stabilité des formats de skills, de combos ou de mémoire. Une équipe qui empaquette ses flux de travail en skills prend donc un risque de migration à chaque évolution.

Le coût de maintenance se répartit en trois postes. Les intégrations OAuth dépendent de fournisseurs tiers et de leurs changements d'API. Les serveurs MCP installés depuis la place de marché sont du code tiers exécuté localement, avec les risques associés. L'application Electron elle-même suit le cycle de vie de Chromium et de Node, ce qui impose des mises à jour régulières.

Sur la licence, je ne donne pas de conseil juridique. Le point factuel est celui-ci : GitHub ne reconnaît pas le fichier de licence du dépôt, puisqu'il affiche NOASSERTION, alors que le README annonce une licence Apache 2.0 modifiée. Ces deux signaux ne se contredisent pas nécessairement, mais ils imposent de lire le texte de licence avant de redistribuer le logiciel ou de le proposer à des tiers.

Conclusion éditoriale

Adoptez holaOS si vous voulez un poste de travail Electron où Claude Code, Codex et un agent intégré partagent outils, fichiers et mémoire, avec des applications réelles affichées à côté de l'agent. Évitez-le si votre besoin est un service sans interface graphique, un déploiement serveur, ou une chaîne d'approvisionnement logicielle qui exige une licence OSI standard, puisque le dépôt affiche NOASSERTION et que le README parle d'une licence Apache 2.0 modifiée. Avant de vous engager, lisez le fichier LICENSE et les conditions de l'offre holaOS intégrée, puis vérifiez dans la documentation si les clés BYOK et les serveurs MCP que vous comptez utiliser sont bien pris en charge par votre agent.

Sources officielles

1. holaboss-ai/holaOS on GitHub
2. Issues
3. Project website
4. README
5. Releases