Vous suivez la voie recommandée par la documentation : vous vous connectez à un compte Nous, ne collez aucune clé API tierce, et vous attendez à ce que la recherche fonctionne tout simplement. Or la première recherche renvoie une erreur disant que votre identité n’a pas les droits. Rien n’est mal configuré et votre compte va bien — la requête n’a jamais quitté votre machine. Elle a été arrêtée par l’une des trois barrières locales, et une seule d’entre elles concerne réellement les droits.

Voici comment la route de recherche rapide gratuite décide qui y a droit, pourquoi elle excluait autrefois les utilisateurs enregistrés, et comment déterminer dans quel cas vous vous trouvez désormais.

Deux types de route, deux questions différentes

Le gateway managé sert deux choses très différentes :

• Les intégrations de fournisseurs facturées (extract, browser, images, etc.). Celles-ci vérifient que vous êtes autorisé — accès Portal payant, ou un tool pool gratuit actif.
• La route search_type: "fast". Le gateway la sert sans aucune vérification de financement, donc sa question d’éligibilité est intrinsèquement qui êtes-vous, et non combien avez-vous payé.

Historiquement, les deux routes passaient par un même résolveur, si bien que la seconde question recevait la réponse de la première règle. C’est là tout le bug.

Les trois barrières, dans l’ordre

Le correctif les parcourt dans l’ordre d’exécution, et cela vaut la peine d’être lu en entier — car si l’une d’elles dit non, vous voyez le même message « pas de droits » :

1. resolve_managed_tool_gateway() appliquait managed_nous_tools_enabled() (accès payant, ou un compte avec un tool pool actif) à chaque fournisseur — Perplexity inclus.
2. _managed_web_search() ne signalait une route managée que lorsque l’autodétection avait abouti à Firecrawl et que la sonde de préparation du gateway, soumise à barrière, réussissait. Une identité sans droits n’était donc jamais résolue vers la recherche Perplexity.
3. Le provider Perplexity rappelait ce même résolveur soumis à barrière. Voilà pourquoi même en écrivant web.backend: nous à la main, on se heurtait au même refus.

Empilées, l’effet était le suivant : créer un compte, voir qu’une route gratuite existe pour vous, et ne jamais pouvoir l’atteindre.

Le correctif : cadrer la route gratuite par l’identité

PR #130660 ne desserre pas la barrière payante. Elle donne à la route gratuite sa propre règle :

• Un nouveau resolve_free_search_gateway() résout purement sur l’identité.
• Le nouveau prédicat fast_search_entitled() accepte une identité Portal enregistrée de n’importe quel tier — aucune exigence de crédit, aucune exigence de tool pool.
• Les fournisseurs facturés continuent de passer par resolve_managed_tool_gateway(), exactement comme avant.

Et les invités ? Délibérément exclus. La route gratuite est délivrée par identité, et le palier d’invité anonyme n’a aucun compte Portal derrière lui. Les invités sont identiques octet pour octet à avant et conservent le keyless ring. Ce n’est pas une porte qui se ferme aux nouveaux venus — c’est « prouvez qui vous êtes et utilisez la route managée ; sinon, utilisez la rotation publique ».

Deux détails méritent d’être isolés :

• Un échec échoue en mode fermé plutôt que de deviner. Une recherche de compte échouée se résout en « non disponible ». La partie contre-intuitive : une recherche échouée est toujours marquée comme connectée, et seul le champ error la distingue d’un vrai compte — ce champ est donc porteur, pas une ceinture et des bretelles.
• La correspondance de tier ne dépend plus de la casse ni des espaces. Le claim de tier arrive tel quel depuis le JWT ou les informations du compte, et il était autrefois comparé littéralement — un seul espace parasite suffisait à fausser le verdict.

Quand elle ne résout pas, le message vous dit dans quel cas vous êtes

Le même changement a transformé « pourquoi ça n’a pas marché » en trois phrases distinctes :

Votre situation	Ce qui vous est dit
Vous êtes le palier invité anonyme	il faut un compte Nous (connectez-vous avec /login)
Il n’y a aucune identité utilisable (déconnecté, ou la recherche a échoué)	il n’y a aucune identité Nous utilisable (connectez-vous avec /login)
Le gateway est injoignable	le Nous Tool Gateway est injoignable

Elles sont distinctes à dessein, car elles correspondent à trois actions différentes : se connecter pour les deux premières, et traiter la troisième comme un problème réseau ou de service qu’aucune quantité de connexions ne résoudra.

Comment vérifier sur votre propre machine

• Assurez-vous de ne pas avoir explicitement pin un autre fournisseur de recherche. Une fois que web.backend ou web.search_backend nomme un fournisseur concret, c’est votre choix et il n’est jamais redirigé — c’est un compromis délibéré. Les clés sont documentées dans la référence de configuration hermes.
• Séparez la recherche de l’extract. Sous web.backend: nous, la recherche est servie par le gateway Perplexity managé tandis que l’extract passe toujours par Firecrawl ; la route gratuite est réservée à la recherche, et toute autre route de fournisseur conserve son exigence de droits.
• Vous n’êtes pas obligé de vous connecter. La rotation publique sans clé reste disponible pour les invités — voir les cinq canaux de recherche gratuits et le guide du palier gratuit sans clé API ; si vous préférez apporter votre propre clé, c’est traité dans le backend de recherche Perplexity.
• Vérifiez sur quelle build vous êtes. Le correctif a été fusionné dans main le 2026-10-01, et le tag le plus récent (v0.21.5) date du 9-24, il n’y est donc pas encore. Les installations Git qui suivent main l’ont déjà.

En résumé

Ce n’était pas une fonctionnalité manquante. C’était une éligibilité jugée sur la mauvaise dimension : une route qui ne vérifie jamais votre solde était bloquée par une logique qui, elle, le fait, et les trois barrières rapportaient la même phrase — vous ne pouviez donc voir que « pas de droits », jamais « vous n’auriez jamais dû avoir besoin de droits ».

La leçon pratique est simple. Si la recherche vous refuse juste après la connexion, n’allez pas auditer vos crédits : vérifiez d’abord si vous avez pin web.backend sur un autre fournisseur, puis lisez quel problème d’identité le message nomme réellement. Mettez l’identité au bon endroit et la recherche rapide gratuite est tout simplement gratuite.