Comment donner à l’IA l’accès à mes outils sans bricolage opaque ? Le Model Context Protocol (MCP) propose un standard pour exposer des capacités (fichiers, agenda, base, API internes) à des clients IA compatibles. Ce tutoriel explique le concept, guide un premier serveur, montre le branchement côté client, donne trois exemples de périmètre, et insiste sur la sécurité — pour un labo associatif à Lille, une DSI de collectivité, ou un indépendant qui veut éviter les plugins jetables.
C’est quoi MCP (sans mythologie)
MCP est un protocole pour brancher des outils contextuels à des assistants. L’idée : plutôt que chaque application invente son plugin propriétaire, un serveur MCP expose des capacités standardisées qu’un client comprend. L’écosystème évolue vite (clients, SDK, exemples). Vérifiez toujours la spécification et les guides officiels à la date de votre atelier.
MCP ne rend pas un modèle « omniscient ». Il lui donne des portes. Si vous laissez la porte ouverte sur tout le disque, le modèle n’a pas besoin d’être malveillant pour faire des dégâts : une consigne ambiguë suffit.
Tenez le registre MCP comme vous tiendriez un registre de comptes de service : nom, propriétaire, données, date de revue, interrupteur de coupure. Présentez-le en cinq minutes en comité technique. L’absence de registre est déjà un signal d’alerte pour une DSI régionale.
Dans un labo associatif à Lille, commencez par l’outil fichiers en lecture seule pendant deux ateliers avant toute écriture. La frustration pédagogique d’aller lentement est inférieure au coût d’un fichier écrasé sur un partage mal borné.
Méfiez-vous des serveurs MCP « tout-en-un » qui promettent shell, Docker et cloud admin. Plus le serveur est puissant, plus la relecture doit être longue. Un atelier IAHDF sérieux coupe ces exemples plutôt que de les démarrer sous les applaudissements.
Si un prestataire propose d’« installer MCP en une heure » sans registre ni sandbox, demandez le détail des droits OS et le plan de coupure. L’absence de réponse claire suffit à reporter. La vitesse d’installation n’est pas un critère de maturité pour une structure qui gère des dossiers usagers.
MCP vs outils Open WebUI vs n8n
Dans Open WebUI outils, les extensions vivent souvent dans l’univers de l’interface. Dans n8n, l’automatisation est scénarisée hors chat. MCP se place comme un contrat d’outil réutilisable entre clients compatibles. Vous pouvez cohabiter : n8n pour les flux planifiés, MCP pour l’assistance interactive, Open WebUI pour le quotidien local. Choisissez selon la compétence de maintenance, pas selon la mode.
| Besoin | Piste | Commentaire |
|---|---|---|
| Chat + outils dans Open WebUI | Functions / Tools OWUI | Simple si tout reste là |
| Flux planifiés multi-apps | n8n (+ Ollama) | Orchestration visuelle |
| Outils standard entre clients IA | Serveur MCP | Portabilité relative |
| Action métier critique | Humain + workflow dédié | Pas le chat seul |
Installer un premier serveur MCP
Les SDK (selon langage) permettent d’exposer des outils déclarés : par exemple lister des fichiers d’un répertoire borné, créer un événement d’agenda de test, lire une table en lecture seule. Partez d’un exemple officiel ou d’un template à jour, puis réduisez les droits. Travaillez dans un dossier sandbox, jamais sur le partage RH.
Prérequis terminal : savoir lancer un process, lire des logs, définir des variables d’environnement. Sur Windows comme sur Linux de serveur régional, isolez l’utilisateur système qui exécute le serveur MCP.
# Pseudo-schéma pédagogique — adaptez au SDK MCP du jour Outil: list_sandbox_files Description: Liste les fichiers du répertoire sandbox uniquement. Paramètres: - subpath (string, optionnel) : sous-chemin relatif, sans ".." Règles serveur: - racine = /var/mcp/sandbox (exemple) - refuser toute sortie de racine - pas d’écriture - journaliser l’appel (horodatage, subpath, compte client) Retour: - liste de noms de fichiers - erreur explicite si subpath invalide # Branchement client : déclarer la commande de démarrage du serveur # dans la config du client compatible (syntaxe selon doc du client).
Connecter un client compatible
Des assistants et IDEs documentent l’ajout de serveurs MCP (fichiers de config, commandes, transports). Les noms de champs changent : suivez la doc du client que votre structure autorise. Principe : déclarer la commande de lancement du serveur, les variables, éventuellement un périmètre. Redémarrer le client. Vérifier dans les logs que l’outil apparaît.
Si vous utilisez un client cloud, posez la question du trajet des données : l’outil s’exécute où ? Le contenu remonte où ? Un serveur MCP local branché à un client qui envoie tout à un cloud n’offre qu’une souveraineté partielle. Alignez-vous sur hybride local/API et données sensibles.
Trois exemples de périmètre
Exemple fichiers : lecture d’un dépôt de procédures qualité à Arras, écriture interdite. Exemple agenda : créer des événements dans un calendrier de test, jamais le calendrier officiel des élus sans circuit. Exemple base : SELECT seul sur une vue SQL préparée, pas d’UPDATE libre. Ces trois exemples suffisent à un atelier ; n’ouvrez pas le shell système « pour voir ».
Sécurité : le chapitre qui compte
Allowlist de chemins, refus des traversées de répertoires, comptes dédiés, secrets hors prompts, revue de code avant prod, désactivation rapide. Journalisez les appels d’outils. Formez les utilisateurs : « l’IA a dit qu’elle avait supprimé » n’est pas une preuve — vérifiez le système cible.
Gouvernance légère HdF
Registre des serveurs MCP : nom, propriétaire, données touchées, date de revue. Présentation en cinq minutes en comité technique. Même discipline que pour les outils Open WebUI. L’outil change ; le registre reste.
Atelier pratique d’une demi-journée
Matin : concept + tableau comparatif + menaces. Après-midi : sandbox fichiers en binômes, puis démo agenda de test. Clôture : checklist sécurité lue à voix haute. À Valenciennes comme à Calais, ce format produit plus de prudence que deux heures de slides.
Pas à pas : premier serveur MCP utile et borné
Clarifier le besoin d’outil
Écrivez une phrase : « pendant le chat, l’assistant doit pouvoir faire X sur Y, rien d’autre ». Si X est un flux planifié multi-étapes, basculez vers n8n. Si X est un filtre de messages Open WebUI, restez dans outils OWUI. MCP n’est pertinent que si vous voulez un serveur d’outil réutilisable par un client compatible. Cette phrase évite le bricolage de prestige. Faites-la valider par un métier avant d’ouvrir le terminal, pour ancrer le périmètre hors de la seule curiosité technique.
Préparer une sandbox et un utilisateur OS dédié
Créez un répertoire sandbox avec des fichiers fictifs représentatifs. Créez un utilisateur ou un service account qui n’a accès qu’à ce répertoire. Préparez un agenda de test ou une base de démo si besoin. Aucune donnée nominative réelle à ce stade. Sur un serveur de collectivité, faites valider ce cloisonnement par l’admin système avant d’aller plus loin. Documentez les chemins et les comptes dans le registre MCP dès le premier jour du labo. Prenez le temps de documenter ce point dans votre cahier d’atelier avant de passer à l’étape suivante.
Implémenter le serveur minimal
Partir du SDK ou de l’exemple officiel à jour pour votre langage. Exposez un seul outil en lecture (liste ou lecture de fichier bornée). Ajoutez la validation de chemin anti-traversée. Ajoutez des logs horodatés. Lancez en terminal et testez avec le client de développement documenté. Refusez toute expansion de scope tant que ce minimal n’est pas stable, relu à deux, et décrit dans le registre. Un second outil trop tôt dilue la relecture. Prenez le temps de documenter ce point dans votre cahier d’atelier avant de passer à l’étape suivante.
Déclarer le serveur dans le client IA
Suivez la configuration du client autorisé par votre structure (fichier, UI, variables — menus selon version). Pointez vers la commande de démarrage du serveur. Redémarrez. Vérifiez que l’outil est visible. Posez une consigne qui doit déclencher l’outil, puis une consigne hors périmètre qui ne doit rien modifier. Documentez les captures de menus pour vos collègues en rappelant qu’ils peuvent changer selon versions. Archivez aussi les logs d’un essai réussi et d’un essai refusé. Prenez le temps de documenter ce point dans votre cahier d’atelier avant de passer à l’étape suivante.
Ajouter un deuxième outil encore borné
Par exemple lecture d’un événement d’agenda de test, ou SELECT sur une vue SQL préparée. Gardez l’écriture pour plus tard, avec validation humaine obligatoire. Mettez à jour le registre. Faites une revue de code en binôme. Mesurez le comportement sur cas d’erreur (chemin invalide, base down, timeout). Un outil silencieux qui « réussit » à vide est un piège : exigez des erreurs explicites. Ne passez à l’écriture que si la lecture est irréprochable pendant une période d’essai définie. Prenez le temps de documenter ce point dans votre cahier d’atelier avant de passer à l’étape suivante.
Checklist sécu et décision go / no-go
Parcourez : cloisonnement OS, secrets, logs, allowlist, procédure de coupure, formation utilisateurs, trajet des données si le client est cloud. Décidez explicitement si le serveur peut toucher un préproduit. Sinon, restez en labo sans ambiguïté. Planifiez une revue à trente jours. Croisez avec données à ne pas confier avant tout dossier réel. Une décision no-go écrite est un succès pédagogique, pas un échec : elle prouve que le cadre fonctionne. Prenez le temps de documenter ce point dans votre cahier d’atelier avant de passer à l’étape suivante.
Questions fréquentes
Comment donner à l’IA l’accès à mes outils ?
En exposant des capacités bornées via un mécanisme maîtrisé : outils d’interface, scénarios n8n, ou serveurs MCP selon le besoin. L’important est le périmètre, la relecture, et la journalisation. « Brancher MCP » n’est pas une fin : c’est une façon de déclarer des portes. Commencez lecture seule, sur sandbox, avec un propriétaire nommé. Éclaircissez le trajet des données si le client d’IA n’est pas entièrement local, pour ne pas croire à une souveraineté fictive. Prenez le temps de documenter ce point dans votre cahier d’atelier avant de passer à l’étape suivante.
MCP fonctionne-t-il uniquement avec un fournisseur précis ?
Le protocole vise l’interopérance entre clients et serveurs compatibles. La liste des clients évolue rapidement. Vérifiez la compatibilité de votre assistant ou IDE sur la documentation du jour. Ne supposez pas qu’un serveur trouvé sur un dépôt public marchera partout sans adaptation. Testez dans votre labo, avec vos versions, et documentez le couple client/serveur qui a réellement fonctionné. Méfiez-vous des tutoriels non datés qui promettent une universalité immédiate. Prenez le temps de documenter ce point dans votre cahier d’atelier avant de passer à l’étape suivante.
Puis-je exposer toute ma base de données ?
Ce n’est pas raisonnable. Exposez une vue limitée, en lecture, avec des filtres serveur stricts. Interdisez le SQL libre demandé par le modèle. Les données métier critiques passent par des applications dédiées et des droits métier, pas par un chat. MCP n’annule pas la gestion des accès ni le principe du moindre privilège. Si un métier demande « tout », reformulez avec lui un sous-ensemble utile et auditable pour un premier serveur. Prenez le temps de documenter ce point dans votre cahier d’atelier avant de passer à l’étape suivante.
Quel lien avec la sécurité RGPD ?
Si les outils restent sur votre machine ou réseau maîtrisé, vous favorisez la maîtrise des flux — à condition de minimiser les données exposées à l’outil et de clarifier tout sous-traitant (hébergeur, client cloud). Documentez finalité et accès. Consultez votre référent pour les traitements sensibles. Aucun protocole n’est « conforme » par magie. Un serveur MCP trop large peut créer un nouveau canal de sortie de données aussi risqué qu’un export manuel mal encadré. Prenez le temps de documenter ce point dans votre cahier d’atelier avant de passer à l’étape suivante.
Que faire après ce premier serveur ?
Tenir le registre, former les utilisateurs, et n’ajouter un outil d’écriture qu’avec validation humaine. Comparer avec outils Open WebUI et n8n pour éviter la duplication de briques. Pratiquer en atelier via l’agenda et l’inscription. Relire données à ne pas confier avant le passage sur données réelles. Planifiez la revue à trente jours dès le jour où vous dites « ça marche » en labo. Prenez le temps de documenter ce point dans votre cahier d’atelier avant de passer à l’étape suivante.
Pour aller plus loin
Vous savez ce qu’est MCP, comment monter un serveur minimal, et pourquoi la sécurité prime sur la démo. Gardez peu d’outils, beaucoup de bornes. Sessions : agenda, inscription, référence croisée étendre Open WebUI.