Interfaces et intégrations

Un modèle derrière un endpoint HTTP, c'est de l'infrastructure ; l'interface est le produit que votre foyer ou votre équipe touche réellement. Parce que presque chaque interface parle la forme OpenAI-completions, elles sont interchangeables au-dessus de n'importe quel moteur issu du service — choisissez par rôle, pas par guerres de nombre de fonctions, et sachez que le choix est réversible.

À dire d'emblée : l'interface limite rarement le modèle — une simple boîte de chat avec un bon modèle bat un palais de fonctionnalités avec un faible.

Open WebUI

Le sosie auto-hébergé de ChatGPT et la réponse par défaut du « serveur familial » (github.com/open-webui/open-webui). Comptes multi-utilisateurs avec auth, changement de modèle en pleine conversation à travers Ollama et n'importe quel backend compatible OpenAI, dépôt de documents avec RAG intégré, recherche web, bibliothèque de prompts, permissions de modèles. Tourne en une commande Docker. Si votre objectif est « ma famille utilise mon GPU au lieu d'un abonnement », commencez ici.

Les fonctions qui comptent au quotidien :

• Comptes multi-utilisateurs et contrôles admin — permissions de modèles par utilisateur ou groupe.
• Changement de modèle en pleine conversation, à travers tous les backends connectés à la fois.
• Dépôt de documents avec RAG intégré et bascules de recherche web.
• Bibliothèque de prompts et préréglages sauvegardés partageables par tout le foyer.
• Une page de clés API, pour que les scripts frappent le même serveur sur lequel votre famille discute (voir service).

LibreChat

Multi-fournisseurs par conception : OpenAI, Anthropic, Google et votre endpoint local côte à côte dans une interface aux conversations partagées. Le bon choix quand le foyer est hybride — le cloud pour certaines tâches, le local pour les privées — ou quand une équipe a déjà des comptes et veut ajouter le local, pas le substituer (github.com/danny-avila/LibreChat).

Aussi le choix pragmatique quand certains utilisateurs doivent garder des modèles cloud pour le travail : une interface, des fournisseurs clairement étiquetés.

text-generation-webui

Le couteau suisse du power-user (github.com/oobabooga/text-generation-webui) : chaque chargeur (llama.cpp, exllamav2, transformers), chaque réglage d'échantillonneur exposé, cartes de personnages, carnets, onglets d'entraînement. Plafond le plus haut, désordre le plus haut. On en sort généralement vers moteur-plus-API-plus-interface-propre, mais pendant que vous expérimentez quants et échantillonneurs, rien d'autre n'a autant d'interrupteurs.

Il peut aussi exposer une API compatible OpenAI, donc il sert de backend — mais à ce stade llama-server est l'outil plus simple.

Dans votre éditeur

• Continue.dev — open source, VS Code et JetBrains ; autocomplètement, chat et éditions en ligne contre un endpoint local. Pointez-le sur Ollama ou n'importe quelle URL de base compatible OpenAI et votre assistant de code cesse d'être un abonnement.
• Cursor — accepte une URL de base compatible OpenAI personnalisée pour le chat/les modèles. Lisez sa doc actuelle sur ce qui quitte encore la machine ; à ce jour, des pans de son indexation peuvent être côté cloud.
• Zed — fournisseur OpenAI personnalisé dans les réglages ; trivialement local.
• Tout ce qui a un champ « URL de base OpenAI » — le motif est universel ; si un outil a ce réglage, il marche en local.

Même motif à chaque fois : URL de base vers localhost, clé d'API décorative (voir service).

L'autocomplètement veut un petit modèle rapide (1–3B) même sur du gros matériel — le budget de latence est de quelques centaines de ms (voir vitesse).

Dans votre terminal

• ollama run — discuter avec zéro installation au-delà de l'install (premier lancement).
• aichat — REPL multi-backend avec sessions, rôles et RAG léger ; se pipe proprement dans des scripts et est chez lui dans les cron.
• gptme — agentique : exécute des commandes shell et édite des fichiers, piloté par votre endpoint local.

# one-shot depuis un script — pas de boucle de chat
ollama run qwen3:8b "résumé en une phrase : le churn trimestriel a monté de 2%"

Le terminal compte plus qu'il n'y paraît : agents, tâches planifiées et agents de jeu de ce forum vivent ici (voir agents).

Voix et mobile

Open WebUI est du web responsive, donc les téléphones marchent via le navigateur contre votre serveur domestique — pas d'appli, pas de sync. Il intègre aussi la parole locale : modèles de classe Whisper en entrée, TTS façon Piper en sortie. La qualité vocale est sous les assistants cloud, mais la latence d'un 8B local peut réellement battre un aller-retour vers un centre de données.

Les pipelines vocaux sont entièrement séparés du modèle de chat — un petit modèle rapide pour la voix et un gros pour le texte, voilà le découpage sain.

Notes et bases de connaissances

Coffres Obsidian plus endpoints locaux via plugins — résumer, réécrire, lier des notes sans rien qui quitte la machine. Pour « parler à mes documents », le RAG intégré d'Open WebUI est le départ le plus rapide, mais les intégrations fragmentent grossièrement et choisissent les embeddings pour vous ; pour une qualité de récupération sérieuse, une petite pipeline maison gagne (les compromis sont dans RAG).

Les synthèses audio façon NotebookLM restent une fonctionnalité cloud ; les équivalents locaux les plus proches sont des pipelines DIY, pas une bascule.

Hygiène multi-utilisateurs

Dès que plus d'une personne utilise votre interface, vous êtes l'admin :

• Activez les comptes avant d'inviter qui que ce soit ; greffer de l'auth sur une instance partagée « sans login » est misérable.
• Décidez de la visibilité des modèles par utilisateur — tout le monde n'a pas besoin du 32B qui mange le GPU.
• L'historique de conversation est stocké côté serveur dans ce que vous avez déployé ; sauvegardez-le comme toute base de données.
• Il n'y a pas de modération de contenu intégrée ; la politique du foyer est appliquée par vous, en personne.
• La saisie coréenne marche partout ci-dessus ; le tokenizer du modèle compte plus que l'interface (voir jetons).

Choisir par rôle

Les lignes sont des points de départ. La plupart des foyers s'installent sur une interface de chat plus Continue.dev, et c'est un point d'arrivée parfaitement correct.

La plomberie est l'essentiel

Chaque outil ci-dessus parle OpenAI-compat, donc n'importe quel moteur issu du service se branche sur n'importe lequel d'eux — échangez le backend sans toucher l'interface que vos proches ont apprise. Deux réserves. La profondeur des fonctions varie (qualité RAG, auth, contrôles admin), vérifiez celle qui vous importe. Et « compatible OpenAI » est une spec floue : parfois une interface envoie un paramètre que votre moteur ignore en silence — testez la paire précise que vous déployez, avec une vraie conversation, avant de l'annoncer au foyer.

Avant d'imposer une interface à votre foyer, passez dix minutes : créez un second compte et connectez-vous en tant que lui, vérifiez ce qu'il peut voir, cassez une conversation, restaurez-la depuis la sauvegarde.

Chaque interface ci-dessus est un bon logiciel ; aucune n'est un logiciel géré. Vous êtes le canal de mise à jour, la tâche de sauvegarde et la réponse aux incidents.

Voir aussi : servir un endpoint · RAG · prompting · premier lancement