Vous confiez Hermes à un collègue. Il installe l’application desktop, l’ouvre et pose la question évidente : « et je clique sur quoi, d’abord ? » Avant même de pouvoir dire bonjour, il lui faut un compte, une clé API, une page de réglages et un modèle à choisir. L’autre version de cette scène, c’est vous sur une machine neuve, vingt minutes dans la configuration, qui abandonnez pour la soirée. La v0.22.0 (tag v0.22.0, sortie le 13 octobre 2026) s’attaque à tout ce seuil — tout ce qui sépare « je viens de l’installer » de « il a fait quelque chose d’utile ».

C’est aussi la plus grande fenêtre jamais livrée par ce projet : environ 24 200 commits, ~6 080 PR fusionnées et ~15 600 fichiers modifiés depuis la v0.21.0, avec près de 2 520 contributeurs et ~7 180 issues fermées — environ 2,5x le cycle précédent — et elle regroupe et documente les releases correctives v0.21.1–v0.21.7. Voici ce qui change réellement votre façon de vous en servir.

Le premier lancement est une conversation

Ouvrez l’application desktop sur un ordinateur où Hermes n’a jamais tourné et vous obtenez un court chat de configuration guidé au lieu d’un écran de réglages. Une carte à la fois, il demande votre nom, une couleur d’accent et une disposition, quelles applications connecter et quels plugins installer ; puis il offre une visite rapide et aligne jusqu’à quatre premières tâches pour vous. Il tourne sur un modèle d’essai gratuit, nous/welcome (une fois par utilisateur de l’OS), donc aucune clé API n’est nécessaire : un nouveau venu parle à l’agent avant d’avoir payé quoi que ce soit. Skip setup l’interrompt, et Settings → Run onboarding again le ramène. L’agent a aussi gagné un outil set_theme, donc « mets-le en violet, mode sombre » fonctionne vraiment dans n’importe quel chat desktop. Il n’apparaît que sur les installations neuves — les backends distants (SSH, URL, Cloud) ne l’obtiennent pas automatiquement (le parcours d’onboarding).

Les Connectors font entrer l’agent dans vos applications

Un agent qui ne peut agir que dans sa propre fenêtre de chat fait de vous l’intégration : vous copiez le ticket dans la conversation, puis vous recopiez la réponse. À travers le tool gateway de Nous, Hermes peut désormais agir dans des applications hébergées comme Linear et Notion — nommez l’application voulue, connectez-vous une fois dans votre navigateur, et ses outils sont utilisables dans le même tour. Vous n’avez pas besoin d’un compte Nous pour commencer : la première fois que vous utilisez une application, Hermes crée une identité gratuite limitée aux connectors. Le desktop a gagné une page Connectors qui liste ensemble les applications hébergées et vos serveurs MCP (elle remplace l’onglet MCP), le TUI et le CLI affichent la même carte de configuration, et vous pouvez connecter plusieurs comptes nommés d’une même application — par exemple un compte work et un compte home.

Des modèles locaux sans se battre avec l’outillage

Si votre raison de vouloir un modèle local est que rien ne doit quitter la machine, cette release élimine l’essentiel du travail. Hermes installe et maintient llama.cpp avec le moteur adapté à votre matériel (CPU, CUDA, Metal, Vulkan ou ROCm), évalue chaque modèle du catalogue par rapport à votre GPU et à votre RAM, et choisit la meilleure build qui tient réellement. Les téléchargements se mettent en pause et reprennent, le serveur démarre et s’arrête avec Hermes, et les mises à jour du moteur se font en un clic. Partez de Settings → Providers → Local Models, ou de hermes model → Local models. Le catalogue inclut Qwen3.8 27B, Qwen3.8 Flash Next avec sa tête spéculative MTP, Qwen3.6 35B-A3B et DeepSeek V4 Flash, plus n’importe quel GGUF de Hugging Face. Les recommandations se sont aussi durcies : seuls les modèles qui tiennent entièrement en mémoire GPU sont suggérés désormais.

Les mises à jour suivent des releases testées, et hermes pm prend en charge la toolchain

Une installation depuis les sources suivait auparavant chaque commit de main. Elle suit désormais des releases stables SemVer testées : chaque release passe le CI source, Docker, Nix, les builds desktop signés et les exécutions d’installation et de mise à niveau sur chaque OS avant d’être publiée. Vous préférez le tout dernier commit ? hermes update --set-channel main, ou le sélecteur de canal dans Settings → About. Revenir à une release plus ancienne est étiqueté comme un rollback et n’arrive jamais sans demander.

En dessous, un gestionnaire de paquets unifié (hermes pm) prend en charge chaque outil épinglé et vérifié par hash ainsi que les environnements Python, avec hermes pm doctor|status|repair|gc. Il corrige un ancien mode de défaillance bien précis : une mise à jour construit un nouvel environnement et ne bascule qu’une fois sa vérification passée, donc une mise à jour échouée ou tuée ne peut pas vous laisser à moitié appliqué — une mise à jour tuée se répare elle-même au lancement suivant. Les environnements de dépendances sont des générations, et les anciennes sont récupérables : 92 GB à 18 GB sur un hôte.

Des paquets signés, et le Microsoft Store

