Qu’est-ce que MCP
Cette page explique comment un modèle de langage accède aux données de vos propres systèmes. Elle s’adresse aux responsables informatiques qui n’ont jamais entendu le terme MCP, et elle pose les bases de toutes les autres pages de ce chapitre.
Le problème que MCP résout
Section intitulée « Le problème que MCP résout »Un modèle de langage ne connaît que ce qui figurait dans ses données d’entraînement et ce qui figure dans la conversation en cours. Il ne sait rien de vos clients, de vos factures ni de vos appareils. Pour qu’il puisse répondre à de telles questions, il lui faut un moyen d’interroger l’un de vos systèmes métier pendant la conversation.
C’est exactement à cela que sert le Model Context Protocol, MCP en abrégé. C’est un langage commun qui décrit comment un système de chat pose une question à un système métier et en reçoit la réponse. MCP est une norme ouverte avec une spécification publique, publiée à l’origine par Anthropic et reprise depuis par de nombreux éditeurs. Ce n’est pas une invention de Kisuno, et vous ne vous liez pas à nous en l’adoptant.
Pour vous, cela signifie deux choses. Premièrement, pour beaucoup de produits répandus, il existe déjà un serveur MCP prêt à l’emploi que vous pouvez raccorder. Deuxièmement, ce que vous construisez une fois pour Kisuno fonctionne aussi avec d’autres logiciels qui parlent MCP.
Trois termes dont vous avez besoin
Section intitulée « Trois termes dont vous avez besoin »Outil. Un outil est une capacité unique et clairement délimitée. Il a un nom technique, une description en prose et une liste de paramètres. Un raccordement à un système de supervision aurait par exemple un outil dont la tâche consiste à rechercher des appareils selon un petit nombre de critères. Un outil est toujours une action, jamais un système entier.
Connecteur, techniquement serveur MCP. Un connecteur est un petit service qui propose un ensemble d’outils et qui, derrière eux, dialogue avec le système cible proprement dit. Dans cette documentation, nous l’appelons connecteur, parce que c’est plus parlant pour qui n’est pas développeur. Dans la configuration et dans le panneau d’administration, il s’appelle « MCP-Server » (serveur MCP).
Client. Le client est la partie à laquelle les outils sont proposés et qui les appelle. Chez nous, c’est LibreChat, la couche de chat de Kisuno.
Un connecteur est souvent un pont : le système cible lui-même ne parle pas MCP, il n’a qu’une interface de programmation ordinaire. Le connecteur traduit alors entre les deux mondes. C’est ainsi que fonctionnent la plupart des raccordements à un ERP, à un système de supervision ou à un système de tickets.
Un exemple : « Quelles factures ouvertes le client X a-t-il ? »
Section intitulée « Un exemple : « Quelles factures ouvertes le client X a-t-il ? » »Sans connecteur, le modèle ne peut pas répondre à cette question. Il ne sait pas qui est le client X, et il n’a aucun accès à votre comptabilité. Avec un connecteur ERP raccordé, voici ce qui se passe :
- La personne pose la question dans le chat.
- En même temps que la question, le modèle reçoit la liste des outils autorisés, chacun avec son nom et sa description. Parmi eux se trouvent les outils du connecteur ERP.
- Le modèle constate qu’il ne peut pas répondre à la question à partir de ses propres connaissances, et il appelle un outil, par exemple « rechercher des enregistrements » avec le nom du client comme filtre.
- Avant que l’appel n’atteigne le connecteur, une vérification établit si cette personne a bien le droit d’utiliser ce connecteur. La décision est journalisée.
- Si l’appel est autorisé, le connecteur interroge l’ERP et renvoie le résultat sous forme de texte.
- Le modèle lit le résultat, appelle au besoin un deuxième outil, par exemple « lire un enregistrement » avec le numéro de client trouvé, et formule sa réponse à partir de là.
L’essentiel dans ce déroulement : le modèle décide quel outil il appelle, mais il ne détermine pas ce qu’il a le droit de faire. La limite est tracée par le contrôle des droits en amont et par le système cible en aval. Un modèle ne peut pas s’inventer des droits qu’il n’a pas.
Les deux modes de connexion
Section intitulée « Les deux modes de connexion »Chaque connecteur doit s’authentifier auprès du système cible. Il existe pour cela deux voies fondamentalement différentes, et ce choix décide de l’endroit où se situe la limite des droits.
| Authentification par personne | Compte de service | |
|---|---|---|
| Qui s’authentifie | chaque personne avec son propre compte | un seul compte technique pour tous |
| Qui connaît les droits | le système cible lui-même | le système cible ne connaît que le compte de service |
| Limite des droits | les droits de la personne dans le système cible | les autorisations dans Kisuno plus les droits du compte de service |
| Granularité | jusqu’au niveau du document et du champ | jusqu’au niveau du connecteur et de l’outil |
| Typique pour | espace de stockage de fichiers, gestion documentaire, stockage cloud | ERP, gestion commerciale, comptabilité, supervision |
Authentification par personne signifie ceci : à la première utilisation, la personne est envoyée vers la boîte de dialogue de connexion du système cible, y confirme l’accès, et le connecteur travaille dès lors avec son accès personnel. Qui n’a pas le droit de voir un dossier dans votre espace de stockage de fichiers ne le voit pas non plus dans le chat. Le système cible reste l’instance de référence, et vous n’avez pas à reconstruire les droits une deuxième fois.
Compte de service signifie ceci : le connecteur détient une clé unique et s’authentifie de la même manière pour tout le monde. Le système cible ne voit que ce seul compte et ne peut donc pas distinguer vos collaborateurs les uns des autres. La séparation doit alors se faire en amont, par les autorisations dans Kisuno.
Ce que coûte un connecteur
Section intitulée « Ce que coûte un connecteur »Un connecteur n’est pas gratuit, même quand il ne coûte rien. Le catalogue d’outils, c’est-à-dire le nom, la description et les paramètres de chaque outil, est transmis au modèle à chaque message. Il occupe donc en permanence de la place dans le contexte, et il est payé à chaque appel.
L’ordre de grandeur est considérable. Un connecteur volumineux peut facilement proposer plus de cent outils et occuper ainsi une part notable du contexte disponible avant même que la première question ne soit posée. Limité aux outils dont le cas d’usage a réellement besoin, le catalogue se réduit souvent à une petite fraction.
À cela s’ajoute un second effet : plus le catalogue contient d’outils aux noms voisins, plus le modèle se trompe souvent d’outil. Des outils peu nombreux et clairement nommés donnent donc non seulement des réponses moins coûteuses, mais aussi des réponses meilleures.