Un modèle de langage local s’essaie rapidement. Un assistant IA partagé exige aussi des accès encadrés, des flux de données clairs et un responsable de l’exploitation. Ollama et Open WebUI peuvent travailler ensemble : un composant exécute les modèles, l’autre fournit l’interface pour le travail quotidien.
En entreprise, la planification part d’une tâche précise : rédiger à partir de notes approuvées, structurer des notes internes ou aider sur des questions techniques. Définir les entrées autorisées, la vérification des résultats et les délais de réponse acceptables précède le choix du matériel.
Deux composants aux rôles distincts
Ollama fournit l’environnement d’exécution et une API pour les modèles de langage. Open WebUI ajoute une interface web administrable. Une interface installée localement ne dit toutefois pas où chaque modèle connecté traite les requêtes. Modèles cloud, recherche web et outils supplémentaires peuvent emprunter d’autres flux de données.
Dans ce concept d’exploitation, les employés accèdent à l’interface par un accès autorisé. Open WebUI se connecte en interne à Ollama. L’API du modèle est réservée aux services qui en ont réellement besoin. Les connexions entre conteneurs ou serveurs distincts doivent être planifiées explicitement : localhost désigne l’environnement réseau propre à chaque composant.
Du poste individuel au service partagé
La différence porte surtout sur ce qui suit le premier chat réussi. Ce comparatif décrit une évolution possible pour une petite entreprise ; il s’agit d’une aide à la planification, pas d’un projet client documenté.
| Domaine | Test individuel | Usage partagé |
|---|---|---|
| Accès | Une personne teste sur son propre ordinateur. | Comptes individuels, rôles définis et retrait d’accès encadré. |
| Données | Données d’exemple non sensibles. | Types de données autorisés, conservation et droits vérifiables sur les sources. |
| Disponibilité | L’ordinateur reste allumé pendant le test. | Horaires d’utilisation convenus et reprise documentée. |
| Capacité | Une requête donne une réponse utile. | Mesure des tâches simultanées, des attentes et des entrées plus longues. |
| Modifications | Le modèle et le logiciel sont essayés. | Versions testées, sauvegarde avant modification et retour arrière fiable. |
Sécuriser séparément l’accès et l’API du modèle
Selon l’éditeur, l’API locale d’Ollama n’exige pas d’authentification propre. L’exposition au réseau ne remplace donc pas le contrôle d’accès. Pour un service d’entreprise, l’API du modèle ne devrait être accessible que par les connexions internes nécessaires. Un port ouvert à tous les postes ou à Internet n’est pas un point de départ adapté. Ollama : authentification (lien externe).
Configurer volontairement connexion, approbation des utilisateurs et droits administratifs de l’interface. Un service d’identité existant peut constituer une intégration utile ; le choix dépend de l’environnement. Un proxy ne doit transmettre une identité authentifiée qu’au moyen d’informations fiables qu’il définit lui-même. Open WebUI : accès et autorisations (lien externe).
HTTPS protège la liaison du navigateur au point d’accès. Avec plusieurs systèmes, la liaison suivante vers le backend doit aussi être chiffrée et restreinte selon les besoins de protection. Certificats, redirections et connexions nécessaires à l’interface sont testés ensemble. Open WebUI : HTTPS et reverse proxy (lien externe).
Vérifier le caractère « local » par le flux réel des données
Pour des appels exclusivement locaux, Ollama propose un mode sans ses fonctions cloud. Cela ne remplace pas la vérification des autres connexions d’Open WebUI ou des outils ajoutés. Le téléchargement des modèles et les mises à jour nécessitent aussi un chemin d’approvisionnement planifié. Ollama : utilisation locale et fonctions cloud (lien externe).
- Modèle : Quelle version précise traite la requête et où s’exécute-t-elle ?
- Documents : Où sont stockés fichiers téléversés, textes extraits, index de recherche et sauvegardes ?
- Services complémentaires : D’autres prestataires interviennent-ils pour la recherche, l’OCR, la voix ou les embeddings ?
- Outils : Quelle connexion peut lire des données ou déclencher des actions, et avec les droits de qui ?
Le cloud et l’hybride peuvent être des compléments adaptés. Il faut alors définir explicitement prestataires, types de données et autorisations. Le basculement vers un service externe ne devrait pas se produire discrètement parce que le modèle local est occupé.
Les connaissances de l’entreprise exigent des droits précis
La connexion établit d’abord qui utilise l’interface. Elle n’accorde pas automatiquement le droit de voir tous les documents téléversés. Dans cet exemple, un guide approuvé pourrait être disponible pour tous les utilisateurs pilotes, tandis que les dossiers du personnel restent entièrement hors du pilote.
Lors de l’ajout ultérieur de sources, vérifier les droits par collection, document et utilisateur. Résultats de recherche, citations, chats partagés et réponses enregistrées peuvent aussi divulguer des informations. Les modifications de groupes ou de droits sur les sources doivent prendre effet dans la solution de connaissances. Pour approfondir, voir Connaissances d’entreprise et RAG et Sécurité IA et autorisations.
Sauvegarde et mises à jour font partie du concept
Sauvegarder les données réellement utilisées : base de données, fichiers et configuration, ainsi que les clés nécessaires à la restauration. Documenter le nom et la version exacte du modèle, y compris les modèles adaptés et les extensions propres. La sauvegarde est conservée séparément du système en service avec des accès protégés.
Avant une mise à jour, prévoir une sauvegarde restaurable, lire les notes de version et tester hors production. Après une migration de base de données, une ancienne image de conteneur ne rétablit pas nécessairement à elle seule l’état précédent. Open WebUI : mises à jour, sauvegarde et retour arrière (lien externe).
Un test de restauration pertinent commence dans un environnement distinct. Y vérifier connexion, liaison au modèle, tâche non sensible et autorisations attendues. Ce n’est qu’alors qu’on peut estimer la durée réelle d’une interruption. Une VM active ou un répertoire de sauvegarde existant ne suffit pas à le démontrer.
Une interface active ne prouve pas que le modèle fonctionne
La supervision doit distinguer interface accessible, modèle choisi disponible et requête complète fonctionnelle. La documentation Open WebUI sépare également ces niveaux. Open WebUI : supervision fonctionnelle (lien externe).
Pour l’exploitation convenue, surveiller aussi occupation du stockage, capacité disponible, taux d’erreur et temps d’attente. Les requêtes de test ne contiennent aucune information confidentielle. Les journaux doivent suffire au diagnostic sans dupliquer systématiquement toutes les conversations. Définir qui répond aux incidents et qui approuve les mises à jour avant un usage élargi.
Une recette ciblée avant le lancement
- Vérifier l’accès : Un utilisateur autorisé entre ; un utilisateur non autorisé et une zone réseau interdite restent exclus.
- Vérifier les flux de données : Modèle, interface et services complémentaires utilisent exclusivement les connexions convenues.
- Vérifier les droits : Deux rôles de test reçoivent uniquement leurs contenus autorisés. Une révocation prend effet même après une recherche auparavant réussie.
- Vérifier la charge : Exécuter les tâches typiques seules et simultanément ; consigner attentes acceptables et limites.
- Vérifier la reprise : Restaurer une sauvegarde à part ; documenter responsabilités et retour arrière.
Le matériel requis dépend du modèle, de la longueur du contexte, des usages simultanés et de l’objectif de qualité. L’architecture ne permet donc pas de déduire un nombre universel d’utilisateurs servis en même temps. L’article existant Tester l’IA locale : un pilote sous une charge représentative approfondit cette évaluation de capacité.
Commencer utilement par une tâche délimitée
DAXS peut évaluer l’infrastructure existante, planifier flux de données et accès, puis intégrer la solution à l’exploitation convenue. Un cas d’usage délimité avec une valeur vérifiable constitue un bon début. Il permet de déterminer si service local, connexion cloud ou combinaison convient économiquement et à l’organisation.
LLM locaux et infrastructure · MCP et interfaces · Demander du conseil IA et de l’automatisation
Sources : cet exemple décrit une architecture et un processus de vérification possibles, pas des instructions universelles d’installation. Fonctions, licences des modèles et compatibilité effective sont vérifiées pour les versions utilisées.
