Chaindoc MCP Server : transformez n'importe quel assistant IA en employé documentaire

Un serveur MCP est un petit programme qui permet à un assistant IA d'appeler des services externes comme s'il s'agissait d'outils intégrés. Le Model Context Protocol (MCP) a été introduit par Anthropic en novembre 2024 en tant que standard ouvert pour relier les agents IA aux systèmes du monde réel. Au lieu de dire à l'IA "explique-moi comment fonctionne Chaindoc", tu dis "envoie ce NDA à John pour signature" et l'IA l'exécute directement via le serveur MCP, sans copier-coller, sans connexion, sans changement d'outil.

Chaindoc MCP est le premier serveur MCP natif e-signature, et il est disponible pour tous. Quel que soit l'assistant que vous utilisez déjà, il devient une interface opérationnelle pour tout le cycle de vie d'un contrat : rédaction, signature, vérification, suivi. Honnêtement, la première fois qu'on voit un assistant rédiger et envoyer un contrat à votre place, ça donne l'impression de tricher.

Le basculement est réel. Selon le rapport Salesforce State of Sales 2024, les commerciaux ne passent que 28% de leur semaine à vendre activement ; le reste est absorbé par l'administratif comme la rédaction de contrats, la relance de documents et les mises à jour CRM. Les employés IA bâtis sur MCP peuvent réduire l'essentiel de ces 72% à de simples instructions de chat. Les recherches d'Aberdeen Group montrent que les organisations utilisant des workflows e-signature concluent des contrats 80% plus vite et traitent 22,6 propositions par commercial et par mois, contre 10,4 avec des workflows manuels. Combinez ces gains avec un agent IA qui prend la main de bout en bout, et le plafond de productivité monte sensiblement.

Ce guide explique ce que fait le Chaindoc MCP server, en quoi il diffère d'une intégration API classique, quels outils il expose et comment le connecter. Pour le contexte d'intégration plus large, voir notre page API REST pour la signature électronique et l'automatisation documentaire ainsi que notre guide existant sur l'intégration CRM Chaindoc et Pipedrive.

Un employé IA, dans ce contexte, n'est pas un chatbot qui se fait passer pour une personne. C'est un agent IA doté d'un ensemble précis d'outils et autorisé à les utiliser pour vous. Le protocole MCP donne à l'IA trois choses qu'elle n'avait pas avant : un répertoire d'outils disponibles (opérations Chaindoc comme "créer un document" ou "vérifier une signature"), un moyen structuré de les appeler et un chemin pour relire les résultats afin de planifier l'étape suivante.

Pensez à la façon dont un employé humain traite une tâche contractuelle. Vous lui envoyez un mail "envoie le NDA à John, copie nos clauses PI standard, relance s'il n'a pas signé sous une semaine". Il ouvre Chaindoc, retrouve le modèle de NDA, le remplit, l'envoie, place un rappel calendrier pour la relance et vérifie le statut le jour de l'échéance. Chacune de ces étapes correspond à un outil Chaindoc MCP : chaindoc_create_document, chaindoc_create_signature_request, chaindoc_get_status, chaindoc_subscribe_webhook. L'agent IA raisonne sur les outils à appeler, dans quel ordre, et s'adapte à ce que chaque étape lui renvoie.

Ce qui change pour vous, l'humain :

• Vous arrêtez d'ouvrir 14 onglets de navigateur pour le travail contractuel. La plupart des opérations passent dans une seule interface de chat.
• L'agent IA gère le milieu ennuyeux (remplir des modèles, surveiller les signatures, envoyer des relances) ; vous n'intervenez qu'au début (intention) et à la fin (revue).
• Les pistes d'audit deviennent plus solides, pas plus faibles, parce que chaque action de l'IA est enregistrée par Chaindoc de la même façon qu'une action humaine, avec le même ancrage blockchain décrit dans notre guide de conformité du journal d'audit.

À noter franchement : les agents IA font des erreurs. Ils choisissent parfois le mauvais modèle, comptent mal les signataires ou envoient au mauvais email face à une instruction ambiguë. Le serveur MCP renvoie des messages d'erreur complets, donc l'IA repère souvent ses propres erreurs en cours de tâche, mais une étape de revue humaine reste recommandée pour les contrats à forts enjeux.

La plupart des premiers serveurs MCP relient les agents IA à des données en lecture seule : faire une recherche web, interroger une base, lire un fichier. La signature électronique est différente parce que c'est ce workflow rare où la valeur ne se trouve pas dans la récupération mais dans l'action. L'IA ne se contente pas de vous parler d'un contrat ; elle l'envoie. Cela change le calcul de productivité d'un ordre de grandeur entier.

