TauriTavern : SillyTavern empaqueté en application native Tauri/Rust

Le problème concret : Node.js comme prérequis

SillyTavern se distribue comme une application Node.js que l'on lance depuis un terminal. TauriTavern attaque précisément cette couche : le README annonce «不需要安装 Node.js，不需要命令行，安装即用», c'est-à-dire aucune installation de Node.js, aucune ligne de commande, une application installée et utilisable. Le public visé est donc double. D'un côté des utilisateurs de SillyTavern qui veulent conserver leurs données (cartes de personnages, historiques de conversation, presets, world books, extensions frontend) sans entretenir une chaîne Node. De l'autre, des utilisateurs mobiles : le dépôt publie des builds Android et une distribution iOS via TestFlight, ce qui n'a pas d'équivalent direct avec un serveur Node lancé à la main sur un téléphone. Le projet se présente explicitement comme indépendant : «TauriTavern 是独立维护的开源项目，并非 SillyTavern 官方客户端». Ce n'est pas un détail de communication, c'est la clé pour comprendre qui maintient quoi et où signaler un bug de rendu du frontend par rapport à un bug du backend Rust.

Ce que le workspace Cargo sépare réellement

Le backend est un workspace Cargo organisé selon une Clean Architecture, avec les crates sous src-tauri/crates/. Le crate tauritavern joue le rôle de composition root : il héberge le host Tauri et la couche de commandes. En dessous, tt-application, tt-ports, tt-domain et tt-contracts portent respectivement les cas d'usage, les ports, le modèle de domaine et les contrats partagés entre crates. Les implémentations concrètes sont dans les crates tt-adapter-*, qui couvrent le stockage, le HTTP, les médias, la synchronisation, les extensions et la tokenisation. Côté interface, le frontend reste celui de SillyTavern, augmenté d'une couche d'injection Tauri modulaire dans src/tauri/main/, et la communication avec le backend passe par une ABI de plateforme exposée sous window.__TAURITAVERN__. Deux documents sont cités pour approfondir : docs/BackendStructure.md et docs/FrontendGuide.md. Cette séparation a une conséquence pratique : la frontière entre le code hérité de l'amont et le code propre au projet est nette, ce qui rend les points de rupture identifiables lors d'une resynchronisation avec SillyTavern.

Installer sans terminal, ou presque

Le chemin recommandé est la page de téléchargement, qui détecte la plateforme et renvoie vers la dernière version stable. Des canaux par gestionnaire de paquets existent aussi. Sous Windows avec Scoop : scoop bucket add Darkatse https://github.com/Darkatse/Scoop-Darkatse.git puis scoop install Darkatse/TauriTavern. Sous macOS : brew install --cask tauritavern. Sous Arch Linux, le paquet AUR tauritavern-bin est maintenu par un tiers, avec yay -S tauritavern-bin. Pour Debian, Ubuntu, Fedora, openSUSE et NixOS, un script détecte la distribution : curl -fsSL https://raw.githubusercontent.com/Darkatse/TauriTavern/main/scripts/install-linux.sh | sh. Les utilisateurs de Nix disposent de nix profile add github:Darkatse/TauriTavern#tauritavern, et un dépôt Flatpak est publié sous com.tauritavern.client. Deux contraintes sont à retenir. La version portable Windows exige que le runtime WebView2 soit déjà présent sur le système. Et sur iOS, l'installation passe par TestFlight, avec iOS 16 minimum et les limites imposées par Apple à ce canal.

Canary : une fréquence quotidienne assumée

Le dépôt distingue clairement deux canaux. La version stable suit des tags numérotés, par exemple v2.2.0 et v2.1.1. Le canal Canary est mis à jour chaque jour et le README le décrit sans détour : il contient les derniers correctifs, mais sa stabilité peut être inférieure à celle de la stable. Le projet recommande d'ailleurs de l'essayer lorsqu'un problème apparaît en stable, pour vérifier s'il a déjà été corrigé. Pour Linux, le basculement se fait avec curl -fsSL https://raw.githubusercontent.com/Darkatse/TauriTavern/main/scripts/install-linux.sh | sh -s -- --channel canary, et sous Nix avec nix profile add github:Darkatse/TauriTavern/Canary#canary. C'est un choix de maintenance cohérent avec un projet qui suit un frontend amont actif, mais il déplace la charge de validation vers l'utilisateur. Si vous ne pouvez pas absorber une régression en cours de semaine, restez sur les tags numérotés : c'est le seul canal dont le rythme est lisible dans les releases fournies.

Synchronisation, migrations et extensions : trois périmètres distincts

