Qu'est-ce que MCP ?
MCP signifie Model Context Protocol. C'est un standard ouvert qui décrit comment un modèle de langage apprend quels outils sont à sa disposition, et comment il les appelle.
Le problème qu'il traite est peu spectaculaire mais coûteux. Avant l'existence d'un standard, chaque lien entre un modèle et un système métier était du code sur mesure. Connectez trois modèles à cinq systèmes et vous avez écrit quinze ponts, chacun avec ses particularités, son authentification et sa charge de maintenance. Changez de fournisseur de modèle et vous recommencez.
MCP transforme cela en une architecture client-serveur. Un serveur déclare ce qu'il propose : des outils qui exécutent des actions, des ressources qui fournissent des données, des prompts qui cadrent une tâche. N'importe quel client compatible peut ensuite les utiliser sans rien savoir de l'implémentation qui se trouve derrière.
Pourquoi MCP compte
- L'intégration cesse de se multiplier. L'effort suit le nombre d'outils, pas les outils multipliés par les modèles. Sur un parc de systèmes internes, c'est la différence entre un pilote et quelque chose de maintenable.
- Changer de fournisseur n'est plus une réécriture. Si le modèle change, les serveurs restent. Cela seul lève l'une des principales objections à s'engager dans l'intégration d'IA.
- Les permissions deviennent explicites. Chaque outil déclare ses entrées et ses sorties, si bien que le cadrage devient une décision de conception écrite noir sur blanc plutôt qu'une hypothèse enfouie dans le code.
- La réutilisation devient réelle. Un serveur écrit pour un système interne sert tous les futurs assistants et agents, au lieu d'être consommé par le seul projet qui l'a financé.
Le point stratégique est que MCP fait de l'intégration d'IA une décision d'infrastructure plutôt qu'une suite d'expérimentations. Cela change qui doit être autour de la table quand on la planifie.
Comment ça fonctionne
Trois concepts portent l'essentiel du standard.
Les outils sont des actions que le modèle peut invoquer : lire un enregistrement, créer une facture, envoyer un message. Chacun déclare ce qu'il accepte et ce qu'il renvoie, ce qui permet au modèle de raisonner sur l'opportunité de l'appeler.
Les ressources sont des données que le modèle peut lire plutôt que modifier : un document, une table, un fichier. La distinction compte parce qu'elle sépare la lecture de la modification, ce qui constitue la première ligne de tout modèle de permissions raisonnable.
Les prompts sont des modèles de tâche réutilisables qu'un serveur peut proposer, pour qu'une façon éprouvée de demander quelque chose n'ait pas à être réinventée par chaque client.
Autour de cela, un serveur gère l'authentification et décide de ce qu'il expose. Le client, qui peut être une interface de conversation ou un agent, découvre ce qui est disponible et l'appelle. Rien n'est supposé quant au modèle, et c'est précisément pourquoi le dispositif survit à un changement de fournisseur.
Le travail dans un vrai projet n'est pas d'écrire le serveur. C'est de décider le périmètre : quelles lectures sont permises, quelles écritures exigent une étape de confirmation, ce qui se passe quand un appel échoue, et comment chaque appel est journalisé. Un outil défini trop largement est la principale source de comportements imprévisibles.
Mise en œuvre
- Commencer par un seul système dont plusieurs cas d'usage futurs auront besoin, typiquement celui qui détient les données clients ou produits.
- Lister les actions avant d'écrire une ligne de code. Chacune doit faire une seule chose avec un résultat prévisible.
- Séparer les lectures des écritures et donner à chaque outil les droits les plus étroits qui lui permettent de fonctionner.
- Exiger une confirmation sur toute écriture ayant une conséquence pour une personne, un contrat ou une facture.
- Journaliser chaque appel avec ses entrées, son résultat et son appelant. Sans cela, le débogage relève de la devinette et un audit est impossible.
- Traiter le protocole comme un adaptateur. Gardez la logique métier derrière lui, pour qu'un futur changement de standard ne vous coûte que l'adaptateur.
Technologies et outils associés
- Appel d'outils : la capacité sous-jacente des modèles que MCP standardise et rend portable d'un fournisseur à l'autre.
- Passerelles d'API : la couche qui gère déjà l'authentification et la limitation de débit, et derrière laquelle un serveur MCP devrait se placer plutôt que la remplacer.
- Couches de recherche documentaire : souvent exposées comme ressources MCP, pour qu'un modèle lise les documents de l'entreprise via la même interface que tout le reste.
- Observabilité : traçage de chaque appel d'outil, ce qui rend le dispositif auditable plutôt qu'opaque.
- Gestion des identités et des secrets : identifiants délimités par outil, pour qu'aucun composant ne détienne un accès large à tout.
Conclusion
MCP, c'est de la plomberie, et la plomberie est l'endroit où les projets d'IA réussissent ou s'enlisent. Le travail intéressant ressemble au choix du modèle et à la conception des prompts, mais le coût se situe dans l'intégration, et c'est l'intégration qu'un standard supprime.
L'approche raisonnable consiste à le traiter comme une infrastructure : un système exposé correctement, des actions cadrées étroitement, des écritures confirmées, tout journalisé, la logique métier gardée derrière l'adaptateur. Construit ainsi, chaque nouvel assistant ou agent hérite de ce qui existe déjà au lieu de repayer les mêmes connexions.
