Hermex : piloter un agent Hermes auto-hébergé depuis un iPhone
Native iPhone app for your Hermes agent
En bref
- De quoi s’agit-il ?
- Hermex est un client SwiftUI natif pour hermes-webui. Il ne fournit pas de serveur : tout le calcul et les données restent sur votre machine, le téléphone ne fait que commander. Voici ce que le dépôt permet réellement de conclure, et ce qu'il laisse en suspens.
- À qui s’adresse-t-il ?
- Adoptez Hermex si vous faites déjà tourner hermes-webui et voulez le piloter depuis un iPhone sans passer par un relais tiers. Passez votre chemin si vous cherchez une solution complète : le dépôt ne fournit ni serveur, ni hébergement, ni mise en réseau.
- Puis-je l’utiliser commercialement ?
- Oui. MIT 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 1 jour.
- En quel langage est-il écrit ?
- Principalement Swift, 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 cockpit mobile, pas une plateforme d'agent
Le problème visé est étroit et bien identifié. hermes-webui s'installe sur une machine que vous contrôlez, mais son interface s'ouvre dans un navigateur. Sur un iPhone, cela signifie jongler avec des onglets, perdre l'état de session au passage en arrière-plan et subir une ergonomie qui n'a pas été pensée pour le tactile. Hermex remplace cette couche par une application SwiftUI native, iOS 18 et plus, distribuée sur l'App Store. Le README est explicite sur la répartition des rôles : le téléphone est un plan de contrôle, pas un plan de calcul. L'agent, ses outils et vos données restent sur votre matériel.
Le public visé est donc restreint : des développeurs ou des utilisateurs techniques qui ont déjà un serveur hermes-webui en fonctionnement et qui veulent le consulter depuis leur poche. Le dépôt ne s'adresse pas à quelqu'un qui cherche un agent prêt à l'emploi. La première phrase de la section de démarrage le dit sans détour : Hermex est un client uniquement, il ne livre, n'héberge et ne provisionne aucun backend.
Ce que l'application expose de l'API serveur
Le README énumère les écrans, et cette liste dessine en creux la surface d'API consommée. Le chat accepte des options de modèle, d'effort de raisonnement, de workspace et de profil, avec pièces jointes et images. La réponse arrive en flux, avec le détail des blocs de réflexion et des appels d'outils. Deux commandes sortent du lot : interrompre une exécution en cours et la réorienter en vol. C'est le genre de fonction que les interfaces web exposent mal, parce qu'elles reposent sur une requête longue dont l'annulation dépend du navigateur.
Autour du chat gravitent des vues en lecture seule et des vues éditables. Sessions, modèles, profils et projets sont navigables. Les tâches cron sont consultables et modifiables depuis le téléphone, ce qui suppose un accès en écriture à la couche de planification du serveur. Les skills sont en lecture et en recherche. Le navigateur de workspace parcourt le système de fichiers du serveur. Memory et Insights sont annoncés comme des panneaux en lecture seule, sans plus de précision.
Cette asymétrie est cohérente : on modifie ce qui est structuré et réversible (une planification, un libellé de session), on se contente de lire ce qui touche à l'état interne de l'agent. Le README ne documente pas le format des échanges ni les points d'entrée utilisés. Impossible, à partir du dépôt seul, de savoir si l'application parle à une API REST, à des websockets ou à un mélange des deux.
Le serveur avant l'application
L'ordre d'installation n'est pas négociable. Il faut d'abord faire tourner hermes-webui sur macOS, Linux ou Windows/WSL2, avec Python 3.11 ou plus récent, et définir la variable HERMES_WEBUI_PASSWORD. Ensuite seulement vient le problème de la joignabilité depuis le téléphone. Le README annonce environ quinze minutes pour l'ensemble, ce qui paraît optimiste dès que la partie réseau entre en jeu.
Trois chemins sont décrits. Le premier, présenté comme recommandé, passe par un tunnel ou un reverse proxy qui termine un vrai TLS sur un nom de domaine que vous possédez. Cloudflare Tunnel est cité en exemple. L'argument avancé est concret : du HTTPS réel évite d'avoir à déclarer une exception App Transport Security côté iOS. Le README ajoute un avertissement qu'il faut prendre au sérieux : sur un nom d'hôte publiquement joignable, le mot de passe constitue la seule défense au niveau applicatif.
Le deuxième chemin utilise Tailscale Serve pour rester en HTTPS privé. La procédure est plus précise : garder le serveur protégé par mot de passe et lié à 127.0.0.1:8787, inspecter les routes Serve ou Funnel existantes, puis lancer tailscale serve --bg 8787 uniquement si le port 443 en HTTPS à la racine est libre. Il faut ensuite installer Tailscale sur l'iPhone et saisir l'URL https://…ts.net exacte rapportée par tailscale serve status. Le troisième chemin, http://localhost:8787, ne vaut que pour le simulateur sur le même Mac. La liaison directe à 0.0.0.0 en HTTP simple est reléguée au rang de repli manuel, et le README précise qu'elle n'est pas le comportement par défaut.
Les quatre points de contrôle avant d'accuser l'application
La section de dépannage tient en quatre vérifications, ce qui en dit long sur les modes de panne attendus. La machine qui héberge hermes-webui doit être éveillée. Le service doit répondre sur /health, ce que le README propose de tester avec curl https://<your-server>/health. Le tunnel, le reverse proxy ou la route Tailscale doit être connecté. L'URL et le mot de passe doivent être corrects.
Aucun de ces points ne concerne l'application elle-même. C'est la conséquence directe du modèle : la majorité des échecs viendra de l'infrastructure que vous avez montée, pas du client. Un serveur endormi, un certificat expiré ou une route Tailscale tombée produisent la même erreur côté iPhone qu'un mot de passe erroné. Le README ne décrit pas de messages d'erreur distincts pour ces cas, et c'est une lacune : un diagnostic qui dirait explicitement « /health ne répond pas » ferait gagner du temps.
La compilation depuis les sources et ses dépendances de version
Le README décourage la compilation maison sauf pour le développement, et recommande la version de l'App Store. Si vous passez outre, il faut Xcode 26 ou plus récent avec le SDK iOS 18, plus un iPhone ou un simulateur en iOS 18 minimum. Le projet s'ouvre via HermesMobile.xcodeproj, avec le schéma HermesMobile. Attention à la nomenclature : la cible Xcode s'appelle HermesMobile, alors que le nom affiché de l'application est Hermex. Les dépendances sont résolues par Swift Package Manager.
En ligne de commande, le README donne deux invocations. La compilation :
xcodebuild -project HermesMobile.xcodeproj -scheme HermesMobile -destination 'platform=iOS Simulator,name=iPhone 17' build
Et les tests :
xcodebuild test -project HermesMobile.xcodeproj -scheme HermesMobile -destination 'platform=iOS Simulator,name=iPhone 17'
Si le simulateur iPhone 17 n'est pas installé, la commande xcrun simctl list devices available permet de lister les appareils disponibles et d'en choisir un proche. Les utilisateurs de XcodeBuildMCP trouveront des valeurs de validation locales dans .xcodebuildmcp/config.yaml, et le flux standard après modification est décrit dans DEVELOPMENT.md. Le README ne précise pas le nombre de tests ni leur couverture.
Le point de rupture : la compatibilité serveur
C'est la limitation la plus sérieuse du projet, et le README la traite en une phrase. L'application est développée et testée contre le commit de hermes-webui épinglé dans le fichier UPSTREAM_TESTED_SHA. Or le README indique qu'en amont, la stabilité de l'API n'est pas garantie : le projet hermes-webui déclare lui-même que les écarts de version ne sont pas pris en charge, en attendant ses travaux sur une API stable. Le texte fourni s'arrête au milieu du mot « individuelles ».
La conséquence pratique est nette. Une mise à jour de votre serveur peut casser l'application sans qu'aucune version de Hermex n'ait changé. Vous ne pouvez pas traiter le serveur comme une dépendance que l'on met à jour librement. Il faut soit aligner votre commit serveur sur celui épinglé, soit accepter de tester chaque mise à jour amont avant de la déployer. Ce n'est pas un défaut de conception de Hermex, c'est une contrainte héritée d'un projet tiers qui n'a pas encore figé son contrat d'interface. Elle reste réelle pour quiconque exploite le couple en production.
Deuxième limite, moins documentée : le README ne dit rien de la gestion du mot de passe côté appareil. On ignore s'il finit dans le Keychain, dans UserDefaults ou ailleurs. Pour une application qui se présente comme privée, l'absence de cette information dans la documentation publique est un manque.
Face à l'interface web d'origine
L'alternative immédiate est hermes-webui lui-même, ouvert dans Safari sur l'iPhone. Les deux options parlent au même serveur et donnent accès aux mêmes données. La différence tient à la couche cliente.
Une interface web dans un navigateur mobile subit le cycle de vie des onglets : l'état est perdu quand iOS décide de libérer la mémoire, les notifications sont absentes, et l'interruption d'une génération en cours dépend de la façon dont la page gère l'annulation. Hermex exploite les primitives natives de la plateforme, ce qui rend l'interruption et la réorientation d'une exécution plus fiables, et permet la mise en cache des sessions pour une lecture hors ligne. C'est un avantage concret, pas cosmétique.
En échange, vous ajoutez une dépendance : une application tierce à installer, à maintenir à jour, et dont la compatibilité avec votre serveur dépend d'un commit épinglé. L'interface web, elle, évolue avec le serveur par construction. Si vous mettez hermes-webui à jour souvent, le navigateur est le chemin qui casse le moins. Si vous préférez un client stable et une expérience tactile correcte, Hermex est le bon compromis, à condition de geler votre version serveur.
Licence, maintenance et ce que le dépôt ne dit pas
Hermex est publié sous licence MIT, comme hermes-webui d'ailleurs. Une licence permissive de ce type autorise la modification et la redistribution, y compris dans un produit propriétaire, à condition de conserver la notice de copyright et le texte de la licence. Elle n'offre en revanche aucune garantie. Pour une application qui manipule l'accès à votre serveur et à son système de fichiers, c'est un point à intégrer : vous dépendez du mainteneur et de la communauté pour les correctifs. Ce paragraphe décrit la licence, il ne constitue pas un avis juridique.
Le rythme de publication est visible dans les données du dépôt : v1.4.0 le 13 juillet 2026, v1.5.0 le 4 août, v1.6.0 le 6 septembre, pour un dernier push le 10 septembre. Trois versions mineures en deux mois indiquent un projet actif. Cela signifie aussi que l'API interne bouge, et que la surface à maintenir côté serveur reste mouvante.
Le dépôt ne contient aucune indication sur la stratégie de test au-delà des commandes xcodebuild test, ni sur la politique de support des anciennes versions de hermes-webui. Il ne dit rien non plus sur le stockage local des sessions mises en cache, ni sur ce qui est chiffré sur l'appareil. Ces silences ne sont pas des accusations, ce sont des zones que la documentation ne couvre pas et qu'il faudra vérifier dans le code avant de confier l'application à un usage quotidien.
Conclusion éditoriale
Adoptez Hermex si vous faites déjà tourner hermes-webui et voulez le piloter depuis un iPhone sans passer par un relais tiers. Passez votre chemin si vous cherchez une solution complète : le dépôt ne fournit ni serveur, ni hébergement, ni mise en réseau. Avant de vous engager, vérifiez trois choses : que votre commit serveur correspond à celui épinglé dans UPSTREAM_TESTED_SHA, que votre URL expose bien /health, et que votre hébergement HTTPS est stable dans le temps.
Notes de la communauté