Alternatives à Open WebUI : licence, BYOK, RAG et migration

La plupart des recherches d’alternatives à Open WebUI ne portent pas réellement sur le prix : Open WebUI est gratuit à auto-héberger pour un nombre illimité d’utilisateurs internes, et le projet ne publie aucun prix. Les raisons réelles du départ sont plus précises — la licence a cessé d’être une licence open source standard à partir de v0.6.6, un serveur n’est pas le bon format pour une seule personne, le fonctionnement des points de terminaison personnalisés ne convient pas à leur passerelle, ou ils veulent que quelqu’un d’autre l’héberge. Chacun de ces motifs désigne un remplacement différent, et le coût de migration entre eux varie fortement.

Une précision s’impose d’abord, car les résultats de recherche mélangent plusieurs projets aux noms similaires mais sans lien. Open WebUI est open-webui/open-webui, anciennement Ollama WebUI. Il ne s’agit ni de l’interface web Stable Diffusion d’AUTOMATIC1111, ni de OpenUI (générer une interface à partir d’une invite), ni de text-generation-webui, renommé TextGen à l’adresse oobabooga/textgen, qui est une application de bureau pour modèles locaux plutôt qu’une interface pour équipes.

Commencez par la raison de votre départ

La licence, précisément — et le mythe qu'il faut cesser de répéter

L'événement déterminant du cycle de vie n'est ni un changement de nom ni une acquisition. C'est un changement de licence. D'après la documentation de la licence du projet, tout le code soumis ou fusionné jusqu'à la version v0.6.5 incluse reste sous licence BSD-3. À partir de v0.6.6, le projet est distribué sous l'Open WebUI License spécifique, dérivée de BSD-3 et comportant une clause de protection de la marque, et l'API du dépôt GitHub indique la licence comme NOASSERTION plutôt que comme une licence standard reconnue. Les versions publiées sur GitHub datent la transition : v0.6.5 le 14 avril 2025 et v0.6.6 le 5 mai 2025. Notez que la documentation de la licence associe à la modification sa propre date calendaire — « Effective with v0.6.6 (April 19, 2025) » — qui ne correspond pas à la date enregistrée par GitHub pour cette version ; citez donc la version plutôt que l'une ou l'autre date.

Passons maintenant à la correction. Le texte de la licence interdit de modifier, supprimer, dissimuler ou remplacer la marque Open WebUI, sauf dans trois cas, le premier étant un déploiement « where the total number of end users … does not exceed fifty (50) within any rolling thirty (30) day period » ; les deux autres sont l'autorisation écrite préalable du détenteur des droits d'auteur et une licence d'entreprise dûment signée. La documentation de la licence indique séparément « Deploy to any number of internal users within your own organization (with all official branding kept) » parmi les usages autorisés par la licence gratuite. Le chiffre de cinquante utilisateurs est donc une exception concernant la marque, et non une limite de déploiement — c'est l'inverse de ce qu'affirment la plupart des articles comparatifs. Les droits d'auteur sont détenus par Open WebUI Inc. [Created by Timothy Jaeryang Baek].

Ce que la licence d'entreprise restreint réellement, ce sont le white-labeling, la suppression de la marque et les fonctionnalités réservées à l'entreprise. Son prix n'est pas publié : la page Enterprise vous demande d'« Send us your deployment end user count (seats) », et openwebui.com/pricing renvoyait HTTP 404 lors de la vérification du 21 septembre 2026. Tout tarif par siège affiché ailleurs correspond soit au prix d'un fournisseur d'hébergement géré, soit à une invention.

Le projet lui-même est en bonne santé selon les indicateurs importants : il n'est pas archivé, compte plus de 150 000 étoiles, a reçu un push dans les jours précédant cette vérification et sa version stable v0.11.3 a été publiée le 31 août 2026 (API Releases). Un sous-composant ne l'est pas : open-webui/pipelines, le framework de plugins, a reçu son dernier push le 18 août 2025. Si votre déploiement dépend de Pipelines, cette cadence mérite d'être prise en compte avant de vous appuyer davantage dessus.

La sélection, regroupée selon votre mode d'exécution