Trois raisons pour lesquelles la signature électronique colle particulièrement bien à MCP :

1. 1.
   Actions discrètes et bien définies. Les opérations contractuelles se décomposent en primitives propres (créer, envoyer, signer, vérifier, statut, lister). Les agents IA savent choisir la bonne primitive face à une instruction ; ils sont plus faibles quand il s'agit d'improviser des workflows multi-étapes flous. Les opérations e-signature sont précisément le genre de chose qu'on décrirait à un junior en une phrase.
2. 2.
   Rigueur élevée du journal d'audit. La plupart des workflows touchés par des agents IA ont une provenance fragile. L'agent a-t-il vraiment envoyé ce mail ? Les données étaient-elles propres ? Avec Chaindoc, chaque action de l'IA atterrit dans un journal d'audit infalsifiable ancré sur une blockchain publique, le même enregistrement qu'un utilisateur humain produirait. Cela rend les contrats pilotés par IA conformes par défaut pour ESIGN, eIDAS et SOX ; voir notre guide journal d'audit et preuve juridique.
3. 3.
   Longue traîne de variantes contractuelles. Une entreprise type gère des dizaines de types de contrats (NDA, MSA, SOW, accords fournisseurs, contrats de travail, contrats de prestation). Chacun a de légères variations selon la juridiction, le secteur et la contrepartie. Les agents IA gèrent bien cette variabilité parce qu'ils raisonnent sur des modèles et des clauses ; l'automatisation à base de règles ne le peut pas.

Pour des scénarios contractuels précis où Chaindoc MCP est utilisé, voir nos articles existants sur le NDA prestataire pour éditeurs de logiciels, le guide du formulaire W-9 pour les indépendants et la classification indépendant vs salarié.

Le Chaindoc MCP server expose sept outils qui couvrent tout le cycle de vie d'un contrat. Chaque outil correspond à un endpoint REST API précis de Chaindoc, la couche MCP gérant l'authentification, le parsing de la réponse et le contexte d'erreur pour que l'agent IA récupère quelque chose sur quoi il peut réellement raisonner.

Outils disponibles

Authentification

L'accès passe par OAuth 2.0 avec des jetons par utilisateur : chaque action se rattache à un compte nommé et les déploiements multi-tenant fonctionnent sans clé partagée. La facturation et l'orchestration KYC sont livrées avec les outils contractuels.

Si vous avez déjà intégré Chaindoc via l'API REST et les SDK, la question est légitime : pourquoi ajouter une nouvelle couche ? La réponse, c'est que MCP n'est pas un remplacement de l'API ; c'est une surface différente pour un consommateur différent. Les intégrations API classiques sont écrites pour du code (un service backend, un plugin CRM). MCP est écrit pour des agents IA, quel que soit le modèle derrière.

Chaque action menée par un agent IA via le serveur MCP passe par le même backend Chaindoc qui traite les actions humaines. Pas de chemin parallèle, pas de journalisation distincte, pas de mode "contournement IA". Le journal d'audit capture les sept champs requis décrits dans notre guide de conformité du journal d'audit, avec un ajout : la session de l'agent IA est marquée pour que vous voyiez quelles actions ont été lancées par une IA et lesquelles par un humain.

Concrètement :

• Identité : le jeton OAuth utilisateur identifie le compte humain pour le compte duquel l'IA agit. Chaque action est traçable jusqu'à une vraie personne, pas une identité générique "agent IA".
• Authentification : les portées OAuth (lecture seule, écriture, admin) permettent d'accorder le minimum d'accès nécessaire à des clients IA spécifiques.
• Provenance des actions : le journal enregistre que l'action provient de MCP, plus quel client s'est connecté et quel outil a été appelé. Si un agent a envoyé un contrat pour votre compte, la trace montre "envoyé via MCP, client : , outil : chaindoc_create_signature_request, utilisateur : alex@chaindoc.example".
• Inviolabilité : chaque entrée d'audit est chaînée par hachage et ancrée sur une blockchain publique, exactement comme les actions humaines directes. Les contrats pilotés par IA ne sont pas moins défendables que ceux envoyés manuellement ; à certains égards, ils le sont davantage parce que l'appel d'outil structuré est conservé aux côtés de l'instruction chat humaine.

Pour les cadres de conformité sous-jacents, voir notre article sur la conformité de la signature numérique avec eIDAS, GDPR et NIST et sur l'ancrage des signatures sur une blockchain. Pour les contrôles d'accès au niveau équipe qui régissent qui peut connecter des clients IA à votre compte, voir notre page de gestion d'équipe.