L’application desktop est désormais un paquet scellé et signé qui embarque son propre Python et son propre Node et se met à jour elle-même, si bien que le premier lancement ne compile rien. Windows reçoit un MSIX signé (x64 et ARM64) via App Installer ou le Microsoft Store ; macOS reçoit une build Apple Silicon signée et notariée. Deux bords à connaître : le desktop Windows est MSIX uniquement et nécessite Windows 11 22H2 ou plus récent, et les builds macOS par défaut sont réservées à Apple Silicon. Si vous avez repoussé le passage parce que votre installation était un tas de dépendances non packagées, c’est la version pour réinstaller proprement.

La vague de modèles, et un raisonnement qui survit

Claude Fable 5.1, Opus 5.5, Sonnet 5.5 et Haiku 5.5, GPT-6 Astra / Sol / Luna plus GPT-6.1 Sol, et Gemini 4 Argon sont tous sélectionnables sur Nous Portal, OpenRouter et les routes natives là où elles sont proposées. Le changement le plus pratique est que le raisonnement antérieur est rejoué par défaut sur chaque provider capable de le lire, à travers la reprise, les branches et la compaction, si bien qu’une longue tâche en plusieurs étapes conserve son fil de raisonnement au lieu de le redériver. Et quand un provider passe une mauvaise heure, Hermes attend la fin des 503/529/timeouts transitoires en cycles visibles et bornés plutôt que de terminer votre tour.

Le sélecteur s’est aussi mis au courant de vos forfaits : marquez vos favoris d’une étoile, voyez un abonnement qui s’épuise (« 17 % restants · réinitialisation à 15 h 00 ») et le moment où une limite de débit se lève, et choisissez l’effort de raisonnement au moment de sélectionner un modèle (/model X --reasoning high).

Le reste de la colonne vertébrale

• Connectez-vous aux sites avec votre gestionnaire de mots de passe — 1Password, Bitwarden ou le coffre chiffré de Hermes remplissent les identifiants sans que le mot de passe entre jamais dans le contexte du modèle ; les codes à usage unique sont saisis automatiquement, et les remplissages de carte au paiement attendent votre confirmation (le parcours de connexion).
• Bot Screen — un bot sur un gateway Linux peut avoir son propre desktop, diffusé en direct vers Hermes Desktop ; quand il tombe sur un login, un 2FA ou un CAPTCHA, vous prenez l’écran, terminez l’étape, puis rendez le contrôle.
• Un seul gateway et un seul backend pour chaque profile — au lieu d’un processus par profile, une machine exécute un gateway de messagerie et un backend desktop qui les servent tous ; les bots des nouveaux profiles deviennent actifs sans redémarrage et conservent leurs propres identifiants, allowlists, tâches cron et sessions.
• Des subagents que vous pilotez en direct — le CLI (F6), le TUI (Ctrl+T) et le Desktop affichent au-dessus du composer la tâche de chaque enfant, le temps écoulé et le transcript en direct, avec Steer et Stop ; /stop atteint les enfants en arrière-plan et récupère leur travail partiel.
• Un seul catalogue de traduction — les chaînes du CLI, du gateway, du TUI et du Desktop le partagent, de nouvelles langues arrivent sous forme de plugins, et n’importe quel profile peut remplacer des chaînes individuelles avec un petit fichier YAML (le guide des language packs).
• Une codebase d’un tiers plus petite — de 1,06 M de lignes à 698 K (−34 %), et gateway/run.py de 34 847 lignes à 5 512 ; environ 19 outils rarement utilisés ne se chargent plus que lorsque l’agent les cherche, ce qui divise à peu près par deux le schéma d’outils desktop envoyé à chaque appel.
• Un catalogue de 600 plugins — chaque entrée épinglée à un commit vérifié, parcourable par catégorie et par étoiles, avec une page par plugin et par auteur ; les providers de mémoire ont quitté le cœur pour rejoindre leurs créateurs et se migrent automatiquement.

Trois choses à savoir avant de mettre à niveau

Premièrement, les chats ne se réinitialisent plus sur un minuteur d’inactivité ou quotidien : les modes idle/daily de session_reset sont retirés, et seuls /new ou /reset repartent de zéro. Deuxièmement, les anciennes sessions sont élaguées automatiquement : sessions.auto_prune est activé par défaut et supprime au démarrage les sessions terminées inactives depuis 90 jours — les sessions épinglées et ouvertes ne sont jamais touchées, et sessions.auto_prune: false conserve tout. Troisièmement, pour les auteurs de plugins : l’ancienne couche d’import de compatibilité, hermes sync et le scanner tirith intégré ont disparu, et todo, cronjob et process sont devenus todo_list, cronjob_manage et process_manage (les anciens noms fonctionnent toujours).

Mise à niveau

hermes update

Les installations gérées obtiennent un runtime Python 3.14 (KittenTTS n’est pas disponible sur 3.14). Après la mise à niveau, lancez hermes doctor pour vérifier l’installation et redémarrez le gateway (hermes gateway) afin que les changements de plateforme prennent effet. Pour voir ce que la prochaine mise à jour touchera avant de la lancer, utilisez hermes update --plan ; le journal des modifications groupé complet se trouve sur la page de cette release.