Chaindoc MCP Server (Beta): Turn Claude and ChatGPT Into Your AI Document Employee

Un serveur MCP est un petit programme qui permet à des assistants IA comme Claude Desktop ou ChatGPT 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, actuellement en bêta privée. Il transforme Claude Desktop, ChatGPT (via le OpenAI Apps SDK), Cursor et Zed en 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 Claude 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, ce qui est disponible en bêta et comment demander un accès. 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 testé en bêta, 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 en bêta 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 en bêta

• `chaindoc_create_document` , téléverse un fichier ou une variante de modèle et renvoie un identifiant de document et une URL de visualisation. L'IA s'en sert pour rédiger à partir d'un modèle d'après les instructions du chat.
• `chaindoc_create_signature_request` , envoie un document à signer à un ou plusieurs signataires, avec vérification KYC optionnelle, ordre de signature et calendrier de relances.
• `chaindoc_get_status` , renvoie l'état complet d'une demande de signature : qui a signé, qui est en attente, URL de signature pour les signataires actifs et journal d'audit à ce jour.
• `chaindoc_verify_document` , passe un document signé par Chaindoc dans la vérification anti-falsification et renvoie le certificat de signature, l'ancrage blockchain et le résultat d'intégrité.
• `chaindoc_list_documents` , liste paginée de documents avec filtres optionnels (statut, période, email du signataire). Permet à l'IA de retrouver le bon document avec une référence floue.
• `chaindoc_get_template` — récupère un modèle stocké et son schéma de variables, pour que l'IA sache exactement quels champs remplir.
• `chaindoc_subscribe_webhook` — enregistre un webhook pour les événements de statut, en renvoyant l'identifiant du webhook et le secret HMAC. Sert à mettre en place des notifications asynchrones que l'IA peut consulter plus tard.

Ce qui n'est pas encore en bêta

Les outils de facturation, l'orchestration KYC et l'OAuth multi-tenant figurent sur la feuille de route (voir la section ci-dessous). La bêta actuelle s'appuie sur une clé API, ce qui suffit pour des utilisateurs individuels et de petites équipes mais ne couvre pas encore le flux OAuth par utilisateur dont auront besoin les déploiements multi-tenant en production.

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 (Claude, ChatGPT, Cursor).

Une fois le serveur MCP configuré (voir la section accès bêta plus bas), le flux côté utilisateur se passe en conversation. Voici un exemple réel issu des tests bêta.

Étape 1 : ouvrir Claude Desktop et décrire ce dont vous avez besoin

Vous tapez : "Envoie le NDA prestataire à John Smith à john@acme.example, échéance de signature vendredi prochain, copie la clause de cession PI depuis notre modèle logiciel."

Étape 2 : Claude raisonne sur les outils à appeler

Claude appelle `chaindoc_get_template` pour récupérer votre modèle de NDA prestataire, identifie les emplacements variables (nom de la contrepartie, email, échéance, juridiction) et fusionne la clause de cession PI depuis votre bibliothèque standard. Il appelle ensuite `chaindoc_create_document` avec le modèle rempli.

Étape 3 : Claude met en place la demande de signature

Claude appelle `chaindoc_create_signature_request` avec l'email de John, l'échéance de signature et (en option) la vérification KYC. Il renvoie une confirmation : "Document rédigé depuis le modèle `Contractor NDA v3`, envoyé à john@acme.example, URL de signature active jusqu'à vendredi 9 mai à 23:59 UTC."

Étape 4 : Claude enregistre un webhook de statut

Claude appelle `chaindoc_subscribe_webhook` pour écouter l'événement `signature.completed`, vous recevrez ainsi une notification dans Claude quand John signe sans avoir à interroger vous-même. Tout le flux prend environ 60 secondes entre votre message initial et la mise en ligne de la demande de signature dans la boîte de John.

Étape 5 : vérification à l'achèvement

Quand John signe, le webhook se déclenche et Claude rapporte le résultat. Vous pouvez ensuite demander à Claude de vérifier la signature, et il appellera `chaindoc_verify_document` pour confirmer l'ancrage blockchain, le certificat de signature et le journal d'audit. La même vérification que vous feriez manuellement sur /verify-document, mais dans le chat où vous avez démarré.

Franchement, l'expérience varie selon le modèle d'IA. Claude Desktop est aujourd'hui la plus fluide parce qu'Anthropic a conçu MCP. ChatGPT via l'Apps SDK fonctionne bien mais avec un peu plus de latence. Cursor et Zed sont parfaits si vous vivez déjà dans un éditeur de code. Le protocole étant standardisé, l'expérience devrait converger entre clients avec le temps.

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é : la clé API (en bêta) ou le jeton OAuth utilisateur (en GA) 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 clés API peuvent être restreintes (lecture seule, écriture, admin), donc les utilisateurs bêta peuvent 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 (Claude Desktop, ChatGPT, Cursor, etc.) et quel outil a été appelé. Si un contrat a été envoyé par Claude pour votre compte, la trace montre "envoyé via MCP, client : claude-desktop, 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 la valeur juridique des signatures électroniques blockchain. Pour les contrôles d'accès au niveau équipe qui régissent qui peut connecter des clients IA à votre compte, voir /team-management.

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.

La bêta est sur invitation, avec des places limitées priorisées pour les clients Chaindoc actifs et les organisations à forte composante développeur. Les participants à la bêta bénéficient d'un accès gratuit jusqu'à la disponibilité générale, d'un support Slack dédié de l'équipe d'ingénierie et d'une ligne directe pour les demandes de fonctionnalités.

Trois manières de demander un accès

1. 1.
   Clients existants : connectez-vous à votre tableau de bord Chaindoc et cherchez la section "AI Agents" sous Paramètres. Le bouton bêta s'y trouve.
2. 2.
   Nouveaux évaluateurs : inscrivez-vous via /api-integration et cochez la case "MCP beta" sur le formulaire d'onboarding développeur.
3. 3.
   Demande directe : écrivez à beta@chaindoc.io avec votre cas d'usage (1-2 phrases), la taille de votre équipe et le client IA que vous voulez connecter (Claude Desktop, ChatGPT, Cursor, Zed). Nous répondons sous deux jours ouvrés.

Installation, une fois l'accès obtenu

La bêta est livrée sous forme de paquet npm. Après réception de votre clé API, ajoutez ce qui suit à votre configuration Claude Desktop (`~/Library/Application Support/Claude/claude_desktop_config.json` sous macOS, chemins équivalents sous Windows et Linux) :

Redémarrez Claude Desktop. L'icône 🔌 doit afficher "chaindoc" connecté avec sept outils disponibles. Le premier appel d'outil se termine en général en 2-3 secondes.

Pour Cursor, Zed et Windsurf, la configuration est similaire ; les instructions complètes arrivent avec votre invitation bêta. Le support ChatGPT via l'OpenAI Apps SDK est en test privé et sera déployé après la GA de Claude Desktop.

La bêta actuelle couvre la rédaction, la signature, la vérification et le suivi des contrats. Trois capacités sont en développement actif pour les phases bêta ultérieures et la disponibilité générale :

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" (Claude Desktop, ChatGPT, Cursor, 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, le bouton bêta 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, demandez l'accès bêta via /api-integration et dites-nous quel client IA vous souhaitez connecter.