Trois fonctions annexes méritent d'être séparées, car elles n'ont pas le même niveau de maturité apparent. La synchronisation multi-appareils est décrite comme un appairage chiffré sur le réseau local, avec une alternative d'envoi automatique via un service distant nommé TT-Sync v2. La migration depuis SillyTavern repose sur deux éléments : un script d'export côté SillyTavern et un import dans l'application. Le README insiste sur la compatibilité des formats de données et de l'arborescence des répertoires. Enfin, les extensions frontend sont gérées par un Git natif intégré, avec installation, mise à jour et changement de branche depuis l'interface. La limite est énoncée sans ambiguïté : les plugins backend Node-only de l'amont ne sont pas pris en charge. C'est le point de rupture le plus probable pour un utilisateur existant, et il se situe côté extensions, pas côté données. Le projet mentionne par ailleurs un cadre Agent (appels d'outils, Skills, sous-agents, chronologie d'exécution) qu'il qualifie lui-même d'en évolution continue, ce qui invite à ne pas le traiter comme une fonction stabilisée.

Tauri Pilot et le coût de maintenance

Pour le développement, les prérequis sont Rust stable avec le support de l'édition 2024, Node.js 20.19.x ou 22.12 et plus, pnpm, et la CLI Tauri. Les commandes listées sont pnpm run check (guardrails frontend, types, contrats, plus un cargo check côté Rust), pnpm run web:build via Rspack, puis pnpm run tauri:dev, pnpm run tauri:build, pnpm run android:dev et pnpm run ios:dev. Le projet intègre aussi Tauri Pilot, un plugin de développement qui permet à un agent IA d'inspecter et de piloter la WebView via des captures d'accessibilité. Le README précise que les commandes de développement et de distribution ordinaires n'activent pas cette capacité ; il faut pnpm run tauri:dev:pilot après un cargo install tauri-pilot-cli. Sur le coût de maintenance, le point structurel est la double dépendance : le frontend suit les versions de SillyTavern, et l'écosystème Tauri v2 évolue de son côté. Un projet qui synchronise un frontend amont tout en maintenant plusieurs crates Rust doit absorber deux calendriers de changements. La licence AGPL-3.0 ajoute sa propre contrainte : elle s'applique aux binaires et aux services dérivés, et mérite un examen attentif si vous envisagez de redistribuer une version modifiée ou d'exposer le logiciel comme service. Ce texte n'est pas un avis juridique.

Face à SillyTavern lancé à la main

L'alternative directe est SillyTavern lui-même, exécuté avec Node.js. La différence n'est pas fonctionnelle, elle est opérationnelle. SillyTavern vous laisse contrôler le runtime, accéder aux logs du serveur Node, modifier le code directement sur place et charger des plugins backend Node-only. TauriTavern échange ce contrôle contre un binaire installable, un backend Rust en workspace, et une gestion des extensions limitée au frontend. Vous ne remplacez donc pas un outil par un autre plus capable : vous déplacez la complexité du runtime vers le paquet. Pour quelqu'un dont l'usage principal est le chat sur ordinateur avec des extensions backend, la version Node reste plus permissive. Pour quelqu'un qui veut la même expérience sur Android et iOS sans administrer un serveur, la version Node n'offre tout simplement pas de chemin équivalent documenté ici.

Vérifier avant d'installer

Trois vérifications se font avant de migrer, pas après. D'abord, listez vos extensions : si l'une d'elles est un plugin backend Node-only, elle ne fonctionnera pas, et aucune option de contournement n'est décrite dans le matériel fourni. Ensuite, choisissez votre canal en connaissance de cause : le canal Canary est quotidien et le README reconnaît une stabilité potentiellement moindre. Enfin, lisez les conditions de l'AGPL-3.0 si votre usage dépasse l'installation personnelle. Pour le reste, la documentation renvoie à docs/BackendStructure.md et docs/FrontendGuide.md, et l'import des données SillyTavern se fait via le script d'export puis l'import intégré. Ce qui n'est pas tranchable depuis le dépôt seul : la qualité réelle du rendu sur les très longs historiques, que le README présente comme un travail de performance (chargement par étapes, DOM virtuel pour le chat) sans chiffres publiés. À vérifier sur votre propre volume de données avant de supprimer votre installation Node.

Conclusion éditoriale

TauriTavern convient à celles et ceux qui utilisent déjà SillyTavern et veulent éviter Node.js, la ligne de commande et les mises à jour manuelles, en particulier sur mobile où le dépôt documente une installation TestFlight pour iOS 16 et plus. Le projet ne convient pas si vous dépendez d'extensions backend Node-only : le README précise qu'elles ne sont pas prises en charge. Avant d'adopter, vérifiez trois points dans l'ordre : la compatibilité de vos extensions frontend avec le frontend 1.18.0, le canal que vous choisissez (Canary est mis à jour quotidiennement et le README indique lui-même que sa stabilité peut être inférieure à celle de la version stable), et la conformité de votre usage avec l'AGPL-3.0 si vous redistribuez le binaire ou un service dérivé.

Sources officielles

1. Darkatse/TauriTavern on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases