MCP, le Model Context Protocol, est un standard ouvert qui permet aux assistants d’IA de communiquer avec des fichiers, des bases de données, des calendriers et des outils créatifs, sans code sur mesure pour chacun. Cet article détaille les clients, serveurs, outils et ressources à l’aide d’analogies simples et d’exemples réels, et passe en revue les risques à surveiller.
Demandez à un assistant d’IA de consulter votre agenda, de lire un tableur ou de corriger un bug dans votre dépôt, et vous obtiendrez souvent des excuses polies. Le modèle est performant, mais il se trouve dans une pièce scellée, sans porte vers vos fichiers, vos applications ou le web en direct. MCP, abréviation de Model Context Protocol, est cette porte. C’est un standard ouvert qui permet aux applications d’IA de se brancher sur des outils et des données externes via une connexion commune, à la manière d’un seul port qui permet à un ordinateur portable de communiquer avec un écran, un disque dur et une caméra. Cet article explique ce qu’est MCP, comment il fonctionne et à quoi il ressemble au quotidien, avec chaque idée rattachée à quelque chose que vous pouvez facilement vous représenter.
💡 En bref : MCP est un langage commun entre les applications d’IA et les outils dont elles dépendent. Anthropic l’a présenté en novembre 2024, et de nombreuses autres entreprises prennent désormais en charge ce protocole.
MCP signifie Model Context Protocol. Un protocole est un ensemble de règles convenues qui définissent la manière dont deux programmes communiquent. Le contexte correspond aux informations dont un modèle a besoin pour fournir une réponse utile : vos documents, vos données, l’état de votre projet. En somme, MCP est un ensemble de règles qui permettent de transmettre du contexte à un modèle, et de lui permettre d’agir à partir de ce contexte.
Sans protocole de ce type, un modèle d’IA ne connaît que ce qu’il a assimilé pendant son entraînement, ainsi que le texte que vous collez dans la conversation. C’est pourquoi il ne peut pas vous dire ce qui se trouve dans votre boîte de réception aujourd’hui, ni ce qui a changé dans votre base de code ce matin. MCP lui offre un moyen sûr et standard de le demander.
La documentation d’Anthropic compare MCP à un port USB-C pour les applications d’IA, et la comparaison tient bien la route. Avant l’USB-C, chaque appareil avait son propre câble et sa propre forme de prise. Un seul port avec une norme de signal commune permet à n’importe quel appareil de communiquer avec n’importe quel autre.
MCP remplit le même rôle pour les logiciels. Une application d’IA compatible MCP peut se connecter à tout serveur compatible MCP, qu’il ait été développé par la même entreprise ou par un inconnu qui l’a publié la semaine dernière.
Avant MCP, relier une IA à un outil était à chaque fois un travail sur mesure. Imaginez que vous disposiez de 5 applications d’IA et de 20 outils que vous voulez leur faire utiliser. Chaque paire nécessite son propre pont, ce qui représente jusqu’à 100 intégrations distinctes, chacune avec ses particularités et son coût de maintenance.
MCP transforme cette multiplication en addition. Chaque application d’IA développe un seul client MCP, et chaque outil développe un seul serveur MCP. Cela fait 5 + 20 = 25 éléments au lieu de 100.
| Configuration | Applications d’IA | Outils | Éléments à développer |
|---|---|---|---|
| Sans MCP | 5 | 20 | Jusqu’à 100 |
| Avec MCP | 5 | 20 | 25 |
Un adaptateur de voyage universel en donne une bonne image mentale. Vous n’emportez pas un chargeur différent pour chaque pays. Vous emportez un seul adaptateur à broches rétractables, et la prise murale compte beaucoup moins. MCP est cet adaptateur pour la connexion entre un modèle et le monde qui l’entoure.
Autre avantage : un serveur écrit une seule fois continue de fonctionner à mesure que de nouvelles applications d’IA apparaissent. Ainsi, l’effort consacré à une connexion ne devient pas caduc lorsque vous changez d’assistant.
Les éléments en jeu sont simples une fois qu’on leur a donné un nom. Trois rôles, trois types de briques de base et un format de message.
Un restaurant permet de retenir facilement ces rôles. Vous êtes le client attablé, et le modèle d’IA est la partie de l’équipe qui décide de ce qu’il faut commander. Le client est le serveur de salle, qui rédige la demande dans un format que la cuisine attend et la transmet. Le serveur est la cuisine, qui effectue le travail réel et renvoie un plat dressé.
Le serveur de salle ne cuisine jamais, et la cuisine n’a jamais besoin de savoir qui est assis à la table six. Chaque côté doit seulement respecter le bon de commande, et ce bon de commande, c’est le protocole.
Un serveur peut exposer trois types de briques de base. La plupart des serveurs n’en utilisent qu’une ou deux.
| Brique de base | Qui décide de l’utiliser | Signification simple | Exemple |
|---|---|---|---|
| Outils | Le modèle | Actions que l’IA peut effectuer | Créer un ticket, envoyer un message, générer une image |
| Ressources | L’application | Données que l’IA peut lire | Un fichier, une ligne de base de données, un document |
| Prompts | L’utilisateur | Modèles prêts à l’emploi | « Relire cette pull request » |
Les outils sont ceux que l’on remarque en premier. Imaginez un panneau perforé d’atelier où chaque outil à main est accroché à son emplacement marqué. Chaque outil MCP possède aussi un nom, une courte description de ce qu’il fait et la liste des entrées dont il a besoin. Le modèle lit ces descriptions pour déterminer quel outil convient à la tâche, comme vous choisissez la bonne clé en regardant le panneau.
Les ressources fonctionnent comme une bibliothèque. L’IA ne modifie rien. Elle retire un livre de l’étagère pour en lire le contenu. Une ressource peut être un fichier texte, un enregistrement de base de données ou un journal de la veille. L’hôte décide généralement quelles ressources joindre, et le modèle les lit comme contexte.
Les prompts sont le menu de raccourcis. Un serveur peut proposer un modèle enregistré, par exemple « résumer les tickets de la semaine », et vous le sélectionnez au lieu de rédiger vous-même les instructions.
Sous le capot, les messages MCP utilisent JSON-RPC 2.0, un format de texte simple qui dit « appelle cette méthode avec ces arguments ». Il existe deux manières courantes de transporter ces messages :
Un appel d’outil ressemble à ceci :
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "get_weather",
"arguments": { "city": "Lisbon" }
}
}
Rien de magique dans ce message. Il s’agit d’un nom d’outil et de quelques arguments. Ajouter un serveur local à une application est généralement tout aussi simple : quelques lignes de configuration qui indiquent le programme à lancer :
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/Documents"]
}
}
}
Cette entrée donne à l’IA accès à un seul dossier, et à rien d’autre.
Voici ce qui se passe lorsque vous demandez « Lesquelles de mes factures sont en retard ? » dans une application connectée à un serveur de base de données.
💡 À noter : le modèle ne touche jamais directement à votre base de données. Il se contente de demander, et c’est le serveur qui décide de ce qui est autorisé. Cette séparation rend MCP exploitable dans un contexte professionnel.
Il existe aujourd’hui des milliers de serveurs MCP, des serveurs officiels maintenus par les entreprises qui développent les outils jusqu’à de petits projets communautaires. Quatre familles illustrent cette diversité.
Le serveur de système de fichiers de référence permet à une IA de lire, rechercher et modifier des fichiers dans les dossiers que vous choisissez. Demandez-lui de renommer un dossier de téléchargements désordonné par date, ou de retrouver chaque mention d’un nom de client dans une pile de notes, et il fait le travail fichier par fichier.
Les développeurs ont été les premiers grands utilisateurs de MCP. Un serveur GitHub peut lire des tickets et ouvrir des pull requests. Un serveur de base de données peut exécuter des requêtes en lecture seule. Un assistant de programmation connecté aux deux peut trouver le ticket en échec, lire le code associé et proposer un correctif, sans que vous ayez à copier-coller quoi que ce soit d’une fenêtre à l’autre.
Un serveur d’automatisation de navigateur, comme celui construit sur Playwright, permet à une IA d’ouvrir une page, de remplir un formulaire et de signaler ce qui ne fonctionne pas. Les outils de design et de gestion de projet publient aussi des serveurs, si bien qu’un assistant peut lire une maquette ou mettre à jour un tableau de tâches.
Le travail créatif se prête bien à MCP, car la génération est un appel d’outil avec une entrée claire (un prompt) et une sortie claire (un fichier). PicassoIA propose une connexion MCP pour ses modèles d’images et de vidéos, notamment PicassoIA Image et PicassoIA Image Editor Pro. Une fois connectée, une application d’IA voit une courte liste d’outils :
| Outil | Ce qu’il fait |
|---|---|
generate_image | Lance une tâche de génération d’image et renvoie un identifiant |
edit_image | Modifie une image existante à partir d’une instruction textuelle |
get_generation | Vérifie une tâche et renvoie les URL des fichiers terminés |
cancel_generation | Arrête une tâche encore en cours |
Cet exemple montre pourquoi les descriptions d’outils sont importantes. Les tâches de génération d’images prennent un peu de temps, donc generate_image ne renvoie pas d’image immédiatement. Il renvoie un identifiant de tâche. L’IA doit lire les descriptions, comprendre cela, puis appeler get_generation après une courte attente pour récupérer le résultat. Personne n’a écrit de script pour cet enchaînement. Le modèle l’a déduit à partir de la liste des outils. Les outils vidéo suivent le même schéma : soumission puis vérification, et un compte peut lancer jusqu’à 5 tâches simultanément. Comme la connexion respecte le standard, les mêmes outils fonctionnent depuis n’importe quelle application compatible MCP, sans intégration spécifique pour chacune.
On demande souvent si MCP remplace les API. Ce n’est pas le cas. La plupart des serveurs MCP appellent en interne une API classique. MCP est la couche qui rend cette API utilisable par un modèle.
| API classique | MCP | |
|---|---|---|
| Conçue pour | Les développeurs qui écrivent du code | Les modèles d’IA qui choisissent les actions |
| Description des capacités | Documentation rédigée pour les humains | Une liste d’outils que le modèle lit à l’exécution |
| Ajout d’une nouvelle capacité | Écrire un nouveau code d’intégration | Connecter un autre serveur |
| Réutilisation entre applications d’IA | Chaque application a besoin de sa propre intégration | Tout client MCP peut se connecter |
| Format des messages | Différent pour chaque service | Un format commun |
L’appel de fonctions est une compétence du modèle : à partir d’une liste de fonctions, il peut répondre par une demande structurée d’exécution de l’une d’elles. MCP est l’infrastructure qui entoure cette compétence. Il standardise l’origine des fonctions, la manière dont elles sont décrites et la façon dont l’appel parvient à ce qui l’exécute.
💡 Une façon simple de le retenir : l’appel de fonctions, c’est le modèle qui décide d’appuyer sur un bouton. MCP, c’est le câblage standard derrière chaque bouton.
La prise en charge de MCP se situe principalement dans l’application hôte, si bien qu’un même serveur peut fonctionner avec différents modèles. Ce qui varie, c’est la qualité avec laquelle un modèle choisit le bon outil et remplit ses entrées. Ces grands modèles de langage disponibles sur PicassoIA sont des choix courants pour les tâches nécessitant beaucoup d’outils :
| Modèle | Décrit sur sa page comme | Adapté à |
|---|---|---|
| Claude Sonnet 5 | Automatisation des tâches de programmation | Le code et le travail sur dépôt |
| GPT 5.6 Sol | Résolution de tâches de programmation complexes | Les tâches de programmation difficiles en plusieurs étapes |
| Gemini 3.5 Flash | Discussion rapide, code et images | Les recherches rapides et l’usage léger d’outils |
| Kimi K2.6 | Création d’agents d’IA et rédaction de code | Les flux de travail de type agent |
Recherchez un modèle qui suit fidèlement les instructions et renvoie des entrées propres et bien formées. Commencez avec un petit ensemble d’outils, car une longue liste d’outils similaires peut dérouter n’importe quel modèle. Utilisez un modèle plus rapide pour les recherches simples et réservez les plus lourds aux tâches qui enchaînent plusieurs outils.
Donner à une IA de véritables outils lui donne une véritable portée. C’est justement le but, et c’est aussi ce qui impose la prudence.
Un outil peut récupérer du texte provenant d’une page web, d’un e-mail ou d’un document partagé. Si quelqu’un a dissimulé des instructions dans ce texte, le modèle pourrait les traiter comme des ordres. Par exemple, une page web pourrait contenir une ligne cachée demandant à l’assistant d’ignorer ses instructions et d’envoyer vos fichiers ailleurs. Traitez tout ce que renvoie un outil comme des données non fiables, limitez ce que chaque outil est autorisé à faire, et gardez les demandes de confirmation activées pour toute action qui envoie, supprime ou dépense.
Le moyen le plus rapide de comprendre ce que fait MCP est de voir une IA utiliser un outil à votre place. Connectez une application compatible MCP à votre compte Picasso IA (les paramètres de connexion se trouvent dans votre espace compte, à l’adresse picassoia.com/en/mcp/accounts), puis demandez une image en langage courant. Vous verrez l’assistant lancer la tâche, vérifier son statut et vous remettre le fichier final, c’est-à-dire l’ensemble du protocole en action.
Essayez des prompts comme ceux-ci :
Chacun correspond à un outil du tableau ci-dessus, et chacun constitue une petite leçon sur la manière dont MCP transforme une phrase en action. Pour découvrir ce que propose la plateforme, parcourez tous les modèles à l’adresse picassoia.com/en/all-models, puis revenez donner à votre assistant un nouvel outil à utiliser.
Choisissez votre langue
