Risuai : une interface de roleplay LLM qui mise sur le scripting plutôt que sur la simplicité

Le problème visé : reprendre la main sur la couche de prompting

Les interfaces de chat avec un modèle de langage imposent en général un format de prompt figé. On choisit un personnage, on écrit, le modèle répond. Toute personnalisation passe par le texte du personnage lui-même. Risuai part d'un constat différent : la sortie du modèle est une chaîne de caractères, et cette chaîne peut être retraitée avant affichage. Le README présente ainsi les Regex Script comme un moyen de modifier la sortie du modèle pour construire une interface personnalisée. C'est le cœur du projet. Le public visé n'est donc pas celui qui veut discuter avec un assistant, mais celui qui veut fabriquer un format de réponse : détourner une balise, transformer une instruction en élément d'interface, nettoyer un préambule que le modèle ajoute systématiquement. Le README mentionne aussi l'impersonation dans les prompts, les conditions et les variables, ce qui déplace le travail de l'écriture du personnage vers l'écriture de la logique de conversation. Cette approche a un coût : elle suppose de comprendre comment le modèle produit son texte, et d'accepter qu'un changement de fournisseur modifie le format brut reçu.

Architecture : Svelte, Tauri et un port Docker

Le dépôt est en TypeScript. Les badges du README indiquent Svelte 5, Tauri 2.5, Vite 8 et Tailwind CSS 4. La présence de Tauri signifie que l'application peut être empaquetée comme binaire de bureau, ce qui explique la mention cross platform dans la description. La même base de code est servie comme application web, puisque le README documente une installation Docker avec accès sur le port 6001. Autrement dit, une seule interface, deux modes de distribution. Les données de conversation, les personnages et les assets restent donc locaux dans le cas du binaire de bureau, alors qu'en hébergement web ils vivent sur le serveur qui exécute le conteneur. Cette distinction n'est pas anodine : le README ne décrit aucun mécanisme d'authentification pour le mode Docker, seulement la commande de lancement et l'URL d'accès. Exposer ce port sur une machine accessible depuis Internet revient à publier vos conversations et vos clés d'API. Le sujet n'est pas traité dans le matériel fourni, ce qui est un manque réel pour un outil qui prend en charge plusieurs fournisseurs payants.

Mémoire longue : trois systèmes nommés, aucune spécification

Le README liste HypaMemoryV2, HypaMemoryV3 et SupaMemory. Le premier est décrit comme une compression de mémoire, le second comme une gestion de contexte destinée à maintenir la cohérence sur une conversation longue. Ce sont les seuls éléments fournis. Aucune indication sur la taille des fenêtres, sur ce qui est résumé et ce qui est conservé tel quel, ni sur la façon dont ces systèmes interagissent avec le Lorebook, présenté séparément comme un carnet de mémoire par personnage. La coexistence de deux mécanismes de mémoire (l'un par personnage via le Lorebook, l'autre global via HypaMemory et SupaMemory) est une source de confusion prévisible pour un nouvel utilisateur, et le README ne dit pas lequel prime. C'est le point où la documentation est la plus mince, et c'est aussi celui qui compte le plus pour un usage de roleplay au long cours. Un test rapide s'impose avant de s'engager : lancer une conversation de plusieurs dizaines d'échanges et vérifier ce qui reste du début.

Plugins, fournisseurs et traductions : ce que le README engage

La prise en charge multi-fournisseurs est annoncée avec une liste ouverte : OpenAI, Claude, Gemini, DeepInfra, Ooba, OpenRouter, et d'autres. Le README ne fournit pas de tableau exhaustif, et la formulation suggère que la liste évolue. Concrètement, cela signifie que vous apportez votre propre clé d'API et que Risuai sert de client. Les plugins permettent d'ajouter des fonctionnalités et des fournisseurs, et le README insiste sur le partage : un plugin s'échange. C'est un choix d'architecture qui a une conséquence directe sur la confiance. Un plugin qui ajoute un fournisseur manipule nécessairement la clé d'API associée. Le dépôt ne décrit ni modèle de permissions ni mécanisme de signature pour ces extensions. Les traducteurs automatiques, qui traduisent l'entrée et la sortie pour permettre de jouer sans connaître la langue du modèle, reposent sur le même principe : le texte transite par un service tiers. Rien dans le matériel fourni ne permet de dire quels services sont utilisés par défaut.

Installation : trois chemins, dont un seul est détaillé

