Héberger Flowise : construire des agents IA et workflows LLM sans coder

Construire un chatbot métier, un assistant documentaire ou un agent capable d’utiliser des outils demande souvent d’assembler de nombreux composants. Flowise simplifie ce travail grâce à une interface visuelle dans laquelle les modèles, les sources de données et les étapes de traitement se connectent par glisser-déposer.

Open source et fondé sur LangChain, Flowise permet d’adopter une approche no-code ou low-code sans abandonner la maîtrise de l’infrastructure. Auto-hébergé sur un serveur français, associé à Ollama et à une base vectorielle locale, il constitue une base pertinente pour développer des workflows LLM plus souverains et mieux contrôler les données traitées.

Ce que permet Flowise

Flowise représente une application d’IA sous la forme d’un graphe de noeuds. Chaque noeud assure une fonction précise, tandis que les connexions définissent le chemin suivi par les données et les requêtes.

L’interface propose notamment des noeuds pour :

• appeler un LLM ;
• créer des embeddings ;
• enregistrer des vecteurs dans un vector store ;
• rechercher les passages pertinents avec un retriever ;
• construire des chaînes de traitement ;
• configurer des agents capables de raisonner et d’appeler des outils ;
• ajouter une mémoire conversationnelle ;
• connecter des fichiers, API, bases de données et autres sources.

Cette composition visuelle facilite le prototypage. Un développeur peut inspecter les paramètres de chaque composant, tandis qu’un profil no-code peut construire un premier assistant sans développer toute l’orchestration.

Une fois le flux validé dans le chat intégré, Flowise permet de l’appeler à travers une API REST ou de l’intégrer à un site avec un widget. Le même flux peut ainsi alimenter une interface interne, un outil métier ou un chatbot public.

Prérequis pour auto-héberger Flowise

Le déploiement présenté ici nécessite :

• un VPS Linux avec Docker et le plugin Docker Compose (voir installer Docker sur un VPS) ;
• un nom de domaine ou sous-domaine ;
• un reverse proxy pour terminer la connexion HTTPS ;
• des identifiants d’administration robustes ;
• une stratégie de sauvegarde du volume persistant.

Flowise n’exige pas de GPU lorsqu’il utilise une API LLM externe ou un serveur Ollama distinct. Un modèle local exécuté avec Ollama consomme toutefois beaucoup de mémoire et de processeur. Il faut donc dimensionner le VPS selon le modèle choisi et le nombre d’utilisateurs simultanés.

Les VPS TalCloud sont hébergés sur des serveurs situés en France, avec stockage NVMe, protection Anti-DDoS Netrix et support humain, à partir de 4,99 € par mois. Ce cadre facilite une architecture hébergée en France et une démarche conforme au RGPD. TalCloud ne proposant pas de GPU, privilégiez des modèles légers exécutés sur CPU ou séparez le serveur d’inférence de l’instance Flowise.

Déployer Flowise avec Docker Compose

Créez un répertoire réservé au service :

mkdir -p /opt/flowise
cd /opt/flowise

Créez ensuite un fichier .env. Les identifiants sont obligatoires dans cette configuration, car une instance Flowise sans authentification laisserait son interface d’administration accessible.

FLOWISE_USERNAME=admin
FLOWISE_PASSWORD=remplacez-par-un-secret-long-et-unique

Limitez les droits de lecture du fichier :

chmod 600 .env

Ajoutez le fichier compose.yaml suivant :

services:
  flowise:
    image: flowiseai/flowise:latest
    container_name: flowise
    restart: unless-stopped
    environment:
      FLOWISE_USERNAME: ${FLOWISE_USERNAME}
      FLOWISE_PASSWORD: ${FLOWISE_PASSWORD}
    ports:
      - "127.0.0.1:3000:3000"
    volumes:
      - flowise_data:/root/.flowise
    command: /bin/sh -c "flowise start"

volumes:
  flowise_data:

Le port est lié à 127.0.0.1 afin de ne pas exposer directement Flowise sur Internet. Seul le reverse proxy installé sur le serveur pourra joindre l’application.

Démarrez le service :

docker compose up -d

Contrôlez son état et consultez les journaux :

docker compose ps
docker compose logs --tail=100 flowise

Flowise écoute maintenant localement sur le port 3000. Le volume flowise_data conserve la configuration, les flux et les données internes lors du remplacement du conteneur.

Pour un environnement de production reproductible, remplacez ultérieurement le tag latest par une version explicitement testée. Vous éviterez ainsi qu’une recréation du conteneur introduise involontairement une mise à jour majeure.

Premier accès et connexion

Avant de publier le service, vous pouvez vérifier son fonctionnement depuis votre poste avec un tunnel SSH :

ssh -L 3000:127.0.0.1:3000 utilisateur@adresse-du-vps

Ouvrez ensuite http://127.0.0.1:3000 dans votre navigateur et connectez-vous avec les valeurs définies dans .env.

Après la connexion, vérifiez immédiatement les paramètres de sécurité et la gestion des credentials. Les clés d’API, mots de passe de bases de données et jetons d’accès doivent être enregistrés dans le gestionnaire de credentials de Flowise. Ne les inscrivez pas directement dans les prompts, les descriptions de noeuds ou les dépôts Git.

Construire un premier flux RAG

Un flux RAG, pour Retrieval-Augmented Generation, recherche des informations dans une base documentaire avant de demander au modèle de répondre. Il réduit la dépendance aux seules connaissances du LLM et permet de produire des réponses fondées sur vos contenus.

Commencez par créer un nouveau chatflow dans l’interface. Ajoutez ensuite les composants suivants :

1. Un noeud de chargement de documents pour importer les fichiers autorisés.
2. Un découpeur de texte pour produire des fragments de taille adaptée.
3. Un noeud d’embeddings pour transformer chaque fragment en vecteur.
4. Un vector store Qdrant pour stocker et interroger ces vecteurs.
5. Un retriever pour sélectionner les passages proches de la question.
6. Un noeud LLM connecté à Ollama.
7. Une chaîne conversationnelle combinant question, contexte retrouvé et historique.

Si Ollama fonctionne sur le même hôte dans un autre conteneur, placez les services sur un réseau Docker commun et utilisez le nom du service comme adresse. N’utilisez pas localhost depuis Flowise, car cette adresse désigne le conteneur Flowise lui-même. Si Ollama tourne directement sur l’hôte, configurez une route explicitement accessible depuis le conteneur sans ouvrir son port à Internet.

Le modèle d’embeddings doit rester identique entre l’indexation et les recherches. Un changement de modèle impose généralement de recalculer les vecteurs de la collection Qdrant.

Testez enfin le flux dans le chat intégré. Posez des questions dont la réponse apparaît clairement dans les documents, puis des questions hors contexte. Demandez au modèle de signaler l’absence d’information plutôt que d’inventer une réponse. Vérifiez également les passages retrouvés avant d’ajuster la taille des fragments, leur chevauchement et le nombre de résultats transmis au LLM.

Renforcer la souveraineté des données

Pour limiter les transferts vers des tiers, privilégiez Ollama en local pour l’inférence et Qdrant auto-hébergé pour les vecteurs. Cette architecture conserve les prompts, documents et résultats sur une infrastructure que vous contrôlez.

Notre guide pour héberger un LLM avec Ollama peut servir à choisir un modèle compatible avec une exécution CPU. Notre guide Qdrant détaille la persistance des collections et leur sécurisation. Flowise devient alors la couche d’orchestration visuelle entre ces services.

Une API externe reste possible, mais elle implique d’examiner la localisation du traitement, la conservation des requêtes, les sous-traitants et les clauses contractuelles. Le simple hébergement de Flowise en France ne garantit pas que toutes les données restent en France si le workflow appelle un fournisseur distant.

Exposer un flux par API ou widget

Chaque flux publié peut être appelé par son endpoint de prédiction. L’application cliente envoie la question et récupère la réponse générée. Le widget fourni par Flowise facilite également l’ajout d’un chat sur une page web.

Considérez toutefois l’identifiant du flux et les clés d’accès comme des informations sensibles. Une clé intégrée dans du JavaScript côté navigateur peut être copiée. Pour un usage privé ou facturable, faites transiter les requêtes par votre backend, appliquez une authentification utilisateur et ajoutez des limites de débit, comme le détaille notre guide pour sécuriser une API.

Ne rendez pas automatiquement publics les endpoints utilisés pour l’administration, l’indexation ou l’appel d’outils. Un agent disposant d’actions sensibles doit également appliquer des autorisations côté service cible.

Activer HTTPS avec un reverse proxy

Configurez un sous-domaine, par exemple flowise.example.fr, vers l’adresse du VPS. Placez ensuite Nginx, Caddy ou Traefik devant Flowise et transmettez les requêtes vers http://127.0.0.1:3000.

Le reverse proxy doit fournir un certificat TLS valide, rediriger HTTP vers HTTPS et transmettre correctement les connexions persistantes. Conservez le port 3000 fermé dans le pare-feu public. Seuls les ports nécessaires, généralement 80 et 443, doivent être accessibles depuis Internet.

Si l’interface est réservée à une équipe, ajoutez idéalement une restriction réseau, un VPN ou une couche d’authentification centralisée devant Flowise.

Sécurité et sauvegardes

L’authentification Flowise doit rester activée avec un mot de passe unique. N’exposez jamais l’interface sans HTTPS et renouvelez immédiatement tout secret accidentellement publié.

Sauvegardez à la fois le volume persistant et les informations nécessaires au déchiffrement ou à la restauration des credentials. Une copie du seul fichier Compose ne suffit pas. Stockez les sauvegardes chiffrées sur un emplacement distinct, définissez une durée de rétention et testez régulièrement une restauration. Notre guide sur les sauvegardes chiffrées avec restic détaille cette approche.

Appliquez aussi le principe du moindre privilège aux comptes Qdrant, aux API externes et aux outils accessibles par les agents. Contrôlez la nature des documents indexés et définissez une politique de suppression conforme aux obligations RGPD.

Mises à jour et supervision

Avant une mise à jour, consultez les changements de version, sauvegardez le volume et testez la nouvelle image sur une instance de préproduction. La procédure courante est :

cd /opt/flowise
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100 flowise

Surveillez la disponibilité HTTP, les redémarrages du conteneur, l’espace disque, la mémoire, la latence et les erreurs d’appel aux modèles. Pour un workflow RAG, suivez également les échecs d’indexation, la taille des collections et la qualité des résultats retrouvés.

Flowise accélère fortement la construction d’agents et de chaînes LLM, mais la mise en production exige les mêmes précautions qu’une application classique : contrôle des accès, sauvegardes vérifiées, mises à jour maîtrisées et observation continue.