Dify 1.19 : traçage des workflows imbriqués et nouveau format d'export, une mise à jour à préparer

Dify permet de construire des assistants et des automatisations IA à la souris, en reliant des blocs : un modèle, une base documentaire, des outils. Beaucoup de petites structures l'installent sur leur propre serveur. La version 1.19.0, publiée le 4 novembre sur GitHub, suit de près la 1.18.0 du 23 octobre.

Ce qui change à l'usage

• Des traces complètes. Dans Dify, un workflow peut être appelé comme outil par un autre. Jusqu'ici, l'outil d'observabilité branché sur la plateforme ne voyait pas l'intérieur de ces appels. Leurs étapes sont désormais transmises, rangées sous l'appel d'outil, avec les prompts, les réponses et la consommation de tokens. Les traces déjà exportées ne sont pas complétées après coup.
• Des applications plus faciles à déplacer. L'export d'une application embarque les workflows qui se trouvent derrière ses outils, dépendances comprises, dans la limite de 20 par paquet par défaut. À l'import, les outils existants sont réutilisés et les manquants recréés.
• Format de paquet v2. Tous les exports passent à ce format. Une instance plus ancienne peut refuser ces paquets : mettez à jour la destination avant d'y importer quoi que ce soit. Les paquets v1 restent acceptés en 1.19.0.
• Compétences en ligne de commande. L'outil difyctl reçoit six commandes pour lister, exporter, importer et publier des compétences (« Skills »). Un import ne publie rien de lui-même.

La 1.18.0 avait déjà apporté des agents capables d'orienter un workflow vers une branche ou une autre, et une base de connaissances pour agents en bêta, désactivée par défaut, qui demande son propre service et sa propre base de données.

Ce qu'il faut vérifier avant de mettre à jour

• Docker Compose 2.35.0 au minimum.
• Tout mettre à jour ensemble : API, workers, interface web, backend des agents et bac à sable local doivent être en 1.19.0.
• File d'attente des traces. Elle change de nom par défaut (ops_trace_v2). Si vous avez personnalisé la liste des files de vos workers, ajoutez-la, sans purger l'ancienne tant que le travail en cours n'est pas terminé.
• Migrations de base. Depuis la 1.18.0, six révisions s'appliquent. L'une supprime les configurations de traçage en double, en gardant la plus récente, et ces lignes ne sont pas restaurées en cas de retour arrière. La sauvegarde préalable n'est pas une formalité.
• Depuis une version antérieure à la 1.18.0, il faut aussi suivre le guide de la 1.18.0, qui comporte ses propres ruptures.

Pour une installation Docker Compose classique, les notes donnent la séquence suivante, à exécuter dans une fenêtre de maintenance et après sauvegarde :

cd dify/docker
docker compose stop -t -1
git fetch --tags
git checkout 1.19.0
docker compose pull
docker compose up -d

Les changements de configuration sont à reporter dans vos fichiers d'environnement avant le pull.

Sécurité

Les notes listent plusieurs durcissements : les identifiants de traçage enregistrés ne sont plus renvoyés par l'API, l'activation des modèles d'un fournisseur exige un rôle de propriétaire ou d'administrateur, et la portée des jetons d'accès aux jeux de données est resserrée. Plusieurs dépendances sont relevées. Aucun identifiant CVE n'est cité, et l'éditeur ne prétend pas avoir traité tous les signalements visant les images de base.

Les limites

Le projet avance vite : deux versions en moins de deux semaines, chacune avec ses ruptures. Sa licence, la « Dify Open Source License », repose sur Apache 2.0 avec des conditions supplémentaires : le texte est à lire avant de revendre un service bâti dessus.

Notre lecture

Si Dify fait tourner chez vous quelques assistants internes, rien ne presse : attendez un moment calme, sauvegardez base, fichiers et secrets, puis mettez à jour d'un bloc. Le traçage imbriqué justifie en revanche d'y passer rapidement pour qui doit expliquer le coût ou une erreur d'un workflow composé. Une habitude à prendre : conservez la liste de vos réglages personnalisés, car chaque version en déplace quelques-uns.