Serveur MCP c'est quoi ? Ce qui change quand un agent IA envoie le contrat à signer

Serveur MCP c'est quoi, et en quoi diffère-t-il d'une API ? Une API est un ensemble de points d'accès sur lesquels un développeur écrit du code. Un serveur MCP est un petit programme posé sur cette API, qui décrit ses points d'accès comme des outils qu'un modèle d'IA trouve et appelle seul. La différence entre MCP et API tient en une ligne : l'API est pour votre code, le serveur MCP pour un agent. En signature électronique, cela décide qui choisit la prochaine étape. Avec l'API REST de Chaindoc, c'est votre code qui décide quand un contrat part. Avec le serveur MCP, c'est l'agent, dans les limites de sa clé. La signature ne passe jamais à l'agent.

Un serveur MCP, c'est le côté serveur du Model Context Protocol (MCP), un standard ouvert qu'Anthropic a publié le 25 novembre 2024 pour relier les applications d'IA à des outils et à des données extérieurs. En décembre 2025, le protocole est passé à l'Agentic AI Foundation, sous l'égide de la Linux Foundation : aucun éditeur de modèle n'en est plus propriétaire. La spécification en vigueur porte la date du 2026-07-28.

MCP distingue trois rôles. L'hôte est l'application d'IA avec laquelle vous parlez, le client est le connecteur à l'intérieur, et le serveur expose ce qu'un système extérieur sait faire, sous trois formes :

• Outils (tools) : des fonctions que le modèle peut appeler, par exemple « créer une demande de signature ».
• Ressources (resources) : des données que le modèle ou l'utilisateur peut lire, comme l'état d'un contrat.
• Les prompts, des tâches nommées qu'un utilisateur peut lancer.

Les messages sont du JSON-RPC 2.0. Un serveur tourne soit comme processus local que le client lance (transport stdio), soit derrière un point d'accès HTTP (Streamable HTTP).

Un serveur MCP est-il vraiment un serveur ? Parfois. Un serveur stdio est un processus sur votre poste, qui démarre et s'arrête avec votre client d'IA. Un serveur HTTP est un service que quelqu'un doit héberger.

Pourquoi « MCP ou API » est-il alors un faux choix ? Parce que presque tout serveur MCP utile enveloppe une API qui existe déjà. Celui de Chaindoc branche ses outils sur les mêmes points d'accès REST que votre backend appellerait. Vous ne choisissez pas l'un ou l'autre. Vous choisissez qui conduit : votre code ou un modèle.

Les points d'accès en dessous sont les mêmes. La différence entre MCP et API, c'est tout ce qui entoure l'appel, et cinq éléments apparaissent dès qu'un agent est l'appelant.

1. 1.
   Découverte. Votre code connaît l'API parce qu'un développeur a lu la documentation. Un client MCP demande au serveur sa liste d'outils (tools/list) à l'exécution et transmet noms, descriptions et schémas d'entrée au modèle. Si vous connaissez l'appel de fonctions (function calling), c'est la même idée dans un format commun : un même serveur fonctionne dans tous les clients MCP.
2. 2.
   Qui choisit l'appel. Dans une intégration par API, la séquence est écrite dans le code et se déroule toujours pareil. Avec MCP, le modèle choisit l'outil et remplit les arguments à partir de votre phrase : la même demande peut suivre deux chemins différents à deux jours d'écart.
3. 3.
   Les erreurs reviennent au modèle. La spécification distingue les erreurs de protocole des erreurs d'exécution d'un outil, et ces dernières sont faites pour atteindre le modèle, qui peut corriger un argument et réessayer. Un backend, lui, l'aurait consignée et se serait arrêté.
4. 4.
   Les identifiants vivent dans un fichier de configuration. Un serveur stdio lit sa clé dans une variable d'environnement que votre client d'IA lui transmet. Qui peut modifier ce fichier décide de ce que l'agent a le droit de faire.
5. 5.
   L'approbation relève du client. La page des outils de la spécification MCP recommande (SHOULD) qu'un humain puisse intervenir sur les appels d'outils et les refuser, et que les clients demandent confirmation pour les opérations sensibles. Un appel venu de votre backend n'a pas cette étape, sauf si vous la construisez.

Soyons francs : le point deux est celui qui compte pour des contrats. Un script qui envoie un NDA envoie exactement le NDA pour lequel il a été écrit. Un agent envoie ce qu'il a compris de votre intention. Pour un document que quelqu'un va signer, cet écart appelle un garde-fou.

Le serveur MCP de Chaindoc est open source. Le code est sur GitHub sous licence MIT, et le paquet s'appelle @chaindoc_io/mcp-server sur npm, en version 0.2.0 à notre vérification du 14 octobre 2026. La plupart des outils correspondent à un seul point d'accès REST et renvoient le résultat sous une forme que le modèle sait lire.

Les outils, par groupe

Les tableaux principaux du README listent 35 outils répartis en dix groupes :

• Documents : créer, modifier, régler les droits d'accès, vérifier une version, lire son statut de vérification.
• Signatures : créer une demande, lire son statut, lister vos demandes, et signer.
• Les contrats, le groupe le plus long : créer, lister, lire, envoyer, annuler, résilier, lire l'activité, joindre une configuration de paiement.
• Factures et transactions pour la facturation à partir d'un contrat signé : créer, envoyer, encaisser, marquer comme payé, lister les paiements.
• Modèles : en tirer un document ou un contrat, ou les envoyer directement à la signature.
• Le téléversement de médias, les sessions de signature intégrées, deux contrôles de compte et un vérificateur de webhook.

La version 0.2.0 a ajouté la recherche, les versions, les relances, les annulations, le téléchargement du fichier signé et de son certificat, et le cycle de vie des modèles.

Ressources et prompts

Des ressources en lecture seule, comme chaindoc://contracts/{id}/status, côtoient des prompts nommés, tel que prepare_signature_request, qui guident le modèle dans une tâche plus longue.

Il y a deux choses qu'il ne fait pas. Il n'enregistre pas de webhooks : ils se règlent par clé API dans le tableau de bord, et l'outil webhook se contente de vérifier un événement que vous avez déjà reçu. Et Chaindoc n'héberge aucun point d'accès : vous le lancez en stdio ou vous hébergez vous-même le mode HTTP.

La vérification est la partie propre à Chaindoc. Le serveur calcule l'empreinte d'un fichier à son téléversement ; quand une version est publiée, cette empreinte est inscrite sur la blockchain, et la preuve de chaque signataire est enregistrée à la fin de la signature. Les outils de vérification comparent une version à cet enregistrement : un agent peut ainsi répondre à « est-ce bien le fichier qui a été signé ? » sans que personne n'ouvre l'application.

Il n'existe pas de clé API MCP distincte. Le serveur fonctionne avec une clé API Chaindoc ordinaire, et les clés se créent sur l'offre Business. Les comptes Team peuvent demander l'accès à l'API ; Free et Personal ne peuvent pas créer de clés, et les webhooks sont réservés à Business.

Deux limites façonnent le comportement d'un agent. Le serveur se bride à 10 requêtes par minute par défaut, la limite du guide de l'API de Chaindoc : un agent qui parcourt cinquante documents est donc volontairement lent. Et son trafic passe par votre compte comme tout appel d'API, si bien que les demandes qu'il envoie sont prélevées sur le même quota mensuel de signatures. Consultez les tarifs actuels avant de le laisser envoyer en masse.

En bref : un agent peut appuyer sur le bouton, mais le droit ne le traite jamais comme le signataire. Le signataire, c'est celui pour qui l'agent agit, et c'est là que s'arrêtent la plupart des inquiétudes sur les contrats conclus avec l'IA.

Aux États-Unis : ESIGN et UETA

ESIGN définit la signature électronique comme un son, un symbole ou un procédé exécuté ou adopté par une personne avec l'intention de signer (15 U.S.C. § 7006(5)) : l'intention appartient à une personne. Pour les logiciels, 15 U.S.C. § 7001(h) dit qu'un contrat ne perd pas ses effets parce qu'un agent électronique a contribué à le former, tant que son action est juridiquement imputable à la personne à lier. L'UETA, adopté par tous les États sauf New York, ajoute que la signature est attribuée à celui dont c'était l'acte (§ 9, par exemple par la procédure de sécurité employée : avec un serveur MCP, la clé API), qu'un contrat peut se former entre agents sans relecture humaine (§ 14), et que celui qui a traité avec votre agent sans pouvoir corriger une erreur peut écarter l'enregistrement s'il agit vite (§ 10). Un circuit sans relecture est un risque que vous avez construit vous-même.

En France et dans l'UE : eIDAS, Code civil et règlement sur l'IA

Le règlement (UE) n° 910/2014 (eIDAS) est plus strict sur le papier. L'article 3, point 9, définit le signataire comme « une personne physique qui crée une signature électronique » : un modèle ne peut donc pas l'être. Une entreprise qui veut marquer des documents sans qu'une personne se tienne derrière chacun dispose d'un autre outil, le cachet électronique, créé par une personne morale selon l'article 3, point 24. Notre guide sur les cachets électroniques pour les entreprises explique quand il convient.

Le droit français arrive au même résultat. Selon l'article 1367 du Code civil, la signature identifie son auteur et manifeste son consentement ; quand elle est électronique, elle repose sur un procédé fiable d'identification garantissant son lien avec l'acte, dont la fiabilité est présumée dans les conditions fixées par le décret n° 2017-1416. L'article 1366 subordonne la force probante de l'écrit électronique à l'identification dûment établie de la personne dont il émane. Dans les deux cas, il faut une personne identifiable. Un agent IA n'a pas de personnalité juridique : il n'est pas un représentant au sens des articles 1153 et 1154, mais le résultat est proche. Ce que l'agent accomplit dans la limite de ce que vous lui avez permis, c'est vous qu'il engage, et avec un serveur MCP cette limite est le périmètre de la clé API.

Un mot sur le règlement (UE) 2024/1689, le règlement sur l'IA. Son article 14 exige, pour les systèmes d'IA à haut risque, que des personnes physiques puissent les superviser efficacement et décider de ne pas les utiliser ou d'ignorer leur sortie. Qu'un usage soit à haut risque dépend de sa finalité (annexe III), et un agent qui envoie des NDA n'y entre en général pas. La logique vaut pourtant ici : un humain doit pouvoir reprendre la main.

Pour un circuit MCP, la ligne pratique est simple. Laissez l'agent préparer, envoyer, relancer et vérifier. Gardez la signature à la personne dont elle consigne la volonté. Que vous confiiez à un agent précis la signature d'un type de document précis, décidez-le par écrit et en connaissance de cause, jamais par défaut. Prenez ceci comme un cadre, pas comme un conseil juridique sur votre contrat.

Quatre points d'un circuit de signature méritent un humain. Le milieu, ennuyeux, n'en fait pas partie.

• Avant tout envoi. La confirmation de votre client devrait couvrir chaque outil qui envoie, signe, annule, résilie ou encaisse. Les appels en lecture seule peuvent tourner sans demander.
• Les signataires et leur ordre. Une demande créée par l'agent invite tous les signataires en même temps. Si l'ordre compte (un responsable valide avant que le client signe), c'est un circuit d'approbation que vous réglez dans l'application Chaindoc sur l'offre Business, pas quelque chose que l'agent improvise.
• L'identité, quand l'enjeu l'exige. Le KYC des signataires est facultatif, via la vérification d'identité de Chaindoc, avec un quota mensuel selon l'offre. Décidez-le par type de contrat, ne le laissez pas au modèle.
• Ce que l'agent lit. Un texte peut porter des instructions que vous n'avez pas écrites : une ligne dans un PDF téléversé, une note dans une fiche CRM. La spécification MCP traite pour cette raison les annotations d'outils venant d'un serveur auquel vous ne faites pas confiance comme non fiables.

Qu'est-ce qui peut tourner sans surveillance ? Les consultations de statut, les relances auprès de personnes qui ont déjà le document, la vérification d'un fichier par rapport à son enregistrement sur la blockchain. Chaque document garde sa propre piste d'audit : même les appels sans surveillance laissent une trace que vous pouvez relire.

DocuSign a annoncé le 4 septembre 2026 que son serveur MCP serait disponible pour tous le 30 septembre, appelable depuis Claude, ChatGPT, Gemini, Copilot, Slack et tout client MCP. DocuSign l'héberge, et la connexion passe par une authentification OAuth et un écran de consentement plutôt que par une clé collée dans un fichier de configuration. C'est un vrai avantage pour une entreprise qui ne veut pas de clés API sur des portables, et Chaindoc ne propose pas de point d'accès hébergé aujourd'hui.

Sur l'axe MCP vs API, les deux se ressemblent : chaque serveur enveloppe l'API de son éditeur. Pour le contrôle, l'échange tourne pourtant dans l'autre sens. Le serveur de Chaindoc est du code sous licence MIT que vous pouvez lire, dupliquer et héberger dans votre propre réseau, et ses outils atteignent l'enregistrement de vérification sur la blockchain en plus de la signature. Si vous comparez une connexion MCP DocuSign à celle de Chaindoc pour un agent, posez trois questions pratiques : qui détient l'identifiant, où tourne le serveur, et quelles actions l'agent peut-il accomplir sans l'approbation d'un humain ?

Utilisez l'API quand le flux est fixe. Une affaire passe à « gagnée », un contrat part d'un modèle, un webhook met à jour le CRM dès la signature. C'est du code, il doit se comporter pareil à chaque fois, et un agent n'y ajoute que de la variance. Si vous voulez de l'automatisation documentaire par IA dans un flux fixe, appelez un modèle depuis votre propre code et laissez l'API faire l'envoi. Notre comparatif des API de signature électronique dit ce qu'il faut vérifier de ce côté.

Utilisez le serveur MCP quand la demande change à chaque fois et qu'une personne est de toute façon dans la conversation : « envoie la lettre de mission aux deux personnes de l'appel d'hier », « quels NDA du mois dernier sont encore non signés ? », « ce PDF est-il la version que nous avons signée ? ». C'est pénible à scripter et facile à dire. Un exemple de cabinet comptable : l'agent prépare et envoie les lettres de mission, et c'est le dirigeant du client qui signe lui-même, par le lien, sous son nom.

La plupart des équipes finissent avec les deux, sur des clés séparées, et c'est la réponse honnête à la question serveur MCP ou API. L'API exécute ce que vous avez déjà décidé. L'agent s'occupe de ce que vous n'avez pas encore décidé. Et pour qui se demandait serveur MCP c'est quoi : c'est la couche qui laisse un agent se servir de l'API que vous avez déjà. Dans les deux cas, la signature reste à une personne.