Une nouvelle interface entre les bibliothèques et l’IA : le Model Context Protocol (MCP)

Pourquoi s’ouvrir (entre autres) au protocole MCP ?

Dans la vaste et multidimensionnelle problématique de l’impact de l’IA générative sur les activités et missions des bibliothèques, l’attention se concentre surtout sur quelques enjeux bien identifiés que l’on pourrait qualifier de "rhétoriques" (formation et accompagnement aux usages éthiques, AI literacy…). Pourtant la question, certes plus technique, de l’ouverture des données et des contenus documentaires aux LLMs se pose comme un enjeu stratégiquement tout aussi important que celui de l’acculturation à l’IA.

Elle s’inscrit dans une perspective plus globale qui, plutôt que de voir les LLMs uniquement comme des outils à mobiliser dans nos activités courantes (RAG) où des maillons des chaînes de traitement documentaire (computer vision, extraction de données structurées…), suppose un “glissement” de point de vue pour :

• considérer les métadonnées comme une ressource à exposer aux LLMs ;
• et donc repenser le rôle des bibliothèques comme fournisseuses de données dans l’écosystème de l’IA générative, participant à la mise en qualité et en fiabilité des outils et des données d'entraînement des modèles.

En élargissant le spectre, on pourrait considérer que ce nouveau périmètre de dissémination concerne d’ailleurs aussi bien la production scientifique dans son ensemble, à commencer par le texte intégral des publications scientifiques : puisqu’à travers leurs nombreuses interfaces grand public les modèles de langage deviennent peu à peu des vecteurs d’accès à l’information et à la connaissance, publier en open access dans ce contexte augmente ses chances en amont d’être intégré aux données d’entraînement d’un modèle (autrement dit, d’entrer dans son “espace de mots”) ou en aval d’être pleinement exploité par un agent conversationnel ou des systèmes multi-agents de deep research, et donc, dans les deux cas, de participer activement à la construction des connaissances que le modèle pourra mobiliser ou restituer.

Ainsi, que cela soit pour du fulltext scientifique ou des contenus culturels (au sens large), l’IA devient au fur et à mesure des usages et des wrappers un canal supplémentaire de diffusion, au même titre qu’un moteur de recherche ou une base de données, faisant du modèle de langage non plus seulement un outil de génération de texte (ou d’image) mais un produit supplémentaire de manipulation, de retraitement et de restitution de la donnée.

Les interactions et intégrations possibles entre les LLMs et les plateformes de diffusion de publications scientifiques sont complexes et globales, touchant aussi bien aux modèles économiques d’éditeurs préférant restreindre l’exploitation de leurs contenus et métadonnées par des outils IA propriétaires, qu’aux outils IA émergents de deep research “fédérée” venant bousculer les pratiques de recherche bibliographique et d’accès à la production académique en dehors des catalogues traditionnels. Ce mouvement est quoi qu’il en soit par nature bi-directionnel et à ce titre il convient de souligner la place centrale occupée par le serveur de preprints Arxiv dans l’écosystème de l’IA

• en amont : à l’instar de l’article fondateur de 2017 sur les réseaux Transformers “Attention is all you need”, les publications issues la recherche et de l’innovation en IA (animée par des communautés d’origines diverses publiques et privées) sont quasiment toutes déposées en preprint sur Arxiv, en open access sans pier-reviewing, ce qui garantit une recherche scientifique qui avance vite et une diffusion maximale sans barrières à l’entrée, en-dehors donc des circuits de publications éditoriaux classiques dont les délais de dépôt, relecture et validation sont bien trop longs et les modalités de publications en OA trop coûteuses
• En aval les intégrations techniques entre Arxiv et les multiples modalités de réutilisation de ses contenus sont nombreuses et structurelles : bien sûr via la plateforme phare de diffusion des modèles et datasets d’IA HuggingFace avec l’outil de veille automatisé daily papers, l’automatisation de la création d’espaces HuggingFace à partir de papiers ArXiv (fonctionnalité de la plateforme Arxiv), les nombreux datasets d’entraînement basés sur les données d’Arxiv, mais aussi par exemple avec les connecteurs fournis nativement par les frameworks Langchain ou Llamaindex

De toutes les façons, ce mouvement est d'autant plus nécessaire que la réalité s'impose déjà de façon tangible : de nombreux sites (ceux des GLAM compris) font face à une augmentation notable du trafic généré par des bots IA, certains pratiquant un scraping intensif, parfois au point de ralentir fortement les serveurs ou de perturber l'accès pour les utilisateurs humains (comme le détaille ce rapport). Cet état de fait rend d’autant plus pertinente une stratégie proactive de mise en place de canaux de diffusion spécifiques et alternatifs destinés aux modèles IA, comme l’a fait par exemple Wikipedia en mettant à disposition l’intégralité de ses contenus sous forme de dataset sur Kaggle. Il ne s’agit pas de freiner ce mouvement, mais d’en canaliser les usages dans une sorte de "régulation douce", en orientant la réutilisation vers des formats, interfaces et protocoles adaptés.

