Toonflow : un atelier Electron pour transformer un roman en短剧 animé

Le problème visé : recoller les étapes d'une adaptation

Adapter un roman en短剧 suppose d'extraire une intrigue, de la découper en scènes, de fixer l'apparence des personnages, puis de générer des images et des plans vidéo cohérents. Ces étapes vivent d'ordinaire dans des outils séparés, et chaque passage de relais fait perdre le contexte : le modèle de storyboard ne sait pas ce que le modèle d'écriture a décidé au chapitre précédent. Toonflow attaque ce point précis en réunissant les étapes dans une seule application de bureau. Le README décrit un enchaînement explicite :策划, 编剧, 分镜, 出片. La cible annoncée est le créateur de contenu court et l'expérimentateur qui veut porter un texte long à l'écran sans assembler cinq services. Le dépôt assume aussi une orientation industrielle, avec l'expression 批量产出, production en lot. C'est un choix : l'outil est pensé pour la répétition, pas pour une pièce unique très travaillée.

Trois couches d'agents et une mémoire locale en ONNX

L'architecture annoncée dans le README repose sur trois couches d'agents : décision, exécution, supervision. La couche de décision décompose la tâche, la couche d'exécution produit le contenu, la couche de supervision relit et renvoie des corrections. Le README présente ce dispositif comme un moyen d'améliorer la stabilité et la cohérence du résultat final, sans donner de mesure. À cela s'ajoute une mémoire persistante décrite comme reposant sur une recherche vectorielle ONNX exécutée en local, avec messages à court terme, résumés à long terme et rappel sémantique entre sessions. C'est le mécanisme qui rend crédible la continuité sur plusieurs épisodes : sans lui, chaque nouveau passage du modèle repartirait de zéro. Autre pièce du dispositif, le graphe d'événements par chapitre : les événements du texte source sont extraits et stockés de façon structurée, puis le contexte est convoqué par événement plutôt que par gros blocs de texte. Le README justifie ce choix par la perte d'information sur les textes longs. Ces trois éléments forment un ensemble cohérent, mais il faut noter que le dépôt ne documente pas, dans les extraits fournis, la manière dont les conflits entre couches de supervision sont arbitrés.

Le canevas infini comme unité de travail

L'interface de production n'est pas un formulaire séquentiel mais un canevas sans bord, où scripts, personnages, storyboards, ressources et nœuds vidéo coexistent. Le README insiste sur la liberté d'organisation, le retour en arrière et la production parallèle, hors contrainte linéaire. Concrètement, cela veut dire qu'un plan peut être retravaillé indépendamment du reste, puis réinjecté dans l'atelier pour l'assemblage et l'export. Cette organisation a un coût : elle déplace la charge de la structure vers l'utilisateur. Rien dans le matériel fourni n'indique un garde-fou automatique qui empêcherait un projet de devenir un graphe illisible après plusieurs dizaines de nœuds. Un outil à étapes imposées protège de ce désordre ; Toonflow choisit l'inverse et en assume les conséquences.

Les fournisseurs se codent en TypeScript, sans redémarrage

Le point le plus inhabituel du projet est le système de fournisseurs programmable. Le README indique que l'on peut écrire la logique d'un fournisseur en TypeScript directement depuis le centre de réglages, et qu'elle prend effet immédiatement, sans modifier le code source ni redémarrer l'application. Le même document mentionne la privatisation et le branchement de plusieurs modèles comme motivations. Pour une équipe qui veut garder ses clés et ses points d'accès chez elle, c'est un argument concret : le fournisseur devient un fichier de configuration exécutable, pas un adaptateur à recompiler. La contrepartie est évidente et le README ne la masque pas vraiment : exécuter du code écrit par l'utilisateur dans une application de bureau suppose une confiance dans la provenance de ce code. Rien dans les extraits fournis ne décrit de bac à sable, de validation ou de permissions autour de ces scripts. C'est un point à instruire avant tout déploiement en équipe.

Prompts externalisés et mise en route réelle

