Aller au contenu
Commencer
Commencer
English
Pages de la documentation

Fournisseurs

Les modèles, services de parole et canaux avec lesquels Nestor fonctionne aujourd’hui, ce qui est prévu, et comment régler chacun.

Nestor a besoin d’un modèle de langage pour l’agent, et de services de parole seulement pour parler à voix haute. On le joint par des canaux : Telegram, les satellites (par écrit, à voix haute ou les deux), ou tous. Tout se règle dans nestor.yaml, avec les clés dans le .env posé à côté. nestor init demande le serveur de modèle et le modèle, et écrit les satellites avec Telegram, ou les satellites avec leur voix sur ElevenLabs quand l’extra voice est installé. Pour changer de fournisseur ensuite, collez ses blocs ci-dessous à la place des blocs correspondants, puis lancez nestor check.

Modèle de langage

L’agent parle à tout serveur qui expose l’API Chat Completions d’OpenAI, en streaming. L’adaptateur est testé avec OpenRouter ; les autres parlent la même API et devraient fonctionner. Choisissez un modèle qui gère les appels d’outils : c’est par eux que l’agent agit.

La clé du modèle est MODEL_API_KEY, dans .env, quel que soit le fournisseur. Les serveurs locaux n’en demandent pas : laissez-la vide. OpenRouter, OpenAI, Mistral et Anthropic refusent une clé vide, et nestor check nomme la variable à remplir.

Une seule clé pour les modèles de nombreux éditeurs, Claude et Gemini compris. C’est le choix par défaut, et celui avec lequel l’adaptateur est testé.

MODEL_API_KEY=sk-or-...
model:
  kind: openai-compatible
  base_url: https://openrouter.ai/api/v1
  api_key: ${MODEL_API_KEY}
  model: anthropic/claude-haiku-5.5

Les noms de modèles sont des exemples : tout modèle du catalogue du fournisseur qui gère les appels d’outils convient, et tout autre hébergeur compatible OpenAI se règle de la même façon. Sur la plupart des machines domestiques, un modèle local répond plus lentement qu’un modèle hébergé, et c’est la parole qui le ressent en premier.

Avec Docker, localhost désigne le conteneur lui-même. Un serveur de modèle qui tourne sur l’hôte est à l’adresse http://host.docker.internal:<port>/v1 : http://host.docker.internal:11434/v1 pour Ollama, http://host.docker.internal:1234/v1 pour LM Studio. Sous Linux, cette adresse n’est pas la boucle locale de l’hôte : le serveur de modèle doit donc écouter au-delà (OLLAMA_HOST=0.0.0.0 pour Ollama, --host 0.0.0.0 pour llama.cpp).

model accepte aussi extra_body, fusionné dans chaque requête (routage d’OpenRouter, réglages de raisonnement…), connect_timeout_s (5) et read_timeout_s (30). Un triage_model avec les mêmes clés confie le tri des éléments entrants à un modèle plus petit.

Parole

La voix des satellites transcrit la personne et dit la réponse. ElevenLabs est aujourd’hui le seul fournisseur, pour les deux ; un autre ne sera ajouté qu’après avoir tenu sur des mesures reproductibles (latence, fins de tour, interruptions).

Scribe v2 Realtime transcrit, v4 Turbo parle ; une seule clé couvre les deux.

ELEVENLABS_API_KEY=sk_...
channels:
  - kind: satellites
    host: 0.0.0.0
    voice:
      speech:
        api_key: ${ELEVENLABS_API_KEY}
        voice_id: GPAQQPp9dazaB2bl4zg9

voice_id est n’importe quelle voix de votre bibliothèque ElevenLabs. La voix suit la langue du texte ; la transcription attend de l’anglais, sauf si speech fixe une autre language (voir plus bas).

Canaux

Chaque canal est une entrée de channels, et plusieurs peuvent tourner ensemble, avec la même mémoire. Telegram et les satellites sont livrés avec le paquet. Les satellites parlent par écrit sans rien de plus ; leur voix est l’extra voice (voir Installer), avec les services de parole ci-dessus.

Créez un bot avec @BotFather sur Telegram et mettez son jeton dans .env :

TELEGRAM_BOT_TOKEN=123456:ABC-...
channels:
  - kind: telegram
    token: ${TELEGRAM_BOT_TOKEN}

Ajoutez "telegram:<votre chat id>" à vos accounts dans household pour que le bot vous reconnaisse. Il lit les messages texte ; les messages vocaux et les photos sont ignorés.

En français

nestor init demande la langue du foyer. Sans réglage, Nestor parle anglais, à l’heure UTC. Pour passer une configuration existante en français, réglez la locale de la persona (les phrases fixes et l’administration), la language dans laquelle écrit le modèle, le fuseau timezone du foyer et, avec la voix des satellites, la language de la transcription :

persona:
  locale: fr
  language: French
  timezone: Europe/Paris

channels:
  - kind: satellites
    voice:
      speech:
        language: fr

Où ranger les clés

  • .env, à côté de nestor.yaml, appelé par ${NOM} : ce qu’écrit nestor init et ce qu’utilisent les blocs ci-dessus. Nestor le relit à chaque démarrage. Une variable déjà définie dans l’environnement (le shell, un gestionnaire de services, Docker) l’emporte sur le fichier.
  • Le coffre, chiffré dans le dossier de données, appelé par ${secret:nom} : réglé avec nestor secrets set <nom> (saisi sans écho) ou depuis l’administration, listé avec nestor secrets list. Mieux vaut y passer une fois l’installation stabilisée : aucune clé ne reste en clair sur le disque, et l’administration peut les changer.
nestor secrets set openrouter   # puis, dans nestor.yaml : api_key: ${secret:openrouter}

NESTOR_SECRET_KEY, dans .env, ouvre le coffre. nestor init le génère : ne le changez jamais, sinon les secrets déjà rangés deviennent illisibles. Redémarrez Nestor après avoir changé une clé.