Au mois de mai 2026, aucun éditeur majeur de signature électronique n'a lancé un serveur MCP public. Les comparaisons les plus proches sont des annonces de fonctionnalités IA dans les produits existants (Docusign IAM et Docusign AI, les outils de revue IA d'Ironclad), mais aucun n'expose ces capacités à des agents IA externes via un standard ouvert. Le tableau ci-dessous résume le paysage.

Le serveur MCP est ouvert à tous les comptes Chaindoc. Pas d'invitation, pas de liste d'attente. Connectez-le depuis la section "AI Agents" dans les Paramètres de votre tableau de bord, ou depuis notre page d'intégration API.

Installation

Le serveur est distribué comme paquet npm et s'authentifie en OAuth 2.0 : aucune clé ne se retrouve dans votre configuration. Ajoutez l'entrée Chaindoc au fichier de configuration MCP de votre client. Le point à retenir : le bloc ci-dessous est identique dans tous les clients compatibles MCP, seul le chemin du fichier change.

{
  "mcpServers": {
    "chaindoc": {
      "command": "npx",
      "args": ["-y", "@chaindoc/mcp-server"]
    }
  }
}

Redémarrez le client. Il doit maintenant lister chaindoc avec 7 outils disponibles, et le premier appel d'outil prend en général 2 à 3 secondes. Les clients qui n'exécutent pas de processus local passent par le point de terminaison HTTP hébergé ; les chemins par client et l'URL du point de terminaison sont sur la page d'intégration API.

À la rédaction, la signature, la vérification et le suivi des contrats s’ajoutent la facturation et l’orchestration KYC, désormais livrées. Une capacité reste à venir :

Automatisation de la facturation

Un outil chaindoc_create_invoice qui génère une facture liée à un contrat signé, avec conditions de paiement, lignes et instructions Stripe / virement. L'outil lit le calendrier de paiement du contrat, génère la facture à la bonne date et l'envoie (en option) via le journal d'audit Chaindoc existant. Voir notre article existant sur l'automatisation des paiements et facturations liés aux contrats pour le workflow humain sur lequel cela s'appuie, ainsi que l'analyse approfondie sur l'automatisation de la facturation après signature électronique.

Orchestration KYC

Un outil chaindoc_request_kyc qui déclenche la vérification d'identité d'un signataire avant qu'il ne signe. L'agent IA peut raisonner sur les signataires nécessitant un KYC complet (contrats à fort enjeu, secteurs régulés) versus une vérification légère (NDA standards) et configurer la demande de signature en conséquence. Aujourd'hui, le KYC est configuré au niveau de la requête par des humains ; l'objectif est de laisser l'IA prendre cette décision.

Workflows multi-agents

Plus loin dans le temps, MCP supporte la communication entre agents. Un serveur Chaindoc MCP peut donc appeler un serveur MCP CRM (HubSpot, Salesforce), un serveur MCP calendrier (Google, Outlook) ou un serveur MCP de paiement (Stripe). Un contrat signé peut déclencher une mise à jour CRM, un rappel calendrier et l'émission d'une facture, le tout coordonné par l'agent IA plutôt que par des webhooks codés en dur. C'est l'architecture qui fait passer l'IA d'un outil d'écriture à une véritable couche d'opérations.

Les fonctionnalités IA collées à des produits existants sont partout en ce moment. Rédaction automatique de clauses, redlining intelligent, résumés de revue de contrat : chaque éditeur historique en livre. Elles sont utiles, mais ce sont des fonctionnalités. Elles vivent à l'intérieur de l'interface de l'éditeur et exigent qu'un humain pilote le workflow.

La signature électronique IA-native est structurellement différente. L'unité de valeur n'est pas "que peut faire notre produit pour vous" mais "que peut faire votre agent IA pour votre compte, où qu'il vive" (un assistant de bureau, une appli de chat, un éditeur de code, votre propre client sur mesure). Cela change les critères d'achat. La vitesse d'exécution d'un contrat cesse de se mesurer en minutes par signature et commence à se mesurer en instructions de chat par résultat. Les journaux d'audit cessent d'être un dispositif de conformité défensif et deviennent une condition préalable pour faire confiance aux workflows pilotés par IA.

Chaindoc parie tôt que cette catégorie devient dominante sur les 24 prochains mois. Le serveur MCP est le premier pas concret. Si vous êtes client existant, la section « AI Agents » est dans votre tableau de bord dès maintenant. Si vous évaluez des outils de signature électronique avec l'IA sur la feuille de route, commencez par notre page d'intégration API.