Créer un agent IA complet avec n8n et Ollama

Un agent IA ne se contente pas de générer du texte. Il reçoit une demande, analyse le contexte, choisit éventuellement un outil, exécute une action et renvoie un résultat. Un chatbot répond. Un agent peut aussi consulter une base, classer un ticket, envoyer un email ou déclencher un autre workflow.

L’association de n8n et Ollama permet de construire ce type de système sans transmettre les données à OpenAI ou à un autre fournisseur de modèles distant. n8n orchestre les événements, les règles et les intégrations. Ollama exécute le modèle de langage directement sur votre serveur.

Ce guide prolonge deux tutoriels déjà publiés : héberger n8n sur un VPS et héberger un LLM avec Ollama. Nous supposons donc que n8n et Ollama sont déjà installés sur le même VPS. L’objectif est maintenant de les connecter pour créer un agent IA auto-hébergé, maîtrisable et adapté aux contraintes de souveraineté des équipes françaises.

Prérequis et connectivité entre n8n et Ollama

Avant de créer le workflow, vérifiez les éléments suivants :

• n8n est accessible et opérationnel
• Ollama fonctionne sur le VPS
• au moins un modèle a déjà été téléchargé
• n8n peut joindre l’API Ollama sur le port 11434
• le modèle choisi apparaît dans la sortie de ollama list

Le nom configuré dans n8n doit correspondre exactement à celui affiché par Ollama, par exemple llama3.2:3b. Une différence de tag suffit à provoquer une erreur indiquant que le modèle est introuvable.

La bonne URL dépend de votre déploiement. Si n8n et Ollama sont deux services Docker présents sur le même réseau, utilisez généralement :

http://ollama:11434

Ici, ollama correspond au nom du service Docker. Les deux conteneurs doivent appartenir au même réseau.

Si n8n et Ollama s’exécutent directement sur le système hôte, l’URL peut être :

http://127.0.0.1:11434

Attention au piège classique : dans un conteneur n8n, 127.0.0.1 désigne le conteneur n8n lui-même, pas le VPS. Si Ollama tourne sur l’hôte et n8n dans Docker, utilisez une adresse permettant au conteneur de joindre l’hôte, puis vérifiez que l’écoute d’Ollama et le pare-feu restent correctement limités. Il est préférable de placer les deux services sur un réseau Docker privé plutôt que d’exposer le port 11434 sur Internet.

Construire un premier agent IA dans n8n

Créons un agent qui reçoit une demande HTTP, la transmet au modèle local, puis renvoie la réponse. Le workflow pourra ensuite être enrichi pour envoyer un email ou écrire dans une base.

Ajoutez d’abord un nœud Webhook. Configurez-le avec la méthode POST et un chemin tel que agent. Le client pourra envoyer un corps JSON simple :

{
  "message": "Résume cette demande et indique son niveau de priorité."
}

Ajoutez ensuite un nœud AI Agent. Dans le champ du message utilisateur, récupérez la valeur reçue par le webhook avec une expression telle que :

{{ $json.body.message }}

Définissez un message système précis. Par exemple :

Tu es un assistant interne. Analyse la demande, réponds en français et n'invente aucune information. Si une action est nécessaire, utilise uniquement les outils disponibles.

Le message système sert à encadrer le comportement général. Il ne remplace cependant pas les validations techniques dans le workflow. Une instruction textuelle ne constitue pas une barrière de sécurité.

Utiliser Ollama comme modèle de l’AI Agent

Le nœud AI Agent a besoin d’un modèle de chat. Ajoutez un sous-nœud Ollama Chat Model sur son connecteur de modèle.

Dans la configuration Ollama, renseignez l’URL adaptée à votre réseau, par exemple http://ollama:11434. Sélectionnez ensuite un modèle réellement présent sur le serveur, comme llama3.2:3b.

Pour commencer, choisissez une température relativement basse, par exemple entre 0,1 et 0,4. Cela favorise des réponses plus régulières pour la classification, l’extraction ou le support interne. Une température plus élevée peut être utile pour la rédaction créative, mais augmente la variabilité.

Reliez enfin un nœud Respond to Webhook à la sortie de l’agent. Configurez-le pour retourner la réponse générée sous forme JSON :

{
  "response": "contenu produit par l'agent"
}

Vous obtenez ainsi une chaîne complète :

Webhook -> AI Agent -> Respond to Webhook
                 |
          Ollama Chat Model

Pour un simple appel sans comportement agentique, un nœud HTTP Request peut aussi interroger directement l’API Ollama, notamment via /api/chat. Cette approche convient à une génération déterministe dans un workflow linéaire. Le nœud AI Agent devient plus intéressant lorsque le modèle doit choisir entre plusieurs outils ou conserver un historique.

Permettre à l’agent d’agir

Un agent devient réellement utile lorsqu’il dispose d’outils. Dans n8n, ces outils sont connectés au port Tool du nœud AI Agent.

Vous pouvez, par exemple, lui fournir :

• un outil d’envoi d’email
• un outil HTTP pour appeler une API interne
• un outil de base de données pour rechercher ou enregistrer une information
• un autre workflow n8n exposé comme outil
• un outil de lecture documentaire ou de recherche dans une base vectorielle

Chaque outil doit avoir un nom et une description sans ambiguïté. L’agent se sert de cette description pour décider quand l’appeler. Pour un outil d’envoi d’email, précisez les paramètres attendus : destinataire, objet et contenu.

Évitez de donner immédiatement à l’agent un accès libre à une boîte mail, à une base en écriture ou à une API d’administration. Créez plutôt des outils étroits. Un sous-workflow creer_brouillon_email est plus sûr qu’un outil générique capable d’envoyer n’importe quel message.

