Locally Uncensored : un studio IA local tout-en-un, sans Docker ni terminal

Le problème visé : quatre outils, quatre installations

Faire tourner un modèle de langage en local demande aujourd'hui de choisir un moteur, de le lancer, de télécharger des poids adaptés à sa VRAM, puis de recommencer l'opération pour la génération d'images avec ComfyUI et ses graphes de nœuds. Le README part de ce constat : quatre usages distincts, quatre chaînes d'installation, et un terminal comme passage obligé. Locally Uncensored cible donc un public précis, celui qui veut un résultat sans administrer une pile de services. Le texte de présentation insiste sur trois promesses : pas de Docker, pas de terminal, pas de cloud obligatoire. Le public visé n'est pas l'ingénieur qui écrit déjà ses propres scripts autour de l'API d'Ollama, mais la personne qui possède une machine correcte et veut discuter, générer des visuels et faire modifier du code dans la même fenêtre. Le nom du projet annonce aussi une position : les modèles qui répondent sans refus figurent dans le même menu que les modèles classiques, ce qui est un choix éditorial assumé et non un détail d'implémentation.

Sous le capot : Tauri, Ollama, ComfyUI et un index local

Le langage principal du dépôt est TypeScript, et la commande de compilation citée dans le README est npm run tauri build, ce qui situe l'application du côté de Tauri plutôt que d'Electron. La structure du projet le confirme : un mode navigateur pour le développement via npm run dev, et un binaire de bureau pour la distribution. L'architecture réelle est celle d'un orchestrateur. L'application ne réimplémente pas l'inférence : elle détecte un moteur déjà présent sur la machine (Ollama, LM Studio et d'autres selon le README), en installe un si nécessaire, et fait de même pour ComfyUI, qu'elle démarre, répare et met à jour. Les modèles déjà stockés par ces outils peuvent être liés sans être recopiés, ce qui évite de dupliquer plusieurs dizaines de gigaoctets de poids. Au-dessus, l'application ajoute ses propres couches : un index local pour interroger ses documents, une mémoire inter-conversations, un résumé automatique des tours anciens quand une conversation devient trop longue, et un agent de code qui construit une carte du dépôt avant d'éditer. Le README mentionne également une Local API dans les paramètres, qui expose tous les modèles locaux sur une adresse compatible OpenAI derrière un jeton. C'est le point le plus intéressant du projet pour un développeur : l'interface graphique n'est pas un cul-de-sac, elle peut servir de backend à d'autres outils.

Installation et premiers pas, commande par commande

Pour un utilisateur final, la voie normale est le fichier de release : .exe en NSIS ou .msi sous Windows 10 et 11, .deb, .rpm ou .AppImage sous Linux. Le README précise que macOS n'a pas d'installeur et qu'il faut compiler depuis les sources. Au premier lancement, un assistant cherche un moteur d'inférence déjà actif et en installe un en un clic s'il n'en trouve pas, puis répète l'opération pour ComfyUI. Le gestionnaire de modèles indique ensuite lesquels tiennent sur votre matériel et les télécharge. Pour un contributeur, la séquence donnée est git clone, cd locally-uncensored, npm install, puis npm run dev pour le mode navigateur ou npm run tauri build pour le binaire. Deux scripts amorcent l'environnement de développement : setup.bat sous Windows, setup.sh sous Linux et macOS, qui installent Node, Git et Ollama. Un point mérite attention : le README reconnaît que certains antivirus signalent l'installeur NSIS non signé comme suspect, et il qualifie cela de faux positif. Le projet indique que l'installeur est produit par GitHub Actions depuis la source publique de la branche master et que le canal de mise à jour est signé par une clé minisign publique, avec un renvoi vers SECURITY.md. C'est vérifiable, mais cela reste une friction réelle au déploiement en entreprise, où ce type d'alerte déclenche souvent un blocage automatique.

L'agent de code et sa règle du diff d'abord

La partie Code mérite qu'on s'y arrête, car c'est là que le projet prend le plus de risques techniques. Le README décrit un agent qui construit une carte du dépôt, n'édite que les lignes demandées, affiche le diff avant toute application, exécute les tests et lit les échecs. Trois modes coexistent par conversation : Ask, Plan et Bypass. Un fichier de règles par projet, nommé .lurules, permet de cadrer le comportement de l'agent, et des outils git typés sont fournis. Le mode Agent va plus loin : recherche et récupération web, lecture et écriture de fichiers, shell, exécution de code, captures d'écran, génération d'images et de vidéo, et serveurs MCP personnalisés. Deux garde-fous sont annoncés : chaque appel d'outil passe par une barrière de permission que l'utilisateur contrôle, et une exécution en lecture seule le reste. Les tâches longues partent en agents d'arrière-plan avec un panneau de suivi. L'affichage préalable du diff est le bon compromis : il rend l'agent utilisable sans lui donner un accès aveugle au dépôt. Le point faible est ailleurs. Le README ne détaille ni la gestion des conflits quand un fichier a changé entre la lecture et l'écriture, ni la politique de retour arrière, ni la façon dont .lurules est fusionné avec d'éventuelles règles globales. Ce sont exactement les questions qu'un utilisateur se pose après la première modification ratée.

Ce que le projet ne dit pas, et les cas où il ne convient pas

Le README est généreux en fonctionnalités et avare en chiffres. Aucune empreinte disque, aucune consommation de VRAM par modèle, aucune exigence minimale de carte graphique n'est donnée. La mention selon laquelle le gestionnaire de modèles sait lesquels tiennent sur votre matériel suggère une détection automatique, mais la façon dont ce classement est calculé n'est pas documentée. Deux lanes de création, Upscale et Erase Object, sont explicitement indiquées comme fonctionnant uniquement dans le cloud, ce qui contredit partiellement la promesse d'un fonctionnement entièrement local : la frontière existe, elle est simplement signalée en fin de paragraphe. Autre limite structurelle : l'application dépend de ComfyUI pour les images et la vidéo. Elle l'installe et le répare, mais si ComfyUI casse après une mise à jour de ses propres nœuds, l'utilisateur se retrouve avec un problème qu'il n'a pas les outils pour diagnostiquer, puisque le projet revendique justement l'absence de terminal. Le rythme de publication est également un facteur : v2.6.7 fin août, v2.6.8 le 6 septembre, v2.6.9 le 8 septembre 2026. Trois versions en neuf jours, c'est le signe d'un projet actif, mais aussi d'une surface qui bouge vite. Enfin, macOS est absent des installeurs, et une carte graphique dédiée reste nécessaire pour les usages de création, ce qui exclut de fait une partie du parc portable.

Face à quoi : Ollama plus Open WebUI, ou ComfyUI seul

L'alternative la plus directe pour le chat local est la combinaison d'Ollama et d'Open WebUI. La différence d'approche est nette : Open WebUI est une interface web servie depuis un conteneur, généralement lancée avec Docker, et elle ne prend en charge ni la génération d'images via ComfyUI ni un agent de code intégré. Elle excelle dans le multi-utilisateur, le déploiement sur un serveur et l'exposition d'une API, là où Locally Uncensored vise un poste de travail unique. Pour la génération d'images, l'alternative est ComfyUI utilisé directement. On y gagne un contrôle total sur les graphes, les nœuds personnalisés et les workflows reproductibles, et on y perd toute la couche de simplification : chaque nouveau modèle demande de reconstruire un graphe, et rien ne relie la sortie au chat ou à l'agent. Le positionnement de Locally Uncensored consiste donc à échanger de la flexibilité contre du temps d'installation. Ce n'est pas un meilleur outil, c'est un outil pour un profil différent. Une nuance toutefois : la Local API compatible OpenAI permet de récupérer une partie de l'interopérabilité perdue, puisque d'autres outils de code peuvent pointer vers la même machine.

Licence, mises à jour et coût de maintenance

Le dépôt est publié sous AGPL-3.0. Pour un usage personnel sur son propre poste, la question ne se pose guère. Elle devient concrète dès qu'on envisage d'intégrer le code dans un service exposé sur un réseau : l'AGPL impose de fournir le code source correspondant aux utilisateurs de ce service. Le README mentionne par ailleurs une offre optionnelle, LU Labs Cloud, avec un interrupteur dans l'application et un compte partagé avec lu-labs.ai, sur abonnement ou en packs de crédits sans expiration. Le projet affirme que l'application locale reste gratuite dans tous les cas. Cette coexistence entre un client AGPL et un service hébergé est courante, mais elle implique que certaines fonctionnalités de création dépendent d'un compte et d'une connexion, ce qui doit être intégré au choix. Sur la maintenance, le coût principal n'est pas l'application elle-même mais son écosystème : modèles qui apparaissent et disparaissent, nœuds ComfyUI qui changent d'interface, mises à jour signées à appliquer. Le README renvoie à CHANGELOG.md pour l'historique complet depuis la version 1.0.0. Avant d'adopter l'outil sur un parc, c'est ce fichier et SECURITY.md qu'il faut lire en premier, pas la page de présentation.

Conclusion éditoriale

Locally Uncensored convient à celles et ceux qui veulent un poste de travail IA local complet sans écrire de configuration, sur Windows ou Linux, avec une carte graphique dédiée. À éviter si votre matériel est modeste, si vous dépendez de macOS, ou si vous avez besoin de garanties de support et d'un modèle de contribution classique : l'AGPL-3.0 et les mises à jour très rapprochées imposent de vérifier CHANGELOG.md et SECURITY.md avant de vous engager.

Sources officielles

1. License: AGPL-3.0
2. Project website
3. PurpleDoubleD/locally-uncensored on GitHub
4. README
5. Releases