Un assistant IA qui connaît vos entités Home Assistant, répond à vos questions sur votre consommation électrique, déclenche vos automatisations à la voix, et ne transmet aucune donnée à l'extérieur de votre réseau local : c'est exactement ce que permet la combinaison Ollama + Home Assistant. Pas d'abonnement OpenAI. Pas de nabu Casa pour l'IA. Pas de cloud. Le modèle tourne sur votre machine, les données restent chez vous.

Ce guide couvre l'intégralité de la mise en place : prérequis matériel, installation d'Ollama, choix du modèle selon votre hardware, intégration native dans Home Assistant, personnalisation via Jinja2, pipeline voix 100 % local avec Whisper et Piper, et automatisations structurées via AI Task. Chaque section est accompagnée de configurations YAML concrètes et testées.

Pourquoi coupler Ollama à Home Assistant

La question mérite d'être posée frontalement, parce que des alternatives existent : OpenAI GPT-4o mini coûte une fraction de centime par requête, Google Gemini Flash est quasi gratuit, et les deux s'intègrent en quelques clics dans Home Assistant. Pourquoi se compliquer la vie avec un LLM local ?

Vie privée : ce que vous dites à votre maison reste chez vous

Quand vous demandez à ChatGPT "Allume le chauffage de la chambre, il fait froid ce soir", vous envoyez à OpenAI la confirmation que vous êtes chez vous, dans quelle pièce, à quelle heure, et potentiellement des données sur vos capteurs de température. Avec Ollama en local, cette requête ne sort jamais de votre réseau. Vos habitudes, vos présences, vos routines de sommeil et vos données de consommation restent sur votre infrastructure.

Ce n'est pas de la paranoïa. Les politiques de rétention des données varient selon les fournisseurs et changent dans le temps. Avec un LLM local, le problème ne se pose tout simplement pas.

Zéro abonnement, zéro dépendance

OpenAI peut modifier ses tarifs, ses modèles disponibles, ses limites de débit ou sa politique d'utilisation. Un fournisseur cloud peut fermer. Avec Ollama, votre assistant IA dépend uniquement de votre matériel. Une fois installé, il fonctionne sans connexion internet, pendant une panne réseau, et sans coût récurrent.

Pour les automatisations critiques (chauffage, sécurité, volets), cette indépendance n'est pas anecdotique. Home Assistant est pensé local-first, et il est cohérent d'étendre cette philosophie à la couche IA.

Contrôle total : les modèles que vous choisissez

Avec un LLM cloud, vous utilisez ce que le fournisseur vous donne. Avec Ollama, vous choisissez le modèle adapté à votre cas d'usage : un modèle spécialisé domotique comme home-3b-v2, un modèle multilingue, un modèle optimisé pour le raisonnement structuré. Vous pouvez faire tourner plusieurs modèles et basculer selon le contexte.

Prérequis matériel : quelle machine pour Ollama en local ?

C'est le point le plus souvent sous-estimé. Ollama fonctionne sur n'importe quel Linux, macOS ou Windows, mais la qualité d'expérience dépend directement du matériel. Un modèle qui met 45 secondes à répondre n'est pas utilisable au quotidien dans Home Assistant.

La RAM : le facteur limitant principal

Les LLM fonctionnent majoritairement en RAM (ou VRAM pour les GPU). La règle pratique : le modèle doit tenir entièrement en mémoire pour que les réponses soient fluides. Un modèle quantifié en Q4 (4 bits) occupe environ 0,6 Go par milliard de paramètres.

  • 8 Go RAM — modèles jusqu'à 7B (Mistral 7B, Llama 3.2 3B confortable). Résultats corrects, latence 3-8 secondes par réponse.
  • 16 Go RAM — modèles jusqu'à 13B. Llama 3.2 3B en Q8 ou Qwen3 8B. Latence 2-4 secondes. C'est le sweet spot pour une utilisation quotidienne.
  • 32 Go RAM — modèles 13B-34B confortablement, 70B possible en Q2. Réponses en moins d'une seconde sur les petits modèles.

Si votre Home Assistant tourne sur un Raspberry Pi 4 avec 4 Go de RAM, Ollama ne pourra pas y tourner confortablement. Il vous faut soit une machine dédiée, soit un mini PC suffisamment doté.

CPU vs GPU : une question de budget

Ollama peut utiliser un GPU NVIDIA (CUDA), AMD (ROCm) ou Apple Silicon (Metal) pour accélérer drastiquement l'inférence. Sur GPU, les temps de réponse passent de 3-8 secondes à moins d'une seconde pour les petits modèles. Mais un mini PC avec GPU dédié coûte significativement plus cher.

Pour un usage Home Assistant avec des requêtes ponctuelles (une question toutes les quelques minutes au maximum), le CPU suffit largement. Un mini PC Intel N150 ou N100 avec 16 Go de RAM fait tourner Llama 3.2 3B en 3-5 secondes par réponse — tout à fait acceptable pour des automatisations.

Machine recommandée : mini PC Intel N150 16 Go

Le profil idéal pour une installation dédiée ou partagée avec d'autres services (Frigate, Proxmox, services Docker) : un mini PC Intel N150 avec 16 Go DDR4. L'Intel N150 est un quad-core Alder Lake N avec 6W TDP — il tourne en silence, consomme peu et offre suffisamment de puissance pour Ollama + Home Assistant + quelques services supplémentaires.

Meilleur choix
Beelink Mini S13

Beelink Mini S13

Intel N150 · 16 Go DDR4 · 500 Go NVMe · 8-12W

Voir sur Amazon Livraison Prime

Si votre Home Assistant tourne déjà sur Proxmox, vous pouvez simplement dédier une VM avec 8-12 Go de RAM à Ollama sur la même machine physique. Le guide installation Home Assistant sur Proxmox 9 couvre la configuration de base.

Installer Ollama : bare metal Linux, Docker, add-on HAOS

Trois méthodes existent selon votre infrastructure. Chacune a ses avantages.

Méthode 1 : installation bare metal sur Linux (recommandée)

C'est la méthode la plus simple et celle qui offre les meilleures performances. Elle convient si vous avez une machine Linux dédiée ou si votre Home Assistant tourne sur un serveur Linux (Debian, Ubuntu, Fedora).

# Installation en une ligne — script officiel Ollama
curl -fsSL https://ollama.com/install.sh | sh

# Vérifier que le service systemd est actif
systemctl status ollama

# Télécharger votre premier modèle
ollama pull llama3.2:3b

# Tester
ollama run llama3.2:3b "Bonjour, réponds en français"

Par défaut, Ollama écoute uniquement sur 127.0.0.1:11434. Pour que Home Assistant puisse y accéder depuis une autre machine, il faut exposer l'API sur le réseau local.

# Modifier le service systemd pour exposer sur le LAN
sudo systemctl edit ollama

# Dans l'éditeur, ajouter :
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

# Redémarrer
sudo systemctl daemon-reload
sudo systemctl restart ollama

# Vérifier depuis une autre machine
curl http://192.168.1.XXX:11434/api/tags

Remplacez 192.168.1.XXX par l'IP fixe de votre serveur. Pensez à configurer une IP statique pour cette machine dans votre routeur ou via /etc/network/interfaces.

Méthode 2 : Docker Compose

Adaptée si vous gérez déjà des services en Docker sur votre infrastructure. Avantage : isolation propre, mise à jour simplifiée.

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    ports:
      - "11434:11434"
    volumes:
      - ollama_data:/root/.ollama
    environment:
      - OLLAMA_HOST=0.0.0.0

volumes:
  ollama_data:

docker compose up -d
docker exec ollama ollama pull llama3.2:3b

Pour utiliser un GPU NVIDIA avec Docker, ajoutez le bloc deploy.resources.reservations et installez le nvidia-container-toolkit sur l'hôte :

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    ports:
      - "11434:11434"
    volumes:
      - ollama_data:/root/.ollama
    environment:
      - OLLAMA_HOST=0.0.0.0
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

volumes:
  ollama_data:

Méthode 3 : add-on HAOS (Home Assistant OS)

Si vous utilisez Home Assistant OS (HAOS) sur un appareil dédié (Home Assistant Green, Yellow, Raspberry Pi), vous pouvez installer Ollama via le store d'add-ons. C'est la méthode la plus simple, mais aussi la plus limitée : les performances dépendent du hardware de l'appareil HA, et les gros modèles ne tournent pas sur un RPi 4.

Dans l'interface HA : Paramètres → Add-ons → Store d'add-ons, cherchez "Ollama". Il n'existe pas d'add-on officiel Nabu Casa pour Ollama — vous trouverez des add-ons communautaires tiers (vérifiez les étoiles et la date de mise à jour). Après installation, configurez le port et téléchargez le modèle depuis l'onglet Configuration.

Pour les installations HAOS sur matériel dédié puissant (NUC, mini PC), cette méthode est très pratique. Pour les installations partagées avec d'autres services, la méthode bare metal ou Docker est préférable.

Choisir son modèle : comparatif 2026

Le choix du modèle est critique. Un modèle trop lourd donne des réponses lentes qui frustrent à l'usage quotidien. Un modèle trop petit rate les nuances de vos requêtes. Voici un comparatif pragmatique des modèles adaptés à une utilisation Home Assistant en 2026.

Llama 3.2 3B — le polyvalent recommandé

ollama pull llama3.2:3b

Le meilleur point d'entrée pour la domotique locale. 3 milliards de paramètres, environ 2 Go en RAM en Q4. Il comprend le français sans configuration particulière, suit correctement les instructions complexes et gère bien le contexte des entités Home Assistant. Sur un N150 avec 16 Go, les réponses arrivent en 2-4 secondes.

Limites : raisonnement mathématique complexe perfectible, contexte long (conversations de 10+ tours) parfois moins précis.

Mistral 7B — équilibre qualité/vitesse sur 8 Go RAM

ollama pull mistral:7b-instruct-q4_K_M

Développé par la société française Mistral AI, ce modèle excelle en français et offre un excellent rapport qualité/vitesse sur 8 Go de RAM (version Q4). La version q4_K_M (quantification mixte 4 bits) est le meilleur compromis entre taille et qualité de réponse.

Idéal si votre infrastructure est un peu juste en RAM et que vous avez des échanges complexes en français. Légèrement plus lent que Llama 3.2 3B sur CPU.

Qwen3 8B — le meilleur raisonnement structuré

ollama pull qwen3:8b

La série Qwen3 d'Alibaba a fait une percée remarquable en 2025-2026. Le modèle 7B surpasse les 7B classiques sur les tâches de raisonnement structuré, ce qui est précieux pour les automatisations HA qui demandent d'analyser plusieurs entités et de prendre des décisions conditionnelles. Bon support du français. Requiert 8 Go de RAM confortablement.

Particulièrement recommandé si vous souhaitez utiliser les AI Task de Home Assistant 2025.7+ (voir plus loin).

home-3b-v2 — spécialisé domotique

ollama pull fixt/home-3b-v2:latest

Un modèle affiné spécifiquement pour Home Assistant par la communauté. Basé sur Phi-2, il est entraîné sur des milliers de conversations domotique en anglais et optimisé pour la reconnaissance et la manipulation d'entités HA. Très léger (2 Go environ), réponses rapides, mais moins polyvalent pour les questions générales et le français moins naturel.

Parfait si vous voulez uniquement piloter votre installation HA à la voix et que vous acceptez de travailler principalement en anglais.

Tableau récapitulatif

  • llama3.2:3b — RAM : 2 Go, Français : excellent, Vitesse (N150) : 2-4s, Usage : polyvalent, recommandé par défaut
  • mistral:7b-instruct-q4_K_M — RAM : ~5 Go, Français : excellent, Vitesse (N150) : 4-8s, Usage : texte riche en FR
  • qwen3:8b — RAM : 5,2 Go, Français : bon, Vitesse (N150) : 5-9s, Usage : raisonnement structuré, AI Task
  • fixt/home-3b-v2 — RAM : 2 Go, Français : moyen, Vitesse (N150) : 2-3s, Usage : contrôle HA pur, anglais

Connecter Ollama à Home Assistant : intégration native

Depuis Home Assistant 2024.4, l'intégration Ollama est incluse dans le cœur de HA. Pas besoin de HACS, pas de configuration YAML complexe.

Ajouter l'intégration

Dans HA : Paramètres → Appareils et services → Ajouter une intégration, cherchez "Ollama". Vous aurez besoin de :

  • L'URL de l'API Ollama : http://192.168.1.XXX:11434 (remplacez par l'IP de votre serveur)
  • Le nom du modèle à utiliser, exactement comme il apparaît dans ollama list (ex: llama3.2:3b)

Une fois l'intégration ajoutée, elle crée automatiquement un Conversation Agent que vous pouvez associer à vos pipelines vocaux.

Associer Ollama à un pipeline Assist

Allez dans Paramètres → Assistants vocaux. Créez un nouveau pipeline ou modifiez le pipeline existant. Dans le champ Agent de conversation, sélectionnez votre agent Ollama au lieu de "Home Assistant".

Vous pouvez conserver plusieurs pipelines : un avec l'agent HA natif (rapide et fiable pour les commandes simples) et un avec Ollama (pour les questions ouvertes et les interactions plus riches).

Tester depuis le panneau Développeur

Dans HA, allez dans Outils de développement → Modèle et testez votre agent :

Quelle est la température dans le salon en ce moment ?

Ou depuis l'icône micro en bas à droite de l'interface HA (panneau Assist). La première réponse est généralement plus lente (chargement du modèle en mémoire), les suivantes beaucoup plus rapides.

Aller plus loin : Extended Ollama Conversation via HACS

L'intégration native Ollama est fonctionnelle mais limitée. Elle ne permet pas, par exemple, de configurer finement le system prompt, d'exposer seulement certaines entités au modèle, ou de gérer la fenêtre de contexte. L'intégration communautaire Extended OpenAI Conversation (compatible Ollama) disponible via HACS comble ces lacunes.

Installation via HACS

Prérequis : HACS installé et fonctionnel.

Dans HACS : Intégrations → Explorer & télécharger des dépôts, cherchez "Extended OpenAI Conversation". Installez, redémarrez Home Assistant.

Ajoutez l'intégration : Paramètres → Appareils et services → Ajouter une intégration → Extended OpenAI Conversation. Dans le champ URL de l'API, entrez l'endpoint compatible OpenAI d'Ollama :

http://192.168.1.XXX:11434/v1

Ollama expose en effet une API compatible OpenAI sur /v1, ce qui permet d'utiliser n'importe quel client OpenAI avec lui. La clé API peut être n'importe quelle chaîne (ex: ollama), elle est ignorée par Ollama en local.

Avantages sur l'intégration native

  • System prompt Jinja2 complet avec accès aux entités et états
  • Filtrage des entités exposées au modèle (évite de noyer le contexte)
  • Contrôle de la fenêtre de contexte (nombre de tokens max)
  • Support des fonctions (function calling) pour les modèles qui le supportent
  • Logs de débogage détaillés pour diagnostiquer les problèmes

Personnaliser l'agent : system prompt Jinja2, entités, context window

C'est là que l'intégration Ollama devient vraiment puissante. Le system prompt définit le comportement du LLM, les informations qu'il connaît sur votre installation et le style de ses réponses.

Structure d'un bon system prompt pour Home Assistant

Le system prompt est le texte envoyé au modèle avant chaque conversation. Il peut contenir du Jinja2, ce qui vous permet d'injecter dynamiquement l'état de vos entités.

Tu es l'assistant domotique de la maison. Tu réponds toujours en
français, de façon concise et précise.

Date et heure actuelles :
{{ now().strftime('%A %d %B %Y, %Hh%M') }}

Températures actuelles :
- Salon : {{ states('sensor.temperature_salon') }}°C
- Chambre : {{ states('sensor.temperature_chambre') }}°C
- Extérieur : {{ states('sensor.temperature_exterieure') }}°C

Présences :
- Maison occupée :
  {{ 'Oui' if is_state('binary_sensor.maison_occupee',
  'on') else 'Non' }}

Règles :
- Pour contrôler des appareils, utilise les services HA disponibles
- Si tu ne sais pas l'état d'une entité, dis-le clairement
- Ne fabrique jamais de données : base-toi sur les valeurs réelles

Ce template Jinja2 est évalué à chaque requête par Home Assistant avant d'être envoyé à Ollama. Le modèle reçoit donc toujours des données fraîches. Pour aller plus loin sur Jinja2 dans Home Assistant, consultez notre guide templates Jinja2 Home Assistant.

Limiter les entités exposées au modèle

Par défaut, l'intégration expose toutes vos entités au LLM. Sur une installation avec 200+ entités, le contexte devient énorme et la qualité des réponses se dégrade. Avec Extended OpenAI Conversation, vous pouvez filtrer précisément quelles entités sont visibles.

Dans la configuration de l'intégration, listez les entités à exposer :

exposed_entities:
  - sensor.temperature_salon
  - sensor.temperature_chambre
  - sensor.temperature_exterieure
  - binary_sensor.maison_occupee
  - light.salon
  - light.chambre
  - climate.chauffage_salon
  - sensor.consommation_electrique_kwh
  - sensor.production_solaire_kwh

Paramètres du modèle

Quelques paramètres importants à ajuster selon votre modèle :

options:
  temperature: 0.3
  top_p: 0.9
  num_ctx: 4096
  num_predict: 512

La temperature contrôle la créativité du modèle (0 = déterministe, 1 = créatif). Pour la domotique, une valeur basse (0.2-0.4) donne des réponses plus fiables et moins fantaisistes. Le num_ctx est la taille de la fenêtre de contexte en tokens — 4096 est suffisant pour la plupart des cas, mais augmentez à 8192 si vous avez de longues conversations ou un system prompt très détaillé.

Cas d'usage concrets

Les possibilités théoriques sont nombreuses, mais voici les cas d'usage qui fonctionnent vraiment au quotidien.

Comprendre ce que le LLM peut et ne peut pas faire

Avant de plonger dans les cas d'usage, clarifier les rôles évite les déceptions. Ollama via Home Assistant peut :

  • Répondre à des questions ouvertes avec le contexte de vos entités ("Est-ce que j'ai oublié d'éteindre la lumière du garage ?")
  • Générer du texte enrichi à partir de données brutes (résumés météo, bilans de consommation, descriptions d'événements)
  • Prendre des décisions simples à partir d'un ensemble de règles formulées en langage naturel
  • Exécuter des services HA si les entités sont correctement exposées et que le modèle supporte le function calling

Ollama ne peut pas, en revanche, accéder à des APIs externes, consulter internet, apprendre de vos interactions au fil du temps (pas de mémoire persistante par défaut), ni remplacer les automatisations classiques YAML pour les tâches répétitives et déterministes. Il excelle là où la logique conditionnelle classique est insuffisante : les situations ambiguës, le langage naturel, et la génération de texte.

Résumés météo intelligents

Plutôt qu'afficher des valeurs brutes, demandez à Ollama de générer un résumé météo contextualisé pour la journée. Une automatisation HA peut déclencher cette requête chaque matin :

alias: Résumé météo du matin
trigger:
  - platform: time
    at: "07:30:00"
action:
  - service: conversation.process
    data:
      agent_id: conversation.ollama_llama3_2_3b
      text: >
        Donne-moi un résumé météo pour aujourd'hui en 2 phrases.
        Température actuelle : {{ states('sensor.temperature_ext') }}°C.
        Température max prévue :
        {{ state_attr('weather.meteo_france',
        'forecast')[0].temperature }}°C.
        Conditions : {{ states('weather.meteo_france') }}.
        Adapte tes recommandations vestimentaires.
    response_variable: meteo_response
  - service: notify.mobile_app_ton_telephone
    data:
      message: >
        {{ meteo_response.response.speech.plain.speech }}

Analyse de consommation électrique

Ollama peut analyser vos données de consommation et vous alerter sur des anomalies ou vous donner du contexte :

alias: Analyse conso hebdo
trigger:
  - platform: time
    at: "20:00:00"
    weekday: sun
action:
  - service: conversation.process
    data:
      agent_id: conversation.ollama_llama3_2_3b
      text: >
        Analyse ma consommation électrique de la semaine.
        Consommation totale : {{ states('sensor.conso_semaine') }} kWh.
        Production solaire : {{ states('sensor.prod_solaire_sem') }}
        kWh.
        Autoconsommation :
        {{ states('sensor.autoconsommation_pct') }}%.
        Donne-moi un bilan en 3 points et un conseil pratique.
    response_variable: conso_response
  - service: notify.mobile_app_ton_telephone
    data:
      message: >
        {{ conso_response.response.speech.plain.speech }}

Notifications intelligentes pour la sécurité

Couplé à Frigate pour les alertes caméra, Frigate 0.17 utilise Ollama pour générer des descriptions d'événements — "Une personne avec un sac à dos a traversé l'allée à 14h32" plutôt que "Personne détectée". Ce flux peut alimenter des notifications push enrichies dans Home Assistant.

Rapport de présence et sécurité

Ollama peut analyser la cohérence des événements de présence et générer un rapport quand quelque chose sort de l'ordinaire :

alias: Rapport présence anormal
trigger:
  - platform: state
    entity_id: binary_sensor.porte_entree
    to: "on"
    for: "00:00:30"
condition:
  - condition: state
    entity_id: binary_sensor.maison_occupee
    state: "off"
action:
  - service: conversation.process
    data:
      agent_id: conversation.ollama_llama3_2_3b
      text: >
        La porte d'entrée vient de s'ouvrir à
        {{ now().strftime('%Hh%M') }} alors que la
        maison semble vide. Dernière présence détectée
        il y a {{ relative_time(states.binary_sensor
        .maison_occupee.last_changed) }}.
        Rédige une alerte courte (1 phrase) pour
        une notification push, ton factuel et précis.
    response_variable: alerte
  - service: notify.mobile_app_ton_telephone
    data:
      message: "{{ alerte.response.speech.plain.speech }}"
      data:
        priority: high

Assistant agenda et rappels

alias: Briefing du soir
trigger:
  - platform: time
    at: "21:00:00"
action:
  - service: conversation.process
    data:
      agent_id: conversation.ollama_llama3_2_3b
      text: >
        Résume ma journée de demain. J'ai
        {{ state_attr('calendar.perso', 'message') }}
        prévu demain. Réveil habituel à 7h30.
        Donne-moi 3 choses à anticiper, en 4 phrases maximum.
    response_variable: agenda_response
  - service: notify.mobile_app_ton_telephone
    data:
      message: >
        {{ agenda_response.response.speech.plain.speech }}

Personnalisation des modes d'interaction

Une subtilité souvent ignorée : vous pouvez créer des scripts HA dédiés qui servent de "fonctions nommées" à votre assistant Ollama. Plutôt que de demander à Ollama d'appeler directement un service, vous lui demandez de retourner le nom d'un script, et Home Assistant l'exécute ensuite. Cette approche est plus fiable car elle ne dépend pas du function calling du modèle :

alias: Assistant Ollama avec scripts dédiés
trigger:
  - platform: conversation
    command: "*"
    agent_id: conversation.ollama_llama3_2_3b
action:
  - choose:
      - conditions:
          - condition: template
            value_template: >
              {{ 'bonne nuit' in trigger.text|lower
                 or 'je vais dormir' in trigger.text|lower
              }}
        sequence:
          - service: script.routine_nuit
      - conditions:
          - condition: template
            value_template: >
              {{ 'je pars' in trigger.text|lower
                 or 'je sors' in trigger.text|lower
              }}
        sequence:
          - service: script.mode_absent
    default:
      - service: conversation.process
        data:
          agent_id: conversation.ollama_llama3_2_3b
          text: "{{ trigger.text }}"

Pipeline voix 100 % local : Whisper + Piper + Ollama

L'intérêt majeur d'Ollama dans Home Assistant s'exprime pleinement quand il est intégré dans un pipeline vocal complet. La pile est entièrement locale : aucune requête ne sort de votre réseau.

Les composants du pipeline

  • Wake word — openWakeWord détecte "Ok Nabu" ou "Hey Jarvis" en permanence sur vos satellites vocaux
  • STT — Whisper (add-on HA) transcrit votre voix en texte. Le modèle small est recommandé pour le français sur N150.
  • Conversation Agent — Ollama analyse le texte, consulte vos entités et génère la réponse
  • TTS — Piper synthétise la réponse en voix française. La voix fr_FR-upmc-medium est naturelle et rapide.

Notre guide complet sur l'assistant vocal local Home Assistant en français couvre l'installation et la configuration de Whisper et Piper. Voici comment y intégrer Ollama :

Configuration du pipeline avec Ollama

Dans Paramètres → Assistants vocaux → Créer un assistant :

Nom : Assistant IA Local
Langue : Français (France)
Agent de conversation : Ollama (llama3.2:3b)
Speech-to-Text : faster-whisper (modèle: small, langue: fr)
Text-to-Speech : Piper (voix: fr_FR-upmc-medium)

Limitation importante : latence composée

Sur un mini PC N150, comptez :

  • Whisper (STT) : 0,5-1,5 secondes
  • Ollama (LLM) : 2-5 secondes
  • Piper (TTS) : 0,3-0,8 secondes

Total : 3-7 secondes du wake word à la première syllabe de la réponse. C'est acceptable pour des questions ouvertes ("Quel temps fait-il demain ?") mais perceptible pour des commandes simples ("Allume la lumière"). Pour les commandes directes, un second pipeline avec l'agent HA natif (Speech-to-Phrase + Assist) est plus réactif (0,5-1 seconde).

Une stratégie efficace : utiliser un wake word différent selon le pipeline. "Ok Nabu" déclenche l'agent HA natif pour les commandes rapides, "Hey Jarvis" déclenche le pipeline Ollama pour les questions ouvertes.

Optimiser la latence voix avec le streaming

Ollama supporte le streaming des réponses : plutôt que d'attendre que le modèle génère l'intégralité du texte avant de le passer à Piper, le streaming permet de commencer la synthèse vocale dès les premiers tokens générés. Home Assistant 2025.6+ supporte cette fonctionnalité via le paramètre stream: true dans les options du modèle.

Avec le streaming activé, la latence perçue est nettement plus agréable : vous entendez le début de la réponse en 1-2 secondes alors que le modèle continue de générer la suite. Pour une conversation naturelle, l'effet est significatif. Ce paramètre est disponible dans la configuration avancée de l'intégration Extended OpenAI Conversation.

Satellites vocaux DIY et Ollama

Si vous avez des satellites vocaux ESPHome (microphone + haut-parleur sur ESP32-S3) répartis dans votre maison, ils s'intègrent parfaitement avec ce pipeline. Chaque satellite envoie l'audio au serveur HA, Whisper transcrit, Ollama répond, Piper synthétise, et l'audio est renvoyé au satellite qui se trouvait dans la pièce. La logique de routage est gérée automatiquement par Home Assistant Assist. Notre guide sur l'assistant vocal local détaille la construction de ces satellites ESPHome.

AI Task (HA 2025.7+) pour automatisations structurées

Home Assistant 2025.7 a introduit l'entité AI Task, qui change fondamentalement comment les LLM peuvent être utilisés dans les automatisations. Plutôt que de forcer le modèle à générer du texte libre que vous parsez ensuite, les AI Tasks demandent au modèle de retourner des données structurées JSON selon un schéma que vous définissez.

Principe des AI Tasks

Une AI Task est définie par :

  • Un prompt textuel
  • Un schéma JSON attendu en sortie
  • Un agent de conversation (ici : Ollama)

Home Assistant injecte automatiquement l'état de vos entités dans le contexte, et le LLM retourne un JSON que vous pouvez utiliser directement dans vos automatisations.

Exemple : décision d'activation du chauffage

alias: IA Task - Ajustement chauffage
trigger:
  - platform: time_pattern
    hours: "/2"
action:
  - service: ai_task.generate_data
    data:
      task_name: heating_decision
      agent_id: conversation.ollama_qwen3_8b
      instructions: >
        Analyse les données et décide si le chauffage
        doit être activé. Retourne ta décision en JSON.
      structure:
        type: object
        properties:
          activate:
            type: boolean
          target_temp:
            type: number
          reason:
            type: string
        required: [activate, target_temp, reason]
    response_variable: heating_decision
  - if: "{{ heating_decision.data.activate }}"
    then:
      - service: climate.set_temperature
        target:
          entity_id: climate.salon
        data:
          temperature: >
            {{ heating_decision.data.target_temp }}

L'avantage est que vous n'avez pas à parser du texte libre : le JSON retourné est directement exploitable dans vos conditions et actions HA. Les modèles comme Qwen3 8B ou Mistral 7B Instruct sont particulièrement fiables sur ce type de tâche structurée.

Bonnes pratiques pour les AI Tasks

Quelques règles qui évitent les frustrations :

  • Schémas stricts — utilisez enum pour les champs à valeurs fixes. Un champ "action": {"type": "string"} peut donner "activer" ou "turn on" selon l'humeur du modèle. Un "enum": ["on", "off", "auto"] force la cohérence.
  • Fallback explicite — ajoutez toujours une condition default dans vos automatisations au cas où le JSON retourné ne correspond pas au schéma attendu.
  • Instructions en français — pour les modèles Mistral et Llama 3.2, rédiger les instructions en français donne de meilleurs résultats JSON qu'en anglais. Pour Qwen3, l'anglais est légèrement plus fiable sur les tâches structurées.
  • Testez avec temperature=0 — pour les AI Tasks, une temperature à 0 donne des résultats parfaitement déterministes, ce qui est précieux pour des automatisations de sécurité ou d'énergie.

Exemple : classification d'événements Frigate

alias: IA Task - Classification alerte Frigate
trigger:
  - platform: event
    event_type: frigate.review
    event_data:
      severity: alert
action:
  - service: ai_task.generate_data
    data:
      task_name: frigate_classification
      agent_id: conversation.ollama_qwen3_8b
      instructions: >
        Classifie cet événement de surveillance :
        {{ trigger.event.data.data.objects }}.
        Caméra : {{ trigger.event.data.camera }}.
        Heure : {{ now().strftime('%Hh%M') }}.
        La maison est
        {{ 'occupée' if is_state(
          'binary_sensor.maison_occupee', 'on')
          else 'vide' }}.
      structure:
        type: object
        properties:
          urgency:
            type: string
            enum: [low, medium, high, critical]
          action:
            type: string
            enum: [ignore, notify, alarm]
          summary:
            type: string
        required: [urgency, action, summary]
    response_variable: classification
  - if: >
      {{ classification.data.action in
         ['notify', 'alarm'] }}
    then:
      - service: notify.mobile_app_ton_telephone
        data:
          message: >
            {{ classification.data.summary }}
          data:
            priority: >
              {{ 'high' if classification.data.urgency
                 == 'critical' else 'normal' }}

Dépannage : les problèmes courants

Ollama ne répond pas depuis Home Assistant

Premier réflexe : vérifier que l'API Ollama est accessible depuis la machine HA. Depuis un terminal sur le serveur HA (ou une VM sur le même réseau) :

curl http://192.168.1.XXX:11434/api/tags

Si la commande échoue, les causes possibles sont :

  • Ollama n'est pas configuré pour écouter sur toutes les interfaces (OLLAMA_HOST=0.0.0.0 manquant)
  • Un firewall bloque le port 11434 sur la machine qui héberge Ollama. Sur Debian/Ubuntu : sudo ufw allow 11434/tcp
  • L'adresse IP a changé — vérifiez que l'IP est bien statique
  • Le service Ollama est arrêté : systemctl status ollama

Latence excessive : le modèle répond en 30+ secondes

Si les réponses prennent plus de 15-20 secondes, le modèle est trop grand pour votre hardware ou est en train d'être swappé sur disque :

  • Vérifiez la RAM disponible : free -h. Si le modèle dépasse la RAM disponible, il utilise le swap et les performances s'effondrent.
  • Essayez un modèle plus petit : ollama pull llama3.2:1b (version 1B paramètres)
  • Réduisez la quantification : un modèle en Q2 est plus rapide qu'en Q8, au prix d'une légère perte de qualité
  • Vérifiez que d'autres processus ne consomment pas la RAM : htop pendant qu'Ollama tourne
# Voir les modèles chargés et leur utilisation mémoire
ollama ps

# Forcer le déchargement d'un modèle inactif
ollama stop llama3.2:3b

Le modèle ne comprend pas les entités Home Assistant

Si le LLM répond "Je n'ai pas accès à vos appareils" alors que vous avez bien configuré l'intégration :

  • Vérifiez que les entités sont bien "exposées" à l'assistant. Dans HA : Paramètres → Assistants vocaux → Entités exposées. Les entités doivent avoir le switch "Exposé" activé.
  • Testez avec l'outil de développement HA → Modèle → en utilisant votre agent Ollama directement
  • Regardez les logs HA pour voir ce qui est envoyé à Ollama : Paramètres → Journaux → Filtrer par "ollama"

Réponses incohérentes ou hallucinations

Les LLM peuvent "inventer" des informations quand le contexte est flou. Quelques pratiques pour réduire les hallucinations :

  • Abaissez la temperature à 0.1-0.2 dans les paramètres du modèle
  • Ajoutez dans le system prompt : "Ne fabrique jamais de données. Si tu ne connais pas l'état d'une entité, dis-le clairement."
  • Limitez les entités exposées pour réduire la confusion du modèle
  • Pour les AI Tasks, utilisez des schémas stricts avec enum sur les champs à valeurs fixes

L'intégration native HA vs Extended OpenAI Conversation

Si l'intégration native fonctionne mais qu'Extended OpenAI Conversation échoue, vérifiez l'URL de l'endpoint : elle doit se terminer par /v1 (pas juste le port).

# URL correcte pour Extended OpenAI Conversation
http://192.168.1.XXX:11434/v1

# URL correcte pour l'intégration native HA
http://192.168.1.XXX:11434

FAQ communauté

Peut-on utiliser Ollama sur le même Raspberry Pi que Home Assistant ?

Techniquement oui, mais c'est déconseillé. Un Raspberry Pi 4 avec 4 Go de RAM va souffrir : Home Assistant consomme déjà 0,8-1,2 Go de RAM, et le plus petit modèle Ollama utilisable en demande 2 Go supplémentaires. Le système va se retrouver en swap permanent, avec des latences de 30-60 secondes par réponse et un risque de corruption de la carte SD. Un mini PC dédié ou une VM séparée est fortement recommandé.

Faut-il une connexion internet pour que ça fonctionne ?

Non, c'est justement l'un des avantages majeurs. Une fois le modèle téléchargé localement (ollama pull nécessite internet), l'inférence est entièrement locale. Ollama fonctionne parfaitement hors ligne, ce qui est précieux pour les automatisations critiques.

Quelle est la différence avec l'IA de Nabu Casa ?

Nabu Casa propose depuis 2024 un accès cloud à des LLM (OpenAI et autres) intégré dans Home Assistant Cloud. C'est pratique car sans infrastructure à gérer, mais les données passent par le cloud et il faut un abonnement Nabu Casa actif. Ollama est l'alternative 100 % locale et gratuite. Si vous avez déjà remplacé Nabu Casa par une solution d'accès distant autonome, notre guide sur remplacer Nabu Casa avec Tailscale ou Cloudflare Tunnel peut vous intéresser.

Peut-on faire tourner plusieurs modèles simultanément ?

Ollama peut charger plusieurs modèles, mais un seul est actif (en VRAM/RAM) à la fois par défaut. Si vous appelez un second modèle pendant qu'un premier est chargé, Ollama le décharge pour charger le nouveau (avec un délai). Vous pouvez configurer OLLAMA_NUM_PARALLEL pour autoriser plusieurs modèles en parallèle, mais cela multiplie la consommation mémoire.

Quels modèles sont les meilleurs pour le français ?

En 2026, Mistral 7B Instruct reste la référence pour le français pur (modèle entraîné par une société française, sur de nombreux textes français). Llama 3.2 3B est excellent également grâce à ses données d'entraînement multilingues de Meta. Évitez les très petits modèles (1B) pour le français : la qualité grammaticale et la compréhension des nuances deviennent rapidement insuffisantes.

Comment mettre à jour Ollama et les modèles ?

# Mettre à jour Ollama (bare metal)
curl -fsSL https://ollama.com/install.sh | sh

# Mettre à jour un modèle (re-télécharger la dernière version)
ollama pull llama3.2:3b

# Lister les modèles installés
ollama list

# Supprimer un modèle inutilisé
ollama rm mistral:7b-instruct-q4_K_M

Est-ce que Ollama supporte plusieurs langues simultanément ?

Oui. Les modèles modernes (Llama 3.2, Mistral, Qwen3) sont multilingues et basculent automatiquement dans la langue de la requête. Si vous avez une installation multilingue (maison franco-belge, famille bilingue), les modèles s'adaptent sans configuration particulière. Il suffit de ne pas forcer une langue dans le system prompt ("réponds uniquement en français") si vous souhaitez ce comportement multilingue.

Comment sauvegarder les données Ollama ?

Les modèles Ollama sont stockés dans ~/.ollama/models/ sur Linux (ou dans le volume Docker si vous utilisez Docker). Un modèle de 2-5 Go, re-téléchargeable à tout moment depuis le registre Ollama, ne nécessite généralement pas de sauvegarde. En revanche, si vous avez créé des modèles personnalisés (ollama create avec un Modelfile), sauvegardez le Modelfile plutôt que le modèle complet.

# Sauvegarder tous les Modelfiles personnalisés
ollama list | grep ':custom' | awk '{print $1}' | while read model; do
  ollama show --modelfile "$model" > "backup_${model//[:\/]/_}.txt"
done

Y a-t-il un risque de sécurité à exposer l'API Ollama sur le LAN ?

L'API Ollama n'a pas d'authentification native. Quiconque sur votre réseau local peut envoyer des requêtes à votre instance Ollama. Dans un contexte domestique avec un réseau WiFi sécurisé, ce risque est limité. Cependant, évitez d'exposer le port 11434 sur internet. Si vous avez besoin d'accéder à Ollama depuis l'extérieur, faites-le via un VPN (Wireguard, Tailscale) et non directement. Pour une couche d'authentification supplémentaire sur le LAN, un reverse proxy Nginx avec basic auth suffit.

Frigate + Ollama : peut-on tout faire tourner sur la même machine ?

Oui, et c'est même la configuration la plus courante sur la communauté. Frigate utilise Ollama pour ses fonctions GenAI (résumés d'événements) et home Assistant utilise le même Ollama pour la conversation. Les deux services partagent l'instance Ollama sans conflit. Notre article Frigate Home Assistant : setup complet couvre l'installation complète si vous démarrez de zéro.

La configuration Frigate pour utiliser Ollama comme fournisseur GenAI se fait dans config.yml :

genai:
  enabled: true
  provider: ollama
  base_url: http://192.168.1.XXX:11434
  model: llama3.2:3b
  object_prompts:
    person: >
      Décris cette personne : tenue, direction, activité.
      Sois factuel et précis en 1-2 phrases.
    car: >
      Décris ce véhicule : couleur, type, position.
      1-2 phrases factuel.