Local ou cloud : peut-on avoir les deux ? Oui, à condition de ne pas mélanger les dossiers dans le même réflexe. Open WebUI permet souvent de déclarer plusieurs connexions : un backend local (Ollama ou équivalent) et des fournisseurs via API. Ce tutoriel pose pourquoi l’hybride existe, comment brancher les connexions, quelles règles d’usage écrire, et comment journaliser sans transformer le chat en zone grise. Scène typique : une mairie de l’Avesnois, un cabinet à Arras, une asso culturelle à Dunkerque.
Pourquoi l’hybride (sans slogan)
Un modèle local bien choisi traite des textes internes sans les envoyer chez un tiers : avantage fort pour la maîtrise des données. Une API distante peut offrir un modèle plus à l’aise sur certaines tâches longues ou multilingues, selon votre abonnement et la politique de votre structure. L’hybride consiste à décider, avant la frappe, où part le contenu. Ce n’est ni une trahison du local, ni une obligation de cloud : c’est un aiguillage explicite.
Ce n’est pas une course au « meilleur modèle ». C’est une hygiène : le compte rendu d’entretien RH reste local ; la reformulation d’un texte déjà public peut, si la charte le permet, passer par une API. Sans charte, les gens choisissent au feeling — et le feeling fuit. Dans les structures des Hauts-de-France que nous accompagnons, le feeling est le premier fournisseur d’incidents discrets.
Posez la question inverse : « Que se passe-t-il si ce collage apparaît demain dans un ticket chez un fournisseur ? » Si la réponse vous gêne, le local s’impose. Si le texte est déjà sur votre site web, l’API peut être discutée. Cette bascule mentale précède toute clé collée dans l’administration Open WebUI.
Scène Hauts-de-France : trois dossiers, trois destinations
Dans un atelier en Maison de l’IA à Lille, proposez trois enveloppes fictives. Enveloppe A : extrait anonymisé d’un règlement d’urbanisme déjà en ligne. Enveloppe B : mail d’un usager avec nom et téléphone. Enveloppe C : brouillon de discours pour une inauguration, sans donnée personnelle. Demandez aux participants de choisir local ou API avant d’ouvrir Open WebUI. Le débat dure dix minutes et ancre mieux qu’un long discours juridique.
Reprenez ensuite les données à ne pas confier : même en local, on minimise. Même via API, on lit les conditions du fournisseur et le rôle éventuel de sous-traitance. Ce tutoriel rappelle des principes ; il n’invente pas d’article de loi. Faites noter sur un paperboard la phrase retenue par le groupe : elle deviendra le bandeau d’aide sous le sélecteur de modèles.
Connexions : local et fournisseurs API
Dans Open WebUI, l’administration permet en général d’ajouter des connexions vers un serveur de modèles local et vers des API compatibles (selon versions : OpenAI, Mistral, Anthropic, ou endpoints compatibles). Les menus et libellés exacts changent : vérifiez la documentation de votre version le jour de l’installation. Principe : une connexion = une destination claire, nommée sans ambiguïté (« Local-Ollama », « API-Mistral-structure », etc.).
Stockez les clés API hors captures d’écran et hors dépôt Git. Préférez les secrets du système de déploiement. Révoquez une clé dès qu’elle a fuité dans un ticket ou un mail. Limitez les comptes qui peuvent créer des connexions. Sur un serveur hébergé par un prestataire régional, clarifiez qui a accès à la console d’administration : l’hybride mal gouverné multiplie les surfaces.
| Type de contenu | Destination par défaut | Condition |
|---|---|---|
| Données nominatives / dossiers internes | Modèle local uniquement | Pas d’outil qui exfiltre |
| Texte déjà public ou anonymisé | Local ou API selon charte | Validation métier si doute |
| Secrets, mots de passe, clés | Aucune IA | Coffre dédié seulement |
| Brouillon créatif non sensible | API possible si autorisée | Clé structure, pas compte perso |
Règles d’usage : une page suffit
Rédigez une page affichée aux utilisateurs : (1) ce qui reste local, (2) ce qui peut partir en API, (3) interdits absolus, (4) qui contacter en cas de doute, (5) rappel que l’humain valide avant envoi externe. Faites valider en réunion d’équipe. Dans une communauté de communes, alignez-vous avec la DSI ou le prestataire. Une page courte lue vaut mieux qu’un PDF de trente écrans jamais ouvert.
Nommez les modèles de façon parlante dans l’interface. « llama-local-sensible » et « api-redaction-publique » évitent l’erreur de clic. Si Open WebUI permet de restreindre certains modèles à certains groupes, activez-le. Sinon, formez et contrôlez par échantillonnage des journaux. Rejouez l’exercice des enveloppes à chaque arrivée d’un collègue.
Coûts et quotas : parler vrai sans inventer de chiffres
Les API cloud sont en général facturées selon l’usage ; les barèmes changent. Ce tutoriel ne publie ni prix, ni quotas, ni estimations inventées. Lisez la grille du fournisseur le jour J, fixez un plafond budgétaire interne, et désignez qui surveille la consommation. En local, le « coût » est surtout électrique, matériel et temps humain — planifiez la maintenance comme une ligne claire du planning informatique.
Interdisez les clés personnelles sur le serveur de la structure : la facture et la responsabilité doivent rester tracées. Un stagiaire qui colle sa clé perso dans Open WebUI crée un angle mort comptable et juridique. Prévoyez une révocation immédiate si un départ n’est pas anticipé.
Journalisation utile, pas intrusive
Journalisez a minima : qui a choisi quelle connexion, à quelle heure, pour quel espace de travail — sans enregistrer le contenu complet des conversations sensibles si ce n’est pas nécessaire. La minimisation s’applique aussi aux logs. Conservez les journaux selon votre politique interne, protégés en accès, avec une durée de vie écrite.
En cas d’incident (contenu sensible parti vers une API), vous devez pouvoir répondre vite : quelle clé, quel modèle, quelle fenêtre de temps. Sans journal, il ne reste que des souvenirs contradictoires. Avec un journal trop bavard, vous créez un nouveau silo sensible : trouvez l’équilibre avec votre référent et testez une restauration de log une fois par an.
Hybride et outils : double vigilance
Si vous avez ajouté des outils comme dans outils et fonctions Open WebUI, vérifiez qu’un outil n’envoie pas vers le réseau un contenu que la règle classe « local only ». L’hybride se joue au niveau modèle et au niveau outil. Un pipeline qui résume en local puis « enrichit » via une API peut être pertinent — ou catastrophique — selon les données. Cartographiez les outils avec la même grille que les modèles.
Charte hybride Open WebUI — version de travail 1) Par défaut : modèle LOCAL pour tout document interne, mail d’usager, note RH, santé, social, justice, éducation nominative. 2) API cloud : uniquement textes non nominatifs, déjà publics, ou explicitement validés par [rôle]. 3) Interdit : mots de passe, clés, numéros de pièces, dossiers médicaux, listes d’élèves, fichiers paie. 4) Clés API : coffre structure uniquement. Jamais dans le chat. Jamais compte personnel. 5) En cas de doute : LOCAL, puis demander à [contact]. 6) Avant envoi externe d’un texte produit : relecture humaine. Adaptez les rôles et listes à votre structure. Faites valider.
Configuration : logique pas à pas
Ordre conseillé : (1) stabiliser le local seul, (2) ajouter une API sur instance de test avec données fictives, (3) vérifier les noms affichés, (4) écrire la charte, (5) former un groupe pilote, (6) ouvrir plus largement. Ne commencez pas par brancher trois fournisseurs le même jour : chaque connexion supplémentaire dilue l’attention portée à la charte.
Testez un scénario d’erreur : demandez volontairement un contenu sensible avec le modèle API sur l’instance de test, et vérifiez que vos garde-fous (droits, noms, formation) détectent le geste. Mieux vaut un exercice contrôlé qu’un incident réel. Documentez le scénario pour le prochain collègue.
Pas à pas : brancher l’hybride sans zone grise
Cartographier les types de contenus
Réunissez un responsable métier et un profil technique dans une salle calme, avec paperboard. Listez les usages réels : courriers, résumés de réunions, aide à la rédaction web, support interne, veille publique. Classez chaque usage en local obligatoire, API possible, interdit à l’IA. Cette carte précède toute clé API et devient la pièce jointe de la charte. Dans une mairie, associez le référent données si le traitement le justifie. Sans carte, la configuration technique n’est qu’une invitation au clic impulsif du vendredi soir.
Stabiliser la connexion locale
Vérifiez qu’Open WebUI parle déjà correctement à votre backend local avant d’ouvrir le chapitre cloud. Créez un modèle visible nommé de façon explicite, testé sur données fictives uniquement. Documentez la version d’Open WebUI, du backend et du système d’exploitation. Seulement ensuite, ouvrez la page des connexions API dans l’admin — en vous calant sur la documentation du jour pour les libellés exacts de votre version. Si le local est instable, l’hybride ne fera qu’ajouter du bruit et des fausses pistes de diagnostic pour toute l’équipe.
Ajouter une première connexion API
Choisissez un seul fournisseur autorisé par votre structure (Mistral, OpenAI, Anthropic ou endpoint compatible). Créez une clé dédiée au projet, avec le minimum de droits côté fournisseur, et un libellé reconnaissable dans la console. Enregistrez-la dans le coffre, pas dans le chat ni dans un mail. Nommez la connexion clairement dans Open WebUI. Testez avec une phrase non sensible. Vérifiez sur le journal du fournisseur que l’appel apparaît comme attendu, sans y coller de données réelles de production. Révoquez immédiatement toute clé exposée par erreur.
Écrire et afficher la règle d’usage
Adaptez la charte courte fournie dans ce tutoriel à vos rôles réels et à votre organigramme. Faites-la relire par un métier et un profil données si disponible. Affichez-la dans l’espace documentation ou le wiki interne, et mentionnez-la à l’ouverture de chaque atelier. Pendant la formation, faites classer oralement cinq exemples issus de votre quotidien. Corrigez les malentendus (« local = anonymisé automatiquement » est faux ; l’anonymisation est un travail à part). Sans cette page visible, l’hybride reste une intention et redevient du feeling.
Restreindre et journaliser
Limitez qui peut ajouter des connexions et qui peut voir quels modèles, si l’outil le permet dans votre version. Activez une journalisation minimale des choix de destination, sans transformer les logs en copie intégrale des chats sensibles. Définissez qui lit ces journaux, pourquoi, et pendant combien de temps. Planifiez une revue mensuelle courte : consommation API, incidents, outils associés, clés à révoquer. Désactivez ce qui n’est plus justifié. Une revue tenue à l’agenda vaut mieux qu’un tableau de bord jamais regardé.
Pilote puis élargissement
Ouvrez l’hybride à un groupe pilote (par exemple communication pour textes publics, et secrétariat sur local seulement). Recueillez les frictions après deux semaines : noms de modèles confus, tentations de bascule, lenteurs locales. Ajustez les libellés et la charte en conséquence. Ensuite seulement, élargissez à d’autres services. Pour automatiser des flux hors interface de chat, croisez avec n8n et Ollama en gardant la même discipline de sensibilité. Clôturez le pilote par une décision écrite go / no-go datée et signée.
Limites et erreurs fréquentes
Erreur fréquente : croire que « l’API anonymise ». Non. Autre erreur : utiliser le compte cloud personnel d’un agent pour la structure. Autre encore : activer le mode hybride sans formation. Enfin : oublier que les plugins et outils peuvent sortir du schéma prévu. Relisez outils Open WebUI avec lunettes hybride. Ajoutez une erreur locale : croire que « personne n’osera » coller un dossier RH dans le modèle le plus fluide.
Exercice d’atelier (45 minutes)
Donnez dix cartes contenu. Les participants placent chaque carte sous Local, API ou Interdit. Débrief collectif. Ensuite, un binôme configure la connexion sur l’instance de labo pendant que les autres rédigent la phrase d’aide affichée sous le sélecteur de modèles. Vous repartez avec une config et une phrase, pas seulement avec des slides. Photographiez le paperboard (sans données réelles) pour le wiki.
Questions fréquentes
Local ou cloud : peut-on avoir les deux ?
Oui, techniquement, Open WebUI peut souvent exposer plusieurs connexions sur la même interface. Organiquement, oui seulement si une règle d’usage claire dit quoi envoyer où, et si quelqu’un forme les nouveaux arrivants. Sans règle, le double branchement augmente le risque plus qu’il n’ajoute de valeur. Avec règle, formation et journalisation, l’hybride devient un compromis maîtrisé entre souveraineté et capacités ponctuelles. La décision est politique et métier autant que technique ; documentez-la pour éviter le retour du feeling au moindre pic de charge.
Quel fournisseur API choisir ?
Celui que votre structure autorise, dont vous acceptez les conditions, et pour lequel vous savez gérer facturation, support et révocation de clés. Ce tutoriel ne classe pas Mistral, OpenAI ou Anthropic. Comparez fonctionnalités, localisation éventuelle des traitements, engagement de sous-traitance et procédures de sécurité selon vos besoins, en relisant les documents officiels à jour plutôt qu’un fil de discussion ancien. Faites valider le choix par la direction ou la DSI avant de coller la première clé sur le serveur.
Les données locales sont-elles « RGPD OK » par défaut ?
Rester sur votre machine favorise la maîtrise et peut réduire les transferts, ce qui aide sous l’angle des principes (minimisation, limitation des destinataires). Cela ne dispense pas d’analyser la finalité, d’informer si nécessaire, de sécuriser l’accès aux comptes et aux sauvegardes, et de traiter correctement les sous-traitants éventuels (hébergeur du serveur, prestataire d’infogérance). Consultez votre référent pour les cas sensibles. Le mot « local » n’est pas un tampon de conformité automatique, même pour une structure des Hauts-de-France bien intentionnée.
Puis-je utiliser ma clé personnelle au travail ?
Évitez. La clé personnelle mélange budgets, responsabilités, traces et propriété perçue des prompts. Demandez une clé de structure, un projet dédié, un responsable nommé, une procédure de révocation au départ d’un agent. Si votre organisation refuse toute API cloud, respectez ce choix et restez en local : l’hybride n’est pas un devoir. Documentez la décision pour les nouveaux arrivants afin d’éviter le contournement bien intentionné du « je prends ma clé, ça ira plus vite » un soir de deadline. Prenez le temps de documenter ce point dans votre cahier d’atelier avant de passer à l’étape suivante.
Que faire après la configuration ?
Formez, journalisez, revoyez chaque mois pendant le premier trimestre, puis à un rythme soutenable. Enrichissez éventuellement les capacités locales via outils et pipelines. Pour un accompagnement présentiel en Hauts-de-France, consultez l’agenda et l’inscription. Pour la discipline des contenus interdits, gardez les données à ne pas confier comme référence interne affichée à côté de la charte hybride, pas perdue dans un drive oublié après le pilote. Prenez le temps de documenter ce point dans votre cahier d’atelier avant de passer à l’étape suivante.
Pour aller plus loin
L’hybride réussi se voit à l’absence d’incidents et à la clarté des noms de modèles, pas à la longueur de la slide de lancement. Gardez peu de connexions, beaucoup de pédagogie, une revue courte mais réelle. Retrouvez les ateliers sur l’agenda, inscrivez-vous via l’inscription, et reliez la pratique à les données à ne pas confier.