Avec 148 000 étoiles sur son dépôt GitHub, Dify tourne, selon son éditeur LangGenius, sur plus de 1,4 million de machines dans plus de 175 pays, avec plus de 2 000 équipes et 280 entreprises qui l'exploitent en version commerciale. Le projet a levé 30 millions de dollars en série Pre-A en mars 2026, un tour mené par HSG avec GL Ventures et 5Y Capital, de quoi financer une feuille de route centrée sur l'agentique et l'entreprise. Peu de guides vont au-delà du tutoriel "créez un chatbot en cinq minutes" pour parler de la clause de licence qui bloque la revente en SaaS multi-tenant, ou du système de crédits de messages qui remplace le comptage à l'appel.
Sur les projets où Noxcod branche un agent sur la documentation d'un client, Dify revient dès que le besoin dépasse le chatbot scripté : une base de connaissances propre, une API stable à appeler depuis une application existante, un historique de conversations pour auditer ce que l'agent a répondu. La suite détaille comment démarrer, où se situe le vrai plafond du plan gratuit, et ce que la licence open source autorise réellement.
Dify, un backend pour applications LLM plutôt qu'un canevas d'agent
Le positionnement se lit dans le nom que l'éditeur donne au produit : une plateforme de développement d'applications LLM, pas un simple constructeur d'agents. Dify permet de créer des agents, des workflows agentiques et des chatbots qui s'appuient sur des données propres, puis de les publier comme applications web ou de les intégrer par API. Quatre types d'application cohabitent dans le même espace de travail : le chatbot conversationnel, l'agent qui décide d'appeler des outils, le workflow qui enchaîne des étapes déterministes, et le générateur de texte pour une tâche ponctuelle comme un résumé ou une classification.
Ce qui distingue Dify d'un canevas comme Flowise tient à ce qui est natif plutôt qu'ajouté après coup. La base de connaissances et le pipeline RAG font partie du cœur du produit, avec de la recherche hybride, du reranking et de la récupération parent-enfant pour améliorer la précision quand un document compte plusieurs centaines de pages, d'après la documentation officielle de la base de connaissances Dify. Chaque application publiée reçoit aussi un point d'API REST par défaut, pensé pour être appelé depuis un produit existant plutôt que pour rester un prototype isolé dans son propre canevas.
Pour qui c'est fait : une équipe qui veut assembler un agent ou un chatbot branché sur sa documentation, avec une API stable à intégrer ailleurs, sans écrire le pipeline RAG (découpage, embeddings, recherche vectorielle) à la main.
S'installer sur Dify : cloud managé ou auto-hébergement Docker
Deux chemins d'accès, à trancher avant de créer la première application. Le plan Sandbox du cloud managé est gratuit et inclut 200 crédits de messages, un espace de travail, un membre, cinq applications et 50 Mo de stockage de connaissances, suffisant pour tester le produit seul mais pas pour le montrer à une équipe sur plusieurs semaines. Le plan Professional, facturé 590 dollars par an, monte à 5 000 crédits de messages par mois, trois membres, 50 applications et 5 Go de stockage. Le plan Team, à 1 590 dollars par an, passe à 10 000 crédits mensuels, 50 membres, 200 applications et 20 Go de stockage, avant un palier Enterprise sur devis pour le SSO et le déploiement dédié.
L'auto-hébergement reste gratuit sous licence Dify Open Source, une variante d'Apache 2.0 avec des conditions supplémentaires détaillées plus bas. L'installation officielle demande au minimum 2 cœurs CPU, 4 Go de RAM et Docker Compose en version 2.24.0 ou supérieure, puis trois commandes : cloner le dépôt sur la dernière version taguée, copier .env.example en .env dans le dossier docker, et lancer docker compose up -d. Le déploiement démarre six services applicatifs et six composants dépendants (base de données, cache, moteur de recherche), accessibles ensuite sur http://localhost/install pour la configuration initiale.
Construire une première application avec une base de connaissances RAG
La prise en main suit une logique commune aux quatre types d'application, que l'agent soit un chatbot simple ou un workflow multi-étapes.
Première étape : depuis le tableau de bord, "Créer depuis un modèle" ou "Créer depuis zéro" ouvre le choix entre chatbot, agent, workflow ou générateur de texte. Un agent qui doit répondre à partir d'une documentation interne part généralement du type chatbot avec le mode agent activé, qui autorise l'appel d'outils en plus de la génération de texte.
Deuxième étape : la connexion du modèle de langage, dans les paramètres du fournisseur de modèle, où une clé API OpenAI, Anthropic, Mistral, ou un modèle auto-hébergé via Ollama, se configure une fois pour tout l'espace de travail plutôt que pour chaque application séparément.
Troisième étape : la création d'une base de connaissances, dans l'onglet Knowledge. Les documents s'y importent, se découpent automatiquement en segments dont la taille se règle à la main pour les documents longs, puis s'indexent en base vectorielle avec un modèle d'embedding au choix.
Quatrième étape : le rattachement de cette base à l'application, dans le contexte de l'éditeur de prompt, avec le choix entre recherche vectorielle seule, recherche plein texte, ou recherche hybride avec reranking pour les cas où la précision prime sur la vitesse de réponse.
Cinquième étape : le test, dans le panneau de prévisualisation intégré à l'éditeur, qui affiche le prompt final envoyé au modèle avec les segments de contexte récupérés, utile pour comprendre pourquoi une réponse s'appuie sur le mauvais passage d'un document.
Dernière étape : la publication, qui expose l'application comme site web autonome avec un lien partageable, comme widget embarquable sur un site existant, ou comme point d'API REST avec une clé dédiée, le chemin que suivent la plupart des intégrations dans une application déjà en production chez un client.
Les crédits de messages qui surprennent après le prototype
Le système de facturation de Dify Cloud compte en crédits de messages plutôt qu'en appels API bruts, une distinction qui compte au moment de dimensionner un plan. Un message simple consomme un crédit, mais un agent qui enchaîne plusieurs appels d'outils, ou une réponse qui déclenche plusieurs requêtes de récupération dans une grosse base de connaissances, peut consommer plusieurs crédits pour une seule question posée par l'utilisateur final.
Sur les projets suivis par Noxcod, le plan Sandbox gratuit tient rarement plus d'une phase de démonstration interne : ses 200 crédits mensuels s'épuisent en quelques jours dès qu'une équipe de plus de deux personnes teste l'application en continu, ce qui impose de passer au Professional, puis au Team dès qu'un deuxième cas d'usage vient s'ajouter au premier.
Deuxième surprise, plus discrète : la grille tarifaire de Dify ne couvre pas le coût du modèle de langage sous-jacent. Une clé API OpenAI, Anthropic ou Mistral reste facturée séparément par le fournisseur du modèle, et ce coût suit le volume réel de tokens échangés, pas le nombre de crédits Dify consommés. Un agent RAG qui relit plusieurs segments de contexte à chaque question fait grimper ce coût plus vite qu'un chatbot simple, une dérive qui touche la plupart des plateformes de ce type, pas seulement Dify.
La clause de licence que peu de guides mentionnent
Le dépôt GitHub de Dify affiche une licence Apache 2.0 modifiée, ce que l'éditeur appelle la Dify Open Source License, et deux clauses supplémentaires changent ce qu'on a le droit de construire par-dessus. Le texte de la licence interdit d'utiliser le code source de Dify pour opérer un environnement multi-tenant sans autorisation écrite de l'éditeur, un tenant étant défini comme un espace de travail avec ses propres données et sa propre configuration.
Concrètement, auto-héberger Dify pour un usage interne ou pour un client unique reste couvert par la licence gratuite. Construire un produit SaaS qui provisionne un espace Dify par client, le modèle économique d'une offre "IA conversationnelle" revendue à plusieurs entreprises sur la même instance, franchit cette limite et demande une licence commerciale. La licence interdit aussi de retirer ou modifier le logo et les mentions de copyright dans la console Dify, une restriction qui ne touche que l'interface front-end, pas une intégration purement backend passée par l'API.
Ce point ne figure presque jamais dans les tutoriels d'installation, alors qu'il détermine si Dify reste un outil interne ou peut servir de socle à un produit revendu. Flowise, sous licence Apache 2.0 sans clause multi-tenant équivalente en dehors de son dossier enterprise sous licence commerciale séparée, ne pose pas la même limite dans son cœur open source, ce qui pèse dans le choix quand le projet final est un produit multi-clients plutôt qu'un usage interne à une seule entreprise.
Dify, Flowise, n8n : quel outil pour quel projet
La question revient à chaque prototype : pourquoi ne pas simplement ajouter un nœud IA à un flow n8n existant, ou construire l'agent sur un canevas comme Flowise déjà connu de l'équipe ? La réponse dépend de ce qui domine dans le projet réel.
n8n reste la référence pour connecter des dizaines d'applications métier autour de déclencheurs et de webhooks, avec un nœud IA comme brique parmi d'autres. Flowise part du canevas d'agent conversationnel, sans backend applicatif complet construit autour. Dify se positionne entre les deux : une base de connaissances RAG native, quatre types d'application prêts à publier, et une API REST par défaut pensée pour être appelée depuis un produit existant plutôt que pour rester un prototype isolé.
Un projet qui doit surtout répondre sur une documentation interne volumineuse avec une API stable à intégrer se construit plus directement sur Dify. Un flux qui doit surtout synchroniser des données entre outils métier reste plus rapide à assembler sur n8n. Un prototype d'agent conversationnel simple, sans besoin de RAG poussé, part plus vite sur Flowise. Les trois s'assemblent aussi : sur plusieurs projets clients, n8n orchestre en coulisses les tâches périodiques qui alimentent la base de connaissances que Dify sert ensuite à l'utilisateur final.
Aller plus loin : de l'application Dify au projet d'agence
Une application qui répond bien en test ne suffit pas à un déploiement en production, la même règle que pour n'importe quel projet logiciel. Le versioning des applications, la supervision des crédits consommés par utilisateur, et la question de savoir qui détient les clés API des fournisseurs de modèle reviennent systématiquement une fois le prototype validé, et rejoignent les questions de gouvernance qui structurent plus largement l'adoption de l'IA agentique en entreprise. Le marché de l'IA en tant que service, dans lequel s'inscrit ce type de plateforme, est estimé à 16,08 milliards de dollars en 2024 et devrait atteindre 105,04 milliards de dollars d'ici 2030 selon Grand View Research, un rythme de croissance qui explique pourquoi autant de plateformes candidates au même usage sortent chaque trimestre.
Sur ce type de passage à l'échelle, Noxcod accompagne le choix entre cloud managé et auto-hébergement, la vérification de la clause de licence avant tout projet multi-clients, et la mise en production d'applications construites avec des outils comme Dify via notre agence spécialisée dans les agents IA sur mesure. Un projet dont le volume de crédits ou la sensibilité des données dépasse ce qu'un plan Dify couvre confortablement gagne à être chiffré avant de s'engager, via un appel avec notre équipe.
Questions fréquentes
Dify est-il vraiment gratuit ?
Le plan Sandbox du cloud managé est gratuit avec 200 crédits de messages par mois et 50 Mo de stockage, ou l'auto-hébergement complet sous licence open source, sans limite de crédits mais avec l'infrastructure à sa charge. Le plafond du plan gratuit se franchit vite dès qu'une équipe l'utilise en continu plutôt que pour un test individuel.
Faut-il savoir coder pour construire une application avec Dify ?
Non pour un chatbot ou un agent standard : connecter un modèle, une base de connaissances et un outil se fait par l'interface, sans écrire de code. Un workflow avec une logique conditionnelle complexe ou un appel d'API métier spécifique demande en revanche de configurer un nœud de code ou une fonction personnalisée.
Peut-on héberger Dify soi-même pour rester conforme au RGPD ?
Oui, la licence open source autorise l'auto-hébergement complet sur un serveur en France ou dans l'Union européenne, via Docker Compose avec au minimum 2 cœurs CPU et 4 Go de RAM. Le choix du fournisseur du modèle de langage reste à vérifier séparément : sa politique de localisation des données ne suit pas automatiquement celle de l'hébergement Dify.
Peut-on revendre un produit construit avec Dify à plusieurs clients ?
Cela dépend de l'architecture. La licence open source interdit d'opérer un environnement multi-tenant, plusieurs espaces de travail cloisonnés sur la même instance, sans autorisation écrite de l'éditeur. Un déploiement mono-tenant, une instance par client, reste couvert par la licence gratuite.
Quelle est la différence entre Dify et Flowise ?
Flowise part d'un canevas visuel pour assembler des chaînes et des agents. Dify part d'une base de connaissances RAG native et de quatre types d'application publiables directement en API, avec un système de crédits de messages plutôt qu'un compteur de prédictions. Le choix dépend surtout du poids du RAG documentaire dans le projet à construire.
