n8n + Ollama : faire tourner un agent IA en local, sans clé API

Chaque appel à l'API OpenAI ou Anthropic a un coût, dépend d'une connexion internet stable, et fait transiter le contenu de vos emails, contrats ou tickets support par un serveur tiers. Pour une partie des tâches qu'un workflow n8n effectue au quotidien — classification, résumé court, extraction simple — un modèle de langage plus modeste, exécuté localement via Ollama, suffit largement, sans clé API et sans facture qui varie avec le volume. Ce guide explique comment brancher n8n sur Ollama, pour quels cas d'usage c'est pertinent, et où s'arrêtent les avantages du local.

Pourquoi faire tourner un LLM en local

Trois raisons motivent généralement ce choix, indépendamment les unes des autres :

• Confidentialité : le contenu ne quitte jamais votre serveur. Pour des données sensibles (RH, juridique, santé), c'est parfois une exigence non négociable plutôt qu'une préférence — le sujet rejoint directement notre guide sur la piste d'audit RGPD, où la localisation des traitements compte autant que leur journalisation.
• Coût prévisible : pas de facturation à la requête. Sur un volume élevé de tâches simples (classification d'emails, tri de tickets), l'inférence locale devient gratuite au-delà du coût du serveur — à comparer avec les ordres de grandeur détaillés dans notre article sur le suivi du coût des appels IA.
• Indépendance réseau : aucun appel externe, donc aucune sensibilité aux limites de débit décrites dans notre guide sur les erreurs 429 ni aux pannes d'un fournisseur cloud.

En contrepartie, un modèle local de taille raisonnable (7-8 milliards de paramètres, ce qui tourne sur du matériel accessible) reste nettement en retrait par rapport à GPT-4o ou Claude sur le raisonnement complexe, la fiabilité du format de sortie et l'usage d'outils (tool calling). Le bon réflexe n'est pas « tout basculer en local », mais choisir la bonne tâche pour la bonne brique.

Installer Ollama et choisir un modèle

Sur Linux, l'installation tient en une commande :

curl -fsSL https://ollama.com/install.sh | sh

Des installeurs natifs existent pour macOS et Windows. Ollama démarre un service local sur le port 11434 et expose une API HTTP compatible avec la plupart des clients LangChain, dont celui utilisé par n8n. Il ne reste qu'à télécharger un modèle :

ollama pull llama3.1
ollama pull mistral
ollama pull qwen2.5:7b

Pour des tâches de classification ou de résumé — le cœur des workflows IA les plus courants sur n8n — un modèle 7-8B quantifié est un bon point de départ : rapide, léger, et suffisamment précis pour des prompts bien cadrés. Réservez les modèles plus volumineux (14B et plus) aux tâches qui exigent davantage de nuance, au prix d'une latence plus élevée.

Connecter n8n à Ollama

Dans n8n, le node Ollama Chat Model (catégorie AI, sous-nodes de modèle de langage) se branche comme n'importe quel autre modèle de chat : sur un Basic LLM Chain pour une tâche simple, ou sur un AI Agent pour une logique avec outils et mémoire de conversation. La credential associée ne demande qu'une Base URL, par défaut http://localhost:11434.

Le point qui bloque le plus souvent : la mise en réseau sous Docker. Si n8n tourne dans un conteneur et qu'Ollama tourne sur la machine hôte, localhost depuis le conteneur ne désigne pas l'hôte mais le conteneur lui-même. Deux solutions courantes :

• Sur macOS et Windows (Docker Desktop), utilisez http://host.docker.internal:11434 comme Base URL.
• Sur Linux, ajoutez --add-host=host.docker.internal:host-gateway au lancement du conteneur n8n, ou faites tourner Ollama comme un service du même docker-compose.yml (référencé alors par son nom de service, par exemple http://ollama:11434).

n8n propose d'ailleurs un Self-hosted AI Starter Kit officiel (n8n + Ollama + Qdrant + PostgreSQL en docker-compose) qui règle ce câblage réseau par défaut — un bon point de départ pour tester rapidement sans tout configurer à la main.

Cas d'usage adaptés à un modèle local

Certaines tâches tolèrent bien un modèle plus modeste et bénéficient directement de la gratuité et de la confidentialité du local :

• Classification simple : catégoriser un email ou un ticket entre quelques options fixes (urgent/normal, client/spam/administratif) — proche du workflow décrit dans notre guide sur le tri d'emails par IA.
• Résumé court : condenser un fil de discussion ou une transcription avant de la transmettre à un humain, sans exiger de raisonnement multi-étapes.
• Extraction de champs simples : repérer une date, un montant ou un nom dans un texte structuré, quand le format d'entrée est prévisible.
• Prétraitement avant un modèle plus puissant : filtrer ou dégrossir un gros volume localement (gratuitement), puis n'envoyer à une API cloud que les cas ambigus ou complexes — une architecture hybride qui limite la facture sans sacrifier la qualité là où elle compte.

À l'inverse, un AI Agent avec plusieurs outils personnalisés ou un pipeline RAG avec citations précises restent, à ce jour, plus fiables avec un modèle comme GPT-4o ou Claude : l'enchaînement d'appels d'outils et la fidélité aux sources exigent un niveau de raisonnement que les modèles locaux de taille raisonnable n'atteignent pas encore de façon constante.

La limite concrète : la sortie structurée

Plusieurs workflows n8n orientés production s'appuient sur un Structured Output Parser pour garantir un JSON exploitable en sortie du LLM (score de priorité, catégorie, champs extraits). C'est le cas des workflows de tri et de priorisation d'emails du Pack Inbox IA (79 €), construits sur un Basic LLM Chain dont le sous-modèle est interchangeable. Un modèle local 7-8B respecte généralement bien un format JSON simple, mais devient moins fiable dès que le schéma se complexifie (champs imbriqués, énumérations nombreuses) : mieux vaut tester sur un échantillon réel de vos données avant de basculer un workflow de production entier, et prévoir une validation du JSON en sortie (le node Structured Output Parser échoue proprement si le format ne correspond pas, ce qui reste préférable à une erreur silencieuse).

Une approche hybride, pas un remplacement total

Le local et le cloud ne s'excluent pas : un même workflow peut faire tourner un modèle Ollama pour le tri initial d'un gros volume, puis appeler Claude ou GPT via une clé API uniquement pour les cas remontés comme prioritaires ou ambigus. Cette architecture réduit le volume d'appels facturés sans renoncer à la qualité sur les décisions qui comptent — et elle s'intègre sans friction dans une instance self-hosted où vous maîtrisez déjà l'infrastructure.

Pour aller plus loin

Ollama ne remplace pas une stratégie IA complète, mais il change la donne sur les tâches à fort volume et faible complexité : moins de facture, plus de confidentialité, et une bonne occasion de repenser quelles étapes de vos workflows méritent vraiment un modèle de pointe. Les packs FlowKit sont construits avec des sous-nodes de modèle interchangeables : vous pouvez partir sur OpenAI ou Anthropic pour valider rapidement, puis migrer progressivement les tâches les plus simples vers Ollama une fois le workflow stabilisé.