Le README recommande le site risuai.net, puis les releases GitHub. Pour le développement, il faut Node.js 20.19 ou 22.12 minimum, ainsi que pnpm. La commande de build n'est pas donnée dans l'extrait fourni, seulement les prérequis. Le chemin le mieux documenté est Docker, présenté comme adapté à l'hébergement web. Une seule commande suffit : curl -L https://raw.githubusercontent.com/kwaroran/Risuai/refs/heads/main/docker-compose.yml | docker compose -f - up -d. L'application est ensuite accessible sur http://localhost:6001. Télécharger et exécuter un fichier compose distant en une commande est pratique, mais cela signifie aussi que la configuration effective dépend du contenu de ce fichier au moment de l'exécution, et non de ce que vous avez lu. Pour un déploiement sérieux, récupérez le fichier, lisez-le, puis lancez docker compose up -d depuis le répertoire local. Le README ne documente aucune variable d'environnement, aucun volume persistant ni aucune procédure de sauvegarde. Sur un outil qui stocke des personnages, des images et des historiques de conversation, l'absence de ces éléments dans la documentation principale est une lacune à combler avant toute mise en production.

Ce que le rythme des versions implique pour la maintenance

Les releases fournies montrent des publications rapprochées : v2026.8.240 le 24 août, v2026.8.250 le 25 août, puis une version précédente en juillet. Le schéma de numérotation intègre l'année et le mois, ce qui indique un rythme mensuel au minimum, avec des correctifs intercalaires. Pour un utilisateur, cela veut dire deux choses. D'abord, les correctifs arrivent vite. Ensuite, une version figée vieillit vite : si vous auto-hébergez via Docker et que vous épinglez une image, vous vous éloignez rapidement de l'état du dépôt. Il faut donc prévoir une procédure de mise à jour, et cette procédure n'est pas décrite dans le README. La licence est GPL-3.0. Si vous modifiez le code et le distribuez, y compris en le mettant à disposition via un service réseau selon l'interprétation retenue pour la GPL, les obligations de publication du code source s'appliquent. Pour un usage personnel ou interne, la question ne se pose pas de la même manière. Ce paragraphe décrit la licence telle qu'elle est identifiée dans le dépôt et ne constitue pas un avis juridique.

Face à SillyTavern : deux philosophies d'extension

SillyTavern est l'alternative la plus directement comparable : une interface web de roleplay avec modèles de personnages, lorebooks et connexion à plusieurs backends. La différence tient au mode d'extension. SillyTavern s'étend principalement par des scripts d'interface et des presets de prompt, et se déploie comme serveur Node auquel on accède depuis un navigateur. Risuai ajoute une couche de traitement de la sortie par expressions régulières, présentée comme un moyen de construire une interface personnalisée, et se distribue aussi comme application de bureau via Tauri. Le second point est probablement le plus décisif en pratique : si vous voulez une application installée localement, sans serveur à maintenir, Risuai répond à ce besoin directement. Si vous voulez un serveur accessible depuis plusieurs appareils, les deux projets se ressemblent davantage et le choix se joue sur les fournisseurs pris en charge et sur le confort de l'éditeur de prompts. Le README de Risuai met en avant l'ordre de prompt modifiable, l'impersonation et les variables, ce qui indique un travail sur la logique conditionnelle plutôt que sur la seule bibliothèque de personnages.

Assets, voix et thèmes : la partie qui ne demande pas de scripting

Toutes les fonctionnalités de Risuai ne supposent pas d'écrire du code. Le README liste les images d'émotion, qui affichent une image du personnage selon l'expression détectée, les assets supplémentaires (images, sons, vidéos intégrés au bot et affichables dans le chat ou en arrière-plan), la synthèse vocale pour lire les réponses, les conversations de groupe avec plusieurs personnages, et trois thèmes nommés Classic, WaifuLike et WaifuCut. L'interface est décrite comme accessible et adaptée au mobile. C'est cette partie qui détermine si l'outil est agréable au quotidien, et elle est documentée en une liste à puces sans capture commentée ni explication du format attendu pour les assets. Pour les images d'émotion en particulier, le README ne dit pas comment les expressions sont détectées dans la sortie du modèle, ni quel nommage de fichiers est requis. C'est typiquement le genre de détail qu'un wiki en cours de rédaction est censé porter, et le README indique explicitement que ce wiki est un work in progress.

Conclusion éditoriale

Risuai convient aux utilisateurs qui acceptent d'écrire des scripts regex et de gérer eux-mêmes leurs clés d'API, et qui veulent une application de bureau ou auto-hébergée plutôt qu'un service en ligne. Il ne convient pas à qui cherche un produit sans configuration : la documentation se limite à un wiki annoncé comme work in progress, et le comportement des systèmes de mémoire n'est pas décrit dans le README. Avant d'adopter, vérifiez deux choses concrètes : que votre fournisseur figure parmi ceux listés dans la section Features, et que le fichier docker-compose.yml expose bien le port 6001 sur votre machine.

Sources officielles

1. kwaroran/Risuai on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases