Votre modèle local répond bien aux questions, mais il ne « fait » rien tout seul : pas de météo réelle, pas de calcul fiable sur un fichier métier, pas d’appel à un service interne. Dans Open WebUI, outils, fonctions et pipelines permettent d’étendre l’interface pour qu’une demande puisse déclencher une action contrôlée. Ce tutoriel pose le vocabulaire, le parcours d’installation, trois exemples commentés et les précautions indispensables pour une mairie, une association ou un atelier en Hauts-de-France qui veut rester maître des données.
Pour qui, et dans quel contexte régional
Ce parcours s’adresse à des profils déjà à l’aise avec une IA locale (Ollama ou équivalent) et Open WebUI : médiateurs numériques, responsables informatiques de petites structures, artisans numériques qui animent un atelier. Imaginez une Maison régionale de l’IA à Lille, un atelier associatif à Amiens, ou la salle serveurs d’une communauté de communes près de Valenciennes : l’enjeu n’est pas « avoir le plus d’outils », c’est en brancher peu, utiles, et auditables.
Si vous découvrez encore l’installation de base, commencez par un tutoriel d’amorçage Open WebUI / Ollama de la série avancée (par exemple installer une IA locale si vous l’avez sous la main dans le catalogue) avant d’ajouter des extensions. Ici, on suppose que vous ouvrez déjà un chat local et que vous savez redémarrer le conteneur ou le service.
Outils, fonctions et pipelines : ne pas tout confondre
Les libellés évoluent selon les versions d’Open WebUI. Avant de cliquer, ouvrez la documentation du jour et repérez les menus réels : les noms « Tools », « Functions », « Pipelines » (ou leurs équivalents traduits) peuvent bouger. Ce qui suit est un cadre de principe, pas une capture figée.
En pratique, trois familles se distinguent. Les filtres ou fonctions côté interface agissent sur le message (avant envoi, après réponse) : masquer un motif, ajouter un en-tête, journaliser. Les outils (tool calling) exposent au modèle une capacité déclarée : « obtenir la météo », « calculer », « lire une API autorisée ». Les pipelines assemblent souvent plusieurs étapes plus riches, parfois hors du simple aller-retour chat. Votre décision d’architecture dépend du risque : un filtre de journalisation locale n’a pas le même impact qu’un outil qui appelle un service métier.
| Famille | Rôle typique | Risque principal |
|---|---|---|
| Filtre / fonction légère | Modifier ou annoter le flux de messages | Fuite de données dans un log mal placé |
| Outil (tool) | Action appelée par le modèle sous conditions | Appel réseau ou écriture non voulue |
| Pipeline | Chaîne d’étapes plus structurée | Complexité, dette et surfaces d’attaque |
Pourquoi étendre plutôt que « tout demander au modèle »
Un modèle local invente volontiers une température ou un taux de change. Un outil météo qui interroge une source autorisée, ou un calcul effectué hors LLM, réduit ce genre d’hallucination factuelle. Dans un cabinet de conseil à Roubaix qui prépare des synthèses pour des PME, ou dans un entrepôt logistique à Dourges qui veut un assistant pour des procédures internes, la séparation est claire : le modèle rédige et oriente ; l’outil fournit le fait ou exécute le geste cadrés.
Étendre Open WebUI n’est pas obligatoire pour bien travailler. Beaucoup d’usages restent du texte : reformuler, résumer un PDF déjà local, préparer un ordre du jour. N’ajoutez un outil que lorsqu’une action répétée justifie le coût de maintenance. Chaque extension est un contrat de confiance avec votre structure.
Installer depuis la communauté : méthode saine
Open WebUI propose souvent un catalogue ou un dépôt communautaire d’extensions. Les menus exacts et les tags changent : vérifiez sur la documentation officielle du jour le chemin (administration, espace développeur, import). Principe : lisez le code avant d’activer, préférez une source connue, testez sur une instance jetable, pas sur le serveur qui porte déjà des dossiers agents.
En atelier, affichez le code au vidéoprojecteur. Demandez : quelles URL sont appelées ? Quels secrets sont lus ? Le fichier écrit-il sur le disque ? Qui peut activer l’outil (admin seul, tous les utilisateurs) ? Ces questions valent mieux qu’un tutoriel vidéo trop rapide. Pour la posture données, gardez les données à ne pas confier à portée de main même en local : local n’égale pas « sans risque » si un outil ouvre Internet.
Écrire le sien : un outil minimal et lisible
Commencez par un outil qui ne fait presque rien d’utile métier : par exemple renvoyer l’heure du serveur ou un calcul simple. L’objectif pédagogique est de voir le cycle déclaration → appel → résultat dans le chat, pas de résoudre la facturation dès le premier soir. Documentez en français dans le code : nom de l’outil, paramètres, ce qu’il ne fait pas.
Évitez de coller des clés API dans le corps de l’outil versionné. Utilisez les variables d’environnement ou le coffre prévu par votre déploiement. Si vous devez appeler une API interne de mairie, restreignez l’URL à un préfixe connu et refusez les redirections fantaisistes. Un outil « générique » qui accepte n’importe quelle URL est une invitation aux maladresses.
# Outil minimal — principe pédagogique IAHDF
# Vérifiez la signature exacte (décorateurs, schéma JSON, permissions)
# dans la documentation Open WebUI de votre version avant collage.
"""Outil démo : additionne deux nombres. Aucun accès réseau."""
def add_demo(a: float, b: float) -> dict:
"""Retourne la somme. Entrées numériques uniquement."""
return {
"ok": True,
"sum": a + b,
"note": "Résultat calculé hors modèle, sans appel externe.",
}
# À câbler selon le format Tools/Functions de votre instance :
# - déclarer le nom visible dans le chat
# - déclarer le schéma des paramètres
# - restreindre aux comptes autorisés
# - journaliser l’appel côté serveur (sans coller de données sensibles)Trois exemples commentés (météo, calcul, API)
Exemple 1 — météo : l’outil interroge une API météo que vous avez choisie et autorisée, avec une clé stockée hors chat. Le modèle ne « devine » plus le ciel de Calais. Limitez la ville à une liste ou à un format strict. Journalisez l’appel, pas le contenu des conversations utilisateurs.
Exemple 2 — calcul ou conversion : utile pour des totaux, des pourcentages, des unités. Le modèle propose la formule ; l’outil exécute. Dans une association qui gère des stocks de matériel pédagogique, cela évite des erreurs de relecture fastidieuses.
Exemple 3 — appel d’API interne : lecture seule d’un statut (« salle libre / occupée ») ou d’un référentiel public interne. Refusez l’écriture tant qu’un humain n’a pas validé le flux dans un autre outil (par exemple via n8n + Ollama pour des automatisations plus larges). Le chat n’est pas un bouton « supprimer la base ».
Sécurité : le cœur du tutoriel avancé
Principe de minimisation : l’outil ne reçoit que les paramètres nécessaires. Principe de moindre privilège : compte de service dédié, droits lecture si possible. Principe de séparation : instance de test ≠ instance qui voit des dossiers RH. En local, les données peuvent rester sur la machine — c’est un avantage fort pour le RGPD — mais un outil qui exfiltre vers un SaaS annule cet avantage. Si vous sous-traitez l’hébergement du serveur, clarifiez le rôle du prestataire.
Gouvernance légère pour une structure HdF
Nommez un responsable des extensions (même à temps partiel). Tenez une liste : nom de l’outil, date d’activation, auteur interne, données touchées, URL autorisées. Présentez cette liste en cinq minutes lors d’un comité ou d’une réunion d’équipe. Ce geste suffit souvent à éviter l’accumulation silencieuse d’expérimentations oubliées.
Formez les utilisateurs finaux : « si l’assistant dit qu’il a envoyé un mail, vérifiez dans la messagerie réelle ». Le tool calling donne une impression d’agence ; la responsabilité reste humaine. Pour un usage hybride local + API cloud selon la sensibilité, enchaînez avec local et API selon les besoins.
Pas à pas : de zéro à un premier outil utile
Figer le périmètre de l’instance
Choisissez une machine ou un conteneur de test, distinct de la production et inaccessible depuis le Wi-Fi public de l’accueil. Notez la version d’Open WebUI et celle du backend de modèles, ainsi que le système d’exploitation. Créez un compte admin de labo et un compte utilisateur sans droits d’installation. Décidez quelles données fictives vous utiliserez (fausses adresses, faux horaires de salle, faux numéros de dossier). Ce cadre évite de « tester » sur le vrai dossier d’une association, d’un cabinet ou d’une mairie pendant que vous découvrez encore les menus. Affichez sur un post-it la règle : « pas de fichier réel ici ».
Lire la doc du jour et repérer les menus
Ouvrez la documentation officielle correspondant à votre numéro de version, pas un tutoriel vidéo non daté. Cherchez les pages Tools, Functions, Pipelines (ou équivalents traduits). Repérez où l’on active une extension, où l’on importe du code, où l’on définit les permissions par modèle ou par utilisateur. Ne vous fiez pas à une capture d’écran d’un blog ancien : les tags et libellés bougent d’une version à l’autre. Notez le chemin réel sur un papier pour l’atelier et photographiez uniquement des écrans sans données. Préparez deux chemins alternatifs si l’interface a été renommée.
Importer un exemple communautaire minimal
Choisissez un outil sans accès réseau, ou avec un accès clairement documenté vers une URL de démonstration. Lisez le code ligne à ligne à voix haute en binôme. Cherchez requests, http, subprocess, open en écriture, chemins absolus, variables d’environnement manquantes. Si un secret apparaît en dur, refusez l’outil sans négocier. Activez-le uniquement pour le compte de test. Posez dans le chat une consigne qui doit déclencher l’outil, puis une consigne qui ne doit pas le déclencher, pour observer le comportement réel du modèle et de l’interface. Conservez les journaux de ces deux essais.
Écrire votre outil démo (calcul ou heure)
Reproduisez le squelette de principe ci-dessus en l’adaptant à la signature exigée par votre version (décorateurs, schéma JSON, permissions). Déclarez des types stricts et refusez les chaînes là où un nombre est attendu. Ajoutez un message d’erreur clair si les paramètres sont absents. Testez depuis le compte utilisateur limité, pas seulement depuis l’admin. Vérifiez que le résultat affiché dans le chat correspond au calcul serveur, pas à une invention du modèle. Documentez en cinq lignes dans un README interne : but, limites, contact, date, version Open WebUI. Committez ce README avec le code.
Ajouter un seul outil métier borné
Passez à un cas réel léger : météo bornée à une liste de communes, lecture d’un statut interne en lecture seule, ou conversion d’unités pour un atelier. Bornez les URL et les paramètres ; refusez les jokers. Stockez les secrets hors dépôt Git, dans le coffre de déploiement. Activez la journalisation des appels d’outil sans y coller le contenu complet des conversations. Faites valider le comportement par une personne métier (secrétaire de mairie, gestionnaire d’atelier, responsable de permanence) qui dira si le résultat est actionnable. Si la réponse est « presque », resserrez encore le périmètre avant d’élargir.
Closoir de sécurité et mise en production progressive
Checklist écrite : droits, secrets, URL autorisées, comptes, sauvegarde de la config, procédure de désactivation rapide, propriétaire nommé. Présentez la liste des outils aux collègues avant l’ouverture. Ne déployez sur l’instance réelle qu’après un essai réussi sur données fictives et une relecture du code à deux. Planifiez une revue dans trente jours : l’outil est-il encore utilisé ? Sinon, désactivez-le sans culpabilité. Pour automatiser au-delà du chat, évaluez n8n auto-hébergé plutôt que d’empiler des outils opaques dans Open WebUI. Archivez le compte rendu de revue avec la date.
Animer un atelier d’une heure trente
Découpez : quinze minutes de vocabulaire avec le tableau, vingt minutes de lecture de code en binôme, trente minutes d’installation guidée, quinze minutes de checklist sécurité, dix minutes de questions. À Valenciennes comme à Boulogne-sur-Mer, le moment « on lit le code ensemble » crée plus de confiance que la démo magique où tout fonctionne déjà. Préparez un incident simulé (outil qui tente une URL hors liste) pour ancrer le réflexe de coupure.
Laissez un exercice maison : écrire un outil qui refuse toute URL hors d’une liste blanche, avec un test unitaire minimal si votre stack le permet. Au prochain atelier, comparez les approches sans transformer la session en concours. Vous formerez ainsi une culture d’extensions modestes plutôt qu’une course aux gadgets. Remettez à chaque participant la fiche registre (nom, date, propriétaire, données touchées).
Limites honnêtes
Tous les modèles ne gèrent pas parfaitement le tool calling. Tous les outils communautaires ne sont pas maintenus. Une extension peut casser après une mise à jour majeure d’Open WebUI. Prévoyez du temps de maintenance dans le calendrier de la structure, pas seulement le soir d’enthousiasme. Ce tutoriel ne donne ni grille tarifaire, ni scores de performance, ni quotas d’API inventés : mesurez chez vous, sur vos machines, avec vos journaux, et acceptez qu’un outil utile aujourd’hui soit retiré demain s’il n’a plus de propriétaire.
Questions fréquentes
Mon IA locale peut-elle utiliser des outils ?
Oui, si votre interface (ici Open WebUI) et votre modèle supportent l’appel d’outils, et si vous activez explicitement des extensions après relecture. Ce n’est pas magique : chaque outil est du code que vous acceptez d’exécuter dans le périmètre de votre serveur. Sans outil, le modèle ne fait que générer du texte. Avec un outil borné, il peut obtenir un fait ou déclencher une action cadrée. Vérifiez la compatibilité sur la documentation de votre version avant de promettre l’agence à vos collègues, et prévoyez un plan de coupure si le comportement dévie.
Faut-il préférer un pipeline à un simple outil ?
Pas par défaut. Un outil unique et lisible suffit pour un premier besoin métier, surtout si une seule personne maintient la stack. Les pipelines aident quand plusieurs étapes stables doivent s’enchaîner hors d’un simple aller-retour de chat. La complexité augmente la surface d’erreur et le temps de reprise après mise à jour. Commencez petit ; n’introduisez un pipeline que lorsque le scénario le justifie vraiment, avec un responsable nommé, une documentation courte et un test de non-régression que vous rejouerez après chaque upgrade.
Puis-je laisser tous les agents installer des outils ?
Ce n’est en général pas souhaitable sur une instance partagée. Réservez l’installation à un compte d’administration, tenez un registre, et donnez aux utilisateurs finaux seulement l’usage des outils validés. Dans une mairie ou une asso, la tentation du « j’ai trouvé un truc GitHub » est réelle : le cadre évite les surprises du lundi matin. La confiance se construit par la relecture et le labo séparé, pas par l’interdiction totale d’expérimenter : expérimentez librement, mais sur une instance jetable sans dossiers nominatifs ni accès métier.
Un outil local respecte-t-il automatiquement le RGPD ?
Non. Le fait de rester sur votre machine aide à la maîtrise des données et à la minimisation des transferts, mais un outil peut envoyer des informations vers un tiers, journaliser trop large, ou mélanger des finalités sans que personne ne le remarque. Appliquez les principes : minimisation, accès limité, information des personnes concernées selon votre contexte, et clarté sur d’éventuels sous-traitants d’hébergement. En cas de traitement sensible, associez votre référent données ou juridique avant l’activation en production, pas après l’incident.
Que faire après ce tutoriel ?
Stabilisez un seul outil métier borné, rédigez sa fiche interne (but, limites, propriétaire, date de revue), puis explorez le mode hybride local / API selon la sensibilité avec Open WebUI local et API. Si vous devez automatiser des flux hors chat, regardez n8n et Ollama plutôt que d’empiler des appels opaques. Pour pratiquer en présentiel en Hauts-de-France, consultez l’agenda IAHDF et l’inscription aux ateliers près de chez vous, et emportez votre registre d’outils à faire relire.
Pour aller plus loin
Vous savez maintenant pourquoi étendre Open WebUI, comment distinguer les familles d’extensions, et comment déployer sans naïveté. Gardez une instance propre, peu d’outils, beaucoup de relecture. Retrouvez les sessions près de chez vous sur l’agenda, rejoignez un parcours via l’inscription, et approfondissez la discipline des données avec les données à ne pas confier.