Dans cette perspective, pour les les données gérées par les bibliothèques (catalogues en lignes, plateformes d’archives ouvertes, bibliothèque numériques,...), une nouvelle étape se dessine sans doute après celle de l’exposition des métadonnées pour des interfaces humaines (IHM) et celle de leur moissonnage via des protocoles et interfaces d’exposition interopérables (Z3950, API, OAI-PMH, etc.) : l’étape qui consistera à rendre les données intégrables dans les architectures des modèles de langage.

Les solutions et propositions techniques afférentes demandent de s’acculturer à de nouveaux standards et pratiques (pré et post-training des modèles, déploiement d’agents IA,...) mais sont aussi l’opportunité de repenser la chaîne de valeur de la donnée documentaire et d’imaginer tout une gamme de nouveaux services potentiels à déployer afin de favoriser les usages de ces données dans des scénarios d’agent conversationnel ou d’accès augmenté à l’information scientifique. Ces scénarios de redistribution via les systèmes IA peuvent par exemple inclure des stratégies visant à :

• préparer des datasets de training documentés et structurés pour cet usage (jeux de métadonnées ou chunks de publications avec embeddings par exemple), déposés sur HuggingFace ou autre (et à ce titre se poserait presque la question de plateformes nationales et souveraines pour des datasets de confiance)
• rendre les corpus exploitables par la mise à disposition au niveau des unités documentaires directement dans les interfaces d’export d’embeddings pour faciliter leur intégration dans des applications de RAG, ou pourquoi pas de bases de données vectorielles thématiques prêtes à l’emploi…
• proposer des connecteurs (comme des serveurs MCP) vers les bases de données et référentiels documentaires (HAL,OpenAlex, Sudoc, Idref…)

Le protocole MCP

Dans ce petit panorama des solutions pour une visibilité et une découvrabilité accrue des contenus scientifiques et culturels, le Model Context Protocol est intéressant car il permet de mettre en oeuvre une logique de plug-and-play des données documentaires avec les outils d’IA de façon modulaire et extensive.

Développé par Anthropic (la société qui développe la série des modèles Claude), le MCP est une norme ouverte conçue pour l'interopérabilité des outils d'IA et se décline comme un protocole standardisé, open source et universel permettant aux LLMs d’interagir avec des services ou des sources de données externes.

Techniquement, il définit une architecture client-serveur permettant à des assistants IA d’interagir dynamiquement et de manière sécurisée avec des systèmes externes en se basant sur les spécifications JSON-RPC pour l’échange de contexte.

Source : https://github.com/NirDiamant/agents-towards-production/blob/main/tutorials/agent-with-mcp/mcp-tutorial.ipynb

Tout LLM compatible MCP (c’est-à dire entraîné et configuré pour pouvoir intégrer des "tools", libellé standardisé pour désigner des fonctions) peut être intégré dans un client MCP et interroger n’importe quel serveur MCP, et c’est cette généricité permettant de s’abstraire d’intégrations techniques potentiellement complexes avec chaque source de données différente qui rend ce protocole particulièrement utilisé.

Comment sait-on qu’un LLM est compatible MCP ? En lisant la documentation pour les modèles fermés, et pour les modèles open weights il suffit d’observer leur chat template dans le fichier de configuration de leur tokenizer (par exemple ici ou avec ce raccourci pour Qwen/Qwen3-0.6B)

Concrètement donc, exposer un service ou des données avec un serveur MCP permet d’interagir avec ce service ou ces données en langage naturel avec un LLM qui analyse la requête utilisateur, identifie les outils à appeler et avec quels paramètres (via les schémas fournis par les serveurs MCP), génère les appels de fonctions puis, après retour de la réponse, la reformate pour la restituer de manière intelligible.

De nombreux serveurs MCP open source développés par et pour la communauté sont déjà disponibles, qui permettent de connecter un LLM à différents services comme GitHub, Google Drive, sa messagerie sur Outlook ou gmail, une base de données MySQL ou Neo4j, de la documentation hébergée sur Notion, son environnement python local, ou encore de simuler une navigation sur le web...

Référencés dans plusieurs registres publics (un dépôt Github communautaire de serveurs MCP, le MCP Server Directory, MCP.so, Pulse...), ces serveurs encapsulent donc des outils variés (envois de messages, gestion de fichiers, interactions avec des API, des bases de données et des services cloud, etc.) et peuvent être actionnés dynamiquement en tant que composants prêts à l’emploi :

• dans des applications qui intègrent déjà un client MCP en mode low code ou no code, comme Claude Desktop, Cursor (éditeur de code), ou ChatGPT (version Plus)
• programmatiquement dans des chaînes d’action orchestrées et pilotées par LLM avec des frameworks comme le SDK Agents d’OpenAI ou la librairie smolagents d’HuggingFace ou encore crewAI

Les serveurs MCP sont généralement développés en JavaScript (Node.js) ou en Python. Pour les exécuter localement (y compris dans Claude Desktop), il faut disposer de l’environnement adapté : Node.js et npm pour Javascript, ou python. Ils sont également dockerisables, donc livrables en image Docker et installables en conteneur, et Docker hub expose d’ailleurs aussi un registre d’images MCP https://hub.docker.com/u/mcp

Un cas d’usage très accessible consiste à installer le serveur filesystem dans Claude Desktop pour permettre à Claude d’interagir en lecture et en écriture avec son système de fichier local : il suffit de paramétrer le serveur (en spécifiant les dossiers auxquels accèdera le modèle) dans le fichier claude_desktop_config.json accessible depuis les paramètres de l’application de bureau

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/username/Desktop",
        "/path/to/other/allowed/dir"
      ]
    }
  }
}

À noter toutefois : déclencher un serveur MCP qui donne accès à des données locales (système de fichiers, Google Drive, messagerie, etc.) revient à permettre au LLM de traiter ces contenus. Si le modèle est hébergé par un provider dans le cloud, cela signifie que les données accédées localement peuvent transiter par une infrastructure distante, selon les modalités d’appel du client MCP. Ce type de configuration est donc à activer avec précaution, en tout cas en toute conscience, notamment dans des contextes de confidentialité ou de sensibilité des données.

Pour aller un peu plus loin et pour illustrer ce billet avec des données métiers, deux dépôts GitHub sont présentés afin de démontrer comment, même avec un prototypage minimal, tout service documentaire compatible OpenAPI (via Postman ou autre) peut facilement devenir instantanément accessible aux modèles d’IA :

• postman2mcp : un module Python permettant de convertir automatiquement une collection Postman en un serveur MCP fonctionnel via FastAPI. Le module propose un outil CLI qui automatise la transformation d’une collection Postman en un serveur FastAPI compatible OpenAPI v3 sur lequel se branche un serveur FastMCP prêt à l’usage
• openalex‑postman2mcp : une application de démonstration générée à partir du module précédent, qui expose l’API OpenAlex documentée pour l’occasion dans Postman sous forme de serveur MCP prêt à être interrogeable depuis un agent ou un client LLM. Une fois le serveur lancé localement, il se paramètre par exemple ainsi dans Claude Desktop

{
  "mcpServers": {
    "openalex-mcp-server": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "http://localhost:3333/mcp",
        "--transport",
        "http-only"
      ]
    }
  } 
}

Pour actionner le serveur sans passer par une application tierce, des scripts Gradio sont également fournis dans le repo pour lancer des UI locales d’interrogation du serveur MCP où il suffit d’un prompt pour interroger des métadonnées OpenAlex et en obtenir une analyse structurée (voire un rapport bibliométrique complet)

Quelques nouveaux cas d'usages documentaires

Le temps de l’IA évoluant si rapidement, il n'est pas impossible que d'ici quelques mois le protocole MCP appartienne déjà à la préhistoire de l'IA, remplacé par des mécanismes d'intégrations encore plus fluides.

Mais pour le moment, l’approche générique et modulaire du protocole MCP permet aussi bien de transformer notre manière d’envisager des cas d’usage de l’IA bien établis (finalement le RAG peut aussi être organisé comme une composition de serveurs MCP type filesystem, vectorstore, etc. ) que d'ouvrir la voie à des scénarios plus ambitieux d’ouverture des données et services documentaires. Rendre ces ressources mobilisables dynamiquement dans des systèmes IA, sans passer par des interfaces humaines traditionnelles, permettrait par exemple :

• Obtenir un identifiant IdRef à partir d’un nom d’auteur devient possible simplement en interrogeant, depuis un client, un serveur MCP connecté à l’API IdRef, donc sans avoir à naviguer manuellement sur idref.fr. Couplé à un agent mobilisant un modèle capable de générer automatiquement des notices Unimarc à partir de descriptions textuelles, cela permet d’imaginer un système complet d’automatisation de la production de données bibliographiques alignées sur le référentiel national
• Comme évoqué plus haut, orchestrer un agent qui interroge une base bibliographique comme OpenAlex (via un serveur MCP adapté), récupère les métadonnées d’un corpus, puis déclenche un second agent chargé de rédiger un rapport bibliométrique structuré (analyse de co-auteurs, affiliations, mots-clés, évolutions temporelles…)
• Interroger directement (dans un chatbot ou dans une brique d'un système IA) les bases juridiques françaises (textes de loi, codes, jurisprudence) contenues dans Légifrance sans passer par une étape de recherche textuelle brute grâce au serveur MCP spécialisé Légifrance mcp-serveur-legifrance qui expose les outils suivants : rechercher_dans_texte_legal, rechercher_code et rechercher_jurisprudence_judiciaire. Ainsi équipé, un LLM peut invoquer ces fonctions avec les paramètres adéquats et exploiter le résultat pour synthétiser, commenter ou confronter plusieurs textes.
• Connecter un LLM à un serveur MCP qui expose un catalogue local (type Koha, Alma ou autre) pour générer des réponses sur les disponibilités ou les localisations d’ouvrages, ou encore produire automatiquement des listes thématiques
• Utiliser un serveur de type OCR pour analyser et transcrire à la volée des documents numérisés, extraire des métadonnées textuelles
• Intégrer une logique de veille automatisée où un agent suit, agrège et résume des publications issues de sources ouvertes (archives ouvertes, HAL, bioRxiv...), selon des critères thématiques préalablement configurés