Les grands modèles de langage modernes progressent rapidement dans leur capacité à répondre à des questions et à assister dans les tâches quotidiennes. Ils deviennent également bien plus doués pour masquer leurs lacunes, notamment les hallucinations. Une manière d’améliorer ces modèles est de leur fournir un certain contexte ou de les équiper d’« outils » en leur expliquant comment les utiliser.
Il existe aujourd’hui de nombreux frameworks permettant d’équiper les modèles de langage avec des outils pour leur fournir des données ou des fonctions afin d’améliorer leurs réponses. Les problèmes surgissent lorsqu’on modifie les outils ou les modèles : il faut alors refaire tout le travail d’intégration. L’idéal serait de pouvoir réutiliser la connexion d’un côté comme de l’autre, offrant ainsi une plus grande flexibilité dans ses choix.
L’intérêt croissant pour les grands modèles de langage et leur usage massif ces derniers mois ou années a fait émerger un besoin de standardisation.
Anthropic, la société derrière le modèle Claude, a proposé fin 2024 une norme appelée Model Context Protocol (MCP). Depuis sa présentation initiale, ce protocole a été accepté par Google et OpenAI. Il tend progressivement à devenir le standard de référence pour connecter des ressources aux modèles de langage. Mettre en œuvre MCP pour vos ressources vous garantit qu’elles seront compatibles avec les modèles d’Anthropic, OpenAI et Google.
D’autres solutions ont également été proposées comme agents.json et llms.txt. Ces initiatives, tout comme MCP, aident les développeurs à rendre leurs solutions accessibles aux grands modèles de langage. Ces standards sont récents et encore perfectibles, mais ils vont dans la bonne direction. Ils sont en partie complémentaires. Les implémenter tous peut être chronophage, mais l’effort peut en valoir la peine.
Nous allons désormais détailler chacune de ces solutions et voir comment rendre vos solutions ou APIs accessibles aux modèles de langage, soit pour améliorer des agents locaux, soit pour élargir leur portée via les LLMs. Définir des connecteurs standards pour les données et les outils permet de concevoir des agents locaux évolutifs, non dépendants d’une solution particulière.
Model Context Protocol
Le Model Context Protocol a été introduit par Anthropic fin 2024 dans le but de standardiser les communications entre les grands modèles de langage et les ressources. Il a déjà connu une première révision fin mars 2025. L’objectif affiché est de devenir l’équivalent du port USB-C pour la connexion entre outils et LLMs.
Figure 1 – Architecture générale montrant un serveur connecté à plusieurs clients – https://modelcontextprotocol.io/introduction
Le protocole repose sur un modèle client-serveur. Le client MCP est le modèle de langage. Il établit une connexion vers un serveur MCP et peut l’utiliser pour accéder aux ressources situées derrière le serveur afin de répondre aux requêtes reçues.
Le protocole repose sur des messages JSON-RPC 2.0 pour formuler les requêtes et recevoir les réponses. La connexion entre client et serveur est étatée, ce qui n’est pas idéal et pourrait évoluer dans une prochaine version. Cela ne pose pas de problème pour un agent local accédant à des ressources locales, mais devient plus complexe si vous devez maintenir des milliers de connexions à distance.
Les serveurs MCP peuvent exposer trois types de ressources au client :
- Resources : pour exposer des données au modèle et enrichir son contexte. Les formats sont variés : fichiers, API, données binaires (PDF, audio, vidéo…).
- Tools : pour fournir au modèle des fonctions qu’il peut appeler et qui peuvent agir sur le monde réel. Les outils permettent au modèle d’interagir avec des APIs, de modifier des bases de données ou de réaliser des calculs exacts.
- Prompts : pour proposer des messages réutilisables à destination du client ou de l’utilisateur, évitant de les retaper à chaque fois.
Il existe aussi une distinction philosophique importante entre Resources, Tools et Prompts. Les Resources sont généralement contrôlées par l’application. Par exemple, « Claude Desktop requiert que l’utilisateur sélectionne manuellement les ressources avant utilisation », ce qui ne sera pas le cas pour tous les clients.
Les Tools sont conçus pour être contrôlés par le modèle, qui les utilise comme bon lui semble. C’est déjà ce qui est fait dans la plupart des agents actuels : on fournit une fonction avec sa description et le modèle décide s’il l’utilise.
Les Prompts, quant à eux, sont destinés à être contrôlés par l’utilisateur final, qui choisira lui-même quand et comment les utiliser.
Construire un serveur MCP permet d’exposer données et fonctions aux LLMs tout en ne le faisant qu’une seule fois par version du protocole. Si vous souhaitez fournir plusieurs outils ou ressources à vos clients, il suffit de décrire ces ressources avec leurs URI pour y accéder depuis n’importe quel LLM, même si vous changez de fournisseur ultérieurement.
Bien que MCP facilite grandement les choses, il ne résout pas tout. Le maintien de connexions persistantes peut poser problème si vous avez un grand nombre de ressources. Par ailleurs, comme les ressources doivent être placées dans le contexte, cela limite leur nombre, malgré l’augmentation des fenêtres de contexte.
Enfin, exposer des outils ou données requiert de toujours rester vigilant sur la manière dont ils seront utilisés. Utiliser MCP ne dispense pas de mettre en place une authentification rigoureuse ou des protections contre des attaques. Ce n’est pas parce qu’un outil est utilisé par une IA qu’il est inoffensif.
agents.json
Agents.json est un standard destiné à aider un grand modèle de langage à comprendre comment utiliser efficacement une API. Il repose sur la norme OpenAPI, utilisée pour décrire les routes d’une API et leur fonctionnement.
Ajouter un fichier agents.json à une API est simple. Il n’est pas nécessaire de modifier l’existant : il suffit d’ajouter un fichier à l’emplacement spécifique /.well-known/agents.json pour qu’il soit découvert par un LLM. Le modèle pourra alors traduire toute requête en langage naturel en appel d’API.
Figure 2 – Schéma de description agents.json – https://github.com/wild-card-ai/agents-json
Le fichier de spécification est au format JSON et étend la norme OpenAPI. Le schéma complet est disponible sur https://docs.wild-card.ai/agentsjson/schema. Lors de la rédaction de ce fichier, il faut décrire des Flows : une suite d’un ou plusieurs appels d’API. Les actions sont les appels en eux-mêmes, et les links définissent la manière dont les paramètres se transmettent entre les appels ou depuis les entrées du LLM.
Puisqu’il repose largement sur OpenAPI, ce standard est plus facile à mettre en œuvre si vous avez déjà une spécification OpenAPI de votre API. Dans le cas contraire, cela peut être un peu fastidieux. La principale différence entre agents.json et MCP est que le premier ne nécessite pas de connexion persistante. De plus, un registre recense les fichiers agents.json publics disponibles, afin de les intégrer à votre agent. Le nombre reste encore faible mais devrait croître.
llms.txt
Llms.txt est une proposition pour aider les modèles de langage à mieux comprendre les sites web. L’idée est d’ajouter un fichier llms.txt à votre site (à la manière d’un robots.txt pour les crawlers) à destination des LLMs.
Le fichier est écrit en Markdown, un format simple à interpréter pour les modèles. Il contient une description du site et, optionnellement, une liste d’URLs pertinentes pour le modèle. Il est aussi suggéré d’ajouter un fichier Markdown avec une extension .md pour chaque URL listée, afin d’en faciliter l’analyse en supprimant tout contenu inutile.
Figure 3 – Format des fichiers llms.txt – https://llmstxt.org
Faciliter la compréhension de votre site par les LLMs augmente la probabilité qu’il soit cité dans leurs réponses. Si un modèle ne comprend pas votre site ou ne trouve pas les informations, il ne les affichera pas.
Le site llmstxt.org maintient deux registres listant les sites web disposant d’un fichier llms.txt, si vous souhaitez tester cela avec votre modèle préféré.
À mesure que les LLMs se généralisent, rendre l’information compréhensible et accessible pour eux devient crucial. Les modèles deviennent une interface de choix pour de nombreuses tâches, et rendre vos outils et APIs accessibles leur permet de faire partie de ces processus.
L’ajout d’un fichier llms.txt à votre site n’entraîne aucun inconvénient. Cela n’ouvre ni vulnérabilité ni accès non souhaité. Il est possible de générer automatiquement les fichiers Markdown, ce qui rend cette pratique compatible avec une approche à grande échelle.
Conclusion
Il existe aujourd’hui de nombreuses manières d’exposer des données, des APIs ou des outils aux grands modèles de langage. Ces derniers mois ont vu émerger de nombreux efforts pour standardiser les communications entre modèles et ressources.
Le Model Context Protocol s’impose comme une approche prometteuse, déjà adoptée par les principaux acteurs du domaine, et permet d’exposer différents types de ressources aux modèles.
Ce n’est cependant pas le seul standard en cours d’évolution. Agents.json et llms.txt, bien que plus ciblés, restent très utiles dans leurs domaines respectifs.
Rendre vos ressources disponibles aux LLMs est une manière nouvelle d’atteindre les utilisateurs qui privilégient cette interface d’interaction avec les données et les outils.
Surveiller les évolutions en matière de standardisation est essentiel pour assurer à vos solutions une compatibilité maximale.