Les prompts centraux de ScriptAgent et ProductionAgent sont sortis du code sous forme de fichiers Skill en Markdown, éditables en ligne. Cela signifie qu'un ajustement de ton ou de format se fait dans un fichier texte, pas dans une chaîne TypeScript enfouie. Le README ne précise pas où ces fichiers résident sur le disque, ni s'ils sont versionnés avec le projet ; c'est une lacune documentaire à combler soi-même. La mise en route, telle que décrite, tient en quelques étapes : lancer l'application et se connecter avec le compte par défaut admin / admin123, configurer les fournisseurs de modèles texte, image et vidéo dans le centre de réglages, créer un projet, importer l'œuvre source et lancer l'extraction des événements par chapitre. Vient ensuite ScriptAgent pour la trame, la stratégie d'adaptation et le script structuré, puis ProductionAgent pour organiser storyboards, ressources et nœuds vidéo sur le canevas, avant l'ajustement plan par plan et l'export. Le couple admin/admin123 est un identifiant par défaut documenté : le changer est la première manipulation à prévoir.

Ce que le dépôt ne permet pas de conclure

Le README avance une efficacité multipliée par dix et un gain de temps massif. Aucune de ces affirmations n'est étayée dans le matériel fourni : pas de protocole, pas de jeu de test, pas de mesure reproductible. La démonstration citée, environ deux heures pour un épisode couvrant écriture, storyboard et montage, reste une vitrine et non une référence. De même, la configuration matérielle requise pour la recherche vectorielle ONNX locale et pour la génération vidéo n'est pas décrite. Autre angle mort : le comportement en cas d'échec d'un fournisseur. Le dépôt ne dit pas si un nœud vidéo en erreur bloque l'ensemble du canevas ou peut être contourné. Enfin, la licence Apache-2.0 couvre le code du projet, mais rien n'indique comment sont traités les droits sur les œuvres importées ni sur les sorties générées ; cette question relève de votre propre analyse, pas de celle du dépôt.

Face à un pipeline ComfyUI assemblé à la main

L'alternative la plus proche n'est pas un autre produit packagé mais un assemblage personnel autour de ComfyUI, où graphes de génération d'images et de vidéo sont construits nœud par nœud. La différence d'approche est nette. ComfyUI expose le graphe de génération lui-même : on contrôle le sampler, le modèle, le conditionnement, et l'on peut reproduire un rendu au détail près. Toonflow se place un cran au-dessus et prend en charge l'orchestration narrative, l'extraction d'événements, la mémoire de session et la gestion des fournisseurs ; en échange, l'accès au graphe de génération passe par la couche fournisseur TypeScript, donc par du code à écrire. Si votre difficulté est la cohérence d'un récit sur plusieurs épisodes, Toonflow attaque le bon problème. Si votre difficulté est le contrôle fin du rendu image par image, ComfyUI reste plus direct, au prix de tout le travail narratif à votre charge. Les deux ne s'excluent pas : le système de fournisseurs de Toonflow est précisément l'endroit où un tel branchement se discute.

Suivi des versions et coût de maintenance

Le rythme de publication est soutenu : v1.1.6 en avril 2026, v1.1.7 en mai, v1.1.8 en juin, avec un dernier push sur master en août 2026. Un rythme pareil sur une application Electron signifie que les interfaces entre couches bougent, et que les fichiers Skill Markdown peuvent demander des retouches après mise à jour. Le coût réel d'adoption n'est donc pas l'installation, mais la surveillance des notes de version à chaque saut de mineure. La licence Apache-2.0 autorise l'usage commercial, la modification et la redistribution, à condition de conserver les mentions de copyright et le fichier de licence, et d'indiquer les fichiers modifiés ; elle comporte aussi une clause de brevets. Elle n'accorde aucun droit sur les modèles tiers que vous branchez, ni sur les œuvres que vous faites entrer dans l'outil. Ces deux points se traitent séparément, et ce texte ne constitue pas un avis juridique.

Conclusion éditoriale

Toonflow s'adresse aux créateurs et petites équipes qui veulent garder la main sur les modèles et le pipeline, pas à ceux qui cherchent un service hébergé. Avant d'investir du temps, vérifiez trois choses dans le dépôt : la configuration du provider dans le centre de réglages, la présence des fichiers Skill Markdown de ScriptAgent et ProductionAgent, et la façon dont vous remplacerez le couple admin/admin123.

Sources officielles

1. HBAI-Ltd/Toonflow-app on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases