Workflows IA n8n avec Ollama et Claude sur VPS

n8n intègre des nœuds IA natifs basés sur LangChain. Vous pouvez brancher un modèle local via Ollama ou un modèle cloud via l'API Claude. Les deux options se connectent de la même façon : comme sous-nœuds à l'intérieur du nœud AI Agent de n8n. Ce tutoriel met en place les deux chemins sur un VPS auto-hébergé, construit un workflow pratique de classification de contenu, et montre comment passer de l'inférence locale à l'inférence cloud en changeant un seul nœud.

Si vous n'avez pas encore installé n8n, commencez par notre guide sur l'installation de n8n avec Docker Compose sur un VPS.

De quoi avez-vous besoin avant d'ajouter l'IA à n8n ?

Il vous faut une instance n8n fonctionnelle sur un VPS avec Docker Compose, un domaine avec TLS et un accès SSH. Pour Ollama, prévoyez au moins 8 Go de RAM sur votre VPS pour faire tourner des petits modèles (7-8 milliards de paramètres). Pour Claude, il vous faut une clé API Anthropic. Aucun GPU n'est nécessaire pour Ollama sur CPU, mais l'inférence sera plus lente.

Liste des prérequis :

Un VPS avec au moins 8 Go de RAM (4 vCPU recommandés). Un Virtua Cloud VCS-8 convient parfaitement.
n8n qui tourne via Docker Compose (voir le guide d'installation de n8n)
Un accès SSH avec un utilisateur non-root disposant de sudo
Un domaine pointant vers votre VPS avec TLS configuré (voir notre guide sur le reverse proxy et l'authentification)
Pour le chemin Claude : un compte sur la console Anthropic avec une clé API

Comment ajouter Ollama à votre stack Docker Compose n8n ?

Ajoutez Ollama comme service dans votre fichier Docker Compose existant, sur le même réseau que n8n. n8n communique avec Ollama via le DNS interne de Docker en utilisant le nom du service comme nom d'hôte. Pas besoin de clé API. Ollama reste uniquement sur le réseau interne, jamais exposé à internet.

Ouvrez votre docker-compose.yml existant et ajoutez le service ollama :

services:
  # ... votre service n8n existant ...

  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    volumes:
      - ollama_data:/root/.ollama
    networks:
      - n8n-network
    environment:
      - OLLAMA_HOST=0.0.0.0
    deploy:
      resources:
        limits:
          memory: 6G
        reservations:
          memory: 4G
    healthcheck:
      test: ["CMD", "ollama", "ps"]
      interval: 30s
      timeout: 10s
      retries: 3

volumes:
  # ... vos volumes existants ...
  ollama_data:

Points importants de cette configuration :

Aucun port publié. Ollama écoute sur le port 11434 à l'intérieur du conteneur, mais on ne le mappe pas sur l'hôte. Seuls les conteneurs sur n8n-network peuvent l'atteindre. Cela empêche quiconque sur internet d'utiliser votre instance Ollama.
OLLAMA_HOST=0.0.0.0 indique à Ollama d'écouter sur toutes les interfaces à l'intérieur du conteneur. Sans cela, il se lie uniquement à localhost et n8n ne peut pas l'atteindre depuis un autre conteneur.
Les limites mémoire empêchent Ollama de consommer toute la RAM du VPS. Ajustez en fonction de la taille de votre modèle.
Le health check utilise ollama ps pour interroger le serveur. Docker redémarre le conteneur si Ollama ne répond plus. L'image Ollama n'inclut pas curl, donc on utilise la CLI intégrée.

Si votre VPS dispose d'un GPU NVIDIA et que vous avez installé le NVIDIA Container Toolkit, ajoutez le passthrough GPU :

  ollama:
    # ... même config que ci-dessus, plus :
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

Démarrez la stack mise à jour :

docker compose up -d ollama

Vérifiez qu'Ollama tourne :

docker compose logs ollama --tail 20

La sortie affiche Listening on [::]:11434. Maintenant, téléchargez un modèle :

docker compose exec ollama ollama pull llama3.2:3b

Cela télécharge le modèle Llama 3.2 à 3 milliards de paramètres (environ 2 Go). Pour un VPS de 8 Go, c'est le point de départ le plus sûr. Consultez le tableau de dimensionnement des modèles ci-dessous pour d'autres options.

Vérifiez que le modèle est chargé :

docker compose exec ollama ollama list

Testez l'inférence directement :

docker compose exec ollama ollama run llama3.2:3b "Say hello in one sentence"

Vous devriez obtenir une réponse en quelques secondes. Si cela fonctionne, Ollama est prêt pour n8n.

Quel modèle Ollama choisir pour votre VPS ?

Le bon modèle dépend de votre RAM disponible. En règle générale : 1 milliard de paramètres nécessite environ 1 Go de RAM en quantification Q4. Sur un VPS sans GPU, le modèle tourne sur CPU, ce qui est plus lent mais fonctionnel pour les workflows en lot et en arrière-plan.

Modèle	Paramètres	Taille disque	RAM nécessaire	Idéal pour
llama3.2:3b	3B	~2 Go	4 Go	Tâches légères, RAM limitée
llama3.1:8b	8B	~4,9 Go	8 Go	Usage général, contexte 128K
mistral:7b	7B	~4,4 Go	7 Go	Inférence rapide, modèle européen
qwen2.5:7b	7B	~4,7 Go	8 Go	Multilingue, tâches de code
gemma3:4b	4B	~3,3 Go	5 Go	Multimodal, bon ratio qualité/taille

Sur un VPS 4 vCPU, 8 Go de RAM (comme le Virtua Cloud VCS-8), llama3.2:3b tourne avec de la marge pour n8n et l'OS. Les modèles 7-8B rentrent mais laissent moins de marge. Pour ceux-là, envisagez un VPS de 16 Go.

Téléchargez le modèle de votre choix avant de continuer. Toutes les étapes ci-dessous fonctionnent avec n'importe quel modèle du tableau.

Comment connecter n8n à l'API Claude ?

Créez un identifiant Anthropic dans n8n avec votre clé API. Puis utilisez le sous-nœud Anthropic Chat Model à l'intérieur de n'importe quel workflow AI Agent. n8n gère les appels API nativement. Pas besoin de nœud HTTP Request.

Générer une clé API

Rendez-vous sur Console Anthropic > Settings > API Keys
Cliquez sur Create Key
Donnez-lui un nom identifiable comme n8n-vps
Copiez la clé immédiatement. Vous ne la reverrez plus.

Stockez la clé en sécurité. Ne la collez pas dans des fichiers sur le disque. Vous la saisirez directement dans le gestionnaire d'identifiants de n8n, qui la chiffre.

Ajouter l'identifiant dans n8n

Dans n8n, allez dans Credentials dans la barre latérale gauche
Cliquez sur Add Credential
Cherchez Anthropic API
Collez votre clé API
Cliquez sur Save

n8n teste la connexion à la sauvegarde. La sortie affiche « Connection tested successfully ». Si cela échoue, vérifiez que votre clé API est valide et que votre VPS peut joindre https://api.anthropic.com (le HTTPS sortant ne doit pas être bloqué par votre pare-feu).

Comment fonctionne le système AI Agent de n8n ?

Les capacités IA de n8n reposent sur LangChain. L'architecture utilise deux types de nœuds : les nœuds racine (aussi appelés nœuds cluster) qui définissent le comportement de l'agent, et les sous-nœuds qui fournissent des capacités spécifiques comme le modèle de langage, la mémoire et les outils. Comprendre cette structure aide à construire et déboguer les workflows.

Nœuds racine :

AI Agent : l'orchestrateur principal. Il reçoit une entrée, l'envoie au modèle de langage, peut utiliser des outils et retourne une réponse. C'est ce que vous utiliserez le plus.
Basic LLM Chain : plus simple que l'Agent. Prend une entrée, l'envoie au LLM, retourne la sortie. Pas d'utilisation d'outils, pas de boucle de raisonnement.

Sous-nœuds (se rattachent aux nœuds racine) :

Chat Model (Ollama Chat Model ou Anthropic Chat Model) : le LLM qui génère les réponses
Memory (Window Buffer Memory, etc.) : stocke l'historique de conversation
Tools (HTTP Request, Code, Calculator, etc.) : les actions que l'agent peut effectuer
Output Parser : structure la réponse du LLM en données exploitables

Le point important : passer d'Ollama à Claude revient à changer un sous-nœud. Le reste du workflow reste identique. C'est pour cela que l'architecture de n8n fonctionne bien pour tester l'inférence locale et cloud.

Comment construire un workflow de classification IA dans n8n ?

Ce workflow reçoit du contenu via un webhook, l'envoie à un LLM pour classification et résumé, puis route le résultat selon l'urgence. C'est un pattern pratique pour le tri d'e-mails, le routage de tickets de support ou la modération de contenu. On le construit d'abord avec Ollama, puis on bascule sur Claude.

Étape 1 : Créer le déclencheur webhook

Créez un nouveau workflow dans n8n
Ajoutez un nœud Webhook comme déclencheur
Définissez la méthode HTTP sur POST
Définissez le chemin sur quelque chose comme classify
Sous Response, sélectionnez « Respond to Webhook » (on ajoutera ce nœud plus tard)
Sauvegardez et notez l'URL du webhook de test

Le webhook recevra du JSON comme ceci :

{
  "title": "Server disk full alert",
  "body": "Production server db-01 has reached 95% disk usage. Immediate action required.",
  "source": "monitoring"
}

Étape 2 : Ajouter le nœud AI Agent avec Ollama

Ajoutez un nœud AI Agent après le webhook
Dans les paramètres de l'Agent, définissez le prompt système :

You are a content classifier. For each incoming message, respond with valid JSON only:
{
  "urgency": "high" or "low",
  "category": "infrastructure" or "security" or "billing" or "general",
  "summary": "one sentence summary"
}
Do not include any text outside the JSON object.

Connectez un sous-nœud Ollama Chat Model à l'Agent :
- Cliquez sur le connecteur Chat Model du nœud AI Agent
- Sélectionnez Ollama Chat Model
- Dans le menu déroulant des identifiants, cliquez sur Create New
- Définissez la Base URL sur http://ollama:11434 (le nom du service Docker)
- Sauvegardez l'identifiant
- Sélectionnez votre modèle (par ex., llama3.2:3b)
Connectez la sortie du webhook à l'entrée du AI Agent. Mappez le texte du message avec une expression :

Title: {{ $json.title }}
Body: {{ $json.body }}
Source: {{ $json.source }}

Étape 3 : Analyser et router la réponse

Ajoutez un nœud IF après le AI Agent
Définissez la condition : vérifiez si la réponse IA contient "urgency": "high" ou analysez le JSON et vérifiez le champ urgency
Branche vraie (urgence haute) : ajoutez un nœud de notification (Slack, e-mail ou HTTP Request vers votre endpoint d'alertes)
Branche fausse (urgence basse) : ajoutez une autre action (journaliser dans un tableur, envoyer un e-mail de synthèse, etc.)
Ajoutez un nœud Respond to Webhook à la fin de chaque branche pour retourner le résultat de la classification

Étape 4 : Tester le workflow

Activez le workflow pour le test. Envoyez une requête de test :

curl -X POST https://your-n8n-domain.com/webhook-test/classify \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Server disk full alert",
    "body": "Production server db-01 reached 95% disk usage. Immediate action required.",
    "source": "monitoring"
  }'

Consultez l'historique d'exécution de n8n. La sortie affiche :

Le webhook a reçu la charge utile
Le AI Agent l'a envoyée à Ollama
Ollama a retourné une classification JSON
Le nœud IF a routé vers la bonne branche

le temps d'exécution sur le nœud AI Agent. Avec Ollama sur CPU (llama3.2:3b), attendez-vous à 3-8 secondes selon les specs de votre VPS. C'est suffisant pour de l'automatisation en arrière-plan, mais trop lent pour des réponses en temps réel face à l'utilisateur.

Quel est le comportement du même workflow sur Ollama vs Claude ?

Passer d'Ollama à Claude prend environ 30 secondes. La structure du workflow reste identique. Seul le sous-nœud Chat Model change.

Cliquez sur le nœud AI Agent
Supprimez le sous-nœud Ollama Chat Model
Ajoutez un sous-nœud Anthropic Chat Model à la place
Sélectionnez votre identifiant Anthropic
Choisissez le modèle (par ex., claude-sonnet-4-6)
Relancez la même commande curl de test

Comparaison côte à côte :

Aspect	Ollama (llama3.2:3b, CPU)	Claude (claude-sonnet-4-6)
Temps de réponse	3-8 secondes	0,5-1,5 seconde
Formatage JSON	Ajoute parfois du texte en dehors du JSON	Suit l'instruction JSON-only de manière fiable
Précision de classification	Bon pour les cas évidents	Meilleur sur le contenu ambigu ou nuancé
Coût par requête	Gratuit	Par token (voir tarification Anthropic)
Confidentialité des données	Le contenu ne quitte jamais votre VPS	Le contenu est envoyé à l'API d'Anthropic

Le format de sortie est identique. Votre nœud IF et la logique de routage n'ont pas besoin de modifications. Cela rend pratique l'utilisation d'Ollama pour le développement et les tests, puis le passage à Claude pour les workflows de production qui nécessitent de la vitesse ou un meilleur raisonnement.

Quand utiliser un LLM local plutôt qu'une API cloud ?

Utilisez Ollama quand la confidentialité des données compte, que vous voulez zéro coût d'API, ou que vous traitez des lots où la latence est acceptable. Utilisez Claude quand vous avez besoin de réponses rapides, d'un raisonnement solide, ou que vous gérez des workflows en temps réel face à l'utilisateur. Vous pouvez changer de modèle dans n8n en modifiant un sous-nœud, donc ce n'est pas une décision définitive.

Choisissez Ollama quand :

Des données sensibles ne doivent pas quitter votre infrastructure (dossiers médicaux, données financières, documents internes)
Vous faites du traitement par lots où quelques secondes par requête ne posent pas de problème (digests d'e-mails nocturnes, analyse de logs)
Vous voulez des coûts prévisibles. Après le coût du VPS, l'inférence est gratuite quel que soit le nombre de requêtes
Vous prototypez et itérez rapidement sans vous soucier des factures d'API

Choisissez Claude quand :

Vous avez besoin de réponses en moins d'une seconde pour des fonctionnalités face à l'utilisateur (chatbots, classification en temps réel)
La tâche nécessite un raisonnement solide ou une compréhension nuancée (analyse de documents juridiques, résumé complexe)
Vous traitez un faible volume de requêtes à haute valeur où la qualité compte plus que le coût
Vous avez besoin de très longues fenêtres de contexte (Claude Sonnet supporte jusqu'à 1M de tokens)

Approche hybride : beaucoup de configurations en production utilisent les deux. Routez les tâches simples et à haut volume vers Ollama. Routez les tâches complexes et à faible volume vers Claude. Le nœud IF de n8n peut inspecter les données entrantes et choisir le bon chemin.

Comment ajouter du RAG avec Qdrant à votre workflow IA n8n ?

Le RAG (Retrieval-Augmented Generation, ou génération augmentée par la recherche) permet à votre workflow IA de chercher dans vos propres documents avant de générer une réponse. Ajoutez Qdrant comme magasin de vecteurs à votre stack Docker Compose. n8n dispose de nœuds Qdrant natifs qui se connectent au AI Agent comme outil.

Ajoutez Qdrant à votre docker-compose.yml :

  qdrant:
    image: qdrant/qdrant:latest
    container_name: qdrant
    restart: unless-stopped
    volumes:
      - qdrant_data:/qdrant/storage
    networks:
      - n8n-network
    environment:
      - QDRANT__SERVICE__API_KEY=${QDRANT_API_KEY}

volumes:
  qdrant_data:

Générez une clé API forte pour Qdrant :

openssl rand -base64 32

Ajoutez la clé à votre fichier .env :

QDRANT_API_KEY=<your-generated-key>

Définissez des permissions restrictives sur le fichier .env :

chmod 600 .env

Démarrez Qdrant :

docker compose up -d qdrant

Dans n8n, vous pouvez maintenant :

Ajouter un nœud Qdrant Vector Store comme outil pour le AI Agent
Créer un sous-nœud Ollama Embeddings (ou utiliser un autre modèle d'embedding) pour vectoriser vos documents
Construire un workflow d'ingestion qui charge les documents dans Qdrant
Le AI Agent cherchera dans Qdrant le contexte pertinent avant de générer sa réponse

Le RAG est un sujet vaste. Pour un guide complet, consultez notre guide sur l'auto-hébergement d'agents IA sur un VPS. Le kit de démarrage IA auto-hébergé de n8n regroupe n8n, Ollama, Qdrant et PostgreSQL dans un seul fichier Docker Compose. C'est une bonne référence pour l'architecture RAG, bien qu'il soit conçu pour la preuve de concept plutôt que pour la production.

Quelles sont les exigences en ressources pour les workflows IA sur un VPS ?

Faire tourner Ollama sur un VPS nécessite assez de RAM pour le modèle plus l'OS et les autres services. n8n utilise environ 300-500 Mo. La surcharge Docker ajoute 200-300 Mo supplémentaires. Le reste va à Ollama et au modèle choisi. Le nombre de CPU affecte la vitesse d'inférence mais pas le fait que le modèle se charge ou non.

Tableau de planification des ressources :

Taille du VPS	Disponible pour Ollama	Meilleur modèle adapté	Type de workflow
4 Go de RAM	~2,5 Go	llama3.2:3b (serré)	Classification légère uniquement
8 Go de RAM	~5-6 Go	llama3.2:3b ou mistral:7b	Automatisation générale
16 Go de RAM	~12-13 Go	llama3.1:8b ou qwen2.5:14b	Agents complexes, RAG
32 Go de RAM	~28 Go	Plusieurs modèles chargés	Multi-agents en production

Si vous n'utilisez que le chemin API Claude (sans Ollama), un VPS de 4 Go suffit pour n8n. Le LLM tourne sur l'infrastructure d'Anthropic.

Surveillez l'utilisation des ressources après le déploiement :

docker stats --no-stream

Cela affiche la consommation CPU et mémoire par conteneur. Surveillez le conteneur Ollama pendant l'inférence. L'utilisation mémoire monte en pic lors du traitement d'une requête et redescend ensuite.

Consultez les logs d'Ollama pour les problèmes de performance :

docker compose logs ollama --tail 50

Si vous voyez des erreurs de mémoire insuffisante, passez à un modèle plus petit ou augmentez la RAM de votre VPS.

Dépannage

n8n ne peut pas se connecter à Ollama :

Vérifiez que les deux conteneurs sont sur le même réseau Docker : docker network inspect n8n-network
Vérifiez que la Base URL de l'identifiant Ollama est http://ollama:11434 (pas localhost)
Vérifiez qu'Ollama tourne : docker compose exec ollama ollama ps
Vérifiez que OLLAMA_HOST=0.0.0.0 est défini dans l'environnement Ollama

Ollama est lent ou ne répond pas :

Vérifiez la mémoire : docker stats ollama
Essayez un modèle plus petit. Les modèles 3B sont nettement plus rapides que les 8B sur CPU.
Si l'inférence prend plus de 30 secondes, le modèle est probablement trop gros pour votre RAM. Ollama bascule sur le disque, ce qui détruit les performances.

L'API Claude retourne des erreurs :

Vérifiez votre clé API dans les identifiants n8n (ressaisissez-la si besoin)
Vérifiez le HTTPS sortant depuis votre VPS : curl -I https://api.anthropic.com
Consultez le log d'exécution de n8n pour le message d'erreur précis. Problèmes courants : clé expirée, limite de débit, crédits insuffisants.

Le AI Agent retourne une sortie incohérente ou non-JSON :

Améliorez le prompt système. Soyez explicite sur le format de sortie.
Claude suit les instructions de formatage de manière plus fiable que les petits modèles locaux.
Ajoutez un sous-nœud Output Parser (Structured Output Parser) pour imposer un schéma JSON.
Avec Ollama, les modèles plus grands (8B+) suivent mieux les instructions que les modèles 3B.

Où sont les logs ?

# n8n logs
docker compose logs n8n --tail 100

# Ollama logs
docker compose logs ollama --tail 100

# All services
docker compose logs --tail 50

n8n conserve aussi l'historique d'exécution dans son interface web sous Executions dans la barre latérale gauche. Chaque exécution montre l'entrée/sortie de chaque nœud, ce qui est le moyen le plus rapide de déboguer les problèmes de workflow.

Copyright 2026 Virtua.Cloud. Tous droits réservés. Ce contenu est une création originale de l'équipe Virtua.Cloud. Toute reproduction, republication ou redistribution sans autorisation écrite est interdite.