Principes de conception

Cinq partis pris expliquent la plupart des choix de WivenLLM. Les connaître aide à comprendre pourquoi l'application se comporte comme elle le fait.

1. Local par défaut, cloud par décision

À l'installation, aucune clé d'API n'est requise. WivenLLM démarre avec :

• un moteur d'embeddings intégré qui s'exécute sur la machine ;
• une base vectorielle locale stockée dans un dossier de l'installation ;
• une base de données locale pour les espaces, conversations et réglages.

Le modèle de langage est le seul élément à choisir, et il peut lui aussi être local. Une installation peut donc fonctionner sans aucune connexion sortante.

Brancher un fournisseur cloud reste possible, et c'est parfois le bon choix — pour la qualité, la vitesse, ou un besoin ponctuel. Mais c'est une décision explicite, prise par un administrateur, pas un état par défaut.

Conséquence pratique : l'écran Réglages → Confidentialité récapitule à tout moment quels composants sont locaux et lesquels sortent du périmètre.

2. Aucun composant n'est imposé

Le modèle de langage, le moteur d'embeddings et la base vectorielle sont trois briques interchangeables. WivenLLM parle à chacune à travers une interface commune : ajouter un fournisseur ne change rien au reste de l'application.

C'est ce qui permet de :

• démarrer en local, puis passer à un modèle plus puissant sans réindexer vos espaces (tant que le moteur d'embeddings ne change pas) ;
• utiliser un modèle différent par espace de travail — un modèle rapide pour les questions courantes, un modèle plus lourd pour l'analyse ;
• remplacer la base vectorielle locale par une base d'entreprise le jour où le volume le justifie.

→ Fournisseurs supportés

3. Une réponse doit être vérifiable

Chaque réponse construite à partir de vos documents affiche les extraits sources qui ont servi à la produire : nom du document et passage exact.

Ce principe se décline ailleurs :

• le journal d'événements conserve les actions structurantes de l'instance ;
• l'historique des conversations est consultable et exportable par un administrateur ;
• lorsqu'un agent utilise un outil, la conversation le montre.

L'objectif n'est pas de rendre le modèle infaillible, mais de rendre son travail inspectable.

4. Le contrôle est l'affaire de l'administrateur, pas de l'utilisateur

Les décisions qui engagent l'organisation — quel fournisseur, quelles compétences d'agent, quelles règles de contenu, qui accède à quoi — sont regroupées dans l'administration et invisibles pour les utilisateurs.

Ceux-ci disposent d'une interface volontairement simple : des espaces de travail, des conversations, des documents. Ils peuvent régler ce qui les concerne (apparence, langue, leurs propres mémoires) sans pouvoir modifier la configuration de l'instance.

→ Utilisateurs et rôles

5. On commence petit

L'application est utilisable dès l'onboarding, avec un espace de travail et un document. Les fonctions avancées — agents, flux, tâches planifiées, routeur de modèles, widget web, API — sont désactivées ou vides par défaut et s'activent quand le besoin apparaît.

Ce principe explique pourquoi certaines fonctions sont invisibles tant qu'elles n'ont pas été activées : Réglages → Fonctions bêta, Réglages → Agents, Réglages → Tâches planifiées.

Ce que ces principes impliquent pour vous