La semaine dernière, vous avez terminé un module entier en vol avec un Qwen hébergé localement, hors ligne du début à la fin, et c’était très agréable. Lundi, vous avez ouvert le Webapp pour continuer et vous êtes tombé sur l’accueil familier : « Faisons connaissance… », avec deux boutons en dessous — Nous Portal, et J’ai une clé API.

Votre premier réflexe a été « ma session a expiré » : vous vous êtes reconnecté, vous avez collé une clé, et vous avez perdu dix minutes. La vérité, c’est que votre compte n’avait rien de cassé. Le serveur de modèle local ne tournait simplement pas — l’application de bureau l’arrête à la fermeture, ou il était encore en train de charger un modèle. L’ancienne interface traitait « le modèle n’a pas pu être résolu » et « rien n’est configuré » comme une seule et même chose, et vous envoyait vous connecter.

C’est corrigé, et le correctif vaut le détour : il n’a pas réécrit une phrase, il a transformé la question « quelle est cette panne » en champ structuré.

Une erreur déguisée en une autre

Voilà comment l’ancienne build s’est peinte dans un coin.

Quand le modèle principal est le runtime local géré par Hermes (llama.cpp) et que ce serveur est arrêté, setup.runtime_check du gateway répond ok: false alors que setup.status indique toujours qu’un fournisseur est configuré. Les deux affirmations sont vraies, mais la porte d’entrée de l’assistant (refreshOnboarding) ne lisait que la première : elle traitait chaque ok: false comme « rien de configuré » et ouvrait la fenêtre de connexion au fournisseur.

Puis venait la seconde moitié. Si vous ignoriez tout cela et envoyiez quand même un message, le gateway estampillait l’échec de résolution auth_permanent (échec d’authentification permanent), et le front affichait une carte « Mettre à jour la clé API ». Un simple « le serveur ne tourne pas » se retrouvait déguisé en « votre clé est cassée ».

Une précision, car la méprise est fréquente : l’authentification du Webapp était saine du début à la fin ; le chemin de réauthentification de browser-transport.ts n’a jamais été en cause. Ce que vous voyiez, c’était la fenêtre d’accueil du fournisseur, qui contient justement une phrase sur le modèle local et ressemble donc à un écran de connexion.

Le nouveau code d’erreur : local_runtime_unavailable

Le cœur du correctif, c’est de séparer les deux pannes :

• Un runtime local indisponible lève une nouvelle exception nommée, LocalRuntimeUnavailableError (sous-classe de ValueError, donc les appelants existants continuent de l’attraper), portant le code structuré local_runtime_unavailable.
• La variante « démarré mais pas encore en service » est marquée réessayable. Cette distinction compte : un modèle met du temps à se charger, et vous conseiller de changer de modèle pendant ces quelques secondes serait un mauvais conseil.
• setup.runtime_check place error_code dans sa réponse via un helper partagé. À noter : c’est un champ structuré, pas une chaîne sur laquelle le front fait du pattern matching — les textes changent, les champs non.

Les deux états disent maintenant des choses différentes :

• En cours de démarrage : « Le serveur de modèle local ne tourne pas. Il est peut-être encore en train de démarrer — réessayez dans un instant, ou changez de modèle avec /model. »
• Vraiment arrêté : « Le serveur de modèle local est éteint. Démarrez-le depuis l’application de bureau Hermes ou hermes model → Local models, ou changez de modèle avec /model. »

Bureau et Webapp n’ont pas les mêmes étapes suivantes

Ce détail mérite d’être souligné : le correctif n’a pas paresseusement affiché le même conseil aux deux surfaces.

Où vous êtes	Ce que vous voyez	Ce que vous pouvez faire
Bureau	L’application s’ouvre normalement (configured: true) avec un avis « Modèle local indisponible »	Ouvrir les modèles locaux, directement dans ce panneau de réglages
Webapp	L’application s’ouvre normalement, avec un avis indiquant que le modèle local est indisponible	Choisir un autre modèle (le Webapp n’a pas de panneau Local models — ce panneau est réservé à Electron)

Pourquoi ne pas proposer « ouvrir le panneau des modèles locaux » dans le Webapp ? Parce que ce panneau n’existe pas dans un navigateur, et qu’un bouton qui ne peut pas fonctionner est pire que pas de bouton. Le texte du Webapp ne le mentionne donc volontairement pas et propose un changement de modèle à la place.

La carte d’échec dans le chat a changé aussi

Un tour qui échoue de cette façon remonte maintenant failure_reason=local_runtime_unavailable jusqu’à l’interface, et le titre de la carte passe de « votre clé API a été rejetée » à « Impossible de joindre votre serveur de modèle », avec deux actions :

• Réessayer — pertinent tant que le serveur démarre ;
• Changer de fournisseur — plus rapide quand il n’est simplement pas lancé.

Une phrase que seul un ingénieur pouvait aimer a aussi disparu : l’ancienne build ajoutait « setup.status reports configured credentials, but runtime resolution still failed ». La nouvelle l’omet dès qu’il y a un code à remonter.

Quand vous êtes quand même renvoyé à la connexion

Le correctif ne met pas tout sur le dos du runtime local, et c’est important — sinon il masquerait de vrais problèmes d’identifiants. Vous passez toujours par l’accueil quand :

• il n’y a aucun identifiant utilisable (Nous non connecté, aucune clé configurée) ;
• le fournisseur est un service cloud et sa clé est réellement invalide.

Autrement dit : vous n’êtes dispensé de la connexion que lorsque la panne peut être attribuée au runtime local.

Déboguer soi-même

Si votre modèle local cesse soudain de fonctionner, procédez dans cet ordre :

1. Vérifiez que le serveur tourne. Bureau : Réglages → Fournisseurs → Modèles locaux, et regardez si le modèle apparaît comme actif ; s’il est installé mais arrêté, démarrez-le. En terminal : hermes model → Local models liste le catalogue, démarre le serveur et fait de ce modèle votre choix par défaut.
2. Distinguez « pas démarré » de « en cours de chargement ». Dans les quinze premières secondes après avoir cliqué sur démarrer, les poids migrent encore vers la VRAM, donc réessayer est la bonne attitude. Si une minute passe, allez voir les logs.
3. Changez de modèle et continuez à travailler. /model bascule vers un autre fournisseur configuré dans la session ; notez qu’un changement en cours de session invalide le cache de prompt, ce qui n’est pas gratuit sur une longue conversation.
4. Ne cherchez pas un panneau qui n’existe pas. Si vous ne trouvez pas les réglages Local Models dans le Webapp, c’est normal — c’est réservé au bureau. Depuis le Webapp, changez de modèle, ou revenez à l’application de bureau pour démarrer le serveur.

Peut-on l’utiliser dès maintenant

Le correctif est arrivé sur main le 2026-10-30 (PR #146883, étiquetée type/bug, P2) et figure dans la v0.22.6 (2026-11-02) : avec elle, un serveur local arrêté est signalé comme indisponible au lieu de vous envoyer à l’écran de connexion.

Sur cette build, quand Hermes vous demande soudain de vous connecter, ne relancez pas une réauthentification : vérifiez d’abord si le serveur de modèle local tourne. Cette seule vérification vous fait gagner dix minutes et vous évite de vous acharner à vous connecter sur une machine hors ligne.

Nous avons déjà traité deux autres recoins des modèles locaux : comment Hermes héberge llama.cpp pour vous, et comment savoir ce que votre GPU peut réellement faire tourner. Cet article est le troisième : ce que l’interface vous raconte vraiment quand quelque chose casse.