Trois réserves concernant ce tableau, toutes vérifiées le 21 septembre 2026. La balise la plus récente de LibreChat est la préversion v0.8.8-rc3 du 15 septembre 2026 et /releases/latest de GitHub renvoie 404 ; aucune version n'est donc actuellement signalée comme la plus récente — consultez le propre journal des modifications du projet avant de figer une version, plutôt que de vous fier à un chiffre provenant d'un résumé. La page des tarifs de LobeHub se contredit : les cartes des forfaits affichent Starter, Premium et Ultimate à 9,9 $, 19,9 $ et 39,9 $ par mois, tandis que le tableau comparatif de la même page affiche 12,9 $ pour Starter, avec un montant annuel de 118,8 $ ; confirmez donc le montant lors du paiement avant de vous engager. Le prix Premium de TypingMind fait en outre l'objet d'une promotion annoncée de 50 %, le genre de chiffre qui devient le plus vite obsolète. Les niveaux payants de Chatbox concernent ses propres modèles hébergés ; selon son guide d'utilisation de votre propre clé, le fait de lui associer votre propre clé est l'option gratuite.

Deux projets qui apparaissent dans les listes d'alternatives et ne devraient pas y figurer : Chatbot UI est sous MIT et n'est pas archivé, mais son dernier push date du 3 août 2024 et il ne propose aucune version publiée ; il est donc dormant plutôt qu'une option active. De son côté, NextChat se décrit désormais comme un assistant sans configuration auquel on s'inscrit sans clé API, facturé à l'utilisation, plutôt que comme une interface reposant exclusivement sur votre propre clé. À distinguer également dans les recherches : Jan n'est pas Janitor AI, Msty Studio n'est pas le fonds négocié en bourse MSTY, et LobeChat et LobeHub constituent un seul projet après un changement de nom ; les tutoriels de configuration de LobeChat antérieurs à la version 1.0 ne sont donc plus à jour.

Comment chacun accepte un endpoint personnalisé compatible avec OpenAI

Les huit clients ci-dessous documentent chacun une manière de les connecter à un endpoint tiers. Ce qui diffère, c'est la surface de configuration, la forme de l'URL et la possibilité ou non d'utiliser autre chose que Chat Completions. Une colonne nécessite que sa question soit formulée précisément : « Anthropic Messages route » demande si le client lui-même enverra des requêtes au format Anthropic à votre endpoint. « None documented » signifie que la documentation du fournisseur ne décrit pas ce mode — et non qu'il est connu comme inexistant.

Ce tableau provient de la documentation de chaque fournisseur : les pages de connexion OpenAI-compatible et Open Responses d'Open WebUI, la référence des endpoints personnalisés de LibreChat, la page Generic OpenAI d'AnythingLLM, la documentation des endpoints personnalisés de Jan, la documentation des fournisseurs personnalisés de ChatWise, la page des fournisseurs de LobeHub, la documentation des fournisseurs en ligne de Msty et la documentation des connexions de modèles de TypingMind.

Cherry Studio est volontairement absent de ce tableau. Son domaine de documentation redirige désormais de docs.cherry-ai.com vers docs.cherryai.com.cn, un site en chinois dont les pages consacrées aux fournisseurs n'ont pas été consultées pour cette page ; les noms de champs et la convention de chemin n'y sont donc pas vérifiés — contrôlez-les dans l'application avant de copier une URL de base depuis un ancien tutoriel.

Deux précisions sur Open WebUI qu'il est utile de connaître quel que soit votre choix. Sa documentation sur les connexions aux fournisseurs indique que certains fournisseurs n'implémentent pas du tout /models, auquel cas la vérification de la connexion échoue mais les complétions de chat continuent de fonctionner et vous saisissez manuellement les ID des modèles. Elle avertit également que la couche de compatibilité de Google s'écarte du schéma de streaming OpenAI, et recommande de régler Function Calling sur Legacy afin que les outils passent par une requête distincte sans streaming. Cet avertissement concerne la couche d'un fournisseur donné, et non les couches de compatibilité en général — mais il rappelle utilement que l'appel d'outils passe par ce que le service amont implémente réellement, et que l'interface ne peut pas corriger une lacune du schéma à votre place.

Du côté de Kunavo, /v1/chat/completions, /v1/messages et /v1/responses existent tous comme routes ; les modes compatibles avec Anthropic de LibreChat (provider: anthropic), de Jan et de ChatWise, ainsi que le chemin expérimental Responses d'Open WebUI, disposent donc chacun d'une surface correspondante. Aucun de ces clients n'a été testé en conditions réelles avec Kunavo pour cette page ; un guide de configuration publié est une référence de configuration, pas un test de compatibilité. Un bloc personnalisé LibreChat fonctionnel ressemble à ceci :

endpoints:
  custom:
    - name: "Kunavo"
      apiKey: "${KUNAVO_API_KEY}"
      baseURL: "https://api.kunavo.com/v1"
      models:
        default: ["claude-sonnet-4-6", "claude-haiku-4-5"]
        fetch: true
      titleConvo: true
      titleModel: "claude-haiku-4-5"

Pour connaître la structure générale de cette configuration entre les clients, consultez API compatible avec OpenAI. Pour les comparaisons directes entre deux produits, LibreChat vs Open WebUI traite les difficultés de configuration et AnythingLLM vs Open WebUI traite le RAG et le déploiement.

RAG : la partie qui ne suit pas l'endpoint de chat

Diriger une interface vers un endpoint de chat ne dirige pas pour autant son pipeline de recherche documentaire. Open WebUI conserve des identifiants distincts à cet effet. Selon sa référence des variables d'environnement, RAG_EMBEDDING_ENGINE sélectionne le moteur et RAG_OPENAI_API_BASE_URL / RAG_OPENAI_API_KEY transportent son endpoint, tout comme la génération d'images possède son propre IMAGES_OPENAI_API_BASE_URL. Lorsqu'il est vide, RAG_EMBEDDING_ENGINE utilise par défaut SentenceTransformers exécuté localement — l'accélération GPU des embeddings est activée uniquement via l'image CUDA — de sorte que le coût par requête est nul par défaut. AnythingLLM sépare les éléments de la même manière, en configurant son LLM, son embedder et sa base de données vectorielle comme des fournisseurs distincts. La compatibilité de chat n'établit donc pas la compatibilité de recherche documentaire dans l'un ou l'autre produit.

C'est important ici pour une raison concrète : les embeddings ne sont pas fournis par Kunavo — aucun modèle activé ne dessert cet endpoint — ; l'étape de recherche reste donc locale ou pointe vers le fournisseur externe de votre choix. Budgétez-la séparément du chat et excluez-la de tout plan de migration de passerelle. L'implémentation du RAG explique comment les étapes se répartissent.

Ce qui migre, et ce que vous devrez reconstruire

Définissez vos attentes avant de commencer : l'historique des conversations ne se transfère pas automatiquement entre ces produits. La documentation d'importation et d'exportation d'Open WebUI indique que l'export couvre « All chat messages and their metadata, Model information used in each conversation, Timestamps and conversation structure » et que l'importation accepte les exports d'Open WebUI, les exports de ChatGPT et le JSON personnalisé — avec cette formulation sans ambiguïté : pour les autres plateformes, « There is no built-in converter ». Du côté destinataire, la documentation d'importation de LibreChat répertorie ChatGPT, Claude et ChatbotUI v1, sans mentionner Open WebUI. Deux importateurs documentés, aucun recouvrement.

Cette dernière ligne est celle qu'il faut trancher en premier, même si vous restez sur la solution actuelle. Selon la documentation de mise à l'échelle, le choix du moteur devient effectivement permanent dès lors que vous disposez de données de production ; les déploiements à plusieurs réplicas nécessitent PostgreSQL, Redis et une base de données vectorielle externe plutôt que SQLite et Chroma intégré ; et pour SQLite sur un stockage réseau, le seul remède proposé par la documentation est de passer à PostgreSQL, et non d'utiliser un paramètre d'optimisation. Une véritable migration de l'instance entière consiste donc à copier le répertoire de données au niveau des fichiers, plutôt qu'à utiliser un fichier d'exportation. Le tutoriel de maintenance de la base de données place webui.db — avec ses fichiers associés -wal et -shm — à /app/backend/data dans le conteneur ; la référence des variables d'environnement décrit DATA_DIR comme le répertoire de base « for data storage, including uploads, cache, vector database, etc. », et le journal d'audit est configuré par défaut sur audit.log dans ce même répertoire. Copiez le répertoire, pas une liste de fichiers.

Effectuez une sauvegarde avant toute intervention. Confirmez d'abord le nom de votre propre conteneur — voici la structure, pas un script à coller sans vérification :

# 1. Stop the instance so nothing writes mid-copy.
docker stop open-webui

# 2. Copy the whole data directory out of the container.
#    The documented location is /app/backend/data. DATA_DIR is
#    described as the base for uploads, cache, the vector database
#    and the audit log, so take the directory rather than webui.db.
docker cp open-webui:/app/backend/data ./open-webui-backup-$(date +%F)

# 3. Start it again and confirm the UI still loads before you touch anything.
docker start open-webui

Plan de restauration : conservez l'ancienne instance, ainsi que sa balise d'image, intactes et en fonctionnement pendant que vous testez la remplaçante, plutôt que de migrer sur place. Faites fonctionner les deux sur le même endpoint pendant une semaine, faites passer une première équipe, puis ne mettez l'original hors service qu'après que la nouvelle instance a résisté à une charge réelle. Comme l'historique des conversations ne se transfère pas, une restauration après la mise hors service de l'ancienne instance signifie perdre tout ce qui a été écrit dans le nouvel outil — ce qui plaide encore davantage pour une exécution côte à côte que n'importe quelle comparaison de fonctionnalités.

Ce que coûte le côté modèle, quelle que soit l'interface choisie

Aucune de ces interfaces ne facture les tokens ; c'est l'API qui se trouve derrière qui le fait. Les chiffres ci-dessous sont un calcul illustratif de tokens, et non des coûts mesurés ni un plafond de facturation. Supposons qu'une personne mène 10 conversations par jour ouvré, chacune envoyant 25 000 tokens d'entrée non mis en cache au fil de ses tours et recevant 1 500 tokens de sortie, pendant 20 jours ouvrés — cela représente 5 000 000 tokens d'entrée et 300 000 tokens de sortie par personne et par mois. Les tarifs sont les prix actuels du catalogue Kunavo par million de tokens.

Comparez ce montant aux prix de l'interface, et non à leur place. Une interface auto-hébergée ne facture rien par siège ; selon ces hypothèses, le trafic de toute l'équipe sur les modèles Claude Sonnet 4.6 est donc estimé à $68.25 par mois, tandis que la même équipe sur les modèles Claude Haiku 4.5 est estimée à $22.75 — soit une différence mensuelle de $45.50 pour un trafic supposé identique, récurrente chaque mois plutôt que payée une seule fois. Le modèle par défaut vers lequel une interface est dirigée constitue donc en lui-même une décision budgétaire évolutive, distincte de la licence que vous payez pour l'application. C'est la forme réelle de votre usage qui permet de la trancher ; mesurez donc vos propres conversations avant d'établir votre budget. L'optimisation des coûts de l'IA explique comment effectuer cette mesure honnêtement.

Le montant du catalogue Kunavo constitue un seuil de facturation plutôt qu'un plafond : lorsque le service amont communique son coût, la facture correspond au montant le plus élevé entre le coût du catalogue et le coût amont multiplié par la majoration applicable. Les frais de cache et les outils externes ne sont pas inclus dans cet exemple. Le rechargement minimal est de $10 de crédit prépayé ; il alimente un solde plutôt qu'il n'achète un siège ou un forfait — consultez les détails de facturation.

Si vous restez sur Open WebUI

C'est une conclusion défendable de cette page et, pour la plupart des équipes, la bonne : le changement de licence restreint le white-labeling plutôt que la taille du déploiement, le projet fait l'objet de versions régulières et rien de ce qui précède ne justifie de reconstruire une instance fonctionnelle. Dans tous les cas, il est utile de séparer la décision concernant l'interface de celle concernant l'endpoint, afin qu'un futur changement de client n'implique pas aussi un changement de fournisseur et une nouvelle clé. Kunavo publie une référence de configuration pour ce client — le guide d'intégration d'Open WebUI — ainsi que des guides de configuration pour LobeHub, Chatbox et Cherry Studio. Créez un compte Kunavo lorsque vous souhaitez disposer d'une seule clé et d'un seul solde prépayé derrière l'interface que vous aurez choisie.

Questions fréquentes

Vérifié le 21 septembre 2026 en consultant directement chaque page liée ou réponse de l'API GitHub : le texte de la licence d'Open WebUI, sa documentation de licence et d'entreprise, sa documentation des connexions aux fournisseurs, de la mise à l'échelle et de l'importation/exportation, son dépôt et sa dernière version, le 404 de openwebui.com/pricing, le dépôt et la documentation d'importation de LibreChat, ainsi que les pages de tarifs publiées d'AnythingLLM, LobeHub, Msty, ChatWise et TypingMind. Ont également été consultés directement : les pages Open Responses et de référence des variables d'environnement d'Open WebUI, la référence des endpoints personnalisés de LibreChat, la page Generic OpenAI d'AnythingLLM, la documentation des endpoints personnalisés de Jan et ChatWise, la page des fournisseurs de LobeHub (toujours un espace réservé de migration), le guide d'utilisation de votre propre clé de Chatbox et les métadonnées de dépôt de Pipelines, TextGen et de Chatbot UI, qui est dormant. Les étapes de configuration de Msty et TypingMind sont liées, mais proviennent de résumés documentaires plutôt que d'une lecture complète. Les champs de configuration de Cherry Studio restent non vérifiés et sont signalés comme tels ci-dessus. Aucun client de cette page n'a été testé en conditions réelles avec Kunavo. Les tarifs des tokens Kunavo proviennent du catalogue actuel, et chaque montant en dollars de la section des coûts correspond à un calcul illustratif de tokens.