n8n avec Ollama : connecter des modèles d'IA locaux sans le cloud

n8n se connecte à Ollama via son propre identifiant Ollama, dans lequel vous renseignez uniquement une URL de base (par défaut : http://localhost:11434) et, éventuellement, une clé API. Les modèles de langage locaux peuvent ensuite être intégrés dans des workflows via le nœud Ollama Model ou le nœud Ollama Chat Model, sans que les données du prompt ne soient transmises à un fournisseur cloud. Le nœud Ollama Model convient aux chaînes simples avec la Basic LLM Chain, mais selon la documentation de n8n, il ne prend pas en charge le tool-calling. Pour les agents IA avec accès à des outils, le nœud Ollama Chat Model est le bon choix, sachant que tous les modèles locaux ne gèrent pas de manière fiable les appels de fonction. État : juillet 2026.

Comment configurer les identifiants Ollama dans n8n ?

Dans n8n, vous créez d'abord un identifiant Ollama, composé de deux champs : l'URL de base de votre instance Ollama et une clé API facultative pour l'authentification par jeton porteur (bearer token) lors d'installations distantes ou sécurisées par proxy. L'URL de base par défaut est http://localhost:11434. Si vous avez défini la variable d'environnement OLLAMA_HOST sur votre serveur Ollama, saisissez exactement cette valeur à la place, comme le décrit la documentation officielle de n8n sur les identifiants Ollama. En cas d'erreur de connexion avec le message IPv6 "ECONNREFUSED ::1:11434", il est souvent utile de remplacer localhost par l'adresse IPv4 127.0.0.1.

Quel est le piège le plus fréquent dans les environnements Docker ?

L'erreur classique survient parce que chaque conteneur Docker possède son propre espace de noms localhost, ce qui empêche n8n et Ollama de se joindre automatiquement lorsqu'ils sont dans des conteneurs séparés. Si seul Ollama tourne dans Docker et que n8n tourne directement sur l'hôte, il suffit d'exposer le port avec -p 11434:11434 et de conserver http://localhost:11434 dans n8n. Si, en revanche, n8n tourne dans un conteneur et Ollama sur le système hôte, vous devez utiliser http://host.docker.internal:11434 au lieu de localhost dans l'identifiant Ollama. Sous Linux, le conteneur n8n a en outre besoin du flag --add-host host.docker.internal:host-gateway, ou de l'entrée extra_hosts correspondante dans le fichier Docker Compose, car Docker Desktop fournit automatiquement cette résolution de noms, contrairement aux installations Linux serveur pures. Si les deux services tournent comme des conteneurs séparés dans le même réseau Docker, utilisez plutôt le nom du conteneur Ollama comme hôte, par exemple http://my-ollama:11434. Cette distinction est documentée dans les notes sur les problèmes connus du nœud Ollama Chat Model.

Nœud Ollama Model ou nœud Ollama Chat Model : lequel choisir ?

n8n propose deux sous-nœuds différents pour Ollama, et ce choix détermine directement si votre workflow pourra ensuite appeler des outils. Le nœud Ollama Model ne prend explicitement pas en charge le tool-calling selon la documentation et ne peut donc pas être connecté au nœud AI Agent ; il est plutôt destiné à la Basic LLM Chain pour des tâches simples de type prompt-réponse sans accès à des outils. Le nœud Ollama Chat Model, à l'inverse, est conçu pour les scénarios de conversation et la connexion à des workflows d'agents, et propose des paramètres tels que Sampling Temperature, Top K et Top P pour contrôler la diversité des réponses. Vous sélectionnez le modèle concret dans une liste déroulante des modèles téléchargés localement via ollama pull.

Quelles sont les limites du tool-calling avec des modèles locaux ?

Honnêtement, le tool-calling est le plus grand point faible en exploitation locale : tous les modèles fournis via Ollama ne prennent pas en charge des appels de fonction fiables, même si le nœud Ollama Chat Model peut techniquement être connecté à un Tools Agent. Les modèles plus anciens ou plus petits ont tendance à mal formater les appels d'outils, à inventer des paramètres ou tout simplement à ignorer les outils, ce qui peut entraîner des erreurs silencieuses dans des automatisations en production. Quiconque a besoin d'un tool-calling fiable devrait tester spécifiquement des modèles entraînés à cet effet et vérifier les résultats par sondage avant une mise en production, plutôt que de faire confiance aveuglément à la sortie. Pour les entreprises qui ont besoin d'une évaluation solide du setup de modèles cloud et locaux adapté à leur cas d'usage, NordFlux propose un accompagnement sur les agents IA qui inclut précisément cet arbitrage entre souveraineté des données, coûts et fiabilité.

Questions fréquentes sur n8n et Ollama

Ollama doit-il obligatoirement tourner sur le même serveur que n8n ?

Non, Ollama peut aussi tourner sur une machine ou un serveur séparé, tant que n8n peut atteindre l'URL de base de cette instance. Dans ce cas, saisissez dans l'identifiant Ollama l'adresse IP ou le nom d'hôte du serveur Ollama, et sécurisez la connexion si nécessaire via la clé API facultative.

Pourquoi n8n signale-t-il "ECONNREFUSED" alors qu'Ollama fonctionne ?

Ce message d'erreur apparaît souvent lorsque n8n se connecte via IPv6 à l'adresse ::1 au lieu d'utiliser IPv4 sur 127.0.0.1, alors qu'Ollama n'écoute que sur l'adresse IPv4. Remplacez localhost par 127.0.0.1 dans l'URL de base pour corriger l'erreur.

Le nœud Ollama Model fonctionne-t-il avec le nœud AI Agent ?

Non, selon la documentation de n8n, le nœud Ollama Model ne dispose pas du support des outils, c'est pourquoi il ne fonctionne pas avec le nœud AI Agent. Pour les workflows d'agents avec accès à des outils, utilisez plutôt le nœud Ollama Chat Model, mais vous devez vérifier vous-même la capacité de tool-calling du modèle choisi.

n8n prend-il aussi en charge les connexions par proxy vers Ollama ?

De manière limitée seulement : Ollama lui-même ne prend pas en charge les agents HTTP personnalisés, si bien que les configurations classiques de proxy HTTP ou HTTPS entre n8n et Ollama peuvent poser problème. Pour des connexions distantes sécurisées, l'authentification par jeton porteur via la clé API facultative de l'identifiant est l'approche la plus fiable.