Si tu as déjà installé un agent auto-hébergé pour quelqu'un, tu as vu la scène suivante au ralenti, au moins une fois.
Un ami te demande comment faire de la recherche web avec Hermes. Tu lui expliques : inscris-toi chez Firecrawl, va chercher la clé d'API dans le tableau de bord, colle-la dans .env, lance hermes tools, coche la case. Il le fait. Ça marche. Deux jours plus tard, il veut de la génération d'images. Tu lui expliques : inscris-toi chez FAL, va chercher la clé d'API dans le tableau de bord, colle-la dans .env, lance hermes tools, coche la case. Il commence à fatiguer. La fois suivante, quand il a besoin de TTS, il ne demande plus.
L'impôt de friction d'un agent auto-hébergé n'a rien à voir avec l'agent. C'est la danse des clés par outil, le tableau de bord par outil, le calendrier de renouvellement par outil. Le 16 avril 2026 — trois jours après v0.9.0 — v0.10.0 en a taillé un morceau pour toute personne ayant un abonnement Nous Portal.
La release est petite en nombre de lignes — autour de 180 commits sur trois jours. Mais la fonctionnalité qui atterrit ces trois jours-là, c'est celle pour laquelle on retiendra v0.10 : la Nous Tool Gateway.
Ce que veut vraiment dire « outil managé »
La Nous Tool Gateway est un multiplexeur côté serveur. L'agent sur ta machine continue d'appeler web_search ou generate_image exactement comme avant. Ce qui change, c'est que l'appel atterrit maintenant sur la gateway de Nous, qui détient la clé d'API en amont et la facture à ton abonnement portal, pas à toi.
La première vague, ce sont quatre outils, repris mot pour mot des release notes :
- •Recherche web via Firecrawl
- •Génération d'images via FAL avec le modèle FLUX 2 Pro
- •Synthèse vocale via OpenAI TTS
- •Automatisation navigateur via Browser Use
Ce ne sont pas de nouveaux outils. Ce sont les outils que tu as toujours pu câbler toi-même, avec quatre comptes séparés et quatre lignes .env séparées. Ce que v0.10.0 change, c'est que tu n'es plus obligé de le faire.
Tu actives la gateway outil par outil via les nouveaux réglages use_gateway exposés par hermes model. Si tu as déjà une clé d'API directe configurée pour un outil, le runtime préfère encore la directe — la gateway, c'est un filet de secours, pas une mainmise. Le choix se fait à la granularité d'un outil individuel, pas de l'installation entière.
La variable d'environnement morte en sortant
Si tu venais de la ligne v0.8/v0.9, tu te souviens probablement de HERMES_ENABLE_NOUS_MANAGED_TOOLS. v0.10.0 la supprime. C'est l'abonnement lui-même qui sert maintenant de signal : tu te connectes au portal, la gateway s'allume, les outils fonctionnent. Pas de toggle à retenir, pas de ligne .env à synchroniser entre machines.
hermes tools et hermes status sont devenus tous les deux conscients de la gateway dans cette release. Le premier te dit d'un coup d'œil quels outils sont directs, quels sont managés, quels sont coupés ; le second confirme la connexion à la gateway elle-même. Deux petites commandes, mais elles écrasent la question « qui pousse quoi, là, maintenant ? » sur une seule ligne de sortie.
Pourquoi c'est plus gros que ça en a l'air
L'impôt de friction dont je parle plus haut n'apparaît dans aucun benchmark. Personne n'a tracé un graphique « minutes perdues à monter Firecrawl pour un ami ». Mais toute personne qui fait tourner un agent auto-hébergé le paie, et la plupart finissent par laisser tomber le cinquième ou le sixième outil, parce que la gêne marginale dépasse le bénéfice marginal.
Pour un amateur, l'impôt est juste agaçant. Pour une petite équipe qui fait tourner Hermes sur un VPS partagé, l'impôt devient une question de propriété : qui est la personne nommée à qui appartient la facture Firecrawl, et qu'est-ce qui arrive à la recherche web quand elle quitte la boîte ?
La gateway aplatit toute cette surface. Un abonnement, quatre outils, un seul endroit où la facturation se gère. C'est le même deal que le jour où tu glisses ta base de données derrière un service managé — tu rends un peu de contrôle et tu récupères un dimanche après-midi.
Il y a un prix, et les release notes ne le maquillent pas. Passer par la gateway, c'est passer par Nous, et donc Nous voit des métadonnées de requête qu'il ne voyait pas avant. C'est précisément pour cela que la gateway est opt-in par outil : l'accord n'est pas inconditionnel. Si tu ne la veux pas pour un outil donné, ta clé d'API directe est toujours là, et le runtime continue de l'utiliser. Le point clé, c'est que c'est maintenant un choix que tu fais, et plus un cercle qu'il faut franchir pour avoir le droit de commencer à choisir.
Le reste, en bref
v0.10.0, c'est une release centrée sur la tool gateway. Pas de réécriture du TUI ici — celle-là arrive en v0.11.0. Pas de nouvelle plateforme de chat non plus — la vague reprend en v0.12.0. Mais il y a quand même 180+ commits qui traversent le cœur de l'agent, la gateway, le CLI et l'infra des outils. Le diff complet entre v2026.4.13 et v2026.4.16 est sur GitHub si tu veux lire ligne par ligne.
La cadence avance. Trois jours après v0.9.0, une nouvelle fonctionnalité majeure, une deprecation rangée en douce pendant que personne ne regardait.
---
Ce qui me fascine dans v0.10.0, c'est à quel point elle est petite en lignes de code par rapport à ce qu'elle change pour la question « qui peut faire tourner Hermes ». v0.9.0 avait ajouté trois plateformes. v0.10.0 n'en ajoute aucune — mais elle baisse assez le coût de faire tourner les outils que tu avais déjà pour faire revenir toute une classe d'utilisateurs « j'ai laissé tomber parce que c'était trop de clés à gérer ».
Si on déplie le calendrier des releases de cette période, un motif apparaît : la moitié des versions empile des capacités, l'autre moitié rabote la friction. v0.10.0 tombe sans ambiguïté du côté friction. v0.12.0, dans deux semaines, sera du même côté — c'est là qu'arrive l'Autonomous Curator pour élaguer ta bibliothèque de skills pendant que tu dors. La cadence fait paraître ce projet rapide. La forme — semaine de capacité, semaine de friction, semaine de capacité — la rend soutenable.