Donner des mains à un assistant : brancher son application via MCP

Le problème n'est pas que le modèle soit incapable

Un modèle de langage sait déjà produire du texte structuré : donnez-lui un email brut, il en sort des champs propres. Ce qu'il ne sait pas faire, c'est écrire dans votre base. Il n'a pas de mains. Alors on bricole : le modèle produit du JSON, un script le pousse vers une API. Ça tient le temps d'une démonstration, puis le format change et la ligne n'est plus jamais créée.

Pourquoi pas simplement une API REST

C'est la question qu'on m'a le plus posée. La réponse tient au destinataire du contrat. Une documentation REST s'adresse à un humain qui écrira du code de liaison. Un serveur MCP publie ses actions dans un format que le client relit à chaque exécution : le modèle reçoit la forme attendue au lieu de la deviner.

Et comme ce format est standard, n'importe quel client compatible se branche tel quel. Le jour où je change d'assistant, je ne réécris rien. C'est tout, mais c'est ce qui fait la différence entre un connecteur qu'on maintient et une prise qu'on oublie.

Combien de verbes exposer

C'est la seule décision de conception qui compte vraiment, et c'est là que j'ai fait ma plus grosse erreur au premier essai : j'ai voulu exposer toute l'application. Plus on déclare d'actions, plus le modèle hésite, plus il se trompe, et plus la surface de risque grandit pour des fonctions que personne n'appelle.

Chez moi elle tient en huit outils.

Chacun porte ses annotations MCP : update_contact est marqué destructeur parce qu'il écrase une valeur existante, log_interaction ne fait qu'ajouter, et un client qui lit ces indications demande confirmation avant l'un, pas avant l'autre.

Ailleurs le découpage change : ouvrir un dossier et changer son statut, chercher et citer dans une base documentaire, qualifier et router un ticket. La structure, elle, ne bouge pas : des lectures, des écritures cadrées, rien de destructeur. Si une date est absurde, c'est l'application qui refuse. La fiabilité vient de là, pas du modèle.

C'est aussi là que sert l'autorisation. Le jeton OAuth d'un client porte une portée fixée au moment où vous l'accordez, et je n'en ai que deux : crm:read et crm:write. L'assistant qui capture mes emails a besoin d'écrire, donc il écrit. Mais le jour où je branche un client d'analyse pour sortir des statistiques, il reçoit un jeton en lecture seule et aucune formulation, si insistante soit-elle, ne lui fera créer une ligne.

Un même serveur, deux générations du protocole

MCP évolue par révisions datées. En août 2026, mon serveur parle deux générations du protocole à la même URL, parce qu'il n'a pas le choix.

La génération legacy couvre les révisions 2024-11-05, 2025-03-26 et 2025-06-18 : le client ouvre par un appel initialize et la version est négociée une fois, puis répétée sur chaque requête.

La révision moderne 2026-07-28 supprime cette poignée de main : la découverte passe par server/discover, et chaque requête transporte sa version, dans params._meta sous la clé io.modelcontextprotocol/protocolVersion et dans l'en-tête HTTP MCP-Protocol-Version. Chaque appel devient autonome.

Pourquoi les deux ? Le connecteur de Claude.ai, que j'utilise tous les jours, parle encore la génération legacy : ne servir que la moderne, c'était couper mon propre client. À l'inverse, le serveur ne revendique pas la révision 2025-11-25 qu'il n'implémente pas. Un client qui s'y fierait échouerait au pire moment.

Les limites, telles que je les vois aujourd'hui

• La première, je viens de la montrer : le protocole bouge encore, au point qu'un serveur sérieux parle plusieurs dialectes à la fois. Une partie de cet article aura vieilli dans un an, d'où les dates.

• La deuxième : un assistant ne remplace pas une interface. J'ai gardé des écrans classiques pour comparer, trier, vérifier d'un coup d'œil. La conversation est excellente pour capturer et déclencher, mauvaise pour parcourir.

• La troisième touche aux données. Faire analyser un email par un modèle cloud, c'est envoyer cet email chez un tiers, en entier. Parfois c'est acceptable, parfois non, et en contexte réglementé le curseur entre cloud et modèle local est souvent bloqué avant la première ligne de code. Mieux vaut le savoir au cadrage qu'à la recette.

• Enfin, l'injection par le contenu n'est pas résolue, j'en ai parlé plus haut. La réponse reste la discipline sur les droits : portée minimale, rien de destructeur dans le périmètre, journalisation de tout ce qui s'exécute.

Si vous voulez essayer

Et gardez la question de départ : le problème était-il que le modèle ne savait pas faire, ou qu'il n'avait pas de mains ? Si c'est la première, un protocole n'y changera rien. Si c'est la seconde, la prise existe, elle est standard, et elle se pose en quelques jours sur à peu près n'importe quelle application métier.