Un agent IA en une journée : un prototype local, sans cloud et sans développeurs

Quand la direction demande d'intégrer un agent IA à un processus métier, les exigences sont souvent contradictoires : les données ne peuvent pas partir dans le cloud, le budget est quasi nul, les développeurs manquent et le résultat est attendu pour le lendemain. En pratique, c'est faisable. En une journée de travail, on peut monter un prototype local d'agent IA fonctionnel avec des outils ouverts comme Ollama et n8n. Il n'est pas nécessaire d'avoir une équipe de spécialistes, des abonnements cloud ou une architecture complexe.

Pourquoi en local plutôt que dans le cloud

Les API de LLM dans le cloud, comme celle d'OpenAI, sont pratiques, mais le coût augmente à chaque requête et les données sensibles de l'entreprise passent entre les mains de tiers. C'est risqué pour les organisations soumises à des exigences de confidentialité. Un agent local sur la plateforme Ollama tourne directement sur l'ordinateur ou le serveur de l'entreprise : les données ne quittent jamais le périmètre, et seule l'électricité est à payer.

Principaux avantages de l'approche locale :

• Les données restent dans l'entreprise et ne partent pas dans le cloud
• Pas de factures d'API, seulement un coût matériel ponctuel
• Possibilité de travailler sur un réseau fermé, sans connexion internet permanente
• Indépendance totale vis-à-vis des services cloud et de leurs pannes
• Montée en charge moins coûteuse pour de gros volumes de requêtes

Ollama et n8n : deux outils pour construire l'agent

Ollama empaquette de grands modèles de langage dans un conteneur. On télécharge un modèle prêt à l'emploi (Llama 2, Mistral, Deepseek, Phi et d'autres), on le lance via Docker, et le modèle devient accessible par une API REST. Pas de Python, pas de configuration CUDA, pas de bataille avec les dépendances. En 15 minutes, le modèle est prêt à répondre à une première requête.

n8n est une plateforme d'automatisation no-code. Voyez-la comme un constructeur de workflows. On connecte Ollama comme un nœud dans l'éditeur visuel, on relie des sources de données (CRM, Slack, e-mail, bases de connaissances, fichiers), on crée une chaîne d'actions, et l'agent se met au travail. Pas besoin d'écrire du code : tout se passe dans une interface en glisser-déposer.

De zéro à une démo fonctionnelle en une journée

Voici un calendrier indicatif pour s'organiser sur une journée de travail :

• 09:00 — installer Ollama et télécharger le modèle choisi (40–50 minutes)
• 09:50 — configurer l'API REST locale et tester le modèle avec curl (30 minutes)
• 10:20 — installer et lancer n8n pour la première fois sur la même machine (30 minutes)
• 10:50 — créer le premier workflow dans n8n et connecter Ollama comme nœud (1 heure)
• 11:50 — régler le prompt et tester sur des exemples simples (45 minutes)
• 12:35 — intégrer une source de données (par exemple, charger des documents ou se connecter à Slack) (1 heure)
• 13:35 — déboguer, corriger les erreurs et vérifier les cas limites (1 heure)
• 14:35 — présenter le prototype fonctionnel à la direction

Ce calendrier est réaliste si l'on ne cherche pas la perfection. L'essentiel est de montrer que l'idée fonctionne.

Quand le RAG devient nécessaire : chercher dans ses propres données

Si l'agent doit répondre à partir des informations internes de l'entreprise (rapports, politiques, documentation technique, FAQ, historiques de ventes), ajoutez du RAG (retrieval-augmented generation). n8n peut charger des documents, créer leurs embeddings (représentations vectorielles) et, à chaque question de l'utilisateur, chercher dans votre base les passages pertinents. L'agent devient nettement plus performant, car il ne s'appuie plus seulement sur ce qu'il a appris à l'entraînement, mais aussi sur des données propres à l'entreprise.

Ce que cela change en pratique

Les agents IA locaux passent du stade d'expérience à celui d'outil de travail. Une entreprise de toute taille, de la startup à la multinationale, peut monter en une journée un agent fonctionnel qui travaille sur des données et des processus internes, sans risque de fuite vers le cloud et sans factures énormes. C'est particulièrement important pour le secteur financier, les administrations publiques et l'industrie, où la confidentialité des données n'est pas un souhait, mais une exigence stricte de la loi et de la politique de sécurité.