Dify : livrer des applications IA auto-hébergées
Ce que Dify apporte au-delà d'un éditeur de workflows, comment l'auto-héberger avec Docker, et les clauses de licence à lire avant d'en faire un produit.

Le prototype marche. Le chatbot répond correctement sur la documentation RH, la démo a plu. Puis viennent les vraies questions : qui peut modifier le prompt ? Comment ajouter les nouveaux PDF chaque mois ? Où voir les conversations où le modèle s'est trompé ? Combien ça coûte par jour ? Comment l'intégrer à l'intranet ?
Dify répond à cette deuxième étape. C'est une plateforme open source de développement d'applications LLM : on y construit des chatbots, des agents et des workflows dans une interface visuelle, on y gère des bases de connaissances, et chaque application est publiée avec une page web, une API et des journaux. L'éditeur parle de « LLMOps ». Plus simplement, c'est l'outil qui fait passer une démo à un service utilisé par une équipe.
Le projet
Dify est développé par LangGenius, une entreprise fondée en 2023. Le dépôt langgenius/dify a été créé en avril 2023 et dépasse les 158 000 étoiles et les 25 000 forks en octobre 2026, ce qui en fait l'un des projets IA les plus suivis de GitHub. Le backend est en Python, l'interface en TypeScript. La dernière version, la 1.17.1, date du 10 septembre.
L'entreprise vend Dify Cloud et une édition Enterprise avec SSO, gestion fine des droits et support. La Community Edition auto-hébergée contient l'essentiel des fonctions.
Cinq types d'applications
Dify ne propose pas un seul canevas, mais plusieurs modèles d'application selon le besoin :
| Type | Usage |
|---|---|
| Chatbot | Assistant conversationnel simple, prompt et base de connaissances |
| Générateur de texte | Une entrée, une sortie : résumé, traduction, rédaction |
| Agent | Un modèle qui choisit lui-même ses outils pour atteindre un but |
| Chatflow | Conversation pilotée par un workflow en plusieurs étapes |
| Workflow | Traitement automatisé sans conversation, déclenché par API ou planning |
Les workflows se construisent sur un canevas avec des nœuds : appel de modèle, recherche dans une base de connaissances, condition, boucle, code Python ou JavaScript, requête HTTP, outil. Chaque application s'exporte dans un fichier YAML, le « DSL » de Dify, qui se versionne et se réimporte sur une autre instance.
La base de connaissances
C'est la partie la plus aboutie. On dépose des PDF, des documents Word, des pages Notion ou un site entier, et Dify gère la chaîne complète : extraction du texte, découpage, embeddings, indexation, recherche hybride par mots-clés et par sens, reclassement des résultats. Chaque morceau reste consultable et modifiable à la main, ce qui permet de corriger un passage mal découpé sans tout réindexer.
Les réglages sont exposés sans être imposés. Un débutant garde les valeurs par défaut, un développeur ajuste la taille des morceaux, le modèle d'embedding ou le seuil de pertinence. Depuis la 1.17.1, une clé d'API peut être limitée à une seule base de connaissances, et non plus à tout l'espace de travail.
Publier et intégrer
Chaque application publiée reçoit une page web partageable, un widget à intégrer dans un site, et une API :
curl -X POST "http://localhost/v1/chat-messages" \
-H "Authorization: Bearer app-xxxxxxxx" \
-H "Content-Type: application/json" \
-d '{
"inputs": {},
"query": "Combien de jours de télétravail par semaine ?",
"response_mode": "blocking",
"user": "salarie-42"
}'L'onglet « Journaux » garde chaque conversation, avec les passages récupérés, les tokens consommés et le temps de réponse. On peut annoter une mauvaise réponse pour corriger le comportement, et brancher des outils d'observabilité comme Langfuse ou Arize Phoenix pour aller plus loin.
Les modèles : du cloud au local
Dify se branche sur des centaines de modèles via des plugins : OpenAI, Anthropic, Google, Mistral, et tout serveur compatible avec l'API OpenAI. Avec Ollama pour faire tourner un modèle en local, modèle de chat et modèle d'embedding compris, aucune donnée ne quitte votre infrastructure.
C'est un argument fort pour une entreprise française. Une base de connaissances RH ou juridique contient des données personnelles, et les envoyer à un fournisseur américain soulève des questions que détaille l'article sur le RGPD face à l'IA. Dify auto-hébergé avec un modèle local, ou avec un fournisseur européen, règle une bonne partie du problème.
Installer avec Docker Compose
Il faut au moins 2 cœurs et 4 Go de mémoire, Docker et Docker Compose 2.24 ou plus :
git clone https://github.com/langgenius/dify.git --branch 1.17.1
cd dify/docker
cp .env.example .env
docker compose up -dL'assistant d'installation s'ouvre sur http://localhost/install pour créer le compte administrateur. La pile démarre une dizaine de conteneurs : API, workers, interface web, PostgreSQL, Redis, Nginx, une base vectorielle Weaviate (d'autres sont disponibles, dont pgvector et Qdrant), un bac à sable pour exécuter le code des workflows, un proxy qui filtre ses requêtes sortantes, et le démon de plugins.
Avant d'exposer l'instance, ouvrez le .env. Le mot de passe de PostgreSQL y vaut difyai123456, connu de tous puisqu'il est dans le dépôt, comme celui de Redis, la clé du bac à sable et celle du démon de plugins. Changez-les avant le premier démarrage. La SECRET_KEY, elle, est générée automatiquement si on la laisse vide. Pour une mise en ligne sans écrire la configuration du reverse proxy, Coolify et son catalogue d'applications propose Dify en déploiement en un clic.
Les mises à jour demandent de l'attention
Une pile de dix services ne se met pas à jour à l'aveugle. La 1.17.1 en donne un bon exemple : la version de Weaviate fournie avec Dify saute douze versions mineures, et les notes de version préviennent en gras que tirer les nouvelles images et redémarrer peut casser définitivement la recherche vectorielle. Il faut suivre une migration manuelle par étapes.
Ma méthode : épingler la version dans le git clone, lire les notes de version avant chaque mise à jour, et sauvegarder les volumes de PostgreSQL et de la base vectorielle avant de toucher à quoi que ce soit.
Dify Agent : puissant, à réserver aux utilisateurs de confiance
La version 1.16, en juillet, a introduit Dify Agent, en bêta. L'agent travaille dans un bac à sable Linux : il exécute des commandes, installe des logiciels, manipule des fichiers et utilise des « skills » qu'on lui fournit. La 1.17 a ajouté la possibilité d'exécuter ce bac à sable chez E2B plutôt qu'en local.
Les notes de version sont explicites : ce service ne doit être proposé qu'à des utilisateurs de confiance. Un agent qui exécute des commandes est un agent qu'on peut détourner. Sur une instance ouverte à toute l'entreprise, je le désactiverais, ou je l'isolerais sur une machine dédiée.
La licence n'est pas tout à fait Apache 2.0
C'est le point à lire avant de bâtir un produit sur Dify. Le dépôt est publié sous la « Dify Open Source License », une licence Apache 2.0 avec des conditions supplémentaires :
- Pas de multi-locataire sans autorisation écrite : vous ne pouvez pas utiliser Dify pour héberger plusieurs clients dans des espaces de travail séparés, à la manière d'un SaaS.
- Logo et mentions : si vous utilisez l'interface web de Dify, vous ne pouvez pas retirer ou modifier le logo et les mentions de copyright.
- Contributions : l'éditeur se réserve le droit de rendre la licence plus stricte, et peut utiliser le code des contributeurs dans son offre commerciale.
Pour un usage interne, une instance pour votre entreprise ou votre équipe, aucune de ces clauses ne gêne. Pour revendre une plateforme d'assistants IA en marque blanche à vos clients, il faut une licence commerciale. Ce n'est donc pas de l'open source au sens de l'Open Source Initiative, et c'est une différence nette avec la licence MIT de Langflow.
Dify ou Langflow ?
Les deux outils ont un canevas et des nœuds, mais pas la même cible. Langflow, l'éditeur visuel d'agents s'adresse aux développeurs : chaque composant est une classe Python modifiable, et les flows deviennent des API ou des serveurs MCP. Dify s'adresse à une équipe produit : applications publiées, base de connaissances gérable par un non-développeur, journaux, annotations, comptes utilisateurs.
Si la personne qui mettra à jour les documents de la base de connaissances n'est pas développeur, je choisirais Dify.
Dify est l'outil le plus complet que je connaisse pour faire vivre une application LLM au-delà de la démo. Base de connaissances, publication, journaux, choix du modèle : tout est là, auto-hébergeable, et l'interface est assez claire pour qu'une équipe métier s'en serve seule. Sa licence et ses mises à jour demandent juste plus d'attention qu'un projet MIT ordinaire. Lisez les deux avant de le mettre en production.