Pour une action sensible, insérez une validation humaine. L’agent prépare l’opération, n8n l’enregistre ou la transmet pour approbation, puis un second workflow l’exécute. Cette séparation limite les conséquences d’une mauvaise interprétation ou d’une injection de prompt.

Ajouter une mémoire conversationnelle

Sans mémoire, chaque appel au webhook est indépendant. Pour poursuivre une conversation, reliez un nœud de mémoire au connecteur Memory de l’AI Agent.

Le nœud Simple Memory convient aux tests et aux conversations temporaires. Il faut lui fournir un identifiant de session stable, transmis par le client :

{
  "sessionId": "client-4821",
  "message": "Que dois-je répondre à ce ticket ?"
}

Dans la mémoire, utilisez une expression comme :

{{ $json.body.sessionId }}

En production, privilégiez une mémoire persistante, par exemple Postgres Chat Memory, si votre architecture n8n la prend en charge. Vous pourrez alors conserver l’historique malgré un redémarrage du service.

Ne stockez pas automatiquement toutes les conversations. Définissez une durée de conservation, limitez le nombre de messages et évitez d’enregistrer inutilement des données personnelles. Le caractère local du LLM ne dispense pas d’appliquer les principes du RGPD.

Exemple complet : analyser puis traiter une demande

Imaginons un formulaire interne qui transmet une demande de support. Le webhook reçoit le nom du client, le sujet et le texte. L’agent doit résumer la demande, déterminer une priorité et proposer une réponse.

Le workflow peut suivre cette structure :

Webhook
  -> Edit Fields
  -> AI Agent
  -> Switch
  -> Base de données ou Email
  -> Respond to Webhook

Le nœud Edit Fields prépare une entrée propre pour l’agent. Le message système impose un format structuré comprenant resume, priorite, categorie et reponse_proposee.

Après l’agent, un nœud Switch examine la priorité. Une demande critique peut créer une alerte interne. Une demande normale peut être enregistrée dans la base avec une réponse suggérée.

Pour fiabiliser le traitement, demandez une sortie structurée et validez les champs avant toute action. Si la priorité est absente ou invalide, dirigez le résultat vers une branche de contrôle au lieu de poursuivre silencieusement.

Deuxième exemple : classer et résumer des emails ou tickets

Pour traiter une boîte de support, utilisez un déclencheur email, IMAP ou l’intégration correspondant à votre messagerie. Pour un outil de ticketing, un Webhook, un nœud natif ou un HTTP Request peut récupérer les nouveaux éléments.

Nettoyez d’abord le contenu : supprimez les signatures répétées, limitez la longueur des fils précédents et conservez les métadonnées utiles. Envoyez ensuite à l’agent le sujet, l’expéditeur et le corps du message.

Demandez-lui de produire :

• une catégorie parmi une liste fermée
• un résumé en deux ou trois phrases
• un niveau d’urgence
• les informations manquantes
• un brouillon de réponse

n8n peut ensuite router le ticket avec un nœud Switch, écrire le résultat dans la base et notifier la bonne équipe. Pour les emails, mieux vaut créer un brouillon que déclencher un envoi automatique dès la première version du workflow.

Conservez également le texte original. Le résumé du modèle facilite le traitement, mais ne doit pas devenir l’unique source disponible.

Limites et dimensionnement du VPS

Un LLM local consomme de la mémoire et du processeur. Sans GPU annoncé, il faut raisonner sur une exécution CPU et choisir des modèles compacts. Un modèle de quelques milliards de paramètres, éventuellement quantifié, est généralement plus réaliste qu’un grand modèle destiné à une machine spécialisée.

Les réponses seront aussi plus lentes que sur une infrastructure GPU. La longueur du prompt, l’historique de conversation et le nombre de générations simultanées augmentent directement la charge.

Commencez avec un petit modèle, mesurez la mémoire disponible et chronométrez un workflow représentatif. Limitez ensuite la concurrence dans n8n et ajoutez des files d’attente si plusieurs utilisateurs sollicitent l’agent. Un modèle local rapide et correctement cadré sera souvent plus utile qu’un modèle plus imposant qui bloque le serveur.

Les VPS TalCloud démarrent à 4,99 € par mois, avec 4 à 16 Go de RAM selon l’offre et sans GPU. Ils reposent sur un hébergement en France, du stockage NVMe, une protection Anti-DDoS Netrix et un support humain. Le dimensionnement doit être validé selon le modèle Ollama, la concurrence attendue et les autres services présents sur le VPS.

Sécuriser l’agent et ses données

N’exposez pas directement l’API Ollama sur Internet. Gardez-la sur le réseau interne et protégez n8n avec HTTPS, une authentification forte et des secrets stockés dans les credentials. Un reverse proxy comme Nginx Proxy Manager permet de centraliser HTTPS proprement.

Ajoutez une authentification au webhook, limitez la taille des requêtes et appliquez un contrôle de débit. Considérez chaque email, ticket ou document comme une entrée non fiable : son contenu peut tenter de modifier les instructions de l’agent.

Journalisez les appels d’outils et les erreurs, sans enregistrer plus de données personnelles que nécessaire. Utilisez des comptes techniques aux permissions minimales, sauvegardez les workflows et testez les scénarios d’échec : Ollama indisponible, réponse invalide, délai dépassé ou outil refusé.

Le workflow concret à tester en premier est donc Webhook -> AI Agent + Ollama Chat Model -> Respond to Webhook. Ajoutez ensuite une mémoire de session, un unique outil à faible risque et une validation humaine avant toute action externe.