Dify et Flowise

Comment ça marche

Dify et Flowise proposent une toile sur laquelle on assemble des blocs : un modèle de langage, une consigne, une base de documents indexés, une mémoire de conversation, des outils externes, des conditions. En reliant les blocs, on obtient un assistant qui répond à partir de vos documents, un agent qui appelle des outils, un flux qui classe et route des demandes. On teste dans l’interface, on ajuste, on publie sous forme d’interface de chat ou d’API. Les deux sont open source et s’installent sur un serveur de l’entreprise.

Leur intérêt principal est la vitesse de prototypage. Un RAG sur un dossier de documents se monte en une matinée, et l’équipe métier peut le tester l’après-midi. On apprend vite si l’idée tient : les documents suffisent-ils, les réponses sont-elles justes, les utilisateurs y reviennent-ils. Si oui, on consolide, dans l’outil pour un usage interne modéré, ou en développement pour un usage plus exigeant. Si non, on a perdu une journée au lieu d’un trimestre.

Un exemple concret

1. Matin, jour 1 : le responsable RH et un informaticien montent dans Dify, installé sur un serveur interne, un assistant qui répond aux questions des salariés à partir de la convention collective, du règlement intérieur et des procédures RH. Un modèle par API, les documents déposés, une consigne de périmètre.
2. Après-midi, jour 1 : dix salariés testent avec leurs vraies questions. 70 % de réponses justes et sourcées, 20 % de « je ne trouve pas », 10 % d’erreurs, dont deux sur les congés, dues à un document périmé.
3. Semaine 1 : documents mis à jour, consigne affinée, escalade vers la RH pour toute question sur une situation individuelle. 90 % de réponses justes au second test.
4. Mois 2 : ouvert à tous les salariés, en interne, avec une mention claire de ce qu’il fait et ne fait pas. 400 questions le premier mois ; la RH en reçoit un tiers de moins.
5. La décision reportée : une version plus robuste, développée, est envisagée si l’usage grandit. Pour l’instant, l’outil visuel suffit.

L’idée a été validée en un jour et déployée en deux mois, sans projet informatique. Le prototype est devenu l’outil.

Ce que ça change pour une équipe

• Un prototype en une journée. On teste une idée d’assistant ou de RAG avant de parler budget.
• Le métier participe à la construction. La toile se comprend ; le responsable métier ajuste lui-même la consigne et les documents.
• Auto-hébergé, les données restent en interne. Avec un modèle local, rien ne sort du tout.
• Le prototype devient spécification. Si l’usage exige du développement, le prototype dit exactement quoi construire.

Les limites et les erreurs fréquentes

• Mettre en production un prototype sans surveillance. Un outil visuel sans tests ni journaux tombe sans qu’on le sache. Hébergement et suivi sérieux.
• La logique complexe sur une toile. Au-delà de quelques dizaines de blocs, plus personne ne comprend. Un signe qu’il faut développer.
• Oublier la mise à jour des documents. Un RAG sur des procédures périmées répond faux avec assurance. Un responsable et une date de revue par document.
• Le prototype qui dure. Parce que « ça marche », on ne consolide jamais. Fixer dès le départ les critères qui déclencheront la version suivante.