Page informative, sans valeur de conseil. Téléchargez depuis la source officielle et lisez la licence attentivement : celle de Dify est une Apache 2.0 modifiée qui ajoute deux restrictions précises (voir plus bas). Dify exécute du code dans ses nœuds et peut piloter des agents autonomes : testez en environnement isolé.
À quoi ça sert
Dify réunit dans un seul environnement ce qu'on assemble habituellement à la main : un éditeur de prompts, un constructeur de workflows visuels, une base de connaissances vectorielle pour le RAG, une gestion des clés API par provider, et surtout une couche d'observabilité — chaque appel LLM est tracé, les tokens sont comptabilisés, les erreurs enregistrées. On crée un assistant sur ses documents, un agent de traitement, un pipeline d'extraction, puis on l'expose via une API REST pour l'intégrer ailleurs.
Cas d'usage courants : assistant interne sur base documentaire, extraction structurée depuis des PDF, agent de qualification, outil de modération, orchestration multi-agents — avec, à chaque fois, la possibilité de mesurer ce qui se passe.
Ce qui fait sa force
- L'observabilité native. Le vrai différenciateur : suivi des appels, comptage des tokens, journal des erreurs. Pour qui doit maîtriser des coûts ou auditer des interactions, c'est un atout rare dans cette catégorie.
- Une vraie API de production. Chaque application créée est immédiatement appelable en REST, avec gestion des clés. Dify vise l'exploitation, pas seulement la maquette.
- Workflows et agents réunis. Constructeur visuel de workflows et orchestration d'agents cohabitent. On passe d'un simple chatbot RAG à un pipeline outillé sans changer d'outil.
- Multi-providers, local compris. Dify se branche sur de nombreux providers et sur Ollama en local. On garde les traitements sensibles sur sa machine.
- Base de connaissances intégrée. Import de documents, découpage, indexation vectorielle et récupération sont fournis, sans empiler des briques séparées.
Pour qui
Pour des équipes techniques qui veulent un environnement d'exploitation, pas un simple outil de prototypage. La mise en route (Docker, variables d'environnement, choix des providers) suppose un profil technique ; en revanche, une fois en place, l'interface de test s'ouvre à des utilisateurs métier. Dify part du principe que vous savez ce qu'est un LLM, un embedding et une base vectorielle. Pour prototyper plus légèrement, regardez Langflow ou Flowise ; pour de l'automatisation métier large, n8n.
Installation
Prérequis
Docker et Docker Compose. Dify est une stack multi-conteneurs : prévoyez de la ressource (un minimum de 2 Go de RAM pour un usage léger, davantage en pratique). Aucun GPU requis côté Dify — les modèles sont appelés via API ou via Ollama en local.
Cloner et démarrer
# Récupérer le dépôt
git clone https://github.com/langgenius/dify.git
cd dify/docker
# Configuration par défaut
cp .env.example .env
# Démarrer tous les services
docker compose up -dOuvrez http://localhost (port 80 par défaut). La première connexion crée le compte administrateur.
Mise à jour
cd dify/docker
docker compose down
git pull origin main
docker compose pull
docker compose up -dAller plus loin : l'exécution de code et la stack
Les nœuds de code de Dify (Python, JavaScript, modèles Jinja2) ne s'exécutent pas dans le service principal mais dans un service séparé, DifySandbox — un environnement d'exécution conçu pour isoler du code non fiable, pensé pour les contextes multi-utilisateurs. C'est une protection utile, à condition de garder ce service à jour.
Côté infrastructure, docker compose up lance plusieurs services : l'API et le worker
Dify, une base PostgreSQL, un Redis, une base vectorielle
(Weaviate ou pgvector selon la configuration) et le sandbox. C'est puissant, mais cela représente
une surface à maintenir plus large qu'un outil mono-conteneur.
Points de vigilance
Dify est une application web multi-services qui exécute du code et orchestre des agents. Les points ci-dessous sont propres à ce qu'elle est — à commencer par sa licence, plus exigeante qu'une Apache 2.0 standard.
| Point d'attention | Niveau | Ce qu'il faut savoir |
|---|---|---|
| Licence : Apache 2.0 modifiée, deux restrictions | 🔴 avant tout usage SaaS / commercial | Dify est sous une Apache 2.0 assortie de conditions additionnelles : (1) vous ne pouvez pas utiliser le code de Dify pour exploiter un service multi-tenants (offre SaaS) sans autorisation écrite de l'éditeur ; (2) vous ne pouvez pas retirer ou modifier le logo et les mentions de copyright dans la console et les applications Dify. En dehors de ces deux points, l'usage commercial (back-end, plateforme interne) est permis. Lisez la licence avant tout déploiement. |
| Agents autonomes avec accès à vos systèmes | 🔴 selon les outils accordés | Workflows et agents peuvent appeler des API, lire/écrire des données, déclencher des webhooks. Restreignez les permissions des outils et supervisez les premières exécutions en production. |
| Secrets par défaut à changer | 🟡 réel | Le fichier .env contient une SECRET_KEY et des mots de passe (PostgreSQL, Redis) à modifier avant le premier démarrage. Les laisser par défaut expose l'instance. |
| Données sensibles envoyées à un provider cloud | 🟡 selon le provider choisi | Si une application pointe sur un provider distant, les données transmises au modèle quittent votre infrastructure. Pour le confidentiel, utilisez Ollama en local. |
| Stack multi-conteneurs à maintenir | 🟡 réel | PostgreSQL, Redis, base vectorielle, sandbox, services Dify : davantage de composants à mettre à jour et à sauvegarder. Automatisez la sauvegarde de PostgreSQL et du volume de données. |
| Failles du sandbox — tenir à jour | 🟡 réel | Des failles dans DifySandbox (le service qui isole l'exécution de code) ont été corrigées. Ce service est un maillon clé : un sandbox non à jour peut être contourné. Tenez l'ensemble de la stack Dify à jour, et accordez une attention particulière aux mises à jour du service sandbox dans le changelog officiel. |
Sécurité
- Changez les secrets avant le premier démarrage.
SECRET_KEYet mots de passe PostgreSQL / Redis dans.env. - HTTPS et pas de port 80 brut sur Internet. Reverse proxy (Nginx, Caddy) avec TLS ; restriction par IP si possible.
- Compte administrateur solide. Mot de passe fort, et authentification renforcée si disponible.
- Gardez DifySandbox à jour. C'est lui qui isole l'exécution de code des nœuds ; ses correctifs comptent.
- Sauvegardez PostgreSQL et le volume. Ils contiennent vos applications, workflows, bases de connaissances et journaux.
- Restreignez les outils des agents. N'accordez que ce qui est nécessaire ; surveillez les premiers passages en production.
Aller plus loin
- Ollama — brancher un modèle local pour garder vos données chez vous.
- LiteLLM — unifier plusieurs providers derrière un seul endpoint, en amont de Dify.
- Langflow — une alternative plus légère pour prototyper.
- n8n — pour les automatisations qui dépassent le périmètre LLM.
- OSIALab — comparer tous les outils d'automatisation IA.
Sources
- Site officiel : dify.ai
- Code source : github.com/langgenius/dify
- Documentation : docs.dify.ai
- Licence : Dify Open Source License — Apache 2.0 modifiée (interdiction d'exploitation multi-tenants/SaaS sans accord + interdiction de retirer le logo